Wine license change

[Roger Fujii]

>On Tue, Feb 12, 2002 at 04:21:59PM -0500, Roger Fujii wrote:
> > 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.

it also restricts the ways and means of binary distribution.

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

I believe your case falls under the "work as a whole" clause.  The problem
in the wine context is that it is NOT clear that any propriatary library
doesn't fall under that clause unless you make it as a dropin replacement
for something that's already there.  And, if it's NEW functionality you're
adding, you must do it in such a way that it can be removed at runtime.
So, if your business model is to develop a value-add, LGPL is not your friend.

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

if you can make a propriatary extension, it holds that you can license the source
code for it some other way too.  If the point was that with enough effort, you can
roll (some of) the changes back in, then I agree.  But is this practical?
 
> 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.

this is a perceptual difference.  the legal mechanism for both is simply
conditions of the transfer of the copyright since neither case makes any
difference to anyone who doesn't distribute what they have to the public.

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

well, not according to that calif. ruling (in certain cases). 
 
> 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.

I don't believe anyone has said there is NO legal basis.  What has been
said is that there is little legal PRECEDENT.  There are various parts
to *GPL that are quite arbitrary (like, why is it legal to link with a .so,
but not a .a, or a .o?  what is being linked is the same) and is not clear
it will stand a good challenge.  As such, it's pointless to argue what it
means except in the cases that it's absolutely clear on.  For all other cases,
you are in untested territory.  
 
> 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.

until there is case law, what those words mean in the software context
is open to interpretation.  "Aggregation" of books may not be considered
the same as aggregation of programs.  If you need convincing of this, look
at the consent degree between the justice dept and M$ with IE in win98.

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

would you care to enumerate one that is the result of the license?

> So while an easily understandable license may be helpful
> to some, it doesn't eliminate the need for corporate lawyers.

you must know some INCREDIBLE lawyers.  The ones I have dealt with always
makes something simple really complicated.  If you know of someone that
can make something complicated simple, I'd like to have their #.

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

If lindows was just a branded version of wine, why are people getting so bent out of
shape about them contributing?

> 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?

I would presume a little of both.

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

'lots of'?  I really think you are overstating the case.  Gav doesn't think
so.  I think Michael Robertson has implied he didn't think so either -
the pie just isn't that big...

> > (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.

you may not have, but this statement has either been said or implied by
many in the *GPL camp.  It is a pervasive attitude that always makes this
topic more imflamatory than it needs to be.
 
> > 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;

this is a given, but they CAN still exist.  The notion that LGPL will prevent
that kind of behavior is just not true.

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

the misguided ones I think (MHO) eventually will contribute back, for the very same
reason you have stated (problems with keeping the trees synced).  Regardless, the
whole point boils down to this:

  Is the code you are going to coerce out worth the code that is lost by entities
  either unwilling or unable to abide by *GPL?  
  
There has been ample statements made saying that the latter part of the question
is not insignificant.  
 

> [2] Not a very sustainable business model, btw; on the whole, being evil 
> is no more profitable than being altruistic.

I agree that it's self-defeating, but there is nothing altruistic if you
EXPECT to be paid, whether it's cash, or code.  I haven't seen any
arguments for *GPL made here on altruistic grounds (not to say that *GPL
can't be used for such purposes - take quake from Id software for example,
but this is when you take something propriatary and *GPL it).  All I see
are pretty selfish - which is fine, as long as it's not being passed as
being altruistic.

-r