decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

To read comments to this article, go here
A Bit of Insight into Methods and Concepts - Some New Pacer Docs
Thursday, August 04 2005 @ 05:26 PM EDT

Some fascinating SCO v. IBM documents have just shown up on Pacer. For one thing, we learn that there was a bit of a dustup after the April 21 hearing, with some letters being sent to Judge Kimball, and an odd suggestion on the eve of the hearing from SCO that the hearing be closed to the public, allegedly because they thought IBM might want it that way.

Hilarious. Their believability level is dropping in my eyes, and it was hovering fairly low to the ground already. Anyway, now we find out what Judge Dale Kimball was talking about at the hearing, when he said this:

"The second one, the motion for leave to file a third amended complaint, there might be some alleged confidential information there, but you can argue it in a way that doesn't refer directly to it. You can refer to it in exhibits and so on. So I'm sure for the happy conclusion of the spectators, the courtroom will not be sealed."
Now we know he was responding to SCO's letter, which we now can read. We also learn from the letters that SCO can be just as annoying in private as they are in public, that they either have no computer skills whatsoever or are pretending, and I think you will enjoy IBM's withering reply to SCO's letters. Here's the list of new documents available, all PDFs (which means we need transcribers, please):
Mr. Normand's letter is the one IBM responds to. It was all about SCO "clarifying" for the record an issue of when they received discovery from IBM. They contended that IBM didn't give them the discovery (the emails that they kept trying to out) until after the deadline for amending its complaint. SCO's basis for asking to amend its complaint a third time was that it had no reason to know about SVRX being used in AIX on Power and that they only found out from the discovery materials they alleged they didn't get until after the deadline to amend had passed. IBM had turned the materials over prior to the deadline, and they told the court they did at the hearing in April. So SCO next, in this letter after the hearing, tried to argue that the CDs produced were not in a proper form and so hindered their discovery. IBM tells the judge that SCO once again is trying to blame IBM for its own errors. SCO lost that battle, but here you can see the lengths they went to to try to prevail. SCO's arguments always sound so plausible, until you hear IBM reply.

SCO contends in the letter with a straight face that it couldn't possibly begin looking at documents on a CD IBM had turned over unless IBM redid it to include pagination inside the CD as opposed to an accompanying source log. IBM points out all they had to do is either print it out or scroll through or look at the log, but in any case, they did the CD over and turned it over eventually anyway, as a courtesy. IBM sent the judge a copy of the CDs so he could see, they say, that the materials were available to SCO literally at a click of the mouse.

SCO must stay up nights trying to figure out any, and I do mean any, conceivable way to spin things their way. I have a suggestion. I think before they submit things, they should ask the following questions: Is this true? Is it at least plausible? Will it make us look (a) petty, (b) silly (c) dishonest, (d) clueless, or (e) dishonorable? That might spare us all a lot of paperwork. Just a suggestion.

The redacted SCO memorandum is fascinating to me because it gives us a much clearer picture of what SCO is thinking in its methods and concepts claim regarding Linux. I also see why Judge Wells ordered discovery regarding Linux materials, something I found incomprehensible before.

See if you agree. What SCO complained to the court about was not just a list of IBM contributions to Linux, which are readily available to anyone by just looking in the public records. Here's what they wanted, in the context of complaining that IBM was refusing to provide a witness to testify:

With respect to SCO's Rule 30(b)(6) notices, IBM has improperly refused to produce any witness to testify on numerous subjects of central relevance to this case. With respect to SCO's Rule 30(b)(6) notice dated November 30, 2004, IBM has improperly refused to produce any witness to testify to the following topics:
"1. The extent to and manner in which UNIX Software Products were used, directly or indirectly, in the creation, derivation or modification of any source code that IBM contributed to Linux, including but not limited to the following:

a. The date and nature of IBM's contributions of source code from AIX or Dynix, whether copied in a literal or non-literal manner, to Linux;

b. IBM's and Sequent's use of structures, sequences, organization, ideas, method or concepts contained within any UNIX Software Product in developing source code that IBM contributed to Linux; and

c. The identity of the programmers who were exposed to any UNIX Software Product.

2. Identification of and role of IBM employees or contractors involved in the work responsive to Topic 1 above.

3. Identification of the steps taken by corporate representative witness to be able to respond fully and accurately to Topics 1 and 2 above, including but not limited to documents reviewed, employees consulted, and databases consulted." Exh. K.

IBM objects to each topic "on the grounds that it is vague, ambiguous, and overbroad and unduly burdensome." IBM further objects to these topics on the grounds that they seek information "more appropriately sought" through other discovery methods. Exh. M at 1.

IBM's objections to these topics are meritless. Either IBM is capable of identifying the code it contributed to Linux and the nature and manner of those contributions or it is not. Either way, this evidence is directly relevant because IBM's reliance on UNIX-derived AIX and Dynix in developing Linux is at the very heart of SCO's breach-of-contract claims. IBM's objections to SCO's 30(b)(6) topics are particularly untenable in light of IBM's long-standing refusal to produce adequate responses to SCO interrogatories and document requests that attempt to discover the programming history of IBM's Linux contributions.

That at least sounds more reasonable. I never could figure out why they would ask for a list of code contributions, which they can just find on the Internet.

Items 1(b) and (c) particularly caught my eye. They are wanting that information in (c) because if you can show access to proprietary code, and also similarity, you can more easily support a claim of copyright infringement. Here there is the added element of methods and concepts, which I think they are tying to their contract claims, although I do believe they have ideas about extending copyright to include methods and concepts at some point, if they can.

However, they face a couple of real problems. One is that practically every programmer on earth studied UNIX in school. They were able to do so because AT&T licensed UNIX to schools precisely so they would teach it. To turn around now and claim infringement of methods and concepts that you promoted be taught in colleges and universities around the world is ridiculous and sounds like a mighty dirty set-up to me. I feel sure they won't argue any such foolish thing. Well, after the no-pagination-on-CDs argument, who knows? But it's a losing argument.

For one thing, they've already acknowledged in open court that there are no trade secrets in Unix, just in UnixWare. But here, regarding UnixWare, they face another problem: SCO needs to ask themselves the following question. When Santa Cruz wrote code and donated it to Linux, and they did, did they carefully separate their UNIX and Linux coders? If not, where might any similarities in methods and concepts come from? You'll remember, if you've been with Groklaw long enough, that Santa Cruz UnixWare kernel engineer Tigran Aivazian told Groklaw that he was also making contributions to Linux with approval from his boss:

"Yes, my very humble contributions to the Linux kernel (BFS filesystem and IA32 microcode update driver) done during my work as an escalations (UnixWare kernel) engineer at SCO were approved by our then-director Wendy Jones (who now works for Sun I think) and by higher management as well (I have bad memory on names, so I can't remember exactly, I think it was on Doug's level or so).

"For example in the case of BFS filesystem the matter was as follows. I did NOT use any of the UnixWare (or other) proprietary code for the implementation, of course. However, despite this fact, I still (for courtesy and generally being cautious) requested permission from Wendy (Development director) before the release under GPL and she confirmed that SCO has no claims to this work whatsoever and has no objections to its release under GPL, because it is not connected to UnixWare source code in any way."

There's just one example of oldSCO's relaxed practices. There was evidently no Chinese wall at Santa Cruz separating UNIX and Linux coders, yet now SCO Group is suing IBM and trying desperately to prove that its Linux coders were exposed to UNIX and thus any similarities would be actionable under the contract. See any problems with that logic, given Tigran's testimony? Me too.

For those of you who like to keep track of such things, Groklaw has now published 2,000 articles. This one is 2,001. And our page on the lawyers in the SCO litigation, the Cast, has just hit a milestone too. There are now 100 lawyers listed on that page. Can you imagine?

  View Printable Version

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )