Wine license change
rmf at lookhere.com
Tue Feb 12 15:21:59 CST 2002
> 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?
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?
> 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.
More information about the wine-devel