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