- by Paul Murphy -
SCO's basic claim against IBM is simple. According to SCO, it is the legal successor to AT&T with respect to licensing of the AT&T Unix source code and its derivitives. IBM, they say, violated the contractual terms under which it has access to AT&T and related code by passing protected knowledge into the Linux development effort. As a result SCO issued a stop use order with the 100 day hiatus required under the contract but IBM neither changed it's behavior nor embarked on good faith negotiations to settle the issue. SCO therefore asked the court to enforce its rights under the contract.
By itself this was a straight forward contractual dispute that could, and should, have been settled quickly and easily.
History provides two opposite parallels to what happened next: the victory won by King Pyrrhus over the Roman legions at Asculum in 279 BC, and Rod Canion's victory over IBM in IBM v. Compaq, 1982.
The fundemental issue in the 1982 lawsuit IBM launched against Compaq was whether the PC would be the open architecture machine it became or remain, like the Macintosh, a proprietory one. IBM lost largely because the nuts and bolts of this focused on the PC's ROM-BIOS and Compaq was able to show that its subcontractor, Pheonix Technologies, had reverse engineered, not copied, key functionality found in IBM's product.
Software reverse engineering requires two teams neither of which has any members who have had previous contact with the source code of the product being reverse engineered. The first team analyzes the target product to write a specification based on what it does. The second team takes the specification and builds the replacement product. If the two teams have no contact except through the specifications document, and neither team is contaminated by knowledge of the original engineering, then the new product is considered just that: a new product and not an illegal copy.
It's possible, therefore, to recast SCO's basic claim as saying that IBM was contractually obligated to ensure that this type of "chinese wall" existed between those of its people who had some contact with the protected Unix knowledge or code and those of its people who contributed to the Linux development effort in the runup to the 2.4 kernel release, but failed to do it.
If SCO could show, for example, that any one of the people directly involved in IBM's authorized Linux 390 port had any kind of access to the AT&T derived code base, including the Monterey and Pink stuff, their case would be made. Quite aside from any "smoking gun" emails SCO may have, there are at least four feasible ways of doing that - none of which require a line by line source code match:
My guess is that SCO could meet these, or similar, requirements quite easily and therefore has every reason to be confident that the court will eventually enforce its stop use order against IBM.
(Notice, however, that I'm not saying that the code matches didn't exist; I believe they did, only that proving this isn't a necessity for SCO to prevail and therefore that most of the public noise, and consequently most of IBM's defence to date, is generally irrelevant to the original issue - except for their reliance on third parties for Linux licensing sales, that dodge will let them continue shipping product after the court rules against them.)
In the normal course of events, of course, the issue would long since have been arbitrated in the courts or settled through negotiation, leaving SCO ahead by a few million dollars in retro-active licensing and the Linux community pretty much unaffected. Unfortunately, somewhere after SCO's first Utah court filing and before IBM made its decision to continue selling AIX and other Unix products regardless of its license status, the normal process got completely derailed.
How that happened is anyone's guess but the bottom line is that it takes two to tango: someone saw the SCO side of this as a goldmine, and someone at IBM decided to circle the wagons rather than settle -perhaps as a residual consequence of the internal acrimony that led to the authorized System 390 port taking precedence over the the original (and probably uncontaminated) Linux for 370 project set up by Linas Vepstas.
Thus one of the first new filings by the Boies et al firm that took over leadership on the claim upped the ante considerably. In this version, SCO is made to claim nothing less than an all out attack on its rights and businesses by an IBM evily bent on the complete destruction of Unix business value - and therefore to ask the court for not less than a billion dollars in damages on each of five separate counts of action and unspecified, but substantial, damages on four others.
That filing was made almost two years ago and the legal process, now really just getting started, will run for a few more years if this isn't settled through negotiation. The community reaction, meanwhile, started before that second filing in June of 2003 and has developed a momentum that may see it do more harm to Linux than the court action itself ever could.
That's not to say that the lawsuits haven't influenced some more positive things too. Responsible members of the development community, for example, have reviewed and/or revised code and moved to emplace tougher standards for intellectual property protection in open source. Sun's Common Development and Distribution License (CDDL), to cite an other example, was undoubtedly influenced by the lawsuit and now offers a new way to extend legal protections to both the open and the proprietory parts of packaged solutions like Bitkeeper.
Others, however, have either publically or privately sided with IBM and intentionally or otherwise worked either to mislead the public on the issues or simply to focus attention on irrelavancies while whipping up what amounts to an anti-SCO hysteria. Unfortunately that's not a harmless activity in an environment where concensus rules and the negative consequences could, in the end, prove more damaging than anything SCO's worst detractors accuse it of trying to do.
First among these is something that I think of as the myth of immaculate conception according to which Linux sprang forth, fully formed, from nothing at all. Thus a reference, in my March 4/05 CIOtoday.com column to Mr. Torvald's having started Linux by hacking on Minix unleashed a storm of protest from believers denying that what Torvalds refered to as his "free Unix for the 386" could have started as "a better minix than minix."
Pamala Jones of Groklaw, for example, sent me fourteen emails starting with a gentle chiding for co-operating with SCO by believing this and ending by impugning both my integrity and my intelligence for failing to see the error of my ways (and then retroactively claimed copyright protection on her emails when I wanted to publish them!).
For the recond, however, here's how Eric Raymond, in The Cathedral & the Bazaar, described the process through which Linux came about:
Linus Torvalds, for example, didn't actually try to write Linux from scratch. Instead, he started by reusing code and ideas from Minix, a tiny Unix-like operating system for PC clones. Eventually all the Minix code went away or was completely rewritten -- but while it was there, it provided scaffolding for the infant that would eventually become Linux....
In other words, what happened with Linux was exactly the normal process you expect in open source: you start with some one else's code, hack on it until you really understand what you wanted to do with it, and in that process replace all the original code to make your own product. That's how a fall 1990 Minix kernel hack aimed at using interupts to speed processing became a new kernel by March of 1991 and a whole new Unix clone when file system processing was internalized in June.
Torvalds himself not only signed off on Raymond's essay but said something of deeper interest during a 1997 wired magazine interview with Glyn Moody:
In the summer of 1991 - just six months after he got his first PC - Linus found he needed to download some files. But before he could read and write to a disk, he recalls, "I had to write a disk driver. Then I had to write a file system so I could read the Minix file system in order to be able to write files and read files to upload them," he explains, as if it was the only reasonable thing to do. "When you have task-switching, a file-system, and device drivers, that's Unix" - or at least its kernel. Linux was born. "
That not only describes the process, but makes the point that Unix is fundamentally a set of ideas, not a bunch of computer code and exactly how you implement those ideas isn't all that important. That's really what the educational use of Minix is about -and the reason Tannenbaum apparently gave Linus a "C" for his kernel hack wasn't that the code was bad or derivitive, but that he disapproved of sacrificing design elegance for a performance benefit available only on the x86.
Notice, however, that the openness and legitimacy of the processes constitute the key differences between what Torvalds did to create Linux and what SCO accuses IBM of doing to bring it up to System 5.4 standards. Torvalds was working in an open, academic, environment within the scope of both Tannebaum's intent and the Prentice Hall source license for Minix. If you believe SCO (as I do) some IBM people undertook basically the same process: except that they worked in isolation and started with code and documentation whose confidentiality their employer was contractually committed to protect.
No matter what IBM did nor didn't do, however, what Torvalds did was laudable and not remotely something to be concerned about in the context of the SCO lawsuit. Instead the reality of the Minix/Unix heritage positions Linux squarely within the legitimate center of the academic and open source traditions - but that's not how believers like Ms. Jones see it.
To them, the fact that SCO ses Linux as a Unix clone not only makes holding that view morally wrong, but requires the immediate repudiation of non believers and indeed the remarketing of Linux as "not Unix" - a move that would replace the academic and open source heritage powering its development with a lie and thus destroy it.
The second example is more subtle. Here the position being run up the flagpole by what Stalin famously called "useful idiots" is first that the lawsuit itself is no longer a real issue and secondly that its consequences have been generally positive.
For example, here's how Matt Loney writing for zdnet on March 10/05 summarized a trial run of these ideas:
Speaking at Queen Mary, University of London, on Monday night, Open Source Developer Labs chief executive Stuart Cohen said the lawsuits were "the best thing that ever happened to Linux".Cohen, who heads the organisation that employs Linus Torvalds and lead kernel maintainer Andrew Morton, said that although the litigation is "nearly dead now", its legacy is the due diligence that was done around the world on the Linux code base.
"There was a lot of due diligence around the world with people looking at the code and looking at software stacks, and all this work validated that there was nothing there, no risk, no issue," said Cohen.
The problem here is that the underlying assumptions about the lawsuit being both over and baseless are unfounded, the claim that a failure to find copied code today proves that previous processes were uncontaminated is falacious, and the presumptive consequence about due diligence having been widely rendered is unsupported wishful thinking.
Fundamentally this is exactly the kind of outcomes based circular reasoning that leads to conspiracy theories -in this case probably one to the effect that a beneficient IBM planned the whole thing as unpleasant but necessary medicine. Sadly, however, there's an equally circular bottom line to this finding of a silver lining: if they can get enough people to believe it the consequence will be to vitiate the entire process, not only destroying the alleged benefit but giving responsible contributers a strong incentive to abandon the Linux community.