SCO's Memorandum in Opposition to IBM's 2nd Motion to Compel Discovery

Wednesday, November 26 2003 @ 10:30 AM EST

Contributed by: PJ

SCO has filed with the court its Memorandum in Opposition to IBM's Second Motion to Compel Discovery. You can get it as a PDF here. We will provide a text version soon.

A quick read-through shows that SCO makes several, to me, oily arguments:

1. They assert that IBM failed to dot their I's and cross their T's in that they failed to comply with DUCivR 37-1 "to meet and confer and set forth a specific recitation of time, date and place of, and the identity of all counsel involved in such efforts." Like they don't know the lawyers involved here. Puh-lease. IBM was supposed to first try to get what they wanted from SCO before bothering the court, they say, and then list all of the above when telling her about their trouble getting answers. That is, of course, laughable to those of us following along here on Groklaw. They are standing on tippy toes on a technicality.

A technicality gives the judge a basis for dismissing the motion if she wants to. But it seems very unlikely she will do so on the basis of this technicality. If she did, she would likely just be faced with a perfected motion from IBM, or a new one, and that's a waste of everyone's time. Part of a judge's job is to rein in both parties to make sure they don't waste time.

2. They next say that IBM wants them to provide what they have been showing to others at, for example, SCOForum. IBM is still asking SCO to tell them what the case is about. What code are we talking about here? SCO says they don't have to produce what they have been showing others, because that was SGI code and has nothing to do with IBM. This case, they argue, is about IBM's misconduct, not theirs, so they object to this IBM request.

Excuse me, are there not counterclaims here? And the code that later was identified as SGI code was only one example shown at SCOForum (and everywhere else). At the time SCO didn't know it was SGI code, and in fact attendees were led to believe it was IBM code, judging by the slides and news reports of the event.

There was another snip of non-SGI code they showed at SCOForum, which SCO here pretends not to know about, saying that their Supplemental Responses more than adequately answer IBM's request, because SGI code is irrelevant. However, might the real reason they do not wish to produce the code be that neither example of code was SCO-owned code in the first place?

It has been reported that they have shown different code to different signers of the NDA. Further, because SCO mentioned IBM in connection with the code they showed at SCOForum, if they used the SGI code to falsely accuse IBM, that in itself is related to IBM's counterclaims. Is their position that IBM has no right to conduct discovery on its counterclaims and are restricted to defending themselves from SCO's claims?

Again, we see some car salesman talk: "It was widely reported that such revealed code was placed in Linux not by IBM, but by another company, SGI. SCO need not produce SGI code that SGI placed in violation of its licenses with SCO. Such information is entirely unrelated to IBM's violations of its particular license agreements."

Sigh. Where to begin?

First, it was "widely reported" that Bruce Perens and others said it was SGI code, but that wasn't the representation that SCO itself had been making. Second, as Eben Moglen has pointed out, this was code that was already in the public domain, was never actually used by anybody anyway, and had already been removed from Linux long before SCOForum. To call it "infringing" is certainly quite a stretch, and that's putting it nicely. I think some people might be tempted to call it a lie. Let's review briefly exactly what Moglen said about the code in his recent OSDL position paper, and remember, he's a lawyer, yes, but he's also a coder:

"Mr McBride showed several dozen lines of memory allocation code from 'Linux,' which was identical to code from Sys V. Once again, however, it turned out that SCO had relied on 'pattern-matching' in the source code without ascertaining the actual history and copyright status of the work as to which it claimed ownership and infringement. The C code shown in the slides was first incorporated in Unix Version 3, and was written in 1973; it descends from an earlier version published by Donald Knuth in his classic The Art of Computer Programming in 1968. AT&T claimed this code, among other portions of its Unix OS, as infringed by the University of California in the BSD litigation, and was denied a preliminary injunction on the ground that it could not show a likelihood of success on its copyright claim, because it had published the code without copyright notices and therefore, under pre-1976 US copyright law, had put the code in the public domain. In 2002, SCO's predecessor Caldera released this code again under a license that permitted free copying and redistribution. Silicon Graphics, Inc. (SGI) then used the code in the variant of the Linux program for `'Trillium' 64-bit architecture computers it was planning to sell but never shipped. In incorporating the code, SGI violated the terms of Caldera's license by erroneously removing Caldera's (incorrect) copyright notice.

"Thus SCO's second example was of supposedly impermissible copying of code that was in the public domain to begin with, and which SCO itself had released under a free software license after erroneously claiming copyright. SGI had complicated matters by improperly removing the inaccurate copyright notice. So how many PCs and Intel-architecture servers around the world contained this supposedly infringing code? Zero. No version of the Linux program for Intel architectures had ever contained it. No SGI hardware for which this code was written ever shipped. HP, which sells 64-bit Itanium servers, has removed the code from the IA-64 branch of the Linux code tree; it was technically redundant anyway. But SCO's research went no farther than discovering a supposed instance of 'copying,' without asking whether SCO had any rights in what had been copied, and certainly without providing the audience to whom it was speaking any indication that the 'Linux' it was talking about was a variant for rare computers from which the supposedly-offending code had already been removed."

Perhaps SCO is just too embarrassed to show this code to the judge. They certainly ought to be.

3. Finally, they say they can't answer with specificity as to how IBM failed to keep trade secrets secret, because they (IBM and Sequent -- especially, they imply, the latter) are the only ones who know what they revealed and SCO doesn't know until they tell them. Again, SCO relies on the original agreement, their Exhibit A to their Complaint, as if none of the subsequent side letters or later agreements happened. They don't even mention them to deny their applicabiity or authority. They just say that under the original agreement, they were supposed to keep derivatives trade secrets. They then list all the things IBM has yet to produce as things they need before they can fully answer all IBM's interrogatories.

Here's a funny quotation from this part of the document. Talk about stalling:

"Meaningful supplemental interrogatory answers can only follow IBM's production of the foregoing materials and the subsequent careful and time consuming review of the documents by counsel and qualified experts."

They will need time, it appears, a lot of time, time, and more time, first to find and rescue the missing MIT mathematicians from the Bermuda Triangle, presumably, or wherever they disappeared to, and then get them to analyze the code IBM turns over. After that, they can begin to answer IBM's interrogatory request that they identify the allegedly infringing code.

This seems quite an admission from SCO. Apparently they don't know what IBM or Sequent has or has not done, except for what they read in the papers, according to this document. This doesn't match what they told investors and the media, does it? I seem to recall they said they deep-dived with three different groups and found specific infringements. So what happened? Why can't they turn that over to IBM? Now they need a lot of time and can't even begin to identify precise infringements until IBM shows them their code first? I guess they hope the judge doesn't read the papers herself.

4. Then, inexplicably, SCO argues that it has already provided IBM with the following information, which IBM allegedly ignored by relying on SCO's first answers instead of its supplemental answers. You can review IBM's Memorandum in Support of their motion and the Addendum they provided to determine the validity of this claim. According to them, the supplemental answers tell IBM what trade secrets SCO alleges they misappropriated, what they were supposed to keep secret but didn't, the methods used by IBM to create derivative works based on UNIX, the identities of entities and individuals having had access to confidential information, and how and when IBM infringed and misappropriated SCO's trade secrets and/or confidential and proprietary information. Evidently they are referring in part to the list of files Frank Sorenson has already debunked on Groklaw. For the rest, I suggest you read their supplemental answers and IBM's Memorandum and Addendum and draw your own conclusions. That is what the judge will do.

5. Next they laughably argue that they already gave IBM what IBM asked for. IBM asked for source code in human readable form, and by producing a million pages of source code on paper, they claim that is what IBM asked for. What IBM asked for was defined precisely like this: "source code shall mean the human readable form of a computer program written in the original and preferred form for human inspection" and SCO pretends that means paper. I'm sure all you coders will confirm that you write your code on paper. Heh heh. What cut-ups those SCOfolk are. It looks like their lawyers have now caught the SCOspeak virus. Oh. I forgot. Their lawyer is SCO.

They say they went to "great expense" to provide the paper printout of the code. What more could you ask? They then say that later, when IBM "changed" its request and asked for CDs, SCO has produced "dozens and dozens" of CDs with the source code in the format requested. However, if you check this claim against their last one and their next one, you'll see they have yet to produce all the code, by any measurement. We'll see what IBM says about that in due time. They claim IBM has yet to produce a "single line of source code in any format" which contradicts what IBM told the judge, so we'll have to see how that plays out too.

6. SCO then says that while they haven't turned over everything yet, they are working on it. The two sides agreed to a "rolling production" and they are rolling. They are almost finished with the source code production, and they will turn it over in "the next few weeks." Promises, promises. They want the judge to dismiss IBM's motion based on a SCO promise. I think IBM will argue that a SCO promise is not a sufficiently reliable foundation on which to rely. Bottom line: they still haven't told IBM what IBM has allegedly done wrong and they won't yet, because they need more time and anyway, IBM needs to show its hand first. It's called poker, ladies and gents. This is legal poker.