SCO V. IBM - SCO's Claims

SCO's Claims

SCO's lawsuit has been consistent only in its claim of breach of contract (since the abandonment in early 2004 of its claim of misappropriation of trade secrets). SCO's initial claims were:

• Misappropriation of trade secrets
• Unfair competition
• Interference with contract
• Breach of IBM Software Agreement

On July 22, 2003, SCO amended its complaint. It added two new claims:

• Breach of IBM Sublicensing Agreement
• Breach of Sequent Software Agreement

On February 27, 2004 SCO amended the complaint again. It dropped the trade secrets claim, but added the following claims:

• Breach of Sequent Sublicensing Agreement
• Copyright infringement
• Interference with business relationships

SCO's claims in press releases and interviews have changed repeatedly as the affair has progressed. SCO has also both claimed and denied that the alleged copyright violations involved the Linux kernel. Computerworld reported Chris Sontag of SCO as saying:

It's very extensive. It is many different sections of code ranging from five to ten to fifteen lines of code in multiple places that are of issue, up to large blocks of code that have been inappropriately copied into Linux in violation of our source-code licensing contract. That's in the kernel itself, so it is significant. It is not a line or two here or there. It was quite a surprise for us.

SCO refuses to allow access to the samples of code containing the alleged copyright violations except under a non-disclosure agreement (NDA). SCO's NDA would not only require that the signer keep confidential which lines of code SCO contested, but would also require that they hold confidential any information SCO told them, even if they already knew that information before being informed of it by SCO; all Linux kernel developers have considered this to be far too restrictive, so none of them have signed it. However, at SCO's annual reseller's convention in August 2003 they revealed two short sections of code they alleged were copyright violations, and images of Darl McBride's presentation of this code were soon after published on German computer magazine publisher Heinz Heise's website.

On May 30, 2003, SCO Group's CEO Darl McBride was quoted as saying that the Linux kernel contained "hundreds of lines" of code from SCO's version of UNIX, and that SCO would reveal the code to other companies under NDA in July. To put this into context, David Wheeler's SLOCCount estimates the size of the Linux 2.4.2 kernel as 2,440,919 source lines of code out of over 30 million physical source lines of code for a typical GNU/Linux distribution. Therefore, as per SCO's own estimate, the allegedly infringing code would make up about 0.001% of the total code of a typical GNU/Linux installation. SCO has since upwardly revised this figure to over a million lines of code, however.

SCO's major claims have now been reported as relating to the following components of the Linux kernel:

• Symmetric multiprocessing (SMP),
• Non-uniform memory access (NUMA) multiprocessing,
• the read-copy-update (RCU) locking strategy,
  • This technique is widely believed to have been developed at Sequent Computer Systems, who were then bought by IBM, who holds several patents (including patent 5,442,758) on this technique.
• SGI's Extended File System (XFS),
• IBM's JFS journaling file system

These claims flow from the accusation of breach of contract. The contract between IBM and AT&T Corporation (to which SCO claims to be successor in interest) allows IBM to use the SVR4 code, but the SVR4 code, plus any derivative works made from that code, must be held confidential by IBM. According to IBM's interpretation of the contract, and the interpretation published by AT&T in their "$ echo" newsletter in 1985, "derivative works" means any works containing SVR4 code. But according to SCO's interpretation, "derivative works" also includes any code built on top of SVR4, even if that does not contain, or even never contained, any SVR4 code. Thus, according to SCO, any AIX operating system code that IBM developed must be kept confidential, even if it contains nothing from SVR4.