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.