Wine, enthusiasts, businesses and the agony of the license

Fredrik Ohrn ohrn at
Sat Feb 9 04:40:54 CST 2002

(I'm a part time lurker on wine-devel and use Wine to run those pesky
apps I can't live without. I regret that I've never mustered the courage
to work on and contribute to the code.)

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

First, what is needed to please the enthusiasts that write code on their
free time? As the variety of open source projects show, the exact license
doesn't matter, as long as the source is available and there is a
reasonable chanse to get your work included in what is perceived as the
"main" distribution, there's plenty of people around that want to lend a

Ofcourse, looking at individuals they have preferences, some prefer the
(L)GPL and other the BSD style and still others don't even get what all
the fuss is about. The point I'm trying to make here is that there's no
predominant license preference among the enthusiasts, so one can go either
way. Ofcourse a change will make some people jump ship, but it also opens
the door to new people who wouldn't have contributed under the old license.

Now over to the $64.000 question, how can one convince companies to do the
heavy lifting and still get them to share the result?

There are 2 obvious ways to make money of Wine. Either you take it as is,
package it and sell it as the ultimate Windows replacement (think Lindows
and TransGaming). Or you use it as the base to port your existing Windows
application (think Corel). And I'm sure there are several not so common
ways, like cherrypicking functionality to create the greatest MS-DOS based
registry editor ever made (don't laugh, I had to make something up).

A viral license would more or less kill the first way. Just as Brett Glass
pointed out, one has to add some secret sause that makes your product more
valuable than the free version of Wine. For example, Lindows has to fix
all bugs and implement everything that prevents Microsoft Office from
running properly, and keep this magic patch to them selves. The BSD style
is an obvious requirement for this business model to work.

Unfortunatley, this is very much at odds with the community, who are
working on Wine with the very same goal. To pharaphrase a previous poster,
Lindows is standing on the shoulders of a giants and the current license
is handing them the coat.

The fact is, that neither (L)GPL or BSD style solves this dilemma, if they
are allowed to keep thier changes secret it won't do anything for Wine as
a whole. If you force Lindows to release their work it will remove the
reason for them to do anything in the first place.

TransGaming belongs to this group too. Flame me all you want, but the only
difference between Lindows and TransGaming are thier long term intentions,
outspoken or implied.

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?

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! :)

Companies that decide to develop a new app and use Wine as the cross-
platform framework also belongs to this group.

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.

Another observation is that companies in group 1 are in direct competition
with each other, so they want closed source. If TransGaming released their
DirectX work BSD style, Lindows would quickly be there to appropriate it.

Companies in group 2 arn't competing directly (not to the same extent
anyway, they have the entire application market to play on, not just the
niche of making the perfect Windows replacement) so they would benefit
from a license that enforces sharing.

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

I'll be back tomorrow with more opinions, and my stab at thinking out of
the box.


   "It is easy to be blinded to the essential uselessness of computers by
   the sense of accomplishment you get from getting them to work at all."
                                                   - Douglas Adams

Fredrik Öhrn                               Chalmers University of Technology
ohrn at                                                  Sweden

More information about the wine-devel mailing list