- Wine-devel - list.winehq.org

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