On Sat, 9 Feb 2002, Patrik Stridvall wrote:
I think you will be able convince both the lazy person above as well as the bean counter that this will be the best long time choice.
If Wine is LGPL they must release the patch if they want
to reap the
benefits of using Wine, and they can release it without
fear of giving
away money to someone else. It can even be argued that the LGPL makes Wine an even safer bet, since it guarantees that other companies in this group will chip in, this way Wine will be in even better shape when the first application was a smash hit and they decide to port their
next app! :)
Correct, but this is likely to be true anyway for reasons
given above.
This is what I imagine the LGPL proponents are dreaming
about at night.
Unfortunately it is a dangerous dream since it total ignores the drawbacks with a LGPL:ed Wine.
The drawback would be that it locks out the companies from group 1 (yes, you have pointed out technical problems that might render the LGPL worthless, but I'll leave the bugfixing for now, lets just assume it actually works).
My question is, to you and everyone else, how valuable are this kind of companies to the Wine community?
A relevant question, unfortunately the problem is much more complex that that.
Assuming that LGPL really prevents wrapper libraries have very far reaching consequences. I have tried to give example of specific cases like the Joe Hacker hobbist with his proprietary hobby related library and his proprietary Windows application and his wish not to dual boot.
I asked whether doing this (or for that matter preventing) this was among other things ethically or morally defendable.
You can't just focus on the companies that wish to profit on Wine in some way.
But yes, short answer: I believe such companies like Transgaming is valuable for the simply reason that our resources are limited, this allows us to concentrate on improving other parts of Wine.
If in the future decide that hey now that we have more developer resources, now let do a really free DirectX, we can do that.
Always remember that: He who defends everything, defends nothing.
In short a strategic retreat means that we get resources to defend what we have and later take it back as we grow stronger.
Yes, they may make progress fast, maby they are even required to take Wine from the allmost but not quite stage to actually reach that elusive goal of 99.9% Windows compatibility.
But at the same time this progress may never make it back to the community. And as pointed out by Alexandre, in the worst case scenario they may halt or slow down progress in the free version, because there is no incentive to implement some missing peice when it already exists and can be bought cheaply from company X.
Well and as I pointed out. Most people have a Windows license and many Micrsoft DLL work fine under Wine.
Yes, I know he thought that to was bad too. But then you can't both have the cake and eat it.
The same thing with other proprietary extensions, except perhaps better from Alexandres point of view, since much more people have Windows licenses than a random proprietary library.
The limited experience shows that things has worked out OK. It will be interesting to see what Lindows ends up doing, I wish they would skip the maketdroid speak for a while and join this discussion.
Agreed.
have the least to gain from contributing anything back. The companies in group 2 have the least incentive to work on Wine, just
fix the bare
minimum to get their application to work, but instead
they can allow
themselves the luxury to contribute and score some goodwill.
Since companies in group 2 are likely to contribiute back anyway for reasons given above I see no reason to hurt group 1 companies.
Yes, each and every one has to go back to his own motivation for working on Wine, does it matter if the group 1 companies get a free lunch?
Well, all users of Wine already get a free lunch, and they might already profit from being able to run say Microsoft Office under Linux so if you are worried about people getting a free lunch you already have a serious problem.