Wine license change: it's about time!

[Patrik Stridvall]

> On Thu, 7 Feb 2002, Dan Kegel wrote:
> 
> > It's about time.  Putting Wine under the xGPL is the best way
> > I can think of to ensure its future.  The xGPL makes it possible
> > for competitors to cooperate for their common good - which 
> is pretty amazing.
> 
> This is a fundamental point which we haven't had a chance of 
> discussing
> last time as we argued over silly future (unlikely) possible 
> changes in
> copyright law.

I think you missunderstood what I was saying I said that I believe
that the courts eventually will interpret the CURRENT law as I
suggested since it the way that IMHO makes the most logical sense.

For the law to perform as you wish will require very complex and
possible self countradictory or unconstitutional interpretations.

Anyway, there is no reason to restart that discussion.
I and Alexandre have in private mail agreed that we disagree
and the discussion is ended.

Lets for the sake or argument assumes that the LGPL can do what you
believe it can. I will try to in this and latter mails explain
why this is not a good idea for a project like Wine that is
not an ordinary library like the LGPL is designed for.
 
> One important argument was that building a thriving economic 
> environment
> around Wine is essential for its success.
> 
> Everybody agreed on this premise, IIRC.

Yes.
 
> The argument followed that BSD license is better for creating such an
> environment, and hence better for Wine, since more business will
> contribute more code back.

Yes.
 
> This, I'm afraid, is entirely false.
> 
> I argue that in fact, the BSD license is a STRONG DETERANT 
> for businesses
> to contribute code back, while the LGPL provides an INCENTIVE.

For normal libraries this might have some (but only some) truth in it .
However Wine is not a normal library as in vain tried to explain last time.

Trying to claim that LGPL is good for Wine because (and only because) it is
good for normal libraries is pure nonense.

There are fundamental differences among them:
In the normal LGPL:ed library world, an application that demands some extra
functionallity in some LGPL:ed library can do that by implementing
that functionallity is the application itself or possibly if the extra
functionallity is extensive in a new library. No need to extend the LGPL:ed
library. Here LGPL doesn't hurt at all. The application or for that matter
the new library can be of any license. You would be hard pressed to claim
derivation even if the new library calls your LGPL:ed library. Claiming
derivation for the application is clearly absurd.

Another difference:
In the normal LGPL library world, the application will need the extra
functionallity for the NEXT version.
In the Wine world, the application will need the extra
functionallity for the CURRENT version since it already
work on Windows.

> Note that I do not care, for the purpose of this discussion, about
> businesses which don't intend to contribute code back. They 
> are of no help
> to Wine, and thus irrelevant (if not a little harmful, for reasons so
> eloquently explained by Alexandre).

Just because they initialy decide not to contribute back doesn't
mean that they won't do it in the future then they for example
see the work of keeping a seperate tree. Or like in the case
of Transgaming when they feel their income is secure.

You can't just dismiss such businesses as irrelevant.
Irrelevant now, perhaps. Irrelevant tomorrow, maybe, maybe not.
 
> A BSD license is a STRONG DETERANT for a business to contribute code
> back. The reason for this is that they have no guarantee that another
> business will not improve a little the code, and thus get a 
> competitive
> advantage. Or that other companies will not use that code on 
> top of the
> code they wrote but not released, and thus again, get that 
> edge.

What competitive advantage?

I don't believe that you will see many business model that will make sense
in the Wine world will compete head to head with some other business model,
including the main tree.

They will select a niche and try and live there. Some will succed some will
not.
However there is no reason to make survivial harder.

> This is a
> fantastic _deterant_ for releasing code back. In fact, Gav validated
> exactly this point when he tried to argue for the BSD license 
> last time:
> 
>   <talking about the DCOM work>
>   But there are companies out there who will benefit significantly 
>   from commercial use of this code, and who can afford to sponsor a 
>   portion of the development cost.  Until such a sponsorship happens, 
>   we cannot apply the WineHQ license to that code.  
> 
> In other words, they needed that code. They invested some money do get
> it. They are happy with the results. Why not release the 
> code? They have
> what they needed in the first place? The reason is clear -- 
> it cost them
> to get there, they can not aford to bring everybody there for 
> free. I can
> 100% understand that. But if the code was under the LGPL, it would not
> matter, because even if they brought everybody there, other companies
> could not step ahead of them, since if they did, they themselves could
> have used that code.
> 
> In other words, TG could have kept Direct3D proprietary, released
> everything else back under LGPL, and they could have _known_ 
> they still
> have the competitive edge in the D3D work! This is why the 
> LGPL is in fact
> an _incentive_ for such colaboration.

Read Gavriels reply. Need I say more?
 
> Bottom line is clear: as the project matures and becomes more 
> useful, the
> deterant of contributing code back from a business 
> perspective is going to
> greatly increase, while at the same time, the incentive under the LGPL
> would have also increased.

This is a just claim without an sort of proof. For head to head competitors
it has some (but only some) relevance. However this is not the kind of
business models we are likely to see IMHO.
 
> In economic terms, for Wine, one spells death, the other, life.

Another grandiose claim without any substance. The world is not that
simple. Both approaches has their pros and cons but neither is life
not death.