Re: Wine license change
Steve Langasek <vorlon(a)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 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.
"Source code" for a work means the preferred form of the work for making 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.
Here we go again.... If this is *all* it did, LGPL is far less objectionable. The problem with *GPL is that it also regulates the UNMODIFIED use of the software.
The creation of derived works does not constitute "unmodified use of the software" under any legal definition I've ever seen, if that's what you're referring to.
no, it's this phase: Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
Freedom means allowing people to do things, even things that you don't agree with. BSD = Free. GPL is not. Call a spade a spade....
Nonsense. To extend your definition to the proper conclusion, it's not Free unless it's placed in the public domain,
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.
Not planning to do that any time soon?
stuff that I have put back into projects go with the license that it's under. All of the changes I've put back goes back with *no* restriction (ie. it's PD as far as I'm concerned).
Then spare us the bullshit arguments about the BSD being Free and the GPL not. (Yes, it is bullshit. Call a spade a spade, right?)
geez. no need to get bent out of shape. I'll rephrase and say BSD is MORE free than GPL. Happy?
All Free Software licenses attempt to find an equitable balance between the freedoms and rights of the authors, and the freedoms and rights of the users.
this statement is true of licenses in general, with the freedoms/rights of the user declining along that freedom spectrum. In the US (forgetting the DCMA for the time being), the freedoms and rights of the authors are guarenteed by law (1st amendment/copyright). What I philosophically object to is using the freedom argument WRT GPL, since the freedom of the author is never in question, while the freedom of the user is curtailed. I have no problems in saying it's equitable, fair, desirable <insert socially desirable adjective here>, even "right" - just not 'free'.
You are free to favor one balance point over the others, but that doesn't make other licenses and other balance points non-free.
my dictionary says one of the definitions of freedom means "unrestricted use". So it's fair to say something that has MORE restrictions is LESS free, or are you arguing that GPL is more "free" than PD?
But neither philosophy nor politics is the issue at hand. The issue at hand is whether the LGPL, or a similar license, would be better or worse for growing the Wine community. For that, there are good arguments on both sides.
we agree.
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.
If this is the goal (it certainly is mine), then *GPL is not a good choice, because it would interfere with deployment (*GPL wouldn't allow being bundled with the playstation2 or other HW platforms as an example). If acceptance is the goal and you care about wine in a non-linux context, stay with BSD/X11. If you don't care about expanding the pie, go *GPL....
Please write what you mean, which seems to be "Sony would never accept the terms of the LGPL, which would prevent them from being able to bundle Wine with the PlayStation2". Again, I don't see where this would be a loss. Companies that are unwilling to contribute back to the community are not any concern of mine; if they want to compete with Microsoft on the desktop, let them fund their own software development instead of leeching off of the community. My only concern with the LGPL is making sure that well-intentioned companies that DO give back to the community aren't caught in the middle.
Let's say the playstation distributed wine for every PS2 that shipped. If only .001% of its users (and these are gamers) get interested in wine, that's 200 additional contributers. Most people get involved with a project because they USE it initially. So, it's reasonable to say that wine is still better off if sony distributed it without contributing *anything* (maybe had had to make NO changes, who knows) because of the additional interest. You might not consider this a loss, but to me, it seems like it is. -r
[snip]
Then spare us the bullshit arguments about the BSD being Free and the GPL not. (Yes, it is bullshit. Call a spade a spade, right?)
geez. no need to get bent out of shape. I'll rephrase and say BSD is MORE free than GPL. Happy?
[snip] Neither the BSD or GPL is free, only public domain is free. BSD and GLP are both contracts with the users. BSD means "you must include my licences information with anything you make". *GPL means "if you make something from my code you have to share it with everyone". Which on you use doesn't depend on freedom, it depends on your goal. I prefer GPL becuase I see getting back what others make as payment for my work, and yes, I know I'm being selfish. [snip]
Please write what you mean, which seems to be "Sony would never accept the terms of the LGPL, which would prevent them from being able to bundle Wine with the PlayStation2". Again, I don't see where this would be a loss. Companies that are unwilling to contribute back to the community are not any concern of mine; if they want to compete with Microsoft on the desktop, let them fund their own software development instead of leeching off of the community. My only concern with the LGPL is making sure that well-intentioned companies that DO give back to the community aren't caught in the middle.
Let's say the playstation distributed wine for every PS2 that shipped. If only .001% of its users (and these are gamers) get interested in wine, that's 200 additional contributers. Most people get involved with a project because they USE it initially. So, it's reasonable to say that wine is still better off if sony distributed it without contributing *anything* (maybe had had to make NO changes, who knows) because of the additional interest. You might not consider this a loss, but to me, it seems like it is.
In case you hadn't noticed Sony let's you run _Linux_ on a PS2, did that change to BSD without anyone telling me? Big companies like *GPL because they know where they stand and they don't loose an advantage by giving back. Sun and IBM both support *GPL projects, so does SGI and a lot of other very large players. Daniel Sabo, The armchair quarterback (Hey! I contributed the smallest patch ever! Don't I get something for that?)
On Fri, Feb 08, 2002 at 06:10:50AM -0500, Roger Fujii wrote:
Steve Langasek <vorlon(a)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 for making 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
participants (3)
-
Daniel Sabo -
Roger Fujii -
Steve Langasek