Wine, enthusiasts, businesses and the agony of the license

Patrik Stridvall ps at leissner.se
Sat Feb 9 07:50:53 CST 2002


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




More information about the wine-devel mailing list