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@free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.