Wine license change

[Francois Gouget]

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

   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.

   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.


   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.

   This means it is important that all the Wine players work together
rather going each their own way, each trying to complete Wine on their
own. None of us have resources to match those of Microsoft, so
separately we don't stand a chance.
   The LGPL can do for Wine what the GPL did for the Linux kernel:
provide the framework of trust that allows all players, including
companies, to work together towards a common goal.


--
Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
           Demander si un ordinateur peut penser revient à demander
                          si un sous-marin peut nager.