Wine license change

Sean Farley sean at
Mon Feb 11 00:35:10 CST 2002

On Sun, 10 Feb 2002 19:47, Francois Gouget wrote:

> On Sun, 10 Feb 2002, jasonp wrote:
> [...]
> > From what I've seen Wine is such a huge undertaking that there are still
> > large areas that are incomplete or in need of much improvement. That seems
> > different than some of the more well known examples of BSD licensed projects
> > that's cited as examples of doing fine with a BSD license.
> > In other words, let's say Wine is "half-way" done (or more). Who would you
> > want to complete it? Yourselves or companies that would not contribute their
> > code back to the community?
> >
> > Didn't the fragmentation of Unix come from several companies using a BSD or
> > proprietary licensed codebase?
> > That fragmentation hasn't been a problem with Linux since it was GPL from day
> > one. So Linus and the community are still the ones with control and ownership
> > of Linux, not any single company.
> >
> > If several different *competing* companies take off with the existing Wine
> > code it will without doubt fragment. In fact it seems like it already has. If
> > there are several different proprietary Wines floating around without
> > improvements and code available then the Wine group's leverage of being the
> > "official source" would diminish in a way that Linux, GNU, KDE, etc have
> > manged to maintain with the *GPL license.
>    This is a very important point. So much so that it is worth
> expanding, even if it means repeating it somewhat.
>    With the current license, if a company returns code to Wine it has no
> garantee that its competitors will do the same. Quite the opposite, it
> has all reasons to expect its competitors to take all that code, and put
> it in their products while not releasing any code of their own. These
> are the rules of the game with BSD/X11 licenses and I see nothing
> morally wrong with them.
>    But I believe that the results will be bad for Wine:
>  * only companies that don't depend on Wine will return their code.
> Examples are Corel, Borland and other software vendors who released
> products based on Wine. They are few and far between.

This is a falsehood.  Transgaming did not need to release their code.
IBM did not need to release their code for Apache.  BSDi did not need to
release their code to FreeBSD.

>  * other companies will keep their code to themselves, trying to lock
> users into their own version of Wine to insure future revenue, and this
> will cause the fragmentation of Wine. This has already happened: we have
> Lindows and to a certain extent CodeWeavers and Transgaming.

>    Fragmentation is not only bad because it causes duplication of work
> when the resources of the Wine community (companies included) are
> already limited. It also lowers the value of each of these Wine clones
> since they only handle a subset of the Windows applications. This is bad
> for the users too since it forces them to choose one or the other, or to
> buy Wine multiple times. For companies that want to deploy Wine on a
> series of computers the problem is compounded.

The duplication of work you mention does not really exist.  Someone in
the WINE community would have to write it anyway regardless of anything
outside the WINE CVS tree.

Did you decide to stop writing code just because a closed-source version
of code existed?  If people thought this way, GCC would never have been

>    Switching Wine to the LGPL will not cause the fragmentation to
> disappear right away. But it puts in place a framework where each
> company can return its changes to the core Wine while being assured that
> the other companies will do the same. It garantees that they will
> benefit as much from the work of others as others benefit from their
> work. This makes it reasonable for them to share their modifications.
>    As Jason pointed out this effect of the *GPL licenses can be viewed
> very clearly in the Unix kernels.
>    The original Unix was under a license similar to the current Wine
> license (with some proprietary components). Each Unix vendor took the
> code and modified it, which is fine. But this resulted into multiple
> versions of Unix, each tied to a specific architecture, each locking
> users into a specific version of Unix.
>    Had they cooperated, today's computing world would certainly be very
> different. But there was no incentive for them to cooperate, no
> framework that would foster trust.

As Brett pointed out, UNIX forked for other reasons (AT&T).

>    Contrast this with the Linux kernel. The GPL which provides the
> framework of trust. As a result we see many companies working together
> on the kernel, both small like Connectiva and RedHat, and big long time
> competitors like IBM and SGI. The GPL did not prevent them from working
> on the kernel, and it provides them with a kernel which evolves at a
> higher rate than each of them could achieve separately and lets them
> offer better products to their clients.

In this area, aren't IBM and SGI mainly hardware companies?  Aren't AIX
and IRIX operating systems written to sell the hardware?

>    There is still a lot of work to do to get Wine where we want it. Some
> dismiss Wine by saying it will never succeed because Windows is a moving
> target. I do not believe in this argument because what counts is whose
> APIs that are actually used by applications and this changes more
> slowly. Still Windows is evolving. Wine's shortcomings when it comes to
> COM and the InstallShield 6 installers is here to remind us of it. And
> no one can deny that Microsoft can put a lot of resources behind
> Windows.

The only comment I recall about this is Brett saying WINE will probably
never match Windows 100%.  It is very hard to match 100% a moving

scf at
PGP key:

More information about the wine-devel mailing list