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
On Tue, Feb 12, 2002 at 04:21:59PM -0500, Roger Fujii wrote:
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.
[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. The LGPL does not contaminate other libraries that are loaded into the same process memory space, nor does it contaminate applications; it only "contaminates" other code which is compiled into the same binary object (such as a shared library) and which results in unnecessarily diminished functionality if absent.
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.
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".
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.
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.
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. 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.
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.
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. 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. So while an easily understandable license may be helpful to some, it doesn't eliminate the need for corporate lawyers.
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. 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?
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.
(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.
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):
- Evil companies that won't contribute no matter what
- Companies that contribute some, but not all of what they do
- 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; 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.
Regards, Steve Langasek postmodern programmer
[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 "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.
[2] Not a very sustainable business model, btw; on the whole, being evil is no more profitable than being altruistic.
At 03:56 PM 2/12/2002, Steve Langasek wrote:
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.
Actually, they may well be unenforceable. The only way in which they have ever been "enforced" is via threats of lawsuits; no court has ever ruled on the issue.
And there are some very good arguments for the proposition that the FSF licenses are unenforceable. Among other things, there are arguments that the recitals are deceptive; that the licenses are contracts to make contracts; that consideration is not reasonable and/or cannot be determined; and that certain portions are vague or ambiguous.
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're right. They most certainly are NOT stealing. They are, in fact, making better use of what they have been given than pure end users, who produce nothing of greater value from the code.
--Brett Glass