The SCO lawsuit, 20 years later
SCO claimed to be the owner of the Unix operating system which, it said, was the power behind the "global technology economy"; the company sold a proprietary Unix system that ran on x86 hardware. By that point, of course, the heyday of proprietary Unix was already well in the past, and SCO's offerings were not doing particularly well. The reason for that, SCO reasoned, was the growth of Linux — which was true to a point, though Windows had been pushing a lot of Unix systems aside for years. But Linux, SCO said, couldn't possibly have reached a point where it threatened Unix on its own:
Prior to IBM's involvement, Linux was the software equivalent of a bicycle. UNIX was the software equivalent of a luxury car. To make Linux of necessary quality for use by enterprise customers, it must be re-designed so that Linux also becomes the software equivalent of a luxury car. This re-design is not technologically feasible or even possible at the enterprise level without (1) a high degree of design coordination, (2) access to expensive and sophisticated design and testing equipment; (3) access to UNIX code, methods and concepts; (4) UNIX architectural experience; and (5) a very significant financial investment.
It was the claim of access to Unix code that was the most threatening
allegation for the Linux community. SCO made it clear that, in its
opinion, Linux was stolen property: "It is not possible for Linux to
rapidly reach UNIX performance standards for complete enterprise
functionality without the misappropriation of UNIX code, methods or
concepts
". To rectify this "misappropriation", SCO was asking for a
judgment of at least $1 billion, later increased to $5 billion.
As the suit dragged on, SCO also started suing Linux users as it tried to
collect a tax for use of the system.
Send in the clowns
Though this has never been proven, it was widely assumed at the time that SCO's real objective was to prod IBM into acquiring the company. That would have solved SCO's ongoing business problems and IBM, for rather less than the amount demanded in court, could have made an annoying problem go away and also lay claim to the ownership of Unix — and, thus, Linux. To SCO's management, it may well have seemed like a good idea at the time.
IBM, though, refused to play that game; the company had invested heavily into Linux in its early days and was uninterested in allowing any sort of intellectual-property taint to attach to that effort. So the company, instead, directed its not inconsiderable legal resources to squashing this attack. But notably, so did the development community as a whole, as did much of the rest of the technology industry.
Over the course of the following years — far too many years — SCO's case fell to pieces. The "misappropriated" technology wasn't there. Due to what must be one of the worst-written contracts in technology-industry history, it turned out that SCO didn't even own the Unix copyrights it was suing over. The level of buffoonery was high from the beginning and got worse; the company lost at every turn and eventually collapsed into bankruptcy.
At a talk some years ago, your editor got a good laugh by saying that, in
the SCO case, we had the good luck to be sued by idiots. SCO created a
great deal of fear, uncertainty, and doubt in the industry, but a smarter
attack could have been a lot worse. Even as it was, this was a period when
SCO was making waves by threatening to sue any company using Linux — at a
time when our foothold was rather less well established than it is now.
Microsoft, which had not yet learned to love Linux, funded SCO and loudly
bought licenses from the company. Magazines like Forbes were warning
the "Linux-loving crunchies in the open-source movement
" that they
"should wake up
". SCO was suggesting
a license fee of $1,399 — per-CPU — to run Linux.
All of this was a campaign to create a maximal level of fear around Linux and, as a result, to put pressure on IBM to settle. It certainly succeeded to an extent. Such an effort, in less incompetent hands, could easily have damaged Linux badly. As it went, SCO, despite its best efforts, instead succeeded in improving the position of Linux — in development, legal, and economic terms — considerably.
The enduring effects
Consider the charge of directly-copied source code — one that SCO CEO Darl
McBride loudly
made in May of that year. At the time, there was not a lot of
oversight applied to code going into the kernel; the project had only just
begun using BitKeeper as its first version-control system, after all, and
the maintainer hierarchy that has served the project so well was in its
infancy. It seemed almost inevitable that, among the millions of lines of
code poured into the kernel from an unknown number of sources, some would
be found to have been copied from Unix; source for various Unix
distributions was not hard to come by in those days. Richard Stallman allowed
that: "In a community of over half a million developers, we can hardly
expect that there will never be plagiarism
". The real question seemed be just how bad the damage
would turn out to be.
The world waited for McBride to actually show all this copied code — sometimes said to be "millions of lines" — that he had found. The actual code turned out to be a snippet in the ia64 architecture subsystem. It undoubtedly shouldn't have been there; interestingly, it had already been removed by the time SCO fingered it. Beyond that, SCO's claims touched on code — read-copy-update and the Berkeley packet filter, for example — that could not possibly have come from anything it owned. When SCO was asked to put up its evidence, all that came out was a bunch of handwaving.
The important part is this, though: SCO's efforts and those it inspired put the Linux kernel code under the sort of microscope that few projects ever see. There were allegedly billions of dollars at stake, after all. But despite that incentive and all of the resources poured into inspecting the kernel source, nobody ever found all that copied code; it simply did not exist. SCO managed to prove the cleanliness of the kernel's pedigree in a far more convincing way than anybody else could have. Nobody now questions the legitimacy of the kernel's source code.
Another thing that is no longer questioned is the need for the free-software community to have lawyers on its side. It is not enough to be right; we have to be able to prove that we are right and deter potential attackers. The SCO lawsuit brought about a substantial increase in the legal resources available to the community, both within companies and in projects and related organizations. Anybody who hopes to extract rents from the free-software community now will face a strong, united, and capable defense.
A related change is the improved procedures that the community has adopted; just because SCO proved that the kernel's code was clean doesn't mean it will always be. The adoption of the developer's certificate of origin for kernel code is one obvious example; its purpose was to avoid the next SCO case. As Linus Torvalds said at the time:
People have been pretty good (understatement of the year) at debunking those claims, but the fact is that part of that debunking involved searching kernel mailing list archives from 1992 etc. Not much fun.For example, in the case of "ctype.h", what made it so clear that it was original work was the horrible bugs it contained originally, and since we obviously don't do bugs any more (right?), we should probably plan on having other ways to document the origin of the code.
So, to avoid these kinds of issues ten years from now, I'm suggesting that we put in more of a process to explicitly document not only where a patch comes from (which we do actually already document pretty well in the changelogs), but the path it came through.
Many other projects have adopted similar procedures, most of which have the happy result of documenting the provenance of code without imposing heavy bureaucracy on the process. Efforts like SPDX are also partially motivated by the desire to avoid another SCO.
Long live the long-hair smellies
Perhaps the most significant outcome of this whole episode, though, is what it revealed about our community. If SCO wanted to scare developers and users into fleeing Linux, it certainly failed. While IBM waged a devastating campaign in the courts, it often seemed like many of the battles were won in the wider community; it turns out that, when thousands of developers and users join a fight against a common enemy, they can do amazing things.
Developers from across the community (occasionally referred to within SCO as the "long-hair smellies") put their time into debunking SCO's code-ownership claims, to great effect. Resources like Groklaw marshaled information for the defense and, just as importantly, informed the community about what was at stake and how the system works. Encouraged by this work, users stuck with Linux and refused to pay SCO's licensing demands. It was not just IBM's lawyers and money that won this fight; it was a widespread community that had built something special and had no intention of letting a failing company steal it.
Twenty years later, it is fair to say that Linux is doing a little better
than The SCO Group. Its swaggering leader, who thought to make his fortune
by taxing Linux, filed
for personal bankruptcy in 2020. We survived a focused and determined
attack that would have brought an end to many other enterprises, regardless
of the injustice involved. But the SCO attack should never be forgotten,
because of the ways that it changed our community, but also because,
despite our much stronger position now, it could happen again. The Linux
community has created a vast amount of wealth, whether measured in code or
in actual money; when that happens, there will always be those who wish to
steal some of that wealth. Hopefully we will be as lucky when the time
comes to fend off the next one.