Wine license change

[Steve Langasek]

On Fri, Feb 08, 2002 at 06:10:50AM -0500, Roger Fujii wrote:
> Steve Langasek <vorlon at 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