What's lacking in this discussion is some sensible analysis of what a license need to contain to encourage future contributions to Wine and to protect the interests of the contributors. Fearmongering about Wine's future and paranoid delusions about the GPL license doesn't bring anything to the table...
Agreed.
Over to category two. Corel's source of income isn't from improving Wine, it's from selling their own work, Wine just makes their work more valuable. Here it doesn't really matter if Wine is BSD or LGPL (remember that the INTENT of the LGPL isn't to infect all and everything).
A company that chooses this route may have to improve Wine here and there to fill in the missing pieces to make their port work, and by releasing this patch they will contribute to Wine as a whole.
Unfortunatley they might not, don't underestimate the power of laziness. One other plausible reason is that some bean counter is afraid that someone else will pick up their work for free and make money out of it (i.e. Lindows) how'd you explain that to your shareholders?
Companies in this group have several choices: 1. Don't use new improvement in the main Wine tree, only resync then a new major version of the application should be released. 2. Maintain a tree by themselves, continually resyncing in order to make even minor version take advantage of new improvements in the new Wine tree. 3. Have some sort of wrapper library that implement all the improvments that they don't what to release, that in turns calls the Wine real corresponding Wine function. Now they can, if the designed it correctly, use new versions of Wine without any problem. 4. Release the code to the Wine project and be able to run with the latest version of Wine without any problem.
(1) and (2) are not very attractive. Resyncing the trees are quite time consuming. Especially (2) will not be fun at all. Both requires continously working with Wine.
In any case I guess most companies want the Wine adaption to be a ONE TIME cost not a continous one. Likely they want to hire specialists from companies like CodeWeavers.
This leaves (3) and (4). If you design (3) wrongly the application will break with newer version of Wine so it is not really a that good choice either. In addition it will require extra work just to be able to hide the improvments.
This leaves (4) ie they treat Wine is LGPL even if it isn't.
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.
Companies that decide to develop a new app and use Wine as the cross- platform framework also belongs to this group.
Partly, but new applications can avoid using unimplemented functions so they are less likely to contribute anything back.
Back to Wine again, the selfish motive here is to make Wine better faster. So if we get the choose between companies in group 1 or 2, who will contribute the most? Obviously the ones in group 1 will do the most work, since their living relies on a perfectly working Wine, unfortunatley they 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.
So what's the conclusion? Either you pick your favourite way of making business and lobby for a compatible license, or you start thinking out of the box and find the perfect balance that let's everyone keep the cake and eat it...
Well, that would be good.
However I'm pretty convinced that a very good solution would be not moving to LGPL. While perhaps not the ultimate solution, I have a gut feeling that no better soltion exists in the real world.
I'll be back tomorrow with more opinions, and my stab at thinking out of the box.
Your welcome.
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?
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.
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.
Companies that decide to develop a new app and use Wine as the cross- platform framework also belongs to this group.
Partly, but new applications can avoid using unimplemented functions so they are less likely to contribute anything back.
True. They can be more or less ignored for the purpose of this discussion.
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?
Regards, Fredrik
-
Fredrik Ohrn -
Patrik Stridvall