SCO: spin and counterspin

In the end therefore neitherthe 2002 memo nor the underlying consultant's report say anything definitive abouteither SCO's guilt or IBM's innocence - but the combination could be eventually used to trumpan IBM argument of the "you did it too" variety.
Written by Paul Murphy, Contributor
Last week the court refereeing the SCO Vs. IBM case allowed the release of a 2002 memo in which SCO employee Michael Davidson reported the failure of consultant Robert Swartz's efforts to find copied Unix source code in Linux. "No smoking gun," he said.

Unfortunately for the anti-SCO crowd the rejoicing had barely started before the wheels came off when it turned out that the consulant had indeed found instances of copying: "first many portions of Linux were clearly written with access to a copy of Unix sources"... "second there is some code where Linux is line for line identical to Unix" and "thirdly, there are also portions of the programs which appear to have been rewritten, perhaps for the purposes of obfuscating that the code is essentially the same."

Unfortunately for SCO, however, those statements appear definitive only if taken completely out of context. In context, the report describes these conclusions as "preliminary" and suggests that the similarities could come from legitimate sources such as the BSD code base.

Oddly, what neither side seems to have noticed in the ensuing uproar is that the comparisons predate the disputed actions: what Swartz looked for were congruencies between Red Hat 5.2 Linux and the Intel specific source files for SCO Openserver, Project Gemini, and Unixware -all from 1998 and earlier.

To the extent that any IBM people worked on the Linux code base before the Bvblingen 390 port in 1998/9 that work would have been covered in the agreements leading up to projects like their work on embedded Unix, the PowerPC port, and collaborative Unix projects like Gemini and Pink. That work was done almost entirely by Americans used to working with tight legal controls and no misuse of the AT&T source would have been tolerated either in project work with third parties or within the Austin group working on support for IBM's own PowerRISC and Intel lines.

What that means is that the code covered in the consultant's comparisons is fundamentally not at issue in the dispute -because all the code involved predated the Bvblingen effort to bring Linux to the mainframe.

There are, nevertheless, two very interesting things about this consultant's report. One of these is the question of how you can fairly compare two code bases -something I'll talk about Friday; and the other is its potential use in the legal case at hand.

Suppose, for example, that SCO eventually shows that the Linux development tree giving rise to SuSe 7.0 and subsequent releases through to the post 2.4 fixes contained improperly derived code. In that situation Swartz's report could become the basis for an argument aimed at establishing that it did not get there legitimately -i.e. as part of Caldera's contributions to Linux or through one of SCO's development agreements with IBM, Apple, or Microsoft.

In the end therefore neither the 2002 memo nor the underlying consultant's report say anything definitive about either SCO's guilt or IBM's innocence - but the combination could be eventually used to trump an IBM argument of the "you did it too" variety.


Editorial standards