New subject: Wine license change: it's about time!

7 Feb 2002


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

RE: Wine license change: it's about time!