wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: Wine license change
by Roger Fujii 14 Feb '02

14 Feb '02

Ian Schmidt <ischmidt(a)cfl.rr.com> wrote: > On Wednesday 13 February 2002 01:28 pm, Brett Glass wrote: > > > business. So, if the company was profitable at all, it was just squeaking > > through. (And $20M in annual revenues after ten years of existence is no > > one's idea of "good money" for a company that size.) > Sure, but they did stay in business for 10 years and were in no reported > danger of going out of it. Not bad by any metric for a license you can't > make money off of ;-) but I wouldn't use the word 'thrive' to describe a company that is barely profitable (which is what the original poster used). It's not my opinion (and probably not even Brent's) that it is *impossible* to eek out a living. I think the point is that it is DIFFICULT to do so. I don't mind hearing GPL advocates say that it is more socially desirable, equitable... (not that I necessarily agree with it, but it is a valid point of view). But I don't see any evidence that it is helpful to commerical entities (which is some of the reasoning behind a license switch). > Anyway to steer back toward my point, can you name any pure-BSD/X11 players > that are profitable? well, depends on what you mean by "pure". X.org presumably is. Usually, the business model for this is a common group that publishes a reference port for other vendors, which can build propriatary value adds on top of the reference port. Ximian's 'mono' model is based on this logic (I think). A better way of looking at it is companies that have 'free' licenses that are NOT *GPL. sendmail.org has a modified license and they seem to be doing ok. Apache would a another one. > See, I think there's a more basic problem, which is that no known business > model works really well for source-available software when the software is > targeted at technically savvy users. Things like the Aladdin license are a > nice compromise, but ultimately won't lead to Microsoft levels of > profitability. No one here is advocating for M$ levels of profitability (at least, not for wine :) ), but the point is correct. The problem is the *GPL highly limits what models can be tried. > The solution as I see it is for GPL/BSD/whatever programmers to actually > cough up something non-technical users not only would use, but would > *prefer*. *Then* support and selling binaries becomes a worthwhile > proposition. you cannot sell *gpl binaries. You can sell the media, but not the content. Think sun has a good idea with dual licensing and having assignment of the copyright. This allows them to change the license so that they can make a productized version. > Codeweavers is leaning in this direction with CrossOver - even > though you could probably duplicate their work eventually with the current > Wine CVS, the installer and overall ease of use make it well worth paying for > if you value your time at all (I bought it and I love it, if you can't tell). Isn't the whole reason this discussion was opened up again was because they want to release LGPLed code (the inference was that they thought that their code released under X11/BSD would harm them materially). The obvious extrapolation is that a more complete wine under X11/BSD is not in codeweaver's interest, regardless of where the code came from. > To put this back on topic, I don't see any immediate benefits from a LGPL > license. If we knew what the threat to Wine Jeremy hinted at was, it might > make for a more informed discussion. I also liked Gav's idea about WineCorp > a lot as a compromise, and I'd love to see more dicussion of that and less > licensing flaming. MORE?! AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!! :) -r

5 6

[patch] - add several structs to ntddk.h
by Ron Gage 14 Feb '02

14 Feb '02

Hi folks... I just sent the following patch to wine-patches. I thought it would be a good idea to let you folks beat it up before someone actually commit's it to CVS... The patch adds several struct definations to include/ntddk.h to assist getting the NtQuerySystemInformation routine working. It also adds several enumerations for the System Information Class. By far, these are not complete, and I can only hope that they are accurate. One thing you may notice is that HANDLEINFO and THREADINFO have been defined. I believe there is already a less complete defination of the THREADINFO struct (called THREAD_INFO) in the code already. This has been left untouched so that this patch minimizes the potential side effects. These are untested in that I have not tried to recompile with these changes in place. My only concern: do FILETIME and LARGE_INTEGER data types exist? Google is your friend - use it wisely! -- Ron Gage - Owner, Linux Network Services - Saginaw, Michigan - 989-274-8088 Your one-stop source for Reliable, Secure and Affordable Networking Solutions --- ntddk.h~ Wed Dec 19 14:16:29 2001 +++ ntddk.h Thu Feb 14 07:32:31 2002 @@ -147,6 +147,21 @@ MaxThreadInfoClass } THREADINFOCLASS; +typedef struct { +/* This is used by NtQuerySystemInformation */ + FILETIME ftCreationTime; + DWORD dwUnknown1; + DWORD dwStartAddress; + DWORD dwOwningPID; + DWORD dwThreadID; + DWORD dwCurrentPriority; + DWORD dwBasePriority; + DWORD dwContextSwitches; + DWORD dwThreadState; + DWORD dwWaitReason; + DWORD dwUnknown2[5]; +} THREADINFO, *PTHREADINFO; + /* file information */ typedef enum _FILE_INFORMATION_CLASS { @@ -220,12 +235,124 @@ /* system information */ typedef enum SYSTEM_INFORMATION_CLASS -{ Unknown1 = 1, - Unknown2, - Unknown3, +{ SystemBasicInformation = 0, + Unknown1, + SystemPerformanceInformation, + SystemTimeInformation, Unknown4, - SystemPerformanceInformation + SystemProcessInformation, + Unknown6, + Unknown7, + Unknown8, + Unknown9, + Unknown10, + SystemDriverInformation, + Unknown12, + Unknown13, + Unknown14, + Unknown15, + SystemHandleList, + Unknown17, + Unknown18, + Unknown19, + Unknown20, + SystemCacheInformation + } SYSTEM_INFORMATION_CLASS, *PSYSTEM_INFORMATION_CLASS; + +typedef struct { +/* System Information Class 0x00 */ + DWORD dwUnknown1; + ULONG uKeMaximumIncrement; + ULONG uPageSize; + ULONG uMmNumberOfPhysicalPages; + ULONG uMmLowestPhysicalPage; + ULONG uMmHighestPhysicalPage; + ULONG uAllocationGranularity; + PVOID pLowestUserAddress; + PVOID pMmHighestUserAddress; + ULONG uKeActiveProcessors; + BYTE bKeNumberProcessors; + BYTE bUnknown2; + WORD wUnknown3; +} SYSTEM_BASIC_INFORMATION; + +typedef struct { +/* System Information Class 0x02 */ + LARGE_INTEGER liIdleTime; + DWORD dwSpare[76]; +} SYSTEM_PERFORMANCE_INFORMATION; + +typedef struct { +/* System Information Class 0x03 */ + LARGE_INTEGER liKeBootTime; + LARGE_INTEGER liKeSystemTime; + LARGE_INTEGER liExpTimeZoneBias; + ULONG uCurrentTimeZoneId; + DWORD dwReserved; +} SYSTEM_TIME_INFORMATION; + +typedef struct { +/* System Information Class 0x05 */ + DWORD dwOffset; + DWORD dwThreadCount; + DWORD dwUnknown1[6]; + FILETIME ftCreationTime; + DWORD dwUnknown2[5]; + WCHAR* pszProcessName; + DWORD dwBasePriority; + DWORD dwProcessID; + DWORD dwParentProcessID; + DWORD dwHandleCount; + DWORD dwUnknown3; + DWORD dwUnknown4; + DWORD dwVirtualBytesPeak; + DWORD dwVirtualBytes; + DWORD dwPageFaults; + DWORD dwWorkingSetPeak; + DWORD dwWorkingSet; + DWORD dwUnknown5; + DWORD dwPagedPool; + DWORD dwUnknown6; + DWORD dwNonPagedPool; + DWORD dwPageFileBytesPeak; + DWORD dwPrivateBytes; + DWORD dwPageFileBytes; + DWORD dwUnknown7[4]; + THREADINFO ti[0]; +} SYSTEM_PROCESS_INFORMATION; + +typedef struct { +/* System Information Class 0x0b */ + PVOID pvAddress; + DWORD dwUnknown1; + DWORD dwUnknown2; + DWORD dwEntryIndex + DWORD dwUnknown3; + char szName[MAX_PATH + 1]; +} SYSTEM_DRIVER_INFORMATION; + +typedef struct { +/* System Information Class 0x10 */ + USHORT dwPID; + USHORT dwCreatorBackTraceIndex; + BYTE bObjectType; + BYTE bHandleAttributes; + USHORT usHandleOffset; + DWORD dwKeObject; + ULONG ulGrantedAccess; +} HANDLEINFO, *PHANDLEINFO; + + +typedef struct { +/* System Information Class 0x15 */ + ULONG CurrentSize; + ULONG PeakSize; + ULONG PageFaultCount; + ULONG MinimumWorkingSet; + ULONG MaximumWorkingSet; + ULONG unused[4]; +} SYSTEM_CACHE_INFORMATION; /* reading coffee grounds... */ typedef struct _THREAD_INFO ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

1 0

Request for wine-license list
by Uwe Bonnes 14 Feb '02

14 Feb '02

Hallo, I repeat may proposal, as the license wars will probably rage on: Let us create a wine-license mailing list and discuss licenses there. Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: Licensing response and an idea
by Roger Fujii 14 Feb '02

14 Feb '02

Tony Bryant <brd(a)paradise.net.nz> wrote: > > The (L)GPL is thus extremely discriminatory against programmers. > It just forces a different way of making money - charging for your > time, not charging for your IP. Revolutionary concept - charge for > work done. Doesn't exactly fit with the bill gates of this world, > but for small programmers like myself, most of my work is one-offs > anyway. what is so "revolutionary" about that idea?! Consulting services where they charge by the hour has been around for quite a while. The PROBLEM with this model is that it forces all the costs up front, thus making it unafforable for people without a large budget. A simple example goes as follows: Let's say I want a device driver for a scanner. I find a relatively proficient programmer and s/he said it's about $1000 worth of work. Under the *GPL model, I have 3 choices: 1) Pay him/her $1000 for a driver for a $200 scanner 2) Go out and play salesman and find others to defer the cost. 3) Write it myself (and for the sake of argument right now, let's say this isn't an option) Under the normal commercial route, you can make up other options that try to keep the per user cost down. > (L)GPL just doesn't suit business people. i.e. those expecting to sit > back and watch the money roll in. I really hate it when things are characterized in this fashion because it shows a fundamental misunderstanding of how normal businesses work. Companies that don't have monopoly power survives by accepting risks and deriving benefit from their success(es). If I spend $10M developing a software project, I'm not "sitting back and watching the money roll in" when the product starts selling. If you're good, you'll have more money at the end than when you started. If not, you'll fail. This is the main concept behind "free enterprise". > One has to wonder why it matters what other people do with Wine. Wasn't > Wine developed because we wanted to run some windoze apps on linux? > Who really cares what codeweavers, transgaming etc do to it. Just as > long as I can still run my windows apps on linux, I'm happy. If lindows > sells a few copies of what is effectively free, what skin is it off > our noses? I was wondering that too, and have come to the following conclusion: Either 1) They believe like the FSF and don't think propriatary software should exist 2) Are not comfortable with the idea of giving up code freely for the good of all. 3) Misunderstand the effects of the *GPL 4) Expect to be paid in other people's work. -r

1 0

Re: Wine license change
by Claus Fischer 14 Feb '02

14 Feb '02

Issue 1: On corporations' dealing with GPL Basically all big companies in the software industry know about the GPL. It's a known quantity. Even if it may not have been publicly enforced, companies have spent lawyers' time finding out the core implications. They know its `spirit', and they mostly equate it with its spirit, i.e. they deal with GPL code according to its spirit. This is true whether they are pro or contra GPL in a particular situation; hardly have big companies ever tried to sneak around it. (Or was there some good enforcement?) GPL'ing code may not fit everybody's needs but it can make a lot of sense for corporations whose core business is not Wine. Imagine some big hardware vendor (Intel), software vendor (IBM), bank, fortune 500 company, considering the use of Wine for some internal or external product. They don't want to get into the Wine business at all. It's much easier for them to hire external consultants, Codeweavers, whoever, to implement some stuff for them and give back to the public if they don't run the risk of a) the competition taking the code b) the competition improving it c) the competition getting better products d) the competition not giving anything back Even if the causal connection between the little money you spent and the success of your competition is very weak, you don't want to read that kind of implication in a newspaper. Rather spend 10 times the money and do it closed-up in-house. Whereas using the GPL, by this time a very well known quantity in most of the above mentioned companies, you can rule out this kind of embarrassment and explain fair and square to your shareholders that a Windows compatibility layer is not a means of competition to you, and that you are just playing by the general rules of the community, and those ensure that your competition will not take advantage of you. For an enabling technology like Wine that will perhaps never become the one big bread and butter product of a fortune 500 company (sorry Lindows guys), this carries a lot of potential for consultants, both individual and incorporated, whose goal is to offer a Windows compatibility layer and to improve Wine. (1) `We need something like Wine' (2) `We need some enhancements' (3) `We have to give back the source code anyway' (4) `So we can as well outsource that and consult with experts' In contrast an X11 style license would modify this: (1) `We need something like Wine' (2) `We need some enhancements' (3) `We do not want our competition to know' (4a) `Let's do it in-house', or (4b) `Let's make a contract with our external consultants that disallows them to reuse the code' Issue 2: On developers discussing licenses You shouldn't. You can't convince others, and you shouldn't try to. You have the power. Just pick one that fits your goals for yourself and for the project, and move on. Claus -- Claus Fischer <claus.fischer(a)clausfischer.com> http://www.clausfischer.com/

2 1

RE: Wine license change
by Patrik Stridvall 14 Feb '02

14 Feb '02

> To give a concrete technical example (but not an > authoritative legal one, > as IANAL), it is my understanding of the LGPL that if someone > has released > a library under the LGPL, a third party cannot distribute a modified > version of this library that has been linked against a proprietary > library[1]. I think because of the reduced scope of the LGPL, there's > also less room for ambiguity on questions of aggregation vs. derived > works. [snip] > [1] The reason for this lies in section 2d of the LGPL: > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > A library that is linked against a proprietary library cannot be used > without the proprietary library; it will fail to load at > runtime with a > complaint of "No such file or directory". If that was the only problem: BOOL (*PROPRIETARY_Foo)(void) = NULL; void call_this_init_on_dll_load(void) { HANDLE h = LoadLibrary("PROPRIETARY.DLL"); PROPRIETARY_Foo = (void *) GetProcAddress(h, "Foo"); } BOOL WINAPI Foo(void) { if(PROPRIETARY_Foo) { return PROPRIETARY_Foo(); } else { /* The old implementation goes here */ } } So no runtime failure any more. At least not anymore than happend before. > If "application > program" as > used above is understood to include other libraries (the > distinction is > artificial, and the LGPL 2.1 does not define "application program" to > exclude this interpretation), then trying to hide proprietary > functions in > a separate library that an LGPLed library is made to depend on is not > permitted under the LGPL. Well, the the requirement if the function didn't exist was "the facility still operates, and performs whatever part of its purpose remains meaningful." Observe the words "remains meaningful". It doesn't have to do the same thing as Alexandre claimed in the last discussion. Yes, I can see why he thought that since the example below paragraf d (not included in your cut) was missleading. It should just do something that in the context of the missing function remains meaningful. It could mean using the old Wine implementation but I guess it could also mean that just doing: SetLastError(ERROR_NOT_IMPLEMENTED); return FALSE; since doing that is ALWAYS meaningful for a Windows API. Sure the application might not check but then this is the responsebillity of application not our problem. Beside since the Wine likely didn't have a non-stub implementation anyway, it was probably was what it already did, so the application crashed anyway without the patch and the proprietary library.

3 2

Re: Wine license change
by Brett Glass 14 Feb '02

14 Feb '02

At 05:44 PM 2/9/2002, J.Brown (Ender/Amigo) wrote: >Sorry, let me clarify that point... the major work that was lost was done >by a COMMUNITY project, not one of ID's in-house ones. His point is that >as the xGPL forces the release of source code with any binaries, so any >valuable work like this won't be lost to the community. In that case, it seems to me that his remarks are a complete non sequitur. The source code of "community" projects that license their work under the MIT X or BSD license is every bit as publicly available as that of projects that use the GPL. In fact, the GPL would actually reduce the likelihood of recovering the code from someone's box, because commercial programmers such as myself won't look at it or download it. --Brett

7 12

Re: Wine license change
by Roger Fujii 13 Feb '02

13 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > When you buy a book, are you paying for the physical paper, or are you > paying for the information contained within its pages? If you are talking about publications by the US government, or books that are in the public domain or have an expired copyright, then I am just paying for the paper. For something with an active copyright, you are also paying for copyright access for the publisher. > How is this anything more than a semantic difference? we are talking about licenses, aren't we? > Just because I can build a greenhouse, plant the seeds and grow my own > 'copies' of the fruit doesn't mean I'm not paying for fruit. bad example, because fruit still has value. And if you want really scary permutations of this, start looking at genetically modified corn and what companies like monsanto are doing.... > > How I read that is that you can charge for the _service_ of copying, but you > > are NOT charging for the content. > Semantics. we are talking about licenses and the law. How can you ignore semantics in this context? > Whatever the license governing the software in question, I'm > buying the same thing when I buy a CD -- and usually less when it's a > proprietary license. If one of these vendors is "selling binaries", then > so is the other. just because you aren't willing to see the distinction, doesn't mean that there isn't one. Why do you think the phrase "Right To Use" exists (you didn't buy the binaries in that case either)? > Or, if the only thing I'm buying from RedHat is the service of copying, > then the only thing I'm buying from Microsoft is insurance against legal > harrassment -- since Windows binaries are just as easy to come by, and > just as easy to copy, as Linux binaries are... what does availability have to do with anything? What am I missing? -r

1 0

Re: Wine license change
by Brett Glass 13 Feb '02

13 Feb '02

At 12:26 PM 2/13/2002, Paul Millar wrote: >> It's hard to conceive of a rational business model that did not recognize >> the advantage of offloading maintenance of non-strategic code to an >> open source team. > >True for non-strategic code, but what about _strategic_ code (strategic in >the sense that the business model assumes the retention of IP-rights). If >this is based on BSD-licensed code then there is no incentive to release >the code back to the community. Whether or not it's based on BSD-licensed code, it's a good idea for the business not to release it for everyone to use. If it's of real value, though, it will probably have a lot of originality to it. --Brett

2 1

Re: Wine license change
by Roger Fujii 13 Feb '02

13 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > > you cannot sell *gpl binaries. You can sell the media, but not the content. > > Think sun has a good idea with dual licensing and having assignment of the > > copyright. This allows them to change the license so that they can make > > a productized version. > > Since this is not the first time this mistruth show up in the discussion > here, I think a clarification is warranted. it is NOT a mistruth. Maybe I should have said, "you are not really selling *gpl binaries", but the meaning is the same. By the license, the source and binaries are freely distrubutable, thus they have no monetary value. So assuming the people in a commerical transaction don't give something for nothing, the monies paid must be for cost of copying, media... > The second paragraph of section 1 of the GPL (v.2) states: > > You may charge a fee for the physical act of transferring a copy, and > you may at your option offer warranty protection in exchange for a fee. How I read that is that you can charge for the _service_ of copying, but you are NOT charging for the content. > The only limits that the GPL places on sales is that once someone has > received a copy of binaries from you, you can't sell them the SOURCE at an > additional cost that's higher than your distribution cost. Up to that > point, you can charge people whatever you want to for access to GPLed ^^^^^^^^^^ > *content*. You just don't have any power to make sure that others don't > sell that same content at a price lower than yours, or even give it away. no disagreement here. But nothing you said so far contradicts what I have said. > And although the LGPL is a different license (which is important to keep > in mind when talking about '*gpl'), the same permission is granted by the > LGPL to charge a fee (an arbitrary fee) for copies of the software. you are confusing the what was said. I did NOT say "you can't charge for GPLed stuff; they must be distributed free". What I said was "you can't charge for the *gpled binaries" because by the license, by section 1, the receiver can make as many copies as s/he wants (providing it falls within the *GPL). The by-product of all this is that the *GPL makes content "zero cost", thus you can only make money by focusing on something other than content. Another way to look at it is like getting a can of compressed air. Do you think you are buying air, or do you think you are buying the process the compressed, canned and distrubuted the air? -r

2 1

RE: Wine build system tech info
by Patrik Stridvall 13 Feb '02

13 Feb '02

> As part of a private investigation I noticed that both > WINE and LINUX kernel > build systems have a mkdep utility which generates in > clude file > dependencies. What I am looking for is to understand > the reasons behind this > decision for the two very popular projects instead the > recipe > suggested by GNU make documentation. For us because we do not wish to depend on GNU Make. For Linux kernel, no idea.

2 1

RE: DLL specific defines
by Patrik Stridvall 13 Feb '02

13 Feb '02

> > With the patch below this is added as EXTRADEFS > > flags so I can pick it up from the Makefile_in's > > and convert to .dsp compile rules. > wouldn't it be better to add them to another specific define > (like EXTRAWINDEFS or something) just to really know what > they are for ? If you wish. I don't care either way. I just want the defines somewhere so I can find them in the Makefile.in to .dsp/.dsw convertor.

1 0

Re: DLL specific defines
by Eric Pouech 13 Feb '02

13 Feb '02

> With the patch below this is added as EXTRADEFS > flags so I can pick it up from the Makefile_in's > and convert to .dsp compile rules. wouldn't it be better to add them to another specific define (like EXTRAWINDEFS or something) just to really know what they are for ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: Wine license change
by Brett Glass 13 Feb '02

13 Feb '02

At 12:09 PM 2/13/2002, Paul Millar wrote: >This is the crux of the issue. What if the business model relies upon >retaining the IP-rights associated with the in-house written code? There >the cost/benefit balance would be tipped towards non-disclosure. It's hard to conceive of a rational business model that did not recognize the advantage of offloading maintenance of non-strategic code to an open source team. --Brett Glass

2 1

Modified makedep to handle #include <>
by Patrik Stridvall 13 Feb '02

13 Feb '02

I have been working some more on a Makefile.in to .dsp/.dsw converter for working in Microsoft Developer studio and it is comming along fine. Anyway one of the the problems compiling with MSVC using the Microsoft headers is that all Wine only includes in wine/include can't use for example: #include "windef.h" it must use #include <windef.h> otherwise Wine's windef.h in the same directory is used. The problem as you pointed out is that makedep.c can't handle this. Here is a patch so it can. BTW. If you apply this patch or a similar should all .h and .c files be converted or should I just do the absolute minimum ie the Wine specific include (.h files) under wine/include. Files like heap.h for example. * tools/makedep.c: Modified makedep to handle #include <> for the Windows includes correctly. ---8<--- Index: wine/tools/makedep.c =================================================================== RCS file: /home/wine/wine/tools/makedep.c,v retrieving revision 1.7 diff -u -u -r1.7 makedep.c --- wine/tools/makedep.c 2000/12/13 21:27:26 1.7 +++ wine/tools/makedep.c 2002/02/13 16:40:21 @@ -4,6 +4,8 @@ * Copyright 1996 Alexandre Julliard */ +#include <sys/types.h> +#include <sys/stat.h> #include <ctype.h> #include <stdio.h> #include <stdlib.h> @@ -185,6 +187,31 @@ return file; } +/******************************************************************* + * find_include_file + */ +static int find_include_file(char *name) +{ + INCL_PATH *path; + int found = 0; + + for (path = firstPath; path; path = path->next) + { + struct stat buf; + char *filename = xmalloc(strlen(path->name) + strlen(name) + 2); + strcpy( filename, path->name ); + strcat( filename, "/" ); + strcat( filename, name ); + if (!stat( filename, &buf )) + { + found = 1; + } + free( filename ); + if(found) break; + } + return found; +} + /******************************************************************* * open_include_file @@ -260,6 +287,7 @@ while (fgets( buffer, sizeof(buffer)-1, file )) { + char qoute; char *p = buffer; line++; while (*p && isspace(*p)) p++; @@ -268,9 +296,11 @@ if (strncmp( p, "include", 7 )) continue; p += 7; while (*p && isspace(*p)) p++; - if (*p++ != '\"') continue; + if (*p != '\"' && *p != '<' ) continue; + qoute = *p++; + if(qoute == '<') qoute = '>'; include = p; - while (*p && (*p != '\"')) p++; + while (*p && (*p != qoute)) p++; if (!*p) { fprintf( stderr, "%s:%d: Malformed #include directive\n", @@ -278,7 +308,9 @@ exit(1); } *p = 0; - add_include( pFile, include, line ); + if (qoute == '\"' || find_include_file(include)) { + add_include( pFile, include, line ); + } } fclose(file); }

1 0

wineconf 2002 user submitted agenda topics
by Michael Robertson 13 Feb '02

13 Feb '02

Here's a list of some of the suggestions people have sent in for wineconf 2002. http://www.lindows.com/wineconf It demonstrates where people's interest is and not a confirmation of the agenda or that the proposed speaker has even confirmed. Some have not responded to my email (like Dr. Ulrich Weigand). As you can see, there's no shortage of interesting topics. Please keep sending me your input and I'll incorporate. I haven't made it through everyone's suggestions yet. Company Presentations: ---------------------- Transgaming, Success To Date [Transgaming/State] ReactOS - Where it's at, where it's going [ReactOS/Filby] Corel, A Look Back [Xandros/Tranter] Crossover Strategy [Codeweavers/JW] Macadamian - Making It As A Software House [Macadamian/???] Business -------- WINE's "Most Wanted": Features To Make WINE Great [???] Developer Funding, Who Pays The Rent [???] Future of WINE licensing [CW/White] Technical --------- Development Model [CW/AJ] NORM - The secret weapon [Codeweavers/???] Making Fonts Not Look Like Crap [CW/Timoshkov/Davies] Multimedia And WINE [eric.pouech(a)wanadoo.fr] Regression Testing [???] How To Improve The Debugger [Meissner/marcus(a)jet.franken.de] Maximizing performance of WINE [???] Package streamlining of WINE [???] WinNT APIs (Odin, ReactOS, winNT wine, WINE) [???] DirectX [Transgaming/Kaaven] WINE as a porting tool [Macadamian/Jacques] Native user.dll [Dr. Ulrich Weigand] API Standardization [???] Lindows.com michael(a)lindows.com 858-410-5941 Bring choice to computers: Become a Lindows.com Insider http://www.lindows.com/signup

6 5

Licensing response and an idea
by Gavriel State 13 Feb '02

13 Feb '02

Hi everyone, As I mentioned, I have been considering the license issue for the last several days. It is a matter very near to my heart, as I believe that it affects not only TransGaming, but really the entire software industry. This posting is somewhat lengthy, but please bear with me. Open Source software has made enormous strides in the last several years, and incredible amounts of great code have been produced. At the same time, it has been unable to compete effectively with proprietary software vendors like Microsoft, except in those areas where sufficient well financed companies have been able to direct full-time developer resources to the problem. With the wellspring of dot com VC funding going dry, the question arises: where will the money come from to pay full-time Open Source developers? Just imagine where Wine would be without the code contributed by the half-dozen or so companies that have been involved. Imagine where Linux would be without the efforts of the companies paying for dozens of full-time Kernel hackers. And imagine where we could be if just one or two percent of Microsoft's annual $25 Billion in revenue were being directed at Open Source projects. The business models capable of supporting traditional Open Source projects are really rather limited: consulting services, technical support, and selling ancilary products with the software. None of these come close to delivering the levels of revenue that traditional mass-market shrinkwrap software can. So far, it is unclear whether they can support much profit at all for their proponents: RedHat, VA, and others bear witness to that. TransGaming, for one, is working with some new ideas on how to do things differently, and profitably. There are a number of interesting possible approaches out there, and it is important to the entire world that we find models that work. Otherwise we are going to be stuck with the kind of information police states envisioned by the RIAAs, MPAAs, and Microsoft's of this world. Now we are all here because we think that there are better ways to do software than the wholly proprietary approach. We want to be able to look at the code, tear it apart, fix the bugs, and make it cooler. And we want others to have the freedom to do the same. Ultimately, the questions that need answering are these: o What freedoms are important to the community? o Can those freedoms be achieved without sacrificing other goals? o What is the best mechanism for ensuring those freedoms, and ensuring the continued development of the code? The Wine X11-style license essentially allows the code to be used anywhere, in any way. Users don't need to pay, Developers can take bits and pieces as they deem appropriate, and corporations can sell the product in whatever way they feel like. But it also has no legal mechanism to try to coerce further development of the project. Current proponents of an LGPL license switch believe that a legal mechanism is important to protect the project. Frankly, I am at a loss to understand the reasoning behind such a switch. I don't see any way in which any company could maintain their own fully proprietary fork of Wine without doing periodic merges into the public project. It's hard enough for TransGaming to do it despite the fact that we deal mostly in very specific areas. And even if someone was able to do so, how does it affect the Wine project any more than the existence of Windows or MainWin does? At most, it would affect the userbase, but in the current model that doesn't matter, since that userbase doesn't contribute significantly to the project. Only the developers contribute, and it is not at all clear to me that they would stop. Marcus Meissner has already shown that the existance of our AFPLed DCOM code didn't stop him from going ahead and doing it himself. On the contrary - it helped him, since he got hints from our design. It's a shame that he had to, since we've been working hard to find a way to contribute that code back, and now we may have no way to recoup our investment. We still have a 2nd pass, more complete DCOM implementation under development, so it is possible that we be able to get a sponsor for that. But regardless, it clearly shows that having code outside the WineHQ tree is no impediment to the community reimplementing it if necessary. The LGPL would severely limit a number of possible commercial applications of Wine, such as: o Companies or groups that might want to take a small bit of Wine code here and there without taking the whole thing. IE: Corel's Mac porting work, or projects like MicroWindows or Odin (similar projects like Xine and ReactOS use parts of Wine this way, though they're GPLed, and thus would not be affected). o Porting Wine to platforms with NDAed APIs. Or commercially oriented ports to other platforms which might not be viable under the LGPL. o The work that TransGaming has done to support copy protection. Releasing that code all at once - as would be required under the LGPL - might violate the DCMA, since it reveals something of how the copy protection systems work. o New business models like TransGaming's, with conditional-future- release of code. While I am open to considering license changes that have the potential to benefit the project, I am very very concerned about the LGPL. Going that route is a one-way street with no turning back. I've been thinking about these problems for a long time. As much as for any other reason, I started TransGaming with the desire to try to find good long-term solutions to the problem of how to fund Open Source development through the people who are actually using the code. I have the germ of an idea that might be useful to address some of the concerns that the LGPL-license-change camp has had, while at the same time leaving the doors open for a much wider variety of different commercial activities. I have been trying to flesh it out while at the same time working to some very tight deadlines, and I have not had time to really think through some of the the possibilities that it entails. I am posting it to the list now anyway so that it's out there for people to think about. Here's the quick and dirty version: o A new non-profit company is created: WineCorp o Developers contribute their work to WineCorp - possibly assigning copyright, or at least giving WineCorp the rights to do with the code whatever it pleases. o WineCorp distributes the code under an AFPL-like license - no commercial redistribution allowed. o WineCorp has a set of standing licenses allowing for commercial redistribution. A company can redistribute commercially if it does one of the following things: - Releases source modifications to WineCorp immediately. - Releases source modifications within a preset timeframe (maybe one year). - Releases source modifications with some appropriate prearranged condition (ie: the TransGaming subscriber limit). - Pays WineCorp a pre-set royalty, which WineCorp can then use to sponsor other Wine development o For cases that don't fall into the above conditions, the WineCorp board of directors can vote to allow some other licensing arrangements. This helps prevent the kind of one-way ticket we have with the LGPL. o WineCorp could also serve as a way for the userbase to direct funding and attention to different parts of Wine. To my mind, this is one of the biggest problem Open Source projects have. The end users get everything, but many don't contribute: no code, no money, no bug reports, nothing. The more they can be encouraged to contribute, the better off everyone is. WineCorp could solicit donations from users who can't contribute otherwise and possibly institute a subscription/voting system similar to TransGaming's. One hard question the above idea creates is how does money gets split fairly amongst different developers working on particular parts of the code? I am sure that there are other problems as well. That said, I think that the importance of new models like this go far beyond the Wine project. Ideally, I hope that methods like these can be profitable enough to make proprietary software companies begin to consider opening up their code in a similar fashion. Just imagine the day that Microsoft makes their first contribution to Wine, openly and without coersion by the government, because they recognize that doing so is in their own best interests. Food for though, anyway. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

3 3

Re: Licensing response and an idea
by Roger Fujii 13 Feb '02

13 Feb '02

Gavriel State <gav(a)transgaming.com> wrote: > > You did not mention whether you want to have this > > license only or to have Wine licensed also with some > > open-source license? > > > > I think in this case even GPL can be a choice for the > > second license. > > Under the WineCorp approach, the AFPL + an allowance > for commercial redistribution if Wine code is returned is > essentially equivalent to the LGPL. It's more flexible though, > since it allows for the possibility of other unforseen ways in > which commercial redistribution without immediate release > of source would be possible. > > It would also be possible for the WineCorp to allow certain > portions or all of the code to be dual-licensed under the LGPL > and mixed with other GPL or LGPLed projects. I think that you'll find considerable resistance from the *GPL people, but you do bring up a good point. If there is going to be a license change, it would probably be wise to require that the copyright of future submissions go to a single (or small #) of people. That way, you can revert the licensing terms if you change your mind. -r

1 0

Re: Wine license change
by Roger Fujii 13 Feb '02

13 Feb '02

>On Tue, Feb 12, 2002 at 04:21:59PM -0500, Roger Fujii wrote: > > Read: http://www.uwsg.iu.edu/hypermail/linux/kernel/0105.3/0203.html > > I don't think that LGPL and GPL differ in this regard. > > [Summary of link: discussion of whether including binary-only firmware in > the Linux kernel is a violation of the GPL.] > > In this regard, they do not differ. However, whereas the GPL is mostly > 'symmetric', placing the same limitations on anything that's linked to GPL > code (except for the "standard system facilities" exemption), the LGPL > quite explicitly only places limits on the licensing and > source-availability of other code on which the LGPLed code is made to > depend. it also restricts the ways and means of binary distribution. > To give a concrete technical example (but not an authoritative legal one, > as IANAL), it is my understanding of the LGPL that if someone has released > a library under the LGPL, a third party cannot distribute a modified > version of this library that has been linked against a proprietary > library[1]. I think because of the reduced scope of the LGPL, there's > also less room for ambiguity on questions of aggregation vs. derived > works. I believe your case falls under the "work as a whole" clause. The problem in the wine context is that it is NOT clear that any propriatary library doesn't fall under that clause unless you make it as a dropin replacement for something that's already there. And, if it's NEW functionality you're adding, you must do it in such a way that it can be removed at runtime. So, if your business model is to develop a value-add, LGPL is not your friend. > > yes, but studying can be done in a non 'open source' license too (like AFPL). > > This is why using the word "contribute" is really a misnomer which is > > why I said "show your work". > The difference is that in the case of the LGPL, a third party can only > erect certain limited sorts of technical barriers to reintegrating the > sources, at some cost to them in terms of programmer time; whereas under > the BSD license, a third party can erect legal barriers to reintegration. if you can make a propriatary extension, it holds that you can license the source code for it some other way too. If the point was that with enough effort, you can roll (some of) the changes back in, then I agree. But is this practical? > There is an important difference between LGPL/GPL and standard EULAs for > proprietary software. An EULA requires a user to give up freedoms they > would otherwise have; the LGPL and GPL give additional freedoms TO users > which under copyright law would normally be reserved for the author. this is a perceptual difference. the legal mechanism for both is simply conditions of the transfer of the copyright since neither case makes any difference to anyone who doesn't distribute what they have to the public. > If a third party does not accept the terms of the GPL, and they have been > granted no other license to modify/redistribute, then they're guilty of > copyright infringement -- and copyright infringement is far easier to > prosecute than tort or breach of contract. well, not according to that calif. ruling (in certain cases). > Eben Moglen has expounded on this point quite persuasively in the past. > Whatever flaws the xGPL licenses might have, I assure you that > unenforcability is not among them. I don't believe anyone has said there is NO legal basis. What has been said is that there is little legal PRECEDENT. There are various parts to *GPL that are quite arbitrary (like, why is it legal to link with a .so, but not a .a, or a .o? what is being linked is the same) and is not clear it will stand a good challenge. As such, it's pointless to argue what it means except in the cases that it's absolutely clear on. For all other cases, you are in untested territory. > To the question of the LGPL being unclear: your example at the top cites > discussion among a number of non-lawyers. The fact that they disagree > about the meaning of "aggregation" may merely be a reflection of the fact > that no party to that discussion is an expert in IP law. until there is case law, what those words mean in the software context is open to interpretation. "Aggregation" of books may not be considered the same as aggregation of programs. If you need convincing of this, look at the consent degree between the justice dept and M$ with IE in win98. > Any company that's considering working with Open Source software as any part of their > business model should seek legal advice; just because the BSD license > seems clear to most informed laymen doesn't guarantee that it's free from > legal pitfalls. would you care to enumerate one that is the result of the license? > So while an easily understandable license may be helpful > to some, it doesn't eliminate the need for corporate lawyers. you must know some INCREDIBLE lawyers. The ones I have dealt with always makes something simple really complicated. If you know of someone that can make something complicated simple, I'd like to have their #. > > > If the company is one like, say, Lindows.com, and they have a business > > > model based on selling a branded, enhanced version of Wine, there are > > > rational reasons for possibly not wanting to use an LGPLed code base. > > > There are several different options for such a company. Some might choose > > > to risk the LGPLity, and decide to see if they can make a profit just from > > > selling people something they can already get for free. This is not out > > > of the question; every Linux vendor is doing this today, and if 90% > > > marketing + 10% programming works for Microsoft, it should work for others > > > too, right? > > > a) M$ can charges for their work > > b) it works for linux (I presume you mean distributions) vendors because > > most others sell a propriatary value add (like transgaming) which does > > not fall under your description for this case. The linux vendors have > > an advantage that what they are replacing (nt, solaris, aix...) are > > a rather expensive. The problem wine solves (for most people) is the > > cost of a PC (US$400). There isn't much of a margin here. Can you > > show me any example of successful companies using this business model? > > Judging by his posts here, it sounds like Michael Robertson believes his > own company's business model is already very close to this. If lindows was just a branded version of wine, why are people getting so bent out of shape about them contributing? > I wonder if he would say Lindows.com's hopes for profitability stand on the ability to > maintain a competitive advantage over other Wine vendors by keeping their > changes proprietary, or on value-added features such as integration into > an easy-to-install product? I would presume a little of both. > There's still lots of room for proprietary value-add with an LGPL Wine; > and I'm not arguing that this is a bad thing. I just think that having > companies create value-added products by making closed-source > modifications to the Wine *core* is a bad thing. 'lots of'? I really think you are overstating the case. Gav doesn't think so. I think Michael Robertson has implied he didn't think so either - the pie just isn't that big... > > (I just love how people use 'steal' in reference to something freely > > given away - I guess the same people ask for interest when they do > > charity work) > As someone who gave his assent (however insignificant) to the current Wine > license, *I* do not use the word "steal" to refer to the actions of such > companies. you may not have, but this statement has either been said or implied by many in the *GPL camp. It is a pervasive attitude that always makes this topic more imflamatory than it needs to be. > > So, given the world of (using "contribute" meaning code that can be easily > > worked back into the common tree): > > 1) Evil companies that won't contribute no matter what > > 2) Companies that contribute some, but not all of what they do > > 3) Companies that contribute > > > The only thing a license change will do is stop #2. If this is what you want, > > we can stop arguing now. > > I disagree with this breakdown. Assuming there are "evil" companies > involved[2], they will find it more difficult to do evil things with Wine > under the LGPL than they would under the BSD license; this is a given, but they CAN still exist. The notion that LGPL will prevent that kind of behavior is just not true. > and at least some of the companies that don't contribute at all do so > because they're misguided, not because they're evil, so the LGPL would cause them to > contribute back to our mutual benefit. Both of these results are wins. the misguided ones I think (MHO) eventually will contribute back, for the very same reason you have stated (problems with keeping the trees synced). Regardless, the whole point boils down to this: Is the code you are going to coerce out worth the code that is lost by entities either unwilling or unable to abide by *GPL? There has been ample statements made saying that the latter part of the question is not insignificant. > [2] Not a very sustainable business model, btw; on the whole, being evil > is no more profitable than being altruistic. I agree that it's self-defeating, but there is nothing altruistic if you EXPECT to be paid, whether it's cash, or code. I haven't seen any arguments for *GPL made here on altruistic grounds (not to say that *GPL can't be used for such purposes - take quake from Id software for example, but this is when you take something propriatary and *GPL it). All I see are pretty selfish - which is fine, as long as it's not being passed as being altruistic. -r

1 0

DirectX implementation on top of OpenGL
by Jakob Eriksson 13 Feb '02

13 Feb '02

DirectX on OpenGL. http://sourceforge.net/project/showfiles.php?group_id=44365&release_id=70636 Seems to BSD style license, but only some files say that. Most files have no copyright information. Warning: a whole slew of files are Copyright Microsoft. (Only include files though.) regards, Jakob Eriksson

1 0

Re: Wine license change
by Roger Fujii 13 Feb '02

13 Feb '02

> The LGPL and the GPL have different restrictions on the creation of > certain types of derivative works. The thing about Wine is that it's not > *a* library, it's a *set* of libraries -- reimplementations of DLLs. How is this any different from the linux kernel and its device drivers? Read: http://www.uwsg.iu.edu/hypermail/linux/kernel/0105.3/0203.html I don't think that LGPL and GPL differ in this regard. > > I have no clue what you are talking about. I didn't say anything until > > the "Here we go again". And Yes, I have read the *GPL, many, many, many > > times. > > 'Effectively license your software to the FSF'. The LGPL, as a license, > is designed to be idempotent, just as the BSD license is; under each > license, everyone is granted the *same* freedoms. There's nothing in the > text of the LGPL that can be interpreted as licensing your software to the > FSF that isn't already present with the existing license. I can change the BSD license. I cannot (or at least, not without a fair amount of work) do this with *GPL. It forces me, the copyright holder of the contributions, to contribute as *GPL, even if I may prefer a freer license. This lack of ability of changing the license is why I say "effectively license to the FSF". > > This AFAIK, fulfills the technical requirement > > of the *GPL, but it certainly isn't a usable form. > In that respect, you're correct that no one has to release the source > code in a form that's easily reintegratable with the main Wine tree. And > if someone wanted to be spiteful, they could do what you describe -- but > they would still have to release the source code in the form that THEY use > it when working on and compiling Wine, which means their changes are still > visible for others to study. yes, but studying can be done in a non 'open source' license too (like AFPL). This is why using the word "contribute" is really a misnomer which is why I said "show your work". > > we can quibble about what "free" means, but saying GPL is "more free" than > > X11/BSD doesn't make any sense. Given the current license is X11/BSD and > > the argument is for changing it to LGPL, I can't see how one can use the > > "freedom" argument in this case. > > > geez. no need to get bent out of shape. I'll rephrase and say BSD is > > MORE free than GPL. Happy? > > I don't believe anyone has argued that Wine should be placed under the > LGPL because the LGPL is more free than the BSD license. er, that was what I was responding to - someone did. > I disagree with the idea that what users are allowed to do with the code is the only > metric of freedom that's important to consider, but since this relicensing > discussion wasn't brought about by concerns that the current license is > non-free, I don't think it's relevant, either. You're correct that the > BSD license is more free than the GPL per this particular metric. The claim that moving to *GPL would make it MORE free (which implies that the current license is LESS free). My point is that this is a non-argument (and you seem to be agreeing with me here) > > The problem with that particular argument is that it makes the fundamental > > assumption that all people who don't contribute back NOW is evil foreever. > > You just don't know what will happen in the future. Maybe Sun/IBM buys out > > lindows.com in 6 months when they are broke, and opens the source. Or, > > maybe in a year, they have a change of heart (has happened before with other > > companies). The point is that it's arguably better to have more players. > > Actually, I don't think that assumption is key to my argument. Consider > that a company which takes without giving back will either spend a lot of > developer time re-merging upstream fixes into their local product, or will > create a product which diverges significantly from the main tree. Either > scenario, when considered by itself (that is to say, setting aside any > reasons this might be profitable), constitutes an inefficient use of > programmer time; the cost of keeping a private tree is higher than the > cost of letting the community maintain the tree for you. ok.. but this argument works for the current license too.... > If the company is one like Corel, who profits not by selling Wine but by > selling products that run under Wine, then trying to keep their changes > private is misguided -- most such companies would still see the advantage > of a Windows implementation that they didn't control exclusively, so long > as Microsoft didn't control it either, and would not be turned off by the > LGPL -- in fact, both we and they would benefit from the LGPL, because of > the more efficient use of developer time. this is still true for the current license. > Other companies in that situation might indeed shy away from an LGPLed Wine; > but I can't think of a rational reason for doing so, and companies that make irrational > business decisions don't strike me as a good reason to avoid a licensing > choice that benefits the rest of us. here is where we differ. The problem with *gpled stuff is that because certain things are unclear, even well meaning people can end up in violation. If you read the kernel arguement at the beginning, we see that there is a difference in interpretation between alan cox and the FSF. It is not irrational to say that the legal risks are greater than the economic gain. And for those of you who say *GPL is on strong legal ground, look at slashdot today. A calif court just threw out a significant section of a EULA and may affect the GPL. Don't know if it is going to be upheld (might make it to the supreme court), but the point is that it is definitely not in settled law. > If the company is one like, say, Lindows.com, and they have a business > model based on selling a branded, enhanced version of Wine, there are > rational reasons for possibly not wanting to use an LGPLed code base. > There are several different options for such a company. Some might choose > to risk the LGPLity, and decide to see if they can make a profit just from > selling people something they can already get for free. This is not out > of the question; every Linux vendor is doing this today, and if 90% > marketing + 10% programming works for Microsoft, it should work for others > too, right? a) M$ can charges for their work b) it works for linux (I presume you mean distributions) vendors because most others sell a propriatary value add (like transgaming) which does not fall under your description for this case. The linux vendors have an advantage that what they are replacing (nt, solaris, aix...) are a rather expensive. The problem wine solves (for most people) is the cost of a PC (US$400). There isn't much of a margin here. Can you show me any example of successful companies using this business model? [snip] > This leaves the last possibility; that such a company chooses not to enter > the market, or fails to come into being, because they can't find numbers > that make sense using either a slightly-older, BSD-licensed Wine or an > up-to-date LGPL-licensed Wine. And we do lose something by not having > such companies around, particularly if they happened to have a 'change of > heart' down the road and freed their source code. or have their participation in current development. Most well meaning companies will send in patches to parts that they are not trying to hold propriatary. You're making the assumption that companies that hold ANY software back will hold ALL the changes. > Does the loss of such companies as players in the Wine community outweigh > all of the other potential advantages described above, including the > advantage of some otherwise closed-source companies choosing to open > their source as a result? I don't think it does. I think that today, if > we look at nothing more than raw lines of code that Codeweavers > contributes to Wine that we are told would not available for use in a > BSD-licensed tree going forward, it makes sense to switch to the LGPL; and > I think the benefits only go up from there. As I said before, if you don't care about other commercial input, go *GPL. But at least be honest and say, "we don't care about companies like transgaming". It's utter nonsense to say that the license change will only affect "the evil companies that steal our source code" (I just love how people use 'steal' in reference to something freely given away - I guess the same people ask for interest when they do charity work) or that wine will benefit because evil companies will now 'contribute'. If they are that evil, they will run the obfuscator and make the merge difficult, if not impossible. So, given the world of (using "contribute" meaning code that can be easily worked back into the common tree): 1) Evil companies that won't contribute no matter what 2) Companies that contribute some, but not all of what they do 3) Companies that contribute The only thing a license change will do is stop #2. If this is what you want, we can stop arguing now. -r

3 2

Re: Copyright, derivative works, and truly free licensing (Was:
by Rolf Kalbermatter 13 Feb '02

13 Feb '02

Brett Glass <brett(a)lariat.org> wrote: >I agree wholeheartedly that such discussion shouldn't be a constant distraction >or devolve into a "flame war." I have taken great pains to express my point >of view very carefully and to make sure that nothing I've posted could be >construed as "flamage." Well, I for myself can only say that you have certainly failed in this. For me, your posts had from the first beginning the character of somone on a crusade against RMS, the FSF and anything connected with it. Although some of your remarks would have been at least interesting, that fanaticism in wording your opinion about xGPL, making claims about what someone elses intentions "doubtlessly" are, and trying to come up with the worst doom scenarios, made it virtually impossible for me to accept and listen to any of your other more serious statements. The subject of what direction Wine should go, seemed obviosly just the coat hanger on which you continued this, your personal crusade! So as far as I'm concerned you have certainly not reached your goal. I'm certainly not a xGPL fanatic, but it personally feels not right to me that people spend their time on something to work on and any company can come in and take whatever there is and make profit out of it, without contributing something back. And with that I don't mean the questionable marketing hype of letting those people say: "Hey you know, they made their great product out of our project and I'm so proud that I have spent months and months of my own time to allow them to earn big bucks!" And don't say that they earn the money only for the additional value that company has put in. If it wouldn't be for the developer in the project, that company would not have a product at all to sell as you have actually also agreed on. >I agree, as I have said above, that the developers have the right to make >the decision. But because they are doing the entire project for the benefit >of users as well as for themselves, they certainly should care about how >users feel. What's more, if they are seeking bug fixes or help with >development, they certainly should care how potential contributors feel. >Finally, they should care about how advocates of the project feel. While >advocacy does not expand the code base, it does expand the base of users >and testers. Hence, it plays an important role in any collaborative >software project. You should have started the whole discussion more in this style. This would have helped a lot more than trying to bring in your personal feelings about the FSF and xGPL. Even if the FSF is what you say, it does really not help to bring that topic up in such an emotional tone. It only polarizes everyone, and hinders the solution of the original problem, which might cause the person who is responsible to take a decision out of frustration rather than out of great consideration. >I agree. If anyone has considered any of my messages to be a "flame" rather >than rational discussion, I apologize; nothing I've written was meant to be >a "flame." I really do want to be able to continue to work with, advocate, >and (hopefully) contribute to, WINE, and this has been the reason for the >volume of passionate messages I've posted over the past few days. Well I did actually. This is probably my problem, but your apology is accepted anyhow ;-) And now I go back and continue to work on my first of hopefully a series of contributions to Wine! Rolf Kalbermatter

2 1

Re: Licensing response and an idea
by Lean Fuglsang 12 Feb '02

12 Feb '02

Thanks for an enlightening post, Gav. //DISCLAIMER - I AM JUST AN ORDINARY USER - SO DON'T READ IF YOU DON'T FEEL LIKE I am not a developer (yet). But I truly believe in the spirit of OpenSource Free software. I have reported some bug reports, but I would really like to contribute more. When I first heard about a (very) possible licens change to GPL I thought it was a great Idea, because I hate companies who take code and don't contribute back. With the current license this is possible. But I also think it would be a shame for companies with good intentions (as Transgaming) who (maybe:) will contribute all there code back, and make very fast directed code to wine. I would also be very delighted to pay money directly to the wine project because I like it and use it. An important note is that this is what I do with everything that I buy. When I by music, it is because I like it and have heard it and want's to support the artist. Same with movies. I know this is not the way the corporate world works at the moment, but I can pirate music/video/software very easily and therefore they have to trust me to pay for what I want's to pay to. Phew, hope I didn't confuse all of you (like I confused my self:) But the point is, I really like to make contribution to a gratis project if it is GPL'ed or dual licensed (for 'good' corporations). Many of the people I know has the same 'Ideology' as me, and don't pirate things they think aren't sh**t. And after I have changed to linux and opensource, I have actually pirated a lot less, because all stuff are free, and the things that aren't 'stands out', so to speak. Just my .02$ (and maybe more if it goes as I hope:) //lean Ps. Hope I send this mail to the right place

1 0

Direct 3D 8.0 Wrapper for OpenGL Open Sourced
by Damjan Lango 12 Feb '02

12 Feb '02

Hi, Just found this on http://www.osnews.com/: Direct 3D 8.0 Wrapper for OpenGL Open Sourced http://www.osnews.com/story.php?news_id=613 Not sure what is the license, but maybe it could be incorporated to wine as an alternative to the transgaming's version. ciao Damjan

3 2

wine license vote
by Shane Shields 12 Feb '02

12 Feb '02

hello after having contributed a couple patches (more to come im working on getCalenderInfo now) i feel i can say a couple of words. i have been following the current "discussion" on the license change with avid interest (not to mention a few laughs). just to make sure im not speaking out of a red hat (i compiled my own linux) i downloaded a copy of the licenses in question and compared them side by side. as everything that i wanted to ask has been discussed on the list with good points from both sides of the fence im not going to go over old ground. i think that the lgpl license would be a better choice for WINE than the bsd license. i know that some would disagree and some would agree thats the way the cookie crumbles. but i think that the most important thing is for people to make a decision for themselves and not to try to convince people that dont want to be convinced. its a waste of programming time and cpu cycles (sound familier m$). Shane Shields -- To drink the WINE of success you must first seek the sayings of source _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel