OSCON 2004: The SCO Moot Court
Pages: 1, 2
Mark Radcliffe then took the stage, to argue IBM's position. As you might expect, he started by saying that SCO hasn't given the full story in some respects.
Mark framed his talk rhetorically around the phrase "strong magic". SCO needs strong magic to make the claims that it's making. Remember, this is a business that has failed twice, first with Unix and then with Linux. He suggested that SCO's management has asked "How can we turn this smoking crater into a business?" How can we turn an antique Unix codebase into Unix code?
At its base, Mark explained that SCO's claim is a contract dispute. The meaning of the contracts is vitally important. Though the contracts are messy in some cases, they're very clear in other cases.
Unfortunately, the contracts don't fully define what SCO bought. They did buy the UnixWare business, but the contracts define it unusually. They did not buy the copyrights, as they appear in the original list of excluded assets.
Amendment 2, issued a year later, attempted to change this, but being an exception to an exclusion, it's not clear. IBM believes that the exception to the exclusion of copyrights does not apply in this case. (This was difficult to follow, perhaps a sign that the contracts are especially strange.)
One of SCO's biggest claims against IBM is that IBM violated its confidentiality agreement with AT&T. However, SCO voluntarily dropped its trade secret claim earlier this year.
Mark put forth the argument that claiming trade secret protection for Unix is impossible. To keep a trade secret, you must take reasonable steps to protect the secret and the secret must not be widely known in the industry.
Of course, Unix is widely known. AT&T distributed Unix widely before the anti-trust agreement 20 years ago. After 1984, when AT&T tried to make a business out of selling Unix, the USL-BSD suit failed. Now that this confidentiality has gone, SCO cannot retrieve it.
Mark continued with a series of explanations of why the infringements do not apply. Even if they did, however, IBM supports Novell's conjecture that Novell has the ability to waive violations. Novell sent IBM a letter formally waiving any restrictions on Unix on SCO's behalf. That's very important.
Even if there were a violation, Novell has waived it for IBM.
For example, in Amendment X to the Novell-SCO agreement, IBM acquired "perpetual and irrevocable rights" to Unix. Mark claimed that IBM in fact has a statement from SCO explaining that restrictions on the use and confidentiality of Unix do not apply to IBM's code.
The biggest question so far is what kind of code could and did IBM share with Linux. Is this actually Unix, or is it derivative code, to which SCO can claim some rights?
SCO has made no statement as to which this code actually is. IBM believes that Linux is not a derivative work of anything SCO can claim copyright over. Even if it were, it wouldn't matter, as Novell has waived any violations on SCO's behalf.
SCO has claimed the authority to terminate IBM's ability to distribute AIX. Unfortunately, that flies in the face of IBM's "perpetual and irrevocable" rights to distribute Unix. There's a long history of contracts in which "irrevocable" has never meant "revocable"--that's why IBM paid millions of dollars for the license.
In any case, if there were a violation, Novell's letter has waived it anyway.
Even if SCO didn't realize that it wanted to claim ownership over Linux, it distributed Linux under the GPL voluntarily--the very product that it claims violates its rights. Since SCO did it voluntarily, it cannot rescind the permission it gave.
Besides that, consider that anyone who can demonstrate a legitimate claim of overship to code distributed by SCO under the GPL--which SCO now considers infringing--may have a right to damages for SCO violating the GPL by putting additional conditions on the code that the GPL does not allow.
As did Jon, Mark explained that the contracts at the heart of this contractual dispute are somewhat odd. Again, Amendment 2 is an exception to an exclusion that allowed SCO to assert its rights if necessary. If they were truly important, why did SCO wait so long?
Mark proposed that SCO didn't care until it entered the lawsuit business, pointing out that SCO's lawyers had bet heavily on the first version of Napster as well as Aimster. He left the question of SCO's judgment on copyright issues to the audience.
More importantly, the traditional language a lawyer would expect to find in a contract for transferring copyrights actually does not appear in the SCO-Novell contract. Since lawyers try not to transfer contracts accidentally, this appears to be deliberate. Perhaps the parties intended to transfer some copyrights in the future, but IBM does not believe that the current language of the copyright performs this.
As mentioned many times before, there's a very strong possibility that there are no existing copyrights to Unix as owned by AT&T after the 1984 breakup. Again, the USL v. Berkeley lawsuit was an embarassing trainwreck for USL. AT&T had paid no attention to its confidentiality or the formality of copyright laws. The company tried to enforce this copyright, but it had distributed many copies of Unix without the license attached. Think of it as a disregard for their copyright--if they have done that enough, Unix would be known widely and USL would have little room to start enforcing the copyright.
Mark then attacked the similarities to music copyright cases. The ratio of a few seconds of melody found in a three-minute song is immensely greater than the ratio of a few hundred lines of code to a ten-million-line operating system. Even if this code does infringe, it's hardly substantial--besides, Novell has waived the violation.
IBM interprets Amendment X to mean that it can use the methods and information it learns from Unix to make other operating systems. IBM believes that it has done that. If so, the company's position is very strong.
Mark then repeated that SCO has neglected its duties under the GPL by trying to place additional restrictions (its licensing fee, for one) to code already licenced under the GPL. This is actually a copyright violation.
Worse, SCO has neglected its duty to its shareholders by wasting millions of dollars on stupid cases instead of building a viable business. In the end, SCO brought the case to a court of law, not a court of magic. SCO needs to prove its case on facts and the law but have failed to do so.
The end result was enlightening. While SCO's claims had always seemed somewhat dodgy, I had never really understood how Byzantine its claims were--especially in relation to its contract with Novell.
On the other hand, as the question and answer session at the end reinforced, it's uncommon for open source project leaders to make sure that contributors have the right to make unencumbered contributions to their projects. The initial paperwork to vet the copyright of patches is daunting, but it may be legally necessary for now.
Of course, as one questioner pointed out, it's very easy for open source and free software to make its way into proprietary products, never to be found. One large benefit of publicly developing software--the transparency of the process--makes it easier for companies to claim potential (or real) infringement.
The real solution will likely include continuing to fight bad copyright, patent, and trade secret laws and judgments, working with intellectual property lawyers who want to do the right thing, and being very careful that copyrights on distributed code are very clear.
Return to the OSCON 2004 Coverage Page