Wine license change

[Steve Langasek]

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):
> 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.

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.