On Fri, Feb 08, 2002 at 06:10:50AM -0500, Roger Fujii wrote:
Steve Langasek vorlon@dodds.net wrote:
On Thu, Feb 07, 2002 at 05:45:36PM -0500, Roger Fujii wrote:
If you are using marketing speak for "contribute". GPL requires 1) for you to show your work 2) You effectively license your software to the FSF. It doesn't say it has to be in any useful form to be worked back into the originating project (if any).
We're talking about the LGPL, not the GPL.
true with either. Your "contributions" must be licensed as LGPL/GPL.
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. Even under the LGPL, there are many ways to build proprietary value-added software on top of Wine. All you have to do is create your own reimplementation of the particular DLL that you get your value from without using any LGPLed code in the process. And guess what, there's already an existing body of BSD-licensed Wine code that such companies can draw from to do just that.
If this lends support to the argument that the LGPL can be easily 'circumvented', it also negates some of the objections to such a switch. (At least, the ones that aren't based in rhetoric and personal phobias.)
The rest of this paragraph shows a serious disconnect with the text of the LGPL. Have you actually read the license in question?
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'm glad you've read the LGPL. There are many who form their strong opinions -- positive or negative -- about licenses without bothering to read them and understand them first.
"Source code" for a work means the preferred form of the work formaking modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library.
If you are contesting the "useful form", let's say I did this: Took the original GPLed code and run it through a lexical translator so that all labels and such are changed. Make my changes with respect to THIS codebase. Now publish this. 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.
you are ABSOLUTELY right. The spectrum is PD->BSD->GPL-------->Propriatary. But then, things in the PD really isn't licensed, so X11/BSD is probably as close as one can get.
and any software license that permits you to maintain any portion of your copyright is a fraud if it claims to be Free. If you really cared about giving absolute freedom to the users of code that you write, you would place all of your code in the public domain.
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. 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.
On the other side, companies like Lindows.com don't impress me as bringing any added value back to the community -- they may succeed in increasing the percentage of non-Windows desktops in the world, but the current Wine license makes it possible for all the profits from their OS to pad the wallets of marketroids, sales critters and smooth-talking business execs, without contributing anything back to the Wine tree. I have no problem at all with the idea of eliminating that particular business model.
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.
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. 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.
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? Others would consider that they still have the option of using the slightly out-dated, BSD-licensed Wine tree as a starting point for their proprietary modifications. If they're going to be creating their own proprietary code fork anyway, does it really matter that they don't have access to the last one month, two months, six months of bug fixes? And if it does matter that much, shouldn't they consider using LGPLed versions of components that aren't core to their value-added features?
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.
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.
Steve Langasek postmodern programmer