Wine license change

[Brett Glass]

At 04:10 PM 2/10/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.

There are many projects using a BSD-style license, at every conceivable level
of maturity. Such a license is not at all a hindrance to a project that's
still incomplete; in fact, it can be a big help. Look at how much help
Apache got from individuals and corporations in its early days -- and has 
continued to get from major players such as IBM today! WINE can only hope
to be as successful.

>In other words, let's say Wine is "half-way" done (or more). Who would you 
>want to complete it? 

Alas, WINE will probably never be "complete." Microsoft is sure to keep the 
Windows APIs a moving target, as it has since the release of Windows 3.1.

>Yourselves or companies that would not contribute their 
>code back to the community?

Why do you assume that companies will not contribute code back? The BSDs, 
Apache, and X11 have all received major contributions from companies. And
these companies have all benefited from contributing, because the project
maintains the code and they do not have to re-integrate patches with each
new version.

>Didn't the fragmentation of Unix come from several companies using a BSD or 
>proprietary licensed codebase?

The greatest fragmentation of UNIX happened at the hands of AT&T itself.
AT&T created System V in an attempt to wrest control of the UNIX standard
back from BSD. It intentionally changed things just to make them different,
not to make them better. Vendors who had been licensing UNIX from AT&T 
tried to find a way to bridge the old and the new, each adopting different
portions of each "standard." This caused the "Tower of Babel" effect.

Fortunately, the fragmentation has since diminished. POSIX, the reincarnation 
of BSD as a family of complete operating systems, and the creation of tools 
which handle the minor differences between UNIX-like operating systems have 
spanned virtually all of the gaps. Nearly every open source program for 
UNIX (including very major apps like Sendmail, OpenSSH, etc.) now compiles 
under every UNIX-like OS.

>That fragmentation hasn't been a problem with Linux since it was GPL from day 
>one. 

Actually, Linux is more fragmented than the rest of the UNIX world. This
is due to the many, many vendors who are trying to differentiate their
distributions from one another. The BSDs are far more compatible with one 
another, and with commercial UNIXes, than the many Linuxes (I think there 
are about 60 distros right now) are with one another or with other UNIX-like
OSes. This shows that the GPL does nothing to prevent fragmentation
and forking.

>So Linus and the community are still the ones with control and ownership 
>of Linux, not any single company.

Linus only controls the kernel, and only just barely. There have been splits
between him and Alan Cox -- for example, during the recent controversy over
the VM system. And several parties whose patches have been "dropped on the
floor" due to Linus' limited bandwidth are now moving to create a fork that 
uses a "real" revision control system such as CVS. It's been said, though
I haven't been following minute-by-minute developments, that Linus may
finally capitulate and support the adoption of a revision control system,
as the BSDs did many years ago. But if he doesn't, the kernel will fork.

The vendors of the 60 or so distributions control what users see when they 
install, and introduce major differences such as changes to the directory
tree. This causes MUCH more fragmentation in Linux han there is in the BSD 
world. The BSDs share code, bug fixes, and refinements both in the kernels 
and in their "userlands" very freely. Even though they've diverged due
to specialization, code for one will run on another with few, if any changes.
And there is a movement toward a common API/ABI specification.... This was
discussed with great enthusiasm at Usenix in Boston.

>If several different *competing* companies take off with the existing Wine 
>code it will without doubt fragment. 

Not necessarily. It's doubtful that that there will be anywhere near as
many vendor-specific WINE implementations as there are distributions of
Linux. If the vendors are smart, they'll contribute back everything
that isn't absolutely strategic. And even if they don't contribute a feature
back, the group of core developers will implement it themselves if it's
important enough. We've seen this work very well with the BSDs.

--Brett