SCO NDA Online at LinuxJournal
shadowbearer writes "The full text of the SCO NDA is available here at LinuxJournal. IANAL, but my reading of it makes me understand all the industry "No way!" style comments. Here's a snippet:
"Dan Ravicher, an attorney who specializes in free software and open-source issues at the firm of Patterson, Belknap, Webb & Tyler, said in an interview there are three key problems with the NDA. First, Ravicher said, "SCO can pick and choose among all its evidence" to show only the parts that back up the company's claims. "They're agreeing to let you see the half of the picture that they want you to see", he added.""
"Dan Ravicher, an attorney who specializes in free software and open-source issues at the firm of Patterson, Belknap, Webb & Tyler, said in an interview there are three key problems with the NDA. First, Ravicher said, "SCO can pick and choose among all its evidence" to show only the parts that back up the company's claims. "They're agreeing to let you see the half of the picture that they want you to see", he added.""
"IN CONSIDERATION of the mutual promises ..."
This contract was created by only one side of the deal. So it's worded precisely the way SCO wants it for their maximum advantage. Usually in a dispute courts will favour the party which didn't create the unilateral contract, but it looks like they've covered off that angle by choosing Utah.
Bilateral contracts, where the parties negotiate and both have input into the final wording signed, are much safer as a rule.
This is a one-sided contract by a known litigous company.
The person signing gives up all kinds of rights, is straitjacketed legally, and doesn't even make any money on this.
All the risk with no reward.
What could the counterparty to SCO possibly gain by agreeing to this?
I usually try to be ambivalent, but can't seem to find anything redeeming here.
Esteem isn't a zero sum game
[Claimer: I worked at USL and Novell doing configuration management for parts of Unix System V from 1993 to 1996. Disclaimer: I have no involvement with the development of Linux or any proprietary Unix now.]
They probably won't have to go to AT&T or Novell for historical data, except as secondary verification. SCO has the source code repository (in ClearCase and in other formats) going back to 1984 and, for some things, earlier.
IANAL, but if I were working for SCO and were asked to prove the charges, showing the matching code would only be the first step. The second step would be to show where the code was first introduced in the USL-originated repository. The third step would be to be prepare to show that the timelines in the repository were not altered (think "cleartool setevent"; this is where AT&T might come into the picture). The fourth step would be to show that the code was the IP of SCO or its ancestors from the day it was checked in (i.e., it's not itself stolen GNU code or something). The fifth step would be to show (possibly through subpoena of the AIX source repository) that the code in question was introduced into AIX as a result of a code drop from SCO or its ancestors. The sixth step would be to show (through examination of the Linux [etc.] repositories) that the code in question was introduced into Linux (etc.) as a result of a code drop from IBM subsequent to its being obtained from SCO.
That's the easy (if time consuming) part, establishing the paper trail.
The hard part is then proving that the transfer of the IP into the Linux source base was done knowingly (or whatever else would be actionable under the SCO/IBM contract), and that the Linux coders couldn't possibly have thought it up on their own (e.g., it can't be some algorithm every freshman CompSci student implements as a class project.)
I really can't see SCO's "they can't possibly have had the knowledge or resources to build and test this" claim holding up. They're going to have to present much more convincing positive evidence than that.
Good bloody luck.