Clarification on my call for license change
ps at leissner.se
Sat Feb 16 03:07:56 CST 2002
> On Fri, 15 Feb 2002, Daniel Walker wrote:
> > Wine is a _re_implementation .. 90% of the code we
> write is double
> > work, triple work sometimes .. It doesn't bother me that we had to
> > rewrite something, since after all that is what we do..
> Wouldn't we have
> > it easy is Microsoft would just release their source? The
> real question
> > is, if Wine was GPL'd would TransGaming have written the
> DCOM code in
> > the first place?
> No, the real question is whether Transgaming would have written the
> DCOM code if CodeWeavers had not released its typelib code in
> the first
Is typelib code really in the same DLL as DCOM code?
Note, I haven't checked, just asking.
> Because it seems to me that one of the main arguments of the BSD
> proponents is that we are stupid and that we should have kept all the
> code for ourselves. Maybe they are right.
What I mean is that you, as every other company, must formulate a business
stratergy and from this decide what code is strategic and what code
If you decide for example to be a pure consulting company, releasing
all code might make sense since you get paid anyway and a better Wine
means larger potential market and thus potentially more customers for
If like Transgaming you wish to improve DirectX, it might makes sense
to release non-DirectX code since they don't really have a business
model that makes it possible to recoup such costs. This I think
was made painfully obvious for Gavriel by Marcus reimplementation
of what they did.
> But which of the
> following two
> scenarios leads to the more healthy Wine and Wine marketplace?
It depends on what the market want and are prepared to pay for.
Since the market is unlikely to pay for random bug fixes,
except in some circumstances like support contracts, random bug
fixes have limited value. However releasing them for free,
increases the value of other products in the market, including
your own. Not only because some application will work better,
but because a more stable "ground" increases the trust in
that even seemingly working application really works.
> * The one where we released our window-management code, did dll
> separation work, added cross-process handle support, added
> messaging, released our typelib code (essential for InstallShield/COM
> support), released our true-type support, improved winelib
> and released
> countless bug fixes.
> * Or the one where the public Wine has none of the above (unless new
> volunters had magically sprung up out of thin air).
There is no reason to state the obvious.
But note that since it lies in your intrest to increase the quality
and public intrest in Wine it might not been a bad choice.
> Where would the first scenario, which appears to be what BSD
> proponents advocate, leave the Wine community?
I have said that you, like any other company, must consider what
is strategic and what non-strategic code for you.
It seems to me that Jermemy thinks that by using the LGPL
he can both eat the cake and have it and I have tried to explain
that this is not the case.
By using the LGPL you will force yourself in the future to release code
for the benefit of Linux distributions like Red Hat, SuSE, Caldera and
Mandrake that are likely to will sign support contract for Wine with
100+ seat companies by strength of already having one for non-Wine stuff.
Face it you will not have a chance against them.
Even Lindows will have a hard time I predict.
Sure you can still live by contracting and selling your proprietary
products like CrossOver, but then you can do that even with the
current Wine license.
> Which one do
> and Lindows prefer?
Why don't you concentrate on your own situation
without worrying about others.
> Do they really prefer not to benefit from
> any of our
> code in the future?
There is no reason to ask questions with obvious answers.
> The Wine competitive landscape has changed a lot in the past year,
> and I believe that it is unpractical for us to continue releasing all
> our code under the current license.
That may be, but from that doesn't follow that the LGPL is the answer.
> We could definitely turn our Wine proprietary but as the above
> scenario illustrates this would be bad for the Wine
> community, including
> for our competitors; even if they don't realise it. And I believe that
> all Wine companies need a thriving open-source Wine.
> That's why I think it is important for us (Wine community +
> CodeWeavers + Transgaming + Lindows) to find a better solution.
Yes, but the LGPL is not the answer.
In his initial question Jeremy was talking about CopyLeft,
not nessesarily LGPL. Why not continue the discussion
from that point?
More information about the wine-devel