The Linux wars?

It's part of BSD history, almost folklore: when AT&T discovered that BSD was viable as an operating system even after removing all AT&T code, they did what big companies have to do: they sued.

I'm not going to drag up all the sordid details of that story again. There are plenty of references. A good one is Dennis Ritchie's overview. Google finds quite a few more. In brief, though: this particular incarnation of AT&T was called USL (UNIX Systems Laboratories). In April 1992 it alleged, amongst other things, that BSDI had used AT&T code in their system. They refused to say where, but when the suit was finally settled out of court, the conditions of the settlement included the removal of six files in /usr/src/sys/kern. Many people then went to look at these files, of course, and found code which indeed did look as if it had been derived from Research UNIX. One example is the implementation of timeout(), now in /usr/src/sys/kern/kern_clock.c. It was effectively unchanged since 4.2BSD. It was rewritten in 4.4BSD-Lite (4.4BSD kept the old version), so the problems went away with the import of 4.4BSD-Lite, which corresponded to later releases of the free BSDs.

The lawsuit really only related to BSDI (or BSDi, as they were called later before they became part of Wind River Systems ), but it was important for the other BSDs because of the FUD that it created. Most BSD people and the majority of Linux users agree that this FUD resulted in Linux being able to overtake the BSDs despite being much less well developed at the time. The result was that more and more people worked on Linux, fewer on BSD. When the press discovered free UNIX-like operating systems and told the world about them, the name was synonymous with ``Linux''.

That may be changing. We seem to be seeing the whole thing all over again, but this time it's happening to Linux. On 9 March 2003, SCO sued IBM for giving away trade secrets. There's more to say about this issue than will fit in this article. I'm keeping an ongoing analysis of the complaint.

UNIX code in Linux?

It didn't stop there. On 12 May 2003, SCO sent a letter to their customers. Amongst other things, it states:

We believe that Linux is, in material part, an unauthorized derivative of UNIX.

It has certainly taken them a long time to come to that conclusion, and they offer no evidence. Instead, they resort to conjecture:

Many Linux contributors were originally UNIX developers who had access to UNIX source code distributed by AT&T and were subject to confidentiality agreements, including confidentiality of the methods and concepts involved in software design. We have evidence that portions of UNIX System V software code have been copied into Linux and that additional other portions of UNIX System V software code have been modified and copied into Linux, seemingly for the purposes of obfuscating their original source.

The details that appeared in the press were relatively vague. The Board of Directors of AUUG, the Australian UNIX User Group, decided to issue a press statement about the matter. As president, I found myself in the position to tell SCO Australia about it. On Tuesday, 27 May 2003, I spoke to Kieran O'Shaughnessy, managing director of SCO Australia. He told me that SCO had entrusted three independent companies to compare the code of the UnixWare and Linux kernels. All three had come back pointing to significant occurrences of common code ("UnixWare code", as he put it) in both kernels.

In view of the long and varied history of UNIX, I wondered whether the code in question might have been legally transferred from an older version of UNIX to Linux, so I asked him if he really meant UnixWare and not System V.4. He stated that it was specifically UnixWare 7, which doesn't agree completely with the letter to their customers.

He wasn't prepared to say where the offending code is located either, of course. He suggested that they could reveal that information under a non-disclosure agreement. I've done some thinking and came to the conclusions:

Why do you need non-disclosure for code that has already been released in the Linux source code?
The Linux and UNIX kernels have very different structures. It's very difficult to copy code from Linux to UNIX or the other way round.
Linux source code is freely available. UnixWare source code is not, even less than many other proprietary UNIX implementations. Thus it would be easier to copy code from Linux to UnixWare then from UnixWare to Linux.
I have seen instances of open source code included without attribution in a specific vendor's System V source tree. No, I'm not going to say who it is.
One place where code sharing would make eminent sense would be in code designed to emulate the other kernel. For example, recent versions of UnixWare include Linux emulation. There are two ways to approach this task: write it from scratch or copy the Linux code. The latter would work better, but it would also require releasing the entire UnixWare kernel under the GPL. The BSDs stood before a similar problem. We don't want to be subject to the restrictions of the GPL, so we wrote the Linux support from scratch.
But what about Linux taking the System V ABI code from UNIX? Well, yes, they did that, legitimately. One of the main companies involved in its development was Caldera. See Linux Support for Non-Linux Programs and the Linux ABI project for details. At the time he wrote it, Christoph Hellwig was working for Caldera. But this is an irrelevant detail: it's a patch, not in the base Linux kernel.

All of this is pure educated conjecture, of course. But I'm sure I'm not the only one who has come to this conclusion. If SCO is innocent, it's easy enough to prove it--now. They only need to point to the offending code, which is a good idea even without such theories. If they do it later, they'll leave themselves open to charges that they have rewritten the Linux support in the meantime.

Why are they doing this?

As you can see from the message of 24 January 2002, SCO has changed its attitude to free software completely in the last 15 months. Why?

Obviously there are commercial reasons here. SCO is in trouble. For some time they used to be called Caldera, and their main product was Linux. In mid-2002 they changed their name back to SCO. A high-ranking SCO employee told me at the time that the reasons for this were that they were still making more money out of UNIX than they were out of Linux. This seems reasonable, but it's an open secret that SCO is not making much money out of UNIX. This lawsuit could help them in a number of ways:

The most obvious would seem to be that IBM might find it easier to buy them out than fight the lawsuit. That would be a gamble, of course: if IBM chooses to fight the lawsuit, I don't believe it will complete. SCO will go broke first. But SCOs market capitalization is so low that it might be cheaper to buy them out than do the preparations for the lawsuit.
Another reason is to bolster the price of SCO stock. This seems to be happening ("working"?). On 3 March 2003, the day before they announced the suit, it closed at $1.83, a relatively good price at the time: two weeks before that it was as low as $1.09. Since then it has climbed to nearly $9, and at the time of writing it's still over $6. If the stockholders are looking for a way to get out before the crash, this might help.
Then there's the conspiracy theory: Microsoft is funding them to break up Linux. An article in the Wall Street Journal of in mid-May 2003 carries the headline:

Microsoft agreed to buy rights to Unix technology from SCO, a boost to SCO's efforts to get royalties for a predecessor to Linux.
I'm not a subscriber to the Wall Street Journal, so I can't read the article, but I'm told that the article considers SCO's UNIX patents and source code to be valuable. I doubt that this is the main reason. It's fairly clear that the most significant issue here is Linux, and this is in fact quite a clever way to attack Linux. It's a good thing that the BSDs have already settled their UNIX licensing issues.

And the BSDs?

We BSDs have all the litigation behind us, and it's easy to gloat over Linux's misfortunes. That's inappropriate: this business has occurred through no fault of the Linux community. It's merely an indication of the sorry ethical state of modern businesses. If the BSDs had been as successful as Linux, you can bet that SCO would have found a (probably more plausible) way to sue us instead. Yes, in the settlement of the BSDI wars appears to contain an agreement that BSDI will never again be sued for AT&T proprietary code in the sources. But how much does that count? Firstly, it's no longer the same company, and secondly they might assert that new code has been imported. Or, as in the current case, they may just not state their reasoning at all. We should all hope that this whole mess is cleared up as quickly as possible, and that the Linux code base should be shown to be free of license violations.

Nevertheless, the current situation does offer a certain advantage for the BSDs. To a certain extent, the playing field has been leveled. What is happening to Linux is certainly scaring a number of people who would otherwise have used it. They will be looking for alternatives. We have them.

That doesn't mean we should go out shouting "Linux bad! BSD good!". In particular, there are a number of questions we need to ask ourselves.

Do we want to take over the world?

Do we really want a BSD on every desktop? My suspicion is that we don't. There's an impression out there that Linux is a better desktop operating system than BSD, despite the fact that the software is all the same. Yes, Red Hat and Co. offer shiny install programs that look more and more Microsoft-like, and it's true that that sort of thing does impress inexperienced users. But the software available to run on top is pretty much the same. One difference is the way in which Linux users and BSD users use their system. At various conferences I've looked at a number of laptops running BSD and Linux. Almost invariably, the Linux laptops were running a "desktop" like Gnome or KDE. You see BSD laptops with the same software as well, of course, and without the uname command, you may have difficulty deciding what the operating system is. Even with the uname command, you may see confusing things like:

Linux wantadilla.lemis.com 2.4.2 FreeBSD 5.0-CURRENT #1: Sat Oct 26 11:16:38 CST 2002
    grog@cu i386 unknown

That's the output of the Linux uname binary on my "desktop" machine (actually hidden behind my monitors, where I have to walk quite a way to get to it).

But I have also seen a lot of other BSD laptops which are not running Gnome or KDE. Mine doesn't: I have both Gnome and KDE on my laptop, but the one I use is fvwm2. Others I've seen use even more "primitive" window managers, and some don't use X at all. These are not stupid people: they're some of the most active BSD developers. Obviously there's a difference in mentality here.

Where do you want to go tomorrow?

Coupled with this attitude is the question about where the development direction of the projects should go. FreeBSD is very definitely directed towards "server" operating systems. NetBSD is more interested in portability and (thanks to Wasabi) embedded applications. OpenBSD is interested in cleanliness and security. None of these have very much to do with the vision of a BSD on every desktop, nor particularly with ease of use (though I believe that we should be looking at that issue more carefully). If we try to take a slice of Linux's pie, we may find ourselves compromising beliefs that we hold dear.

Who will do the marketing?

Linux didn't become mainstream by itself. Its success started with a few vocal advocates, but without outside help it wouldn't have got much further. The critical change came when commercial companies became involved. They paid more attention to the interests of the user than to the interests of the developer and did things like product management, marketing and development of "toys" like graphical installers. We don't have anybody doing that at the moment. If we decide that we do want to go into this space, these are issues that we will have to address.

Where to go from here

Assuming we can answer "yes" to the questions above, how do we go about it? The obvious thing is to get articles into newspapers and non-technical magazines. I'm planning to do so here in Australia; it would help for other people to do the same, often at a local level. No matter what happens, this should be good for the BSDs. The next few months promise to be interesting.