decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

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


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
SCO's Reply Memorandum Re Discovery - as text
Monday, July 19 2004 @ 01:41 AM EDT

Here is SCO's Reply Memorandum re Discovery as text, thanks to Steve Martin.

It's the document where SCO tells the judge, in effect, that they need to go through all of IBM's garbage going back to 1989 and reconstruct all shredded materials and unlock private diaries and get the key to the safe and unfettered access to headquarters' executive lounge closets and everybody's file cabinets and rip up the carpets and feel behind the toilet bowls because they just might find one unstudied word or casual phrase that they can hang IBM by. They don't know exactly what they are looking for, but they're sure something will turn up.

One thing is for sure. If IBM filed for summary judgment not so much because they figured it'd work but rather to flush SCO out from hiding behind the bushes, it worked. SCO's hand is now face up on the table. It was never about Linux, about Linus not having a process to block out infringing code. That was all for headlines, for stock price, for Congress, and to please Microsoft, I expect. But the reality is, this case is about a contract dispute. Linux got dragged into it as hostage. SCO is holding Linux by the neck, pointing a gun at its head, and telling IBM, "Do what I tell you, or I'll shoot your little friend."

Not such a pretty picture, is it? And all the sophisticated lawyering is the legal team justifying such behavior. SCO must do this to protect their holy IP, after all. Why, it's required, nay, the American way, nay, noble. Then they go out for a drink afterward and have a sophisticated laugh. And they are all too sophisticated and cynical and clueless about tech to see that they are threatening the country's ability to compete in developing software. That's the trouble with cynics. They can't see past their own sophisticated noses and their own short-term gain. Or they don't care.

SCO started out imagining that if they brought a lawsuit, they could go on a discovery fishing expedition, find the copyright infringement they believed they'd find and then.... Profit! However, Linux is clean as a whistle. They tried and failed to find any literal copying. IBM successfully blocked them from getting every version of AIX by pointing out quite correctly that SCO had System V and it had all versions of Linux, which are publicly available, so if there was copying, all they needed was to look.

Flustered and frustrated in their plan, and in danger of losing everything, SCO now shifts gears and says this is actually just a contract dispute, and they really want all those versions of AIX to look for violations of contract claims, not copyright infringement. Discovery is liberal as long as it is relevant. They have written these 30 pages to make a case that the discovery is relevant to the contract claim. That's all this is. The name-calling is just for effect.

Then they pretend they didn't tell the world for a couple of years that they'd already done a comparison of System V and Linux and found mountains of infringing code. That was then. This is now. Now, the story is that they've never accused IBM of copyright infringement. It's news to them that this is part of this lawsuit. It's only IBM that interjected that alien thought, with its 10th counterclaim. Being a new thought, SCO can't be expected to have done any discovery on *that* subject, now, can they? They need to start afresh now, and it'll take a long time, thousands of man years, to compare all the code to look into this copyright business IBM has suddenly interjected into this contract lawsuit. And to do that comparison, oh, by the way, Your Honor, we need every version of AIX and Dynix from the founding of the world. And time. More time. Lots of time. Every SCO filing seems to ask for that.

According to their interpretation of the contract, there is no excape from System V's derivatives embrace. It's all restricted by the contract, so let's all forget copyright law. We're not talking about that, SCO tells us, straight-faced. Whatever gave you that idea? This is about contracts, which give us more control than copyright law. And by the terms of said contract, they own IBM's every breath forever, and if IBM didn't mean to give them that control over their breathing, they shouldn't have signed the contract to begin with. IBM views the contract differently, because it remembers the side letter and echo and all those after-contract refinements, but SCO, blinders firmly in place, sticks to the original contract, so that means they are entitled to discovery on such a vast scale. Why, they need to X-ray IBM's very colon. Something could have been swallowed, after all, to hide it from SCO's IP Police Squad hunting for contract breakers.

Except for one thing. This is exactly what they have asked for from the very first day. And so far, Judge Wells has never been willing to go that far. There are limits to discovery. SCO asks for the moon. I gather they've decided to go for broke. They have nothing to lose so they present the same old request in more sophisticated language than we are used to seeing. But it's the same wolf, still in grandma's cap and gown.

There is one additional factor. They swore to the court that they had complied with discovery. One thing IBM had asked in discovery was for SCO to tell them all infringing code in Linux, no matter who put it there. Since they didn't come up with anything, and signed off, now IBM is asking the court for a declaratory judgment of non-infringement. Additionally, SCO noticed that IBM mentioned moving for summary judgment on the contract claims later. So the SCO cavalry was called in and this is their bugle blast as they swarm over the hill. "We are entitled to try for more discovery", is their call. "Don't cut us off at the pass! We'll be ruined." We'll see if the judge buys it.

One thing is for sure. They didn't see IBM's strategy coming at them until it was almost too late. Maybe too late, period. And they are charging full steam ahead and giving it all they've got. I have never seen anything like it. Nauseating as it is, I can't help but acknowledge the cleverness. I don't admire cleverness without morality, personally, but I know cleverness when I see it. And I see it, starting with calling this a "Reply Memorandum in further support of its Memorandum dated May 28, 2004, filed pursuant to the Court's Order of March 3, 2004 (the 'March Order'), identifying relevant discovery that SCO has requested, but has not received, from IBM," and pretending that a summary judgment on the contract claims is before the court, so they should be given all the discovery they want to be able to defeat it. They also attack IBM, as if it were IBM who is responsible for the Court's earlier denials of SCO's requests. "IBM shouldn't be allowed to dictate to this court," SCO blusters. All IBM did was present its view, and the court accepted it. How is that IBM dictating? It isn't, and SCO knows it. But this is psychology. They figure it will work better to put it like that than to say, "Judge Wells, you refused us before, and we want you to change your mind and give us all the versions of AIX and Dynix from the founding of the world, even though you said you wouldn't."

Red Hat accused SCO's lawyers of saying whatever they think will work, from place to place, courtroom to courtroom. Here, they are telling the judge and the world that we should all forget about that Linux copyright baloney. It's all about the contracts, so SCO's failure to show any copied or infringed code means nothing. Why, they say, they not only don't have to show any literal copying, now they don't even have to show any nonliteral copying. With their contract, they don't have to show copying period:

"IBM argues that SCO needs only to compare UNIX System V source code with Linux source code to make its case and, therefore, that the discovery SCO seeks is irrelevant. But IBM's argument ignores the fact that SCO's principal claims are, as they have been since the beginning of this litigation, for breach of IBM's contractual obligations under the IBM and Sequent Software Licensing Agreements. Under these contracts, which prohibited IBM from contributing AIX or Dynix/ptx source code into Linux (because such contributions consisted of derivative works and/or "methods or concepts" of protected works), SCO is not required to show literal or non-literal copying of UNIX System V source code into Linux. . . . SCO can prevail on its contract claims without proving IBM's liability for copyright infringement."

To which the only conceivable response must be: Why then did you waste our time?

Speaking of situational slickness, remember at the AutoZone hearing on July 12th, SCO's attorney telling the judge that IBM was unlikely to prevail on its summary judgment re the 10th counterclaim because they hadn't argued that there were no issues of material fact? That was there. This is here:

"In a similar vein, IBM has already moved for summary judgment on its own recently-filed Tenth Counterclaim, arguing that SCO cannot demonstrate any issues of material fact regarding copyright infringement by IBM in any of its (vast and continuously expanding, but only partially enumerated) "Linux activities."

Another example for Red Hat's collection that SCO's legal team will say one thing in one court and the opposite in another. That only works for a short while, before everybody starts to catch on.

*****************************************

Brent O. Hatch (5715)
HATCH, JAMES & DODGE
[address, phone]

Stephen N. Zack (admitted pro hac vice)
Mark J. Heise (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
[address, phone, fax]

Robert Silver, Esq. (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
[address, phone, fax]

Frederick S. Frei (admitted pro hac vice)
Aldo Noto (admitted pro hac vice)
John K. Harrop (admitted pro hac vice)
ANDREWS KURTH LLP
[address, phone, fax]

Attorneys for Plaintiff The SCO Group, Inc.

IN THE UNITED STATES DISTRICT COURT
FOR THE DISTRICT OF UTAH


THE SCO GROUP, INC.

Plaintiff/Counterclaim Defendant

vs.

INTERNATIONAL BUSINESS
MACHINES CORPORATION,

Defendant/Counterclaim Plaintiff
REPLY MEMORANDUM
REGARDING DISCOVERY

Case No. 2:03-CV-0294 DAK

Honorable Dale A. Kimball
Magistrate Judge Brooke C. Wells

The SCO Group, Inc. ("SCO") through its respective counsel of record respectfully submits this Reply Memorandum Regarding Discovery.

Plaintiff the SCO Group, Inc. ("SCO") submits this Reply Memorandum in further support of its Memorandum dated May 28, 2004, filed pursuant to the Court's Order of March 3, 2004 (the "March Order"), identifying relevant discovery that SCO has requested, but has not received, from IBM.

PRELIMINARY STATEMENT

SCO here asks the Court to order IBM to produce the source code of the multiple versions of the AIX and Dynix computer operating systems and related documents that SCO has sought for over a year. These discovery requests remain at the heart of this litigation, because they are directly relevant to, and reasonably calculated to lead to the discovery of admissible evidence concerning, SCO's contract claims — which are based on IBM's copying of AIX and Dynix/ptx code into Linux — as well as IBM's recently-added counterclaim — which seeks a broad declaratory judgment that none of IBM's Linux activities infringe any SCO copyright.

IBM has incorrectly resisted producing earlier versions of AIX and Dynix/ptx on the stated ground that SCO need only compare UNIX System V code to Linux code and, therefore, these two sources of code are everything SCO needs to support its claims. But IBM's argument overlooks the pivotal point that the heart of SCO's complaint — the contract claims — requires no proof of any copying from UNIX System V to Linux. Rather, while IBM focuses on copyright law, the license agreements at issue here expressly provided greater protections, ensuring that any subsequent derivatives of UNIX System V derivatives and/or any "methods or concepts" contained in UNIX System V or any such derivatives receive the same protection under the license agreements as the original licensed System V product. Thus, the license agreements, on their face, clearly provide SCO with far greater protection than the copyright law affords; indeed, the agreements' language would have been surplusage if they had mirrored the copyright protections already provided by operation of law.

IBM's contract argument provides further compelling reasons for SCO's entitlement to design documents, white papers, and programming notes related to the prior versions of AIX and Dynix/ptx. Because IBM's contract argument departs substantially from the language of the operative license agreements, it will be necessary to rely on extrinsic evidence. Although SCO believes that the unambiguous meaning of the contracts will preclude IBM's attempt to vary their terms through such extrinsic evidence, to the extent such evidence is permitted, the parties' performance under and understanding of the agreements will undoubtedly be relevant. Thus, SCO is entitled to discover facts showing, for example, that IBM and Sequent understood the restrictions of the contracts to have protected more than distribution of literal UNIX source code, that they gave weight to the language of the contracts, and that they had incentives to breach the contracts.

IBM wants to hold this evidence back, even though (as it elsewhere tells the Court) IBM intends to move for summary judgment on those same contract claims. Apparently, IBM wants the Court to accept its version of the case as a matter of law, yet shield from discovery the very material that could show that at the times that mattered, the licensees themselves did not believe what IBM would now ask the Court to conclude.

IBM also wants to hold back substantial evidence that could show that IBM (and Sequent) breached the contracts in question. It is undisputable that the purpose of those contracts was to allow IBM and Sequent to make and market products based on UNIX System V. The contracts, granting the licensor more protection than copyright would have done without any agreement, expressly treated the first IBM or Sequent version as subject to the same restrictions that applied to System V itself — as "the original software product." Any subsequent version, based on that contractually redefined "original software product" would be subject to the very same restrictions — the restrictions that stand at the center of this case, and that would have prevented the ultimate transfer to Linux of the IBM and Sequent programs at issue. IBM wants to shut off access to all of the early development history of AIX and Dynix, even to the early distributed releases of these programs. But this is the very material that would show just how the contractual restrictions applied, something that cannot be shown if access to evidence only begins comparatively late in the development process — as opposed to the point when the contracts and the process began.

IBM's claim that this material is irrelevant — when this material could contain proof of one instance after another of breach -- is indefensible. IBM is arrogating to itself the power to tell the Court what evidence it should be allowed to see in order to test the validity of IBM's own versions of the facts.

Wholly apart from SCO's contract claims, the discovery that SCO seeks is now relevant, and indeed critical, to SCO's ability to defend against IBM's recently-added copyright claim. The inordinately time-consuming and labor-intensive task of investigating the entirety of UNIX System V and Linux for evidence of non-literal copying — an issue central to IBM's counterclaim — is not practical for anyone to perform without leads. The basic discovery that SCO seeks but has not received — such as the identities and precise contributions of AIX and Dynix programmers which this Court has already ordered IBM to produce — would permit SCO sensibly to identify the key programmers for deposition. Then, based on such deposition testimony concerning the programmers' access to UNIX source code and the similarity between that code and derivative code in AIX or Dynix, SCO could streamline its investigation by prioritizing and targeting specific areas of code for analysis. By depriving SCO of basic information concerning the contributions of its programmers, IBM seeks to force SCO to undertake this laborious investigation in the most inefficient way possible.

In this and other regards (further detailed below), IBM misapprehends the essence of the discovery process. Discovery is designed to make the investigative process efficient and conducive to truth-finding. IBM has no more right to undermine these goals by blocking discovery than it does to tell the Court what evidence the Court and the jury may see to test the validity of IBM's own claims. Moreover, the question with respect to SCO's requested copyright discovery is not whether SCO possesses some "minimum" amount of evidence that might permit it to prove or defend the claims at issue. Rather, SCO is entitled to the production of all admissible evidence and materials reasonably calculated to lead to the discovery of admissible evidence, unless the burden to IBM outweighs this broad right in a legally and factually significant manner.

In light of the centrality of this evidence to the claims and counterclaims in this case, IBM is hard-pressed to establish any substantial burden that could justify its failure to produce such material. Most of the materials SCO has requested are stored electronically in a centralized, readily accessed system, and, for those that are not, IBM has afforded SCO no opportunity to meet and confer in order to address the issue of producing hard copies. With respect to Dynix/ptx, IBM makes no burden argument of any kind; with respect to AIX, after telling the Court that it would take "many, many months" to meet the request, IBM now says it would take only "weeks". Almost every aspect of discovery in this case has taken "weeks" -- over fifty weeks have passed since SCO requested the materials, for example, and over twelve weeks have passed since the Court ordered IBM to produce certain of the documents.

IBM further asserts that all of the paper documents SCO seeks (such as programmer's notes, design documents and white papers) are too burdensome to produce. IBM makes these statements even though (i) at least a great number of the documents created by programmers are electronically stored, and IBM took the position that SCO would not receive even electronically stored documents, making clear that IBM did not intend to produce any of the discovery to SCO; (ii) when faced with the same issue, SCO agreed to produce documents to IBM in an electronic format; and (iii) by its own admissions, IBM can produce the requested materials in a compact, electronic format. These facts belie any suggestion that IBM is concerned about the burden involved in searching for hard copies, and demonstrate that IBM refuses to produce the discovery at issue in any format.

IBM has repeatedly (and erroneously) argued to this Court and to Judge Kimball that SCO only wants to delay and prolong this litigation in order to further an alleged scheme to create "fear, uncertainty and doubt." IBM Resp. at 3-4. IBM created this cloud over Linux when it copied AIX and Dynix/ptx code into that program in derogation of its express contractual obligations. And when IBM, to increase its profits and advance its strategic objectives, encouraged numerous entities to migrate to Linux, it imposed the risk it had created for itself on them as well. Here, IBM again tries to shift responsibility, this time claiming that when SCO seeks basic discovery and IBM stonewalls for a year, the resulting delay is somehow part of SCO's "scheme" to extend the litigation process.

For a year, SCO has sought, and continues to seek, critical discovery to which it is entitled under the Federal Rules in order to present its strongest case to a jury. If IBM has nothing to hide (as it claims), and actually wishes to expedite this litigation (as it also claims), it should produce the materials SCO has requested and attempt to establish its defense (as well as its new copyright counterclaim) on their merits.

ARGUMENT

I. SCO'S DISCOVERY REQUESTS ARE RELEVANT AND RESONABALY CALCULATED TO LEAD TO ADMISSIBLE EVIDENCE TO SUPPORT ITS CONTRACT CLAIMS AND TO DEFEND AGAINST IBM'S COPYRIGHT COUNTERCLAIM.

SCO has properly requested all versions of AIX and Dynix/ptx; the names of all principal contributors to AIX and Dynix; and revision information including access to CVMS, all programmer notes, design documents, and white papers. All that IBM has produced are actual commercial releases of AIX and Dynix since 1999 -- releases that IBM characterizes as "distributed". Thus, SCO has not even been given commercially distributed versions prior to 1999. Nor has IBM produced any of the other requested materials, even though most of that material is stored electronically.

Under Federal Rule of Civil Procedure 26, SCO is entitled to this discovery — which is not only directly relevant, but potentially dispositive of central claims in the case — unless IBM can show that producing the evidence would constitute such an undue burden that even plainly relevant material should be withheld. Fed. R. Civ. P.26(b)(1). IBM does not and cannot make any such showing.

As an initial matter, IBM incorrectly claims in its latest discovery memorandum that it has produced all "distributed" versions of AIX and Dynix since 1999. IBM Resp. at 6, 10-11. But IBM has still indisputably failed to provide at least one distributed version of AIX — version 5.0, see Initial Memo. at 6, n.7; Declaration of Chris Sontag dated July 12, 2004 ("Sontag Discovery Decl.") ¶ 13 — and IBM offers no explanation for this deficiency. Moreover, SCO's request for all iterations and versions of AIX and Dynix was not limited to "distributed" products. IBM's claim that it has complied with SCO's request because AIX consists only of distributed versions is flatly contradicted by IBM's own discovery requests in this case, which expressly acknowledge that AIX is not limited to distributed versions, but that AIX is "the UNIX-branded operating system distributed and/or developed by IBM, including all prior versions, releases, and maintenance modifications." IBM's First Request for the Production of Documents at 16, ¶ 1 (emphasis added).

A. The Information SCO Seeks Is Discoverable to Support SCO's Contract Claims

IBM argues that SCO needs only to compare UNIX System V source code with Linux source code to make its case and, therefore, that the discovery SCO seeks is irrelevant. But IBM's argument ignores the fact that SCO's principal claims are, as they have been since the beginning of this litigation, for breach of IBM's contractual obligations under the IBM and Sequent Software Licensing Agreements. Under these contracts, which prohibited IBM from contributing AIX or Dynix/ptx source code into Linux (because such contributions consisted of derivative works and/or "methods or concepts" of protected works), SCO is not required to show literal or non-literal copying of UNIX System V source code into Linux.(1).

Contracts, of course, may be used to secure greater legal protection than that afforded by copyright law alone. See, e.g. Bowers v. Baystate Technologies, Inc, 320 F.3d 1317, 1327 (Fed. Cir. 2003) (affirming jury verdict of breach of contract where "[t]he shrink-wrap license agreement prohibited, inter alia, all reverse engineering of [plaintiff's] software, protection encompassing but more extensive than copyright protection, which prohibits only certain copying"); Dispatch Automation, Inc. v. Richards, 280 F.3d 1116, 1120-21 (7th Cir. 2002) ("contractual alternatives to copyright may give an owner of computer software more protection than copyright would"); Nat'l Car Rental Sys., Inc. v. Computer Assocs. Int'l, Inc., 991 F.2d 426, 431-35 (8th Cir. 1993) (finding that party alleging infringement was in actuality asserting that the infringer violated a licensing agreement by processing data for third parties, which was not an infringement of an exclusive right to the copyright holder and that "Absent the parties' agreement, this restriction would not exist").

The IBM and Sequent License Agreements secured such additional protections for SCO; if they had not, the express protective language of the agreements would have no meaning, constituting inexplicable surplusage. Consequently, SCO can prevail on its contract claims without proving IBM's liability for copyright infringement.

IBM therefore misses the point when it claims that prior versions of AIX and Dynix are irrelevant on the grounds that "[a] derivative work based on an original work may be so transformed that it no longer is a derivative work and no longer infringes any copyright of the original work." IBM Response at 14 & n.5. IBM's argument assumes that only copyright law applies. But SCO's Linux-related claims in this case are contract claims, and the contracts at issue were expressly worded to give SCO the protection that IBM claims copyright law would not.

This is also precisely the reason why earlier versions of AIX and Dynix are so critical to SCO's contract claim proof. Specifically, under Paragraph 2.01 of the IBM and Sequent license agreements, "modifications and derivative works based on" UNIX System V are treated as if they were part of the original licensed "SOFTWARE PRODUCT," so that any transfer by IBM of such a modification or derivative work — even if it was included in an early version of AIX and Dynix — would violate the License Agreements. Similarly, under the Sequent License Agreement, IBM is specifically prohibited from disclosing "any or all of such SOFTWARE PRODUCTS [i.e., UNIX System V and, pursuant to Paragraph 2.01, AIX and Dynix] (including methods or concepts utilized therein) to anyone," so that any disclosure by IBM of any portion, method, or concept of Dynix — even if it was included in an early version of the program — would violate the Sequent agreement.

SCO's need for this discovery is especially critical in light of IBM's stated intention to seek summary judgment on SCO's contract claims. See IBM SJ Mem. at 5 n.4. If and when IBM brings such a motion, it will argue (as it must) that SCO has not produced sufficient evidence to raise any issues of material fact regarding its contract claims. In a similar vein, IBM has already moved for summary judgment on its own recently-filed Tenth Counterclaim, arguing that SCO cannot demonstrate any issues of material fact regarding copyright infringement by IBM in any of its (vast and continuously expanding, but only partially enumerated) "Linux activities."

IBM's litigation two-step has thus become clear. First, IBM systematically withholds relevant discovery materials in the face of SCO's requests and this Court's Orders. Then it moves for summary judgment, arguing that SCO cannot produce evidence sufficient to raise a fact issue on its claims. IBM's method of defense litigation runs contrary to both the letter and spirit of the Federal Rules of Civil Procedure and this Court should order IBM to comply with its discovery obligations.

1. The Requested Materials May Contain IBM
Admissions of Contract Liability.

In its Initial Memorandum, SCO requested not only intermediate versions and iterations of AIX and Dynix/ptx, but also revision history information about these programs, as well as programmers' notes, design documents, and white papers. These materials will provide SCO with extensive information about IBM's programmers and their involvement with AIX and Dynix/ptx. Declaration of Chris Sontag submitted July 8, 2004 ("Sontag SJ Decl.") ¶¶ 51-53. The materials SCO seeks may also contain evidence that is not only probative, but dispositive of IBM's liability for breach of contract, such as:

-- admissions concerning the meaning of, and limitations imposed by, the license agreements;
-- admissions regarding IBM's liability for breaching those contracts; and
-- admissions that the development of AIX and Dynix/ptx depended on UNIX System V.

It is difficult to understand IBM's claim that such materials are not relevant to this case -- when they could easily be dispositive of this case. It is even harder to understand how IBM could continue to try to withhold this material, when it has told the Court that it plans to move for summary judgment on the contract issues, and when all of these materials could readily contradict the very claims that IBM will be asking the Court to then accept as undisputed.

2. SCO's Requested Discovery is Directly Relevant to Whether IBM's
Disclosure of AIX and Dynix Violated the Software License
Agreements.

The License Agreements in question allowed IBM and Sequent to use System V source code to prepare operating systems (AIX and Dynix/ptx, respectively) based on System V, subject to several restrictions. Critically, Paragraph 2.01 of the License Agreements provides that any modifications or derivative works based on System V code are to be treated as "part of" System V (and thus subject to the restrictions applicable to System V) under the Agreements. Because of this clause in the Agreements, IBM is no more free to disclose, export, or publish any derivative version of AIX or Dynix/ptx than it is to disclose, export, or publish System V itself.

Accordingly, one way for SCO to prove that IBM breached the License Agreements is for SCO to demonstrate that versions of AIX and/or Dynix/ptx are derivatives of System V within the meaning of the Agreements, and that IBM disclosed, exported, or published those derivatives. As the plain language of the License Agreements makes clear, a modification or derivative of System V is subject to the same confidentiality restrictions as System V itself. Thus, the restrictions in the Agreement apply to each successive iteration of the derivative program and not to System V alone.

To illustrate, suppose that Dynix version 1 is a derivative of System V. Under Paragraph 2.01, every provision in the License Agreement that applies to System V also applies to Dynix v.1 (including Paragraph 2.01 itself). Thus, if Dynix v.2 is a derivative of Dynix v.1, it too must be treated as part of System V for the purposes of the Agreements. Assuming that each version of Dynix is created as a derivative of the previous version, the most recent version of Dynix is every bit as much a derivative of System V under the License Agreements as is Dynix v.1. Accordingly, SCO's request for each iteration and version of AIX and Dynix is discoverable under its breach of contract claims; if SCO can trace the evolution of AIX and Dynix clear back to System V it will be able to prevail on those claims without making any additional showing.

But there is no way for SCO to make this showing without the early history of AIX and Dynix — the very material that IBM is dead set against providing.

IBM, of course, disputes SCO's interpretation of the contracts and argues that, at some (as yet undefined point), AIX and Dynix ceased being derivatives of System V. The analysis in Dispatch Automation, 280 F.3d 1116, demonstrates that the requested materials are discoverable even under IBM's theory of the License Agreements. In that case, Judge Posner explained the inherent difficulty in determining the point at which a computer program ceases to be derived from an old program, and instead becomes so transformed that it is a new work:

To decide ... whether a successive version of a computer software product is a merely incremental improvement or a breakthrough would be like determining the exact moment at which day becomes night. ... How for example to decide whether to compare the latest version of a product with the immediately preceding version or with the original version? Compared to the former, it might seem incremental, while compared to the original version it might seem discontinuous, a radical or fundamental change. The first approach would invite the proliferation of meaningless intermediate steps designed to disguise novelty; but the second would ignore the obvious fact that a process of unmistakable, indeed quite gradual, development can have an end point radically different from its beginning, as in the case of the oak and the acorn it grew from.

Id. at 1119-20.

By resisting SCO's discovery, IBM would arrogate to itself the authority to select evidence with which to test the validity of its claim that at some point AIX and Dynix/ptx ceased to be modifications or derivative works "based upon" SCO's UNIX System V and were no longer subject to the restrictions of the License Agreements. In other words, IBM itself would select that point, without ever allowing the Court, SCO, or the jury to see any evidence that IBM did not want it to see — any evidence of the intermediate stages of development. IBM would also decide how to deny SCO the discovery it needs to prove where the actual point should be located.

If this approach to discovery were permissible, there would be no reason for licensors ever to enter carefully worded license agreements, because they would be literally worthless. Another factor makes IBM's approach even less appropriate; SCO's License Agreements are worded precisely to avoid the complexity of this very evolutionary determination. That is, SCO's contracts with IBM and Sequent make every modification and derivation part of the original "SOFTWARE PRODUCT" and subject to all of the contract's prohibitions and limitations. Following Judge Posner's analogy, accepting IBM's position would be attempting to determine "the exact moment at which day becomes night" with all the blinds drawn. Id. That is the exact type of determination the licensing agreements were drafted to avoid.

3. The Requested Discovery is Relevant to and Will Aid SCO in
Determining Whether IBM Disclosed Contractually-Protected System
V "Methods or Concepts."

Paragraph 7.06 of the Sequent License Agreement prohibits IBM from disclosing any portion (let alone the entirety) of any "SOFTWARE PRODUCT" (i.e., original System V and derivative (Dynix/ptx)), "including methods or concepts utilized therein." Therefore, SCO will prevail on its breach of contract claims if it can demonstrate that IBM in fact disclosed protected "methods or concepts." The most efficient and straightforward way for SCO to discover if IBM made such disclosures is through access to Dynix/ptx programmers and their particular contributions.

In its March Order, this Court directed IBM to produce, among other things, the identities and precise contributions of Dynix programmers. See 3/3/04 Order at 5. SCO has now attempted to obtain this information from IBM in several ways: by serving an interrogatory, filing a motion to compel, and filing a renewed Motion to Compel (on July 6, 2004). Up to this point, IBM has resisted these efforts and withheld this essential discovery. Accordingly SCO requests that IBM again be ordered to produce materials that will reveal the identities and precise contributions of Dynix programmers.

In the first instance, this information would allow SCO to take depositions of the principal Dynix contributors. These depositions could result in admissions of IBM's reliance on protected SCO material, clearly relevant to IBM's potential contract liability. Programmers and engineers can be deposed regarding the following issues:

-- the identify of Linux contributors;
-- specifics about their own Linux contributions;
-- assistance given to Linux contributors; and
-- whether any protected "methods or concepts" were ever disclosed.

This type of testimony will also assist SCO in identifying other former IBM employees contributing to Linux, who may be valuable witnesses.(2)

Accordingly, SCO's requested discovery is clearly relevant to, and reasonably calculated to lead to the discovery of admissible evidence concerning, SCO's contract claims in this case. In fact, the requested material may well contain much that is not only probative — but dispositive — of SCO's contract claims. IBM's argument that such material is not relevant reduces, again, to a demand that IBM be allowed to tell the Court what evidence should be allowed to be used to test the validity of IBM's own claims.

B. SCO's Requested Information Is Discoverable to Defend Against IBM's Recently-Added Copyright Claims.

SCO's case against IBM consists primarily of breach of contract claims. SCO's only copyright claim arises out of IBM's breach of the IBM and Sequent licensing agreements.(3) Nowhere in SCO's complaint is there a Linux-based copyright claim.

On March 29, 2004, however, IBM injected Linux copyright issues into this case through its Tenth Counterclaim, which seeks a broad declaration that none of its Linux activities infringe any of SCO's copyrights. Less than two months later, IBM filed its motion for summary judgment wherein it asserts that SCO must be limited to facts contained in SCO's discovery responses from January 12 and April 19 of this year. IBM SJ Mem. at 7, 23, 28, 30. Thus, having recently introduced new Linux-related copyright claims into this case, IBM is seeking to prevent SCO from conducting any discovery on IBM's new Tenth Counterclaim.

While IBM may prefer such an arrangement, its interests do not dictate the rules of discovery. SCO's discovery requests at issue in this memorandum, though initially made to support its contract claims, are now clearly relevant and necessary to SCO's defense against IBM's copyright claim.

The principal way in which IBM could defeat IBM's declaratory judgment counterclaim is by showing that IBM has copied literal code — or elements of non-literal expression — from SCO's copyrighted material. In refusing to comply with SCO's discovery requests, IBM tries to limit SCO to the least efficient and most time-consuming of all possible manners of investigating IBM's copyright counterclaim. IBM's position is indefensible as a matter of law, would be unjustifiable even if IBM had not injected the copyright claim into the case only recently and then even more recently moved for summary judgment on that claim, and is particularly inexplicable in light of IBM's constant complaints about delay. Indeed, the discovery SCO requested over a year ago would allow it to streamline, narrow, and prioritize its discovery analysis, and thereby speed up the litigation process.

While there are a number of ways to show that IBM copied SCO's protected material, perhaps the most obvious is for SCO to demonstrate that protected material, whether UNIX System V code — or non-literal expression — is present in Linux. IBM would then be liable as an end-user of Linux and possibly as a contributor to Linux as well. To do this, SCO must undertake a complex and laborious comparison of Linux and UNIX System V. Sontag SJ Decl. ¶¶ 9-14. This is a monumental task. Both the UNIX and Linux operating systems are large and complex computer programs with many millions of lines of code. In addition, SCO needs to do more than merely examine the two programs for literal, line-for-line character similarity, a daunting process in its own right. That literal comparison must be supplemented by an even more time-consuming second order review. Even IBM does not (because it cannot) contest that copyright law protects more than literal line-for-line copying — that it also protects copying of structures and sequences, even absent any copying of literal code. Review for such structure and sequence copying is even more time-consuming and laborious, if forced to be done without the aid of discovery, which is what IBM is trying to accomplish here.

Initially, each of the millions of lines of Linux code must be compared with each of the millions of lines of UNIX System V code, line-by-line, or in groups of lines according to the structure, sequence, or function of the code. SCO can use an automated tool to perform the initial literal comparison, but automated tools do not work well in the absence of identical copying. Sontag SJ Decl. ¶¶ 10-13. Those tools identify only exact or nearly-exact literal matches, thereby excluding evidence of non-literal copying.

These inherent limitations of automated code comparison tools mean that most code comparison between Linux and UNIX will require a manual review by a skilled programmer or expert, an extremely time-consuming process. The time required to complete the code comparison without some shortcut — such as a roadmap or list of "hotspots" in Linux — is staggering, on the order of thousands of man-years.(4) SCO needs to use discovery to streamline, narrow, and prioritize this manual review in order to avoid what could otherwise be an unrealistically difficult and time-consuming effort.

Many shortcuts to completion of the code comparison are theoretically available, including: (1) reviewing directory and file structures; (2) searching for similar file names, and (3) reviewing the AIX and Dynix development history, including reviewing interim and published versions of AIX and Dynix/ptx, as well as the associated documents, such as the version control systems (e.g., IBM's CMVC system), bug tracking logs, white papers, design documents, and programming notes. Sontag SJ Decl. && 26-35, 51-53.

SCO has already investigated the viability of the first two shortcuts and, even though those tools are helpful, the breadth of the analysis remains daunting.(5) The third shortcut, however, can greatly streamline SCO's further discovery. Specifically, by reviewing the development of AIX and Dynix/ptx, and their associated documents, SCO would be able to: (1) track original UNIX System V code into Linux and thereby focus its efforts by matching up original UNIX code with its Linux counterpart and (2) identify IBM and Sequent programmers and engineers who can provide deposition testimony that would also allow SCO to focus and prioritize its efforts to locate Linux code substantially similar to UNIX System V code. Sontag SJ Decl. ¶¶ 15-25.

As noted in the accompanying Declaration of Christopher Sontag, IBM's version control system (VCS) — the Configuration Management/Version Control (CMVC) system — can help SCO identify the programmers and engineers familiar with relevant UNIX-based code that IBM or third parties contributed to make Linux enterprise-hardened and multiprocessor-capable. Sontag Discovery Decl. ¶¶ 4-5, 7. SCO can then take their depositions and use that information to focus its analysis of UNIX System V and Linux.

The VCS will also allow SCO to examine the development of AIX and Dynix/ptx. By examining the source code in successive versions of AIX and Dynix, SCO can trace its UNIX System V code through to current versions of AIX and Dynix and determine where in Linux SCO's UNIX System V code is copied.(6) Then, SCO will know exactly which portions of UNIX System V and Linux to group together for comparison. This will significantly streamline SCO's efforts to find code in Linux that is substantially similar to UNIX System V code.(7)

IBM contends that because SCO has UNIX System V code and access to Linux code, SCO does not require interim versions or revision history information and, therefore, needs nothing further to make its copyright infringement case. IBM Resp. at 13-14.(8) But IBM fundamentally misconstrues its discovery obligations. SCO is entitled to the production of all materials relevant or reasonably calculated to lead to the discovery of admissible evidence, unless IBM can show some undue burden. Fed. R. Civ. P. 26(b)(1).

Indeed, IBM cites no authority requiring that SCO be limited to only one method in undertaking to prove that UNIX System V and Linux are substantially similar. That limitation would be the outcome of the decision IBM seeks. SCO would be precluded from knowing the precise contributions made to AIX and Dynix and would therefore be precluded from deposing the significant authors of AIX and Dynix. It would thus be unable to streamline, narrow, and prioritize its searches for code and non-literal elements in Linux that originated in UNIX. Without this discovery, the investigation is much more time consuming, costly, and needlessly inefficient.

The rules of discovery are designed to increase efficiency and to enhance the likelihood that the truth will be brought out. The rules are not, by contrast, designed to give one party the prerogative to make the investigative process as inefficient as conceivably possible and to enhance the likelihood that if the truth ever comes out, it will be long after the claims against it have been adjudicated. IBM has no more right to use the discovery rules to this end than IBM does to tell the Court what evidence the Court and the jury may see to test IBM's own claims.

II. IBM FACES NO SIGNIFICANT OR UNDUE BURDEN IN PRODUCING
THE CRUCIAL DISCOVERY SCO HAS SOUGHT FOR OVER A YEAR.

The party opposing discovery carries the burden of showing that "the burden or expense of the proposed discovery outweighs its likely benefit" under Fed. R. Civ. P. 26(b)(iii). See, e.g., Simpson v. Univ. of Colo., 220 F.R.D. 354, 359 (D. Colo. 2004) (holding that "when the discovery sought appears relevant," the party resisting disclosure on the ground of burdensomeness must demonstrate that its purported burden "would outweigh the ordinary presumption in favor of broad disclosure") (internal quotation marks and citations omitted)).(9) The party opposing discovery must demonstrate some "plainly adequate" reason not to produce relevant material. 8 C. Wright et al., Federal Practice and Procedure § 2035 (2003). With respect to electronically available information, "whether production of documents is unduly burdensome or expensive turns primarily on whether it is kept in an accessible or inaccessible format." Zubulake v. UBS Warburg LLC, 217 F.R.D. 309, 318 (S.D.N.Y. 2003).

IBM fails to show that the requested discovery is inaccessible, or that its burden in producing the discovery would be significant or would outweigh the crucial information (as outlined above) that SCO seeks through the discovery.

IBM Claims No Burden as to Dynix/ptx. While IBM contends that producing the requested information about AIX that is electronically stored would take "many weeks," IBM makes no claim that there would be any similar burden involved in doing so for Dynix. With respect to AIX, IBM's principal argument is that the CMVC on which AIX source code is stored does not permit IBM easily to copy that code for production to SCO -- thus the requirement of "weeks" of work. IBM Resp. at 18-19. At the same time, IBM makes no argument that the version control system on which Dynix source code is stored, Revision Control System (RCS), precludes IBM from easily copying that code for production to SCO. IBM's supporting affidavit, required to support a claim of burden, see, e.g.,, Super Film of Am., Inc. v. UCB Films, Inc., 219 F.R.D.649, 657 (D. Kan. 2004), makes no mention of RCS and Dynix. In the absence of any argument on the issue, IBM necessarily fails to meet its burden with respect to Dynix, including all of the electronically stored programmer notes and design documents and other requested documents, and the identities and precise contributions of programmer contributors to Dynix (which are also the subject of a renewed motion to compel before this Court).

IBM's Claim Cannot Avoid Producing AIX Versions and Related Electronically Stored Documents By Contending That It Would Take "Weeks" to Do So. IBM previously told this Court that it would take "many, many months" for IBM to produce the information, 2/6/04 Tr. at 37:10-14, which IBM now claims would take "many weeks" for IBM to produce (but presumably not a full month). Even assuming IBM is now correct, this burden of "weeks" is not a remotely adequate basis under the law for allowing IBM to withhold the requested materials. Almost every aspect of discovery in this case has taken "weeks" -- over fifty weeks have passed since SCO requested the materials, over twelve weeks have passed since the Court ordered IBM to produce certain of the documents, and the deadline for fact discovery is eight months away. On these bases alone, under the circumstances, IBM does not face a significant burden. The materials are a likely source of probative -- and dispositive -- evidence with respect to SCO's contract claims; the material in fact stands at the center of the case. The material also is essential to streamlining an otherwise unnecessarily time-consuming investigation into non-literal copyright violations, on claims IBM has recently introduced into the case. The proposal by IBM that it should be able to withhold such material from the Magistrate Judge, the Court, and the jury because producing it would inconvenience IBM by a matter of "weeks" is simply not a serious argument.

IBM's Claim Regarding the "Number" of Documents Is Inapposite. IBM claims that the information sought by SCO "amounts to millions of pages of documents," created by programmers and "40 million additional pages of paper" for additional source code. IBM Resp. at 3. IBM makes these statements notwithstanding that (i) at least a great number of the documents created by programmers are electronically stored, and IBM took the position that SCO would not receive even electronically stored documents, making it clear that IBM did not intend to produce any of the discovery to SCO; (ii) when faced with the same issue, SCO agreed to produce documents to IBM in an electronic format; and (iii) by its own admissions, IBM can produce the requested materials in a compact, electronic format. Thomas Decl. ¶ 11. These facts belie any suggestion that IBM is concerned about the burden involved in searching for hard copies, and demonstrate that IBM refuses to produce the discovery at issue in any format.

The foregoing points -- without more -- are independently sufficient to preclude IBM's claims of "burden". It makes no claim with respect to Dynix. Its claims on AIX are trivial, measured against the importance of the evidence, the other discovery tasks in the case, and simply against the kinds of efforts IBM has forced SCO to pursue just to try to obtain rudimentary discovery requested at the very outset of the case (burdens that have required SCO to renew motions to compel and spend much more than "weeks" of effort). But as shown below there are even further problems with IBM's claims.

IBM's Claim of "Weeks" to Produce Certain Discovery is Inaccurate. To the extent the period of "many weeks" is even significant, the question as to AIX is whether it would actually take IBM, one of the world's largest computer companies, that much time to produce earlier versions of the AIX source code. One reason to doubt IBM's representation is that, as noted above, IBM originally told the Court that it would take "many, many months" for IBM to produce the information. 2/6/04 Tr. at 37:10-14. Indeed, IBM's prior production in this case illustrates how long it would take IBM to copy AIX from data tapes onto DVDs or CDs: when IBM produced versions of AIX in unreadable format on March 4, 2004, SCO sought and received replacement CDs three weeks later.(10)

IBM's own pre-litigation statements further belie its current assertion that CMVC faces significant limitations that would make the production of AIX source code difficult:

  • IBM promotes CMVC to its customers based on CMVC's flexibility and sophistication, and IBM touts the use of automated scripts to incorporate fixes and changes daily. IBM-Siebel Marketing at 23 (Sontag Decl. Exh. 5).

  • IBM states that "CMVC is broad in its application, thorough in its implementation, and very flexible." IBM's Redbook, Did You Say CMVC?, Sept. 1994, at 65 (Sontag Decl. Exh. 2).

  • According to IBM, "The most important thing to understand about CMVC is that you do not need to understand all of it, before you begin using some of it. ... CMVC provides many mechanisms to help you accomplish your SCM [software configuration management] goals, but it does not dictate exactly how you should use them, nor does it require that you use them all if you only use some of them." Id.

  • IBM also claims that "CMVC ensures that an audit trail is maintained for every file by identifying for any file change: when the change occurred, who was responsible, and why the file was modified." Id. at 9.

  • One IBM employee explained that the "VC" (Version Control) function of CMVC "eliminates confusion when looking for a particular source code file belonging to a particular product," which describes what SCO seeks to do here. Email from Adrian Mitu of IBM Canada, Aug. 19, 1993 (located at ) (Sontag Decl. Exh.3).

  • The same employee indicates that CMVC data may be accessed remotely implying that IBM could simply grant SCO remote access to CMVC data to respond to SCO's discovery requests. Id.

  • IBM also acknowledges the possibility of granting users remote access to CMVC data, as long as the user has CMVC software. IBM's Redbook at 209-10.

Other, confidential IBM documentation further explains why it would not be burdensome for IBM to access source code and documentation from CMVC. See Sontag Discovery Decl. ¶¶ 5-7, 11-12.(11)

If the foregoing leaves any room for doubt, SCO demonstrates in the accompanying declaration of Chris Sontag that IBM grossly exaggerates the burden it will have to undertake to provide CMVC material. IBM can easily provide its CMVC system, including AIX source code and associated documentation, Thomas Decl. ¶ 7, in electronic format -- IBM admits that the total file size is manageable, on the order of 40 gigabytes, id. ¶ 10. This amount of materials could easily fit onto a laptop computer's hard drive, a portable hard drive, or a few optical disks. CMVC is arranged using IBM's SCCS hierarchy, see IBM's Redbook at 40, which permits IBM easily to design and run searches (accomplished by short computer programs called "scripts") to identify AIX source code. See Sontag Discovery Decl. ¶¶ 18-26. In the alternative, IBM can use standard archival tools to determine the locations of the one or more SCCS directory hierarchies related to AIX, and make copies. See Sontag Discovery Decl. ¶ 27. Contrary to the assertion in Mr. Thomas's declaration, Thomas Decl. ¶ 9, IBM engineers need not conduct a manual search for the components that are part of AIX, Sontag Discovery Decl. ¶ 29.

IBM also takes pains to describe each step it would take to manually produce the responsive materials from CMVC (IBM Resp. at 9-10), but such steps are unnecessary to accomplish the end result electronically. See Sontag Discovery Decl. ¶¶ 18-28. IBM further claims that to copy AIX information from data tapes onto DVDs or CDs would take "many additional weeks", after the "many weeks" already taken to collect the information. IBM Resp. at 10; Thomas Decl. ¶ 11. In fact, the data extraction and transfer process should not take more than two or three days, if IBM follows standard industry practices of maintaining and downloading its CMVC data. See Sontag Discovery Decl. ¶ 34.

IBM's Claim that SCO Merely Seeks "Delay" Is Baseless. IBM finally contends that SCO's requests are designed to "lay the groundwork for further delay." (IBM Resp. at 19.) The claim is remarkable to say the least, give that SCO here seeks the most basic types of discovery, which it has sought for over a year and has recently filed a Renewed Motion to Compel to ask the Court to order (again) IBM to produce.

The assertion also ignores IBM's (plain) responsibility for the delay in the discovery at issue here. IBM could have participated in a meet and confer process to eliminate or dramatically reduce the perceived burden it believed it faced. Further, IBM declined to meet SCO at least partway on SCO's requests for programmers' notes, design documents and white papers, making a blanket claim that all such documents were too burdensome to produce. IBM's conduct has been inconsistent with their stated intent to avoid "delay."

As set forth in SCO's opposition to IBM's motion for summary judgment on its Tenth Counterclaim, a pattern to IBM's conduct has emerged. IBM repeatedly tells the Court (and the world) that SCO has no case and that SCO seeks only to delay. But a defendant who truly believes its adversary has no case, who truly wishes to avoid delay, does not:

-- take every possible step — even in the face of court orders — to withhold access to the information needed to test its position, thereby ensuring great delay; and

-- then ask the Court to cut off all work so that its position can never be tested, thereby ensuring that even a plaintiff with a very strong case could never prosecute it.

Discovery battles are common and, to some extent, unavoidable in complex civil litigation. This pattern is not.

SCO submits that for the foregoing reasons, and as also set forth SCO's Renewed Motion to Compel dated July 7, 2004, IBM faces no significant or undue burden in producing the discovery SCO requests.

CONCLUSION

SCO respectfully requests, for the reasons set forth above, that the Court order IBM to produce the materials set forth above and in SCO's opening memorandum.

Dated this 12th day of July, 2004.

_______[signature]_______
HATCH, JAMES & DODGE, P.C.
Brent O. Hatch


BOIES, SCHILLER & FLEXNER LLP
Robert Silver
Stephen N. Zack
Mark J. Heise

Counsel for Plaintiff/Counterclaim defendant

ANDREWS KURTH LLP
Frederick S. Frei
Aldo Noto
John K. Harrop

Of Counsel


  1. For the reasons explained in Part 1.B below, IBM's argument would be wrong even if this case were based entirely on a Linux-related copyright claim like the one IBM added in its Tenth Counterclaim (but SCO has never asserted).

  2. IBM claims that programmer information is contained in the AIX and Dynix programs themselves and that, consequently, IBM need not provide such information independent of AIX code. SCO shows why IBM's claim is wrong in its renewed Motion to Compel (July 6, 2004) regarding its Interrogatory No. 5.

  3. SCO's copyright claims are based on claims that IBM transferred UNIX code to India, a country where the licensing agreement prohibited its use, and that IBM continued to use and distribute UNIX after SCO had terminated the licensing agreement.

  4. To execute the code comparison, SCO and its experts must compare page after page of code. The 4 million lines of Linux kernel code, which is the core portion of UNIX, takes up 66,000 pages; the UNIX kernel comprises 3.4 million lines of code and takes up 58,000 pages. A simple manual comparison would involve placing the pages of code side by side in some ordered manner and then looking for the same or similar structure, sequence, and organization of the code. Assuming each page comparison takes one minute, and that there are 66,000 x 58,000 comparisons, this "initial" review could take on the order of 25,000 man-years. Following the initial review, SCO and its experts must conduct a detailed comparison of likely copying candidates. This "second-level" review would also require extraordinary human labor and consume enormous time. See Sontag Decl. ¶ 14.

  5. One shortcut to comparing the UNIX and Linux code might be comparing similar directory structures of the UNIX and Linux operating systems. For example, version 2.4 of the Linux kernel contains 530 subdirectories and about 8750 source and assembly files. See Understanding The Linux Kernel, Bovet. Assuming each of the 8750 files requires on an average one day to investigate (some files are small, but others contain thousands of lines of code), about thirty-five man-years would be required to review all the Linux kernel files in detail. However, this calculation ignores the possibility that the two operating systems use different file names and a different file layout, and that similar code sequences may reside in entirely different files. See Sontag Decl. ¶ 15.

  6. Software (i.e., source code) undergoes many changes during its initial development and later over its operational life. Changes may occur as frequently as daily and can continue for years. Software changes typically are driven by the need to correct "bugs," to improve features, or to add new features. Because of changes made to source code over time, a current code version may "look" different than the initial code version, making identification of the initial code version difficult; and substantial similarity and derivation more difficult to establish.

  7. The Sontag Declaration describes how such an examination of code lineage would streamline SCO's discovery efforts. Mr. Sontag provides an example of SCO's UNIX System V source code for a print error function (perror.c), illustrating accumulated modifications over time. The first version of the code appeared in 1981, and by the time the seventeenth version appeared more than ten years later, the perror.c code sequence was almost unrecognizable from the initial version. Yet a careful review of the code reveals that the seventeenth and the initial versions have the same structure, sequence and organization — the accepted test to show substantial similarity. See Gates, F.3d at 836-839. Table 1, which shows the incremental change to perror.c code over time by way of code difference plots, makes explicit what SCO contends here; access to IBM's CMVC system would greatly streamline SCO's discovery efforts. See Sontag Decl. ¶¶ 37-42.

  8. In support of its argument that SCO needs no further discovery, IBM relies on the plainly inapposite case of Gemisys Corp. v. Phoenix Am., Inc., 186 F.R.D. 551 (N.D. Cal. 1999). IBM Resp. at 14. In Gemisys, the plaintiff sought to depose three witnesses for a second time in the apparent hope that they would change their testimony, and to depose an undisclosed number of other witnesses on issues about which it had already obtained information through prior depositions. Id. at 565-66. In a Rule 56(f) motion, the plaintiff requested this redundant discovery based on its mere "hope that further evidence will develop prior to trial." Id. at 566. In contrast, SCO's request is not based on a speculative hope that evidence will develop, but on SCO's specific demonstration of the relevance of the discovery material to SCO's case and the lack of burden IBM will bear in producing it. Moreover, SCO requests discovery thus far withheld by IBM in contravention of SCO's requests and this Court's Orders, and does so through a motion to compel, where "the concept of relevance should be construed very broadly." 3/3/04 Order at 3 (quoting Gohler, IRA et al. v. Wood et al., 162 F.R.D. 691, 695 (D. Utah 1995)).

  9. Magistrate Judge Boyce often remarked that a showing of undue burden sufficient to defeat a request for relevant discovery must be akin to "cleaning the Aegean stables."

  10. Given that IBM initially defended its decision to produce the code on DDS tapes and refused to provide them in the DVD format, it obviously took less than three weeks to make the necessary transfer once they had decided to provide them to SCO in the correct format.

  11. IBM further states that it "does not maintain revision control information for AIX source code prior to 1991" Thomas Decl. ¶ 5 (emphasis added), but does not state whether they possess pre-1991 revision control information for AIX source code. Even if pre-1991 AIX revision control information is unavailable, that does not mean IBM cannot produce pre-1991 notes, white papers and design documents, as well as releases and versions of AIX.


  


SCO's Reply Memorandum Re Discovery - as text | 340 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
SCO's Reply Memorandum Re Discovery - as text
Authored by: Anonymous on Monday, July 19 2004 @ 02:27 AM EDT
PJ, you are a poet.

[ Reply to This | # ]

SCO's Reply Memorandum Re Discovery - as text
Authored by: Philip Stephens on Monday, July 19 2004 @ 02:28 AM EDT
Gads, this is such a slimy document it almost makes me physically ill to read
it.

It disgusts me that SCO wants the entire case to hinge on one poorly worded
paragraph of the contract. Everything else they write is wholly dependant on
their interpretation being the correct one--without that, it all falls apart
like a house of cards.

Would it be reasonable to assume that now that IBM has managed to get SCO to
admit that their case is entirely about the contract, that they're getting ready
to either file their own memo or argue on August 4th that Judge Kimbell should
pospone all discovery pending a decision from him regarding the meaning of the
contract? Or that discovery should be limited to those areas that relate to the
interpretation of the contract?

I sure hope so, otherwise this damn case is just going to drag on and on while
no progress is made towards resolving the actual issues in the case.

[ Reply to This | # ]

Sucessor of Interest
Authored by: Vaino Vaher on Monday, July 19 2004 @ 02:32 AM EDT
Being a Linux fan, I am more interrested to see the copyright issue resolved. If
IBM has a contract problem with SCO then that is secondary to me.
However, to the best of my knowlege IBM never signed a UNIX license NewSCO.
Before NewSCO can ask for all of this discovery, doesn't it have to prove that
they are successor of interest?
To me it would mean:
- Show that Novell bought UNIX from AT&T.
- Show that OldSCO bought Unix from Novell.
- Show that Caldera bought Unix from OldSCO.
- Show that the rights were transfered from Caldera to the re-incorporated
NewSCO.

Before showing that paper trail, how can they ask for any discovery at all? And
why does IBM let them go on like this?

[ Reply to This | # ]

Chess game?
Authored by: Anonymous on Monday, July 19 2004 @ 02:35 AM EDT
PJ: "They didn't see IBM's strategy coming at them until it was almost too late."

This reminds of how I (sometimes) play chess with my father-in-law.

He (like IBM) plays well, knows tactics and strategy, and out-thinks me so I don't see what's coming.

I (like SCO) start out all clever, but soon start to lose. I then throw every piece I have, trading, hoping to win an advantage.

I won once using that strategy. But I think he had a cold.

Hey, maybe IBM is using Deep Blue. That explains why they are 'playing' so well.

M.

[ Reply to This | # ]

Corrections Here, Please
Authored by: thorpie on Monday, July 19 2004 @ 03:09 AM EDT
8th paragraph - Excape
First Heading after ARGUMENT in the memoranda - RESONABALY


---
The memories of a man in his old age are the deeds of a man in his prime -
Floyd, Pink

[ Reply to This | # ]

PJ you've lost the big picture!
Authored by: Anonymous on Monday, July 19 2004 @ 03:09 AM EDT
This isn't about SCO or SCO's morality, this is about FUD and time to Longhorn.
SCO is bought and paid for by M$, no doubt on a week by week basis and when SCO
gets shot down the money stops. That is why they are trying every trick in the
book to perpetuate this farce. The SCO company is dead meat no matter what
happens. It is only WHEN IT HAPPENS that makes any difference to the SCO
players.

[ Reply to This | # ]

IBM should move for summary judgement on the contract claims as well
Authored by: Totosplatz on Monday, July 19 2004 @ 03:12 AM EDT

This is amazing. If SCO is serious about this not being about copyright they should not oppose a judgement confirming that there is no copyright issue.

It seems obvious that IBM is on solid ground in regard to the contract because of the side letter and the echo article. Frustrating. IBM should move for summary judgement on the contract claims as well, right now. Why not?

Even if the judge does not grant IBM's request now I believe this will work out fine in the end. it seems that TSCOG has admitted a lot here which would be hard to deny in the future.

---
All the best to one and all.

[ Reply to This | # ]

OT and links here please.
Authored by: Anonymous on Monday, July 19 2004 @ 03:12 AM EDT
Let's try yo have a nice and organized page !

Loïc

[ Reply to This | # ]

SCO Discovery
Authored by: dht on Monday, July 19 2004 @ 03:15 AM EDT
OK, it's just a contract case. SCO claims it "controls" anything and
everything that has ever been placed in AIX or Dynix regardless of it's source.
IBM's interpretation is quite a bit different of course, based on the side
letter and the AT&T echo newsletter clarification.
IBM has admitted as facts that they have contributed their own AIX code to
Linux.
The issue narrrows down to "is IBM allowed to contribute their own
copyrighted code to Linux?" SCO says no, IBM says yes.

Now just why would SCO need further discovery for this? IBM has already
admitted all the essential facts required for SCO to persue their case (as they
see it). I always thought discovery was meant to unearth facts (disputed or
undisputed) relevent to the case. As it stands now, IBM has already stipulated
as fact all the items nessasary for SCO to "make" their case on a
simple contract dispute. The only issue left is the interpretation of the
contract as written.

I just don't get it.. If it was just a contract dispute over who
"controls" IBM written and copyrighted code all along, and IBM
stipulated from early on that they did in fact contribute their own code to
Linux, then why the need (and continuing need) for every single version of AIX
and Dynix in history?

They don't need all the versions of AIX and Dynix to "prove" IBM
contributed IBM copyrighted code to Linux, IBM has already admitted it, and the
very existance of such code in Linux is all the proof SCO needs. The very lack
of such code, or anything like it, in SCO's UNIX should "prove" it
came from somewhere other than SCO IP (methods, code, and ideas). So this
massive discovery request is in support of - what???

Finally, SCO is able to certify that HP and Sun are totally clean in their
contributions to Linux (based on the same Unix IP contract) without any such
massive discovery requests. How did they do this magical trick when they can't
do it for IBM?

The only reason they could need this level of discovery is to show that code
that was in orginally in Unix, somehow "evolved" into something that
was contributed to Linux in an unrecognized form. And that is back to a
copyright issue, not a contract issue.

This may be a clever document, but if you step back and look at the big picture
it makes even less sense than all the claims they have made to date.. Maybe they
are hoping to snow the courts with details and get them to forget the big
picture. I doubt they will succeed, or that IBM will fail to point out the
inconsistencies in the big picture.

I won't get into the merits of their claims, contract or copyright (worthless),
but it seems to me that this memo supporting their need for massive discovery is
totally inconsistent with the case as it was and how it stands today..

[ Reply to This | # ]

SCO's Reply Memorandum Re Discovery - admits that there is no copyright infringement case.
Authored by: Anonymous on Monday, July 19 2004 @ 03:17 AM EDT
If SCO admit that, then there should be no problem whatsoever in granting a
summary judgement that IBM's Linux activities do not infringe SCO's "IP
rights" - whatever those rights actually turn out to be.

Also, despite SCO continuing to claim that IBM breached a contract, SCO do not
have any contract with IBM. They are depending on a contract that IBM had with
AT&T.

Both IBM and AT&T say that that contract does not encumber any code IBM
writes. IBM code belongs to IBM, and that was the understanding between the
parties to the contract, and there is considerable evidence in writing to show
that that was indeed the understanding.

newSCO's view on what the AT&T - IBM contract means is both totally
irrelevant and totally wrong.

IMO, IANAL.

[ Reply to This | # ]

OT and other issues here, please
Authored by: bruce_s on Monday, July 19 2004 @ 03:31 AM EDT
OT and other issues here, please

Bruce S.

[ Reply to This | # ]

Confusing
Authored by: Anonymous on Monday, July 19 2004 @ 03:36 AM EDT
SCO argues that the whole thing is about a contract. All right, fine. What is
the problem then with the summary judgement in relation to copyright? Just get
it over and done with, it won't change the case anyway. Also, if SCO doesn't
need to show any infringing code at all (it's about a contract, remember), why
the heck have they been wasting court's time on getting all that AIX code and
why on earth do they want more of it?

It should be clear as a bell, right? If it's a contract issue, and if the
contract says that IBM isn't allowed to disclose or use any code that ever
touched Unix in any other way, why are we here? It is an undisputed fact that
JFS, JFS2, RCU etc. are all part of AIX, which is Unix. Why isn't IBM writing
cheques to SCO?

But it isn't all that clear, is it? And, the charade continues... And in the
end, SCO will have absolutely nothing to show - not a single thing. Not in
relation to copyright, not in relation to contract and trade secrecy has already
been dealt with. Did I mention they don't actually own the damn thing at all?

[ Reply to This | # ]

not copyright?
Authored by: Anonymous on Monday, July 19 2004 @ 03:41 AM EDT
From TSG's lawyer in the Autozone hearing:

Basically, it's SCO's position that certain companies, one of them being IBM, contributed code and other types of materials that are protected by not only licensing agreements but copyright laws to Linux for its own business purposes in order to create a competitor to the Microsoft software and the Unix software, which SCO owns and which SCO receives millions and millions of dollars in royalties from every year.

SCO still accusses IBM from copyright infringement in Linux. But I assume they say that they don't sue them over it.

H@ns

[ Reply to This | # ]

Depositions
Authored by: Anonymous on Monday, July 19 2004 @ 03:42 AM EDT
What about the depositions of former AT&T
executives? Have there been any ? They could
easily shed light on the whole "derivative
theory" thing, should the echo letter not be
enough.

[ Reply to This | # ]

No claims since 'beginning of litigation?'
Authored by: RedBarchetta on Monday, July 19 2004 @ 03:48 AM EDT
"But IBM's argument ignores the fact that SCO's principal claims are, as they have been since the beginning of this litigation, for breach of IBM's contractual obligations under the IBM and Sequent Software Licensing Agreements." -- Brent Hatch, SCO2 Attorney

As far as I'm concerned, this is yet another admission by SCO2's counsel that Darl McBride, Chris Sontag and Blake Stowell were lying through their teeth regarding code in Linux. This will definitely help IBM with it's counterclaims.

Just in case Brent Hatch forgot, since the beginning of Litigation (March, 2003), the SCO2 executives have made the following damning statements:
"[..] IBM has been happily giving part of the AIX code away to the Linux community, but the problem is that they don't own the AIX code," McBride said. "It's a huge problem for us. We have been talking to IBM in this regard since early December and have reached an impasse. This was thus the only way forward for us." --
Darl McBride March 10, 2004



"You don't have to be a programmer at all to see copying had occurred. It wasn't just ten lines of code, that example was over 80 to 100 lines of code. Later some of the Linux people said that code shouldn't have been there, Bruce Perens said it was development problem and 'we've taken it out.' My analogy is [that's] like a bank robber with posse in pursuit swinging back by the bank and throwing the money back in...

[...] It's kind of hollow words that we are not showing code, because we have shown examples and if we keep showing it, they'll just take that out and say 'no harm no foul.' That doesn't solve the problem."--
Chris Sontag Nov. 18, 2003



"In other words, SCO will present this evidence (code) to the jury, the judge and to the defendant [IBM], but it will remain confidential. No one in the public will get to see this code [..]" --
Blake Stowell Dec. 16, 2003

---
Collaborative efforts synergise.

[ Reply to This | # ]

Wolf
Authored by: Anonymous on Monday, July 19 2004 @ 03:58 AM EDT
SCO compared to a wolf?

Please PJ, you shouldn't disgrace the poor noble beasts like this ;)

If you have to use an animal analogy, perhaps a better pick is
"vulture": circling in the sky, oppurtunistically waiting for the
moment when someone has fallen or weakened, at which time they can feast on them
undisturbed.

[ Reply to This | # ]

  • Wolf - or louse - Authored by: john82a on Monday, July 19 2004 @ 04:59 AM EDT
  • Wolf - Authored by: inode_buddha on Monday, July 19 2004 @ 07:07 AM EDT
  • Dog - Authored by: Anonymous on Monday, July 19 2004 @ 08:17 AM EDT
    • longhorn - Authored by: seanlynch on Monday, July 19 2004 @ 10:02 AM EDT
      • longhorn - Authored by: darthaggie on Monday, July 19 2004 @ 11:15 AM EDT
        • longhorn - Authored by: Anonymous on Monday, July 19 2004 @ 12:01 PM EDT
  • Wolf - Authored by: Anonymous on Monday, July 19 2004 @ 10:59 AM EDT
  • Wolf - Authored by: Anonymous on Monday, July 19 2004 @ 12:18 PM EDT
  • OT: The persistent part of the argument - Authored by: johan on Monday, July 19 2004 @ 01:23 PM EDT
  • I still think - Authored by: Tim Ransom on Monday, July 19 2004 @ 01:29 PM EDT
  • Wolf - Authored by: Anonymous on Tuesday, July 20 2004 @ 04:57 AM EDT
Damages?
Authored by: Anonymous on Monday, July 19 2004 @ 04:05 AM EDT
Assume SCO proves that IBM's contributions to Linux are
prohibited by the IBM-ATT contract. What would the damages
be? The symbolic dollar?

[ Reply to This | # ]

SCO's real agenda?
Authored by: Philip Stephens on Monday, July 19 2004 @ 04:15 AM EDT
I'm wondering if we're misinterpreting SCO's real agenda in filing this
memorandum.

Think back a year, when Darl McBride and Chris Sontag were shooting off their
mouths to the press about how they want to turn Linux into a non-free OS, one
that they can collect royalties on every copy.

What was their justification for this? That Linux was an unauthorised
derivative of their System V UNIX, so they deserved to be compensated for their
"IP" being in Linux. They seemed supremely confident that their
"IP" was so thoroughly diffused throughout Linux that it could not be
removed.

Now, if the case SCO brought against IBM was truly a contract dispute, why
should SCO care if IBM was granted a summary judgement that Linux doesn't
infringe on SCO's UNIX copyrights? Surely there can only be one answer: despite
what SCO says in this current memorandum, they want to be able to pursue a
copyright infringement case against Linux sometime in the future.

Why else would they need unfetted access to everything related to AIX and Dynix,
except to build up "proof" that certain System V code
"morphed" into certain AIX code, and that same AIX code was then
donated to Linux, causing Linux to become a derivative of System V in the eyes
of copyright law.

We all know that case law doesn't support this creative interpretation of
derivative works. But what if McBride and Sontag have convinced themselves that
they can actually CREATE new case law that allows them to claim Linux as a
derivative of System V?

If this is what they are thinking, then the last thing they want is for a judge
to declare that Linux does not infringe on System V copyrights. They are so
desperate for this not to happen, they have been forced to argue that their case
against IBM is purely a contract dispute, thus the summary judgement should not
even be considered.

We all know that SCO do not need to see the entire history of AIX and Dynix to
support their interpretation of the contract. They only want this information
so that when (in their minds) they have the judge rule that IBM breached it's
contract, they can then file a whole new lawsuit against Linux distributors that
they're infringing on System V copyrights by virtue of AIX code appearing in
Linux.

Now, I don't know whether it's legal to use the discovery from one case to
support other cases, but it seems to me this is what SCO is trying to do. But
SCO has mismanaged the IBM case badly, because they pretty much revealed their
intentions in some of the original filings, where they whined about how Linux
was an unauthorised derivative of UNIX. IBM was smart enough to see what SCO
was trying to do, and gradually turned the screws on SCO until they were forced
to write this memorandum.

Anyway, that's my theory. I'm sure someone can shoot some holes in it, so fire
away... ;-)

[ Reply to This | # ]

SCO's Reply Memoranda -- Whoa, hold on a sec there!
Authored by: inode_buddha on Monday, July 19 2004 @ 04:47 AM EDT
"...but automated tools do not work well in the absence of identical copying. Sontag SJ Decl. ¶¶ 10-13. Those tools identify only exact or nearly-exact literal matches, thereby excluding evidence of non-literal copying." (Sec. 3 B, SCO's Requested Information Is Discoverable to Defend Against IBM's Recently-Added Copyright Claims., para. 6.)

I thought that *literal* copying, or substantial similarity, was required for copyright claims? (Excluding fair use). But wait! This is a *contract* case, isn't it?

"...The 4 million lines of Linux kernel code, which is the core portion of UNIX, takes up 66,000 pages..." (ibid., footnote 4)

Er, since when was the Linux kernel the core of UNIX?

---
"When we speak of free software, we are referring to freedom, not price." -- Richard M. Stallman

[ Reply to This | # ]

Laying an ambush for the GPL
Authored by: Anonymous on Monday, July 19 2004 @ 04:48 AM EDT
The issue now seems to be "IBM has improperly contributed its own code to
Linux in violation of a contract". Since it is not in dispute that IBM has
contributed code to Linux, that would seem to boil down to an argument over
whether SCO has rights over any or all of that code on the grounds of being a
derivative work.

Now if I find my GPL code distributed with the copyright removed, I know there's
a violation. And that applies also to derivative works under the GPL. So if I
*suspect* violation I may need discovery to determine whether it is a derivative
work under the GPL.

The direction this is going will set a precedent that will certainly be cited in
any major GPL trial under US law. So if SCO isn't granted all the discovery
it's asked for, that'll be a useful precedent for, say, M$ to deny discovery
when someone accuses them of GPL violation.

[ Reply to This | # ]

Copyright? What copyright?
Authored by: rand on Monday, July 19 2004 @ 05:38 AM EDT
"The contracts, granting the licensor more protection than copyright would
have done without any agreement..."

Please recall that in the early days of UNIX, AT&T did not rely on
copyright, but on trade-secret status. That's the reason for the contracts.
The original IBM/AT&T agreement was signed in 1985, the year before the 1986
BSD-AT&T License, and well before USL first registered UNIX in 1992.

SCOGroup has declared that there are no trade-secret issues, even though they
now assert that due to "...Contractually-Protected System
V 'Methods or Concepts'", "...IBM is no more free to disclose, export,
or publish any derivative version of AIX or Dynix/ptx than it is to disclose,
export, or publish System V itself." That sounds like a trade secret claim
to me.



---
carpe ductum -- "Grab the tape" (IANAL and so forth and so on)

[ Reply to This | # ]

I think IBM needs to make the points...
Authored by: Jude on Monday, July 19 2004 @ 06:05 AM EDT
...that IBM's contributions are only a small part of Linux, and that no amount
of AIX or Dynix discovery is going to help SCO find any infringment in the parts
of Linux that were not contributed by IBM.

There's also no need to look at all AIX and Dynix code to investigate IBM's
contributions. Only the ancestry of the contributed code should be subject to
discovery.

I think even more discovery could be obviated by getting an early decision on
SCO's "ladder" theory. SCO seem to be saying that any chain of
derivation makes all child nodes derivatives of the parent, but if the court
does not accept this theory then SCO's discovery will gain them nothing.

[ Reply to This | # ]

SCO's Principla Claims
Authored by: micheal on Monday, July 19 2004 @ 06:23 AM EDT
"But IBM's argument ignores the fact that SCO's principal claims are, as they have been since the beginning of this litigation, for breach of IBM's contractual obligations under the IBM and Sequent Software Licensing Agreements. "

What are SCO's secondary claims? Copyright violations?

---
LeRoy -
What a wonderful day.

[ Reply to This | # ]

IBM's Linux Activities
Authored by: micheal on Monday, July 19 2004 @ 06:36 AM EDT
"arguing that SCO cannot demonstrate any issues of material fact regarding copyright infringement by IBM in any of its (vast and continuously expanding, but only partially enumerated) "Linux activities.""

If IBM has a proprietary program that runs on Linux, would that program be considered a "Linux activity"? If it is and that program contains code that is validly copyrighted by TSG then IBM's 10th CC would clear (invalidly) IBM of copyright violation. That is a basis for rejecting he 10th CC. IBM should have been specific what they meant by "Linux activities".

---
LeRoy -
What a wonderful day.

[ Reply to This | # ]

Again SCO's odd (to say the least) views on derivative works
Authored by: Anonymous on Monday, July 19 2004 @ 06:56 AM EDT

So, they've come out and said it. (paraphrasing) Dynix 1 is a derivative of UNIX, and therefore covered by the UNIX licensing agreement. Dynix 2 is a derivative of Dynix 1, therefore of UNIX, and therefore covered by the UNIX licensing agreement. Repeat ad nauseum. Fair enough. I don't remember anyone arguing that this was not the case.

Now that's out in the open, if gives IBM some mighty fine ammunition. What I can see happening here is this:

  • IBM say, "Yeah, Dynix & AIX are derivatives of UNIX. So what?"
  • SCO say, "But you gave Dynix and AIX code to Linux. You're in the wrong"
  • IBM say, "No, we gave IBM code to Linux. Code that we may have added to Dynix and / or AIX as well, but IBM code nonetheless. Code we developed here independently of UNIX."
  • SCO say, "But if it's been in an UNIX derivative, it's ours. QED"
  • IBM say, "Cobblers. The SCO themselves state:
    under Paragraph 2.01 of the IBM and Sequent license agreements, "modifications and derivative works based on" UNIX System V are treated as if they were part of the original licensed "SOFTWARE PRODUCT,"
    this is code that was added to Dynix and / or AIX, code that was developed by us. It is neither a modification nor a derivative of any code existing in UNIX. The specific interface from UNIX derivative to our code is a derivative to our code, not that of the UNIX derivative in question. The core code is most definitely ours, to do with as we wish."
  • SCO say, "but we don't know that. So we need every copy of AIX and Dynix ever created, plus all your other code, just in case."
  • IBM say, "Ah. But you have the original UNIX code. And you have access to every version of Linux ever created. From the Linux source, you can see all and any code submitted by IBM. You also have many versions of AIX and Dynix. From the original UNIX code, you should be able to find any UNIX code that may possibly have slipped into Linux, as you have the source to both. After all, you claimed to have 'mountains' of literal copying in Linux, well before you asked for or received the AIX or Dynix source. If you have that literal copying, and you can tie it to specific IBM contributions, you may have a case. Hell, if you could tie something specific that IBM contributed to a piece of code that may have its roots in UNIX, we could go on. But as you seem unwilling to produce even that, we must conclude that you have no case, no evidence, and we must therefore ask the judge for summary dismissal on both the copyright and contract issues."
  • Judge says, "Sounds fair to me"
  • SCO say, "But.... But.... Damn. But... But, if Chewbacca lives on Endor, and..."

Well, it's unlikely to go exactly like that (except, perhaps, for the last defense of SCO), but I can't see that any sane judge is going to accept the SCO derivatives theory - it goes against all case law that I know of, and would create a most unpleasant precedent.

Frankly, I hope the Judge reams SCO a new one, to coin a phrase.

Simon

[ Reply to This | # ]

SCO contract theory explained
Authored by: MadScientist on Monday, July 19 2004 @ 06:58 AM EDT
This is a reposting of something I wrote on SCO contract theory. Aplogies to
anyone who read this before for this reposting but it seems to me that this
might(?) help any one having trouble with SCO contract claim.

BTW the trade secrets claim has gone away - so ignore this bit please. Also
wearing a tine foil hat while optional is recommened.

++++++++++++++++++++

As I presently understand the non copyright issues here this is a contract
dispute between IBM and SCO. SCO claim thier SOFTWARE PRODUCT (SysV) encompases
all derivative works based upon it and that in addition IBM were bound by thier
contract not to divulge any of the SOFTWARE PRODUCT code to anyone. This I
understand to be the basis of the trade secrets claim.

And that this case has made in in the door is because of the side letter - which
under court proceedings allows parol evidence (material outside the writing) to
be included.

++++++++++++++++++++++++

To review the situation again

In effect SCO claim that IBM and Sequent both agreed to work for AT&T as
part of their contract to use the SOFTWARE PRODUCT. The consideration on the
part of AT&T was that IBM and Sequent could use the SOFTWARE PRODUCT.

In addition to effectively working for hire IBM and Sequent agreed to licence
the use of the SOFTWARE PRODUCT. It is this contract that allows SCO (sucessors
in interest to AT&T) to lay claim to all of IBM's work since 1995 on SysV
and related products - to wit Aix and Dynix.

The royalty buyout that IBM concluded only relieved IBM of the need to pay
further licence fees but did not relieve IBM of the obligation to work for
Novell for no further consideration.

In addition to donating all the copyrights to the IBM created code to AT&T,
IBM has bound its sucessors to this contract. This in addition means that IBM
releasing the new code to anyone else is a breach of the contract because of the
requirement in the contract to keep secret those thing that should be kept
secret.

According to this contract then IBM and Sequent have been working effectively as
SCO employees/contractors since 1995. IBM are in breach of their contract
because they have released SCO owned code to third parties and released trade
secrets (the code itself) again to third parties.

Because of the side letter parol evidence is needed to establish exactly what
the contract meant originally. Hence the need for the depositions etc.

+++++++++++++++++++

Now needless to say I have more than a few problems with this.

Firstly the consideration on the part of AT&T and it sucessors seems to be
highly inequitable. In return for pemission to use the SOFTWARE PRODUCT IBM et
al are bound in perpetuity to donate code to AT&T. And have to pay for the
priviledge. Tricky one that. Wonder if the court will uphold it. Hmm.

Secondly based on the premises of the above paragraph, the uniform comercial
code (UCC) requires a contract that cannot be fulfilled in less than one year to
be reduced to writing. Strange - I missed that in the contract.

Thirdly in general what one creates is one's own copyright - the main exceptions
being works for hire. Unless the contract can be intrepreted to be a contract
for hire, IBMs own code is IBM's.

That is unless there is a 204 assignment. There have been no 204 assignments
produced to date by SCO. Given this one must assume that SCO have understood the
AT&T contract to be one for hire and that somewhere in the provisions it is
stated that IBM (and Sequent) have agreed to work for AT&T without fee for
perpeuity as part of the price for using the SysV code. (See the above
paragraph)

IBM and Sequent by conviently forgetting to mention this in 1995 are in clear
breach of the obligations to the SEC and their shareholders.

+++++++++++++++++++++

What would a "reasonable man" make of this?

Comercial cases are on the "balance of probability" - not "beyond
all reasonable doubt".

First IBM and Sequent essentially sell themselves to AT&T without telling
anyone. And no one realises this for almost 10 years. All the AT&T, IBM,
Sequent and Novell lawyers missed this. All the SEC officials missed this. The
shareholders missed this. The stock market analysts et al missed this deal. That
*is* curious.

Is it *just* possible that that contract never really said that?

That the contract just said that IBM & Sequent could use the SysV code in
return for a licence fee and could study the code as long as the SysV code
itself was kept secret from non employees/contractors. And that the royalty
buyout as essentially the end of the matter as far as IBM were concerned -
except for the secrecy bit which still stands.

And that IBM own thier own code. And that it is IBM owned code that has been
contributed to Linux? And that AT&T, Novell, Sequent & IBMs lawyers were
not wrong. And the shareholders were not wrong. And the SEC were not wrong.

And is it possible that just maybe SCO is the one who is wrong - because their
lawyers have forgotten their contract law?

+++++++++++++++++++

Or is it I myself who has it all totally wrong here?

[ Reply to This | # ]

SCO's Reply Memorandum Re Discovery - as text
Authored by: soronlin on Monday, July 19 2004 @ 07:05 AM EDT
3. The Requested Discovery is Relevant to and Will Aid SCO in Determining Whether IBM Disclosed Contractually-Protected System V "Methods or Concepts."

This section makes no mention about AIX, only Dynix/ptx. Why? Because IBM is allowed to use Unix Methods and Concepts in any of their other products and services. The relevant clause of the licence is 7.06(a):

7.06 (a) LICENSEE agrees that it shall hold all parts of the SOFTWARE PRODUCTS subject to this Agreement in confidence for AT&T. LICENSEE further agrees that it shall not make any disclosure of any or all of such SOFTWARE PRODUCTS (including methods or concepts utilized therein) to anyone, except to employees of LICENSEE to whom such disclosure is necessary to the use for which rights are granted hereunder. LICENSEE shall appropriately notify each employee to whom any such disclosure is made that such disclosure is made in confidence and shall be kept in confidence by such employee. If information relating to a SOFTWARE PRODUCT subject to this Agreement at any time becomes available without restriction to the general public by acts not attributable to LICENSEE or its employees, LICENSEE'S obligations under this section shall not apply to such information after such time.
However the side-letter modified that clause as follows:
7.06(a) LICENSEE agrees that it shall hold SOFTWARE PRODUCTS subject to this Agreement in confidence for AT&T. LICENSEE further agrees that it shall not make any disclosure of such SOFTWARE PRODUCTS to anyone, except to employees of LICENSEE to whom such disclosure is necessary to the use for which rights are granted hereunder. LICENSEE shall appropriately notify each employee to whom any such disclosure is made that such disclosure is made in confidence and shall be kept in confidence by such employee. Nothing in this agreement shall prevent LICENSEE from developing or marketing products or services employing ideas, concepts, know-how or techniques relating to data processing embodied in SOFTWARE PRODUCTS subject to this Agreement, provided that LICENSEE shall not copy any code from such SOFTWARE PRODUCTS into any such product or in connection with any such service and employees of LICENSEE shall not refer to the physical documents and materials comprising SOFTWARE PRODUCTS subject to this Agreement when they are developing any such products or service or providing any such service. If information relating to a SOFTWARE PRODUCT subject to this Agreement at any time becomes available without restriction to the general public by acts not attributable to LICENSEE or its employees, LICENSEE's obligations under this section shall not apply to such information after such time.
Note also 7.06(b) and its side-letter commentary:
(b) Notwithstanding the provisions of Section 7.06(a), LICENSEE may distribute copies of a SOFTWARE PRODUCT, either in modified or unmodified form, to third parties having licenses of equivalent scope herewith from AT&T (or a corporate affiliate thereof) for the same SOFTWARE PRODUCT, provided that LICENSEE first verifies the status of any such third party in accordance with specific instructions issued by AT&T. Such instructions may be obtained on request from AT&T at the correspondence address specified in Section 7.11(b). LICENSEE may also obtain materials based on a SOFTWARE PRODUCT subject to this Agreement, provided that LICENSEE treats such materials as if they were part of such SOFTWARE PRODUCT.

Regarding Section 7.06(b), this section covers the situation where one of our licensees wishes to furnish its modified version of our source code for a SOFTWARE PRODUCT to another of our licensees for the same product. The last sentence of this section makes clear that you may receive source code from another such licensee, provided you treat such source code as if it were the source code we furnished to you. This language is not intended to refer to an object-code product that you obtain from another of our licensees pursuant to that licensee's sublicensing rights.

So the modified subsection (a) obviously defines what IBM can do with Dynix/ptx after they received it from Sequent. They can use "ideas, concepts, know-how or techniques" from Dynix/ptx in any way they like so long as they don't directly copy, or use the manuals. Sequent before the takeover was bound by the original version of 7.06(a), and therefore could not divulge Unix methods or concepts.

[ Reply to This | # ]

A legal rabbit asks...
Authored by: jmc on Monday, July 19 2004 @ 07:14 AM EDT
Why doesn't IBM seek a declaration from the court invalidating the whole of
SCO's mega-viral derivative work theory?

All of the recent rants about discovery would be put to bed wouldn't they?

[ Reply to This | # ]

Shouldn't SCO have said this in November?
Authored by: Anonymous on Monday, July 19 2004 @ 07:21 AM EDT
In arguing that copyright was never part of the case, purely contractual, and so
on, aren't they ignoring the IBM discovery requests completely?

IBM requested details of all rights (which obviously includes copyrights) which
SCO claimed in Linux. In November, SCO had a chance to argue before the court
that such information was overly broad for discovery, that there were no
copyright claims in the case and so they shouldn't have to produce all that.
They could have argued that it should be changed to "all code over which
SCO claims rights under the licensing agreement" for instance.

I don't remember them making that argument, probably because with the broader
but vaguer order they got, they could pretend they were complying with discovery
while doing no such thing.

Presumably they had another chance to argue it in March when they were ordered
to produce the same information again, as they were prepared to argue everything
else. :)

So my point is, didn't SCO (or, if SCO made the arguments and my memory is at
fault, the court) already concede that there were potential copyright issues in
the case, that copyrights in Linux were (or could be) at issue by agreeing that
IBM's discovery requests were reasonable and likely to turn up relevant
information?

[ Reply to This | # ]

Did IBM help open this door?
Authored by: Anonymous on Monday, July 19 2004 @ 08:03 AM EDT
IBM essentially said: "if giving scox some AIX code, and some more time,
will put an end to scox's whining, then sure, we'll give scox some code."

By doing that, IBM gave credibility to the idea that scox, for some reason,
needs AIX code. If scox needs this portion of AIX code, then why not another
portion as well?

I think scox may have won this battle. IBM stepped right into scox's little
trap. Scox now has justification for one delay after the next.

[ Reply to This | # ]

A way to flush out Non-litteral Copying?
Authored by: julianne on Monday, July 19 2004 @ 08:10 AM EDT
For a long time, I have sat through code reviews, thinking that looking for
"real or substantive changes" should be easier to find than wading
through tons of diff listings. Having reviewed the Gates case and the theory of
"non-litteral copying," I thought the very same thing. What is
required is a tool that I would call "code-diff" that parses the
sources in question and looks for differences in the parse trees of the two.
With the parse differences, the program can go back and highlight the sections
that contain the differences. In that way, one can identify such things as
variable renaming, parameter type changes, modifications of control flows, etc.

Since most of the code in question in the SCO vs World cases is written in C,
the challenge is great in finding the way around all of the C-isms that make it
hard to read/maintain (ifdefs, defines, redefs, etc.) However, the preprocessor
stuff can be the subject of further structural comparison.

With a tool like this, this whole thousands-of-years claim could be put to bed
rather quickly, having the ability to do searches as rapidly as the traditional
text diff. All this being said, how does the non-litteral copying theory hold
up when one finds examples of expressions that can only be done a few ways (as
discussed in previous threads)?

Even if this doesn't have much impact on the current case, maybe it's time to
bring a tool like this into the FOSS collection.

[ Reply to This | # ]

Definition of term "SOFTWARE PRODUCTS" in the contracts
Authored by: Totosplatz on Monday, July 19 2004 @ 08:16 AM EDT

It seems clear that TSCOG thinks that the term SOFTWARE PRODUCTS means the original code package obtained from AT&T as well as each successive stage of development made by the recipient.

I think that IBM thinks that the term SOFTWARE PRODUCTS refers to only the original code package obtained from AT&T.

So which is it? Or am I missing something here?

---
All the best to one and all.

[ Reply to This | # ]

A way to end this mess?
Authored by: Totosplatz on Monday, July 19 2004 @ 08:54 AM EDT

It is abundantly, redundantly clear that code originated by a licensee of Sys-V UNIX belongs to the originator, forever.

IBM happily admits that it added code to Linux, and that some or most of that code "came from" AIX (or Dynix) or was substantially similar to code in AIX (or Dynix.)

So if IBM would just identify the several thousand places where they added code to Linux, all one would have to do is look in SYS-V UNIX to see it there is any SYS-V UNIX code as part of what IBM added to Linux.

Therefore: just check IBM's additions only, no Sys-V code amongst those additions, case closed!

I know - much too simple!

---
All the best to one and all.

[ Reply to This | # ]

SCO's Reply Memorandum Re Discovery - as text
Authored by: julian on Monday, July 19 2004 @ 09:38 AM EDT
I remember that IBM requested in discovery that SCO list all IBM contract
violations and to state what part of the contract IBM's behavior violated. If
SCO didn't respond fully or gave their theory on derivitives IBM should have an
easy declaritory judgement for contract violations. I tried finding the
origional doc in "Legal Docs" but couldn't find it.

---
John Julian

[ Reply to This | # ]

SCO's Reply Memorandum Re Discovery - as text
Authored by: blacklight on Monday, July 19 2004 @ 09:47 AM EDT
I haven't read SCOG's latest memo yet, but I will get to it - Work is getting in
the way. In the meantime, the sheer scope of their discovery requests amount to
as explicit a case of attempted discovery abuse as any or all of us have yet
seen. And that scope is a strong and clear indicator as to the lack of evidence
that they have. Otherwise, why would SCOG go through this rigmarole rather than
push the trial schedule forward? The sooner SCOG wins, the sooner SCOG gets its
$5 bils, right?

[ Reply to This | # ]

  • Nitpick - Authored by: Anonymous on Monday, July 19 2004 @ 02:57 PM EDT
SCO's own argument may come back to bite them.
Authored by: Anonymous on Monday, July 19 2004 @ 09:54 AM EDT
It seems to me that if the court ever finds for SCO, SCO's agument that all
IBM's AIX/Dynix code is controlled by SCO may come back to bite them in the
end. After all, if Novell succeeds in showing that it never transferred Unix
copyrights to SCO, then SCO's argument would lead one to believe that Novell
actually controls any additions that SCO made to System V.

[ Reply to This | # ]

Ok now watch the Novell card get played
Authored by: Anonymous on Monday, July 19 2004 @ 10:20 AM EDT
Novell has already told IBM they can do whatever they want so now we will
probably see the Novell card get played.

[ Reply to This | # ]

The Charge of the SCOX Brigade
Authored by: darthaggie on Monday, July 19 2004 @ 11:26 AM EDT
So the SCO cavalry was called in and this is their bugle blast as they swarm over the hill. "We are entitled to try for more discovery", is their call. "Don't cut us off at the pass! We'll be ruined." We'll see if the judge buys it.

One thing is for sure. They didn't see IBM's strategy coming at them until it was almost too late. Maybe too late, period.

My first mental picture was that of the charge of the Light Brigade:

Cannon to right of them,
Cannon to left of them,
Cannon in front of them
Volley'd and thunder'd;
Storm'd at with shot and shell,
Boldly they rode and well,
Into the jaws of Death,
Into the mouth of Hell
Rode the six hundred.

Lord Tennyson

Methinks they're walking into a trap. They may win a stay on CC10, but they're in the process of handing IBM more material to lob back at them when the time is right. There's only so long they can keep changing their story before they get beaten up for it.

[ Reply to This | # ]

About the AT&T-IBM Software Agreement
Authored by: RealProgrammer on Monday, July 19 2004 @ 12:21 PM EDT

Something bothers me between ¶2.01 and ¶7.06(a) of the The 1985 AT&T-IBM Software Agreement, but I can't quite pin it down:

2.01
    AT&T grants to LICENSEE a personal, nontransferable and nonexclusive right to use in the United States each SOFTWARE PRODUCT identified in the one or more Supplements hereto, solely for LICENSEE'S own internal business purposes and solely on or in conjunction with DESIGNATED CPUs for such SOFTWARE PRODUCT. Such right to use includes the right to modify such SOFTWARE PRODUCT and to prepare derivative works based on such SOFTWARE PRODUCT, provided the resulting materials are treated hereunder as part of the original SOFTWARE PRODUCT.
7.06 (a)
    LICENSEE agrees that it shall hold all parts of the SOFTWARE PRODUCTS subject to this Agreement in confidence for AT&T. LICENSEE further agrees that it shall not make any disclosure of any or all of such SOFTWARE PRODUCTS (including methods or concepts utilized therein) to anyone, except to employees of LICENSEE to whom such disclosure is necessary to the use for which rights are granted hereunder. LICENSEE shall appropriately notify each employee to whom any such disclosure is made that such disclosure is made in confidence and shall be kept in confidence by such employee. If information relating to a SOFTWARE PRODUCT subject to this Agreement at any time becomes available without restriction to the general public by acts not attributable to LICENSEE or its employees, LICENSEE'S obligations under this section shall not apply to such information after such time.
(emphasis added)

  1. Paragraph 2.01 says only that the "resulting materials" be treated "hereunder" (i.e, in a subsequent part of the agreement) as part of the original product
  2. I don't read that to say that the modifications themselves must be treated as part of the product
  3. Since Caldera/SCO released Ancient UNIX (pre SysV) code under a no-fee license (pdf) to the general public, none of the code, concepts, or methods represented there apply after Jan 23, 2002
  4. Since Caldera/SCO published Linux before, during, and after the IBM AIX contributions to Linux allegedly took place, the restrictions in 7.06(a) do not apply.
Therefore, IBM was allowed to contribute its own AIX code to Linux. Even if it were not allowed, Caldera/SCO published the alleged materials itself, nullifying any restrictions on disclosure.

I see the holes in my reasoning (such as if "resulting materials" is really the individual IBM-written piece and not the whole derived product), but I think there's something between paragraphs 2.01 and 7.06(a).

---
(I'm not a lawyer, but I know right from wrong)

[ Reply to This | # ]

Why is this in federal court, then?
Authored by: Neil Dunbar on Monday, July 19 2004 @ 12:28 PM EDT
OK, confused UK reader without knowledge of jurisdiction wants to know -

If this is just a contract dispute, and not primarily a copyright issue, then
why isn't it in state court? SCO2 made such a song and dance in the Novell case
that it should be remanded to state court because it wasn't about copyrights.

Surely, then, if it's primarily a contract dispute, it should be in the Utah
state courts. Or is this because the parties are incorporated in different
states that it elevates to the federal level?

Neil

[ Reply to This | # ]

Why not stipulate that some models of code development took place?
Authored by: Anonymous on Monday, July 19 2004 @ 12:38 PM EDT
Why would IBM not stipulate the following:

"SCO code fragment x appears somewhere in a sequence like:
a) Package w internal release a.
<Code not there>
b) Package w internal release b.
<Code not there>
....
c) Package w internal release b+n.
<Code there>
d) Package w internal release b+n+1
<Code removed when inadvertant copying detected.>
e) Package w internal release b+n+2
<Code not there>"

The idea being that they could stipulate that this
sequence of events happened at least once. One occurance
would preclude all the discovery nonsense and get right to
the legal issue on which SCO has built its house of cards.
Damages would depend on scope but that would be a separate
issue once the legal principle has been decided. Couldn't
IBM stipulate those events with the reservation that the
stipulation is not enought to determine damages? Once the
legal theory is determined, the trial can then go on to
assess damages based on the result. As I understand it,
"indirect copying" could occure if a programmer had recreated SCO code
independently and there is no practical
way of determining if the code was deliberately copied
from SCO or not. It seems to me the worst case could be
stipulated in order to test SCO's theories without prejudicing damages.




[ Reply to This | # ]

SCO's Reply Memorandum Re Discovery - as text
Authored by: Anonymous on Monday, July 19 2004 @ 02:00 PM EDT
Ha! Linux may be the hostage all right... but it's Mongo.

'No no, don't do that. If you shoot him, you'll just make him mad.'

[ Reply to This | # ]

Yabut....
Authored by: ihawk on Monday, July 19 2004 @ 02:52 PM EDT
Okay, so let me get something straight here...

SCO says IBM violated the contract with AT&T which stated that IBM needed to
maintain confidentiality of UNIX trade secrets (basically). The contract didn't
have to do with copyright since much of the UNIX source code was not copyrighted
and could not be subsequently copyrighted. So it's a trade secret issue, right?
Methods and structures and stuff, right?

So at some earlier date, SCO or its predecessor in interest released
"ancient" Unix sources to the public. Even though this is an earlier
version of Unix, it's the same trade secrets, the same methods and structures.
That would tend to sort of obviate the trade secrets status of pretty much all
version of Unix, wouldn't it? I mean, they can hardly claim that a method or
structure that was made public in v32 Unix still be held secret in SVRx, can
they? I understood that once a trade secret was dicslosed, no matter how, it
could no longer hold trade secret status. So what's to be held confidential?

Also, SCO can hardly insist that original development by IBM be held as trade
secret if IBM wants to make it public. They are trying to say that new
development by IBM is a derivative of Sys V - which is pretty much completely
ridiculous - and has to be treated as confidential under the terms of the
original AT&T license even though AT&T made it explicit and perfectly
clear that there was no such connection.

So I am now officially and completely mystified as to what SCO is saying IBM did
wrong by contributing their own code to Linux.

..ihawk..

[ Reply to This | # ]

  • Yabut.... - Authored by: Anonymous on Monday, July 19 2004 @ 03:05 PM EDT
    • Yabut.... - Authored by: ihawk on Monday, July 19 2004 @ 04:35 PM EDT
SCO's Reply Memorandum Re Discovery - as text
Authored by: tredman on Monday, July 19 2004 @ 02:54 PM EDT
"Why doesn't IBM seek a declaration from the court invalidating the whole
of SCO's mega-viral derivative work theory?"

I think it's amusing that you should use the apropos term "mega-viral"
to describe TSG's derivative works theory. Wasn't Darl McBride one of those who
was harping on the fact that the GPL was unsuitable for use because of it's
viral nature? The GPL doesn't have anything on Darl's tripe.

Tim

[ Reply to This | # ]

SCO's Reply Memorandum Re Discovery - as text
Authored by: tredman on Monday, July 19 2004 @ 03:59 PM EDT
Am I reading that first paragraph correctly? Is TSG explaining, in a motion
before a federal court for the United States of America written in their
butchered legalese, that they have absolutely no evidence, and that they need
AIX source code to find some?

Nooooo....say it isn't so.

Tim

[ Reply to This | # ]

So many docs, so little memory . . .
Authored by: kjb on Monday, July 19 2004 @ 04:15 PM EDT
I needed to reread the original complaint to compare the two documents. I reread
Sco's Reply Memorandum. After reading Sco's Reply Memorandum preliminary
statement again, it seems that the two documents have little or nothing in
common. Am I that far off or is it just wishful thinking?
kjb

---
"No! Try not. Do, or do not. There is no try."
- Yoda

[ Reply to This | # ]

SCO's Reply Memorandum Re Discovery - as text
Authored by: blacklight on Monday, July 19 2004 @ 04:52 PM EDT
"But the reality is, this case is about a contract dispute. Linux got
dragged into it as hostage. SCO is holding Linux by the neck, pointing a gun at
its head, and telling IBM, "Do what I tell you, or I'll shoot your little
friend."" PJ

or "... Do what I tell you, or the penguin gets it." Darl McBride?

Hey, Darl. If you really want to make the penguin scream, point the gun at your
groin ...

[ Reply to This | # ]

Organized LQWiki pages related to discovery compliance, CC10, PSJ, compel orders
Authored by: Thomas Frayne on Monday, July 19 2004 @ 06:46 PM EDT
I have organized my comments related to discovery compliance, CC10, PSJ, and compel orders in two ways, and put the results in LQWiki pages starting with

LQWiki: SCOvIBM-PSJ

I am trying to get an organized discussion of the arguments which should go into the remaining briefings before, and oral arguments at, the August 4 hearing. The page starts with a list of major court filings, organized by groups of related filings. Next comes a discusion of arguments related to the PSJ and IBM-205's context, organized by the topics argued. Finally, there is a discussion of arguments related to the PSJ, organized by the topics argued.

Section 1 is up to date, and allows finding the filings, including the text in Groklaw. Sections 2 and 3 are just outlines, so far, but they link to detail pages that I am adding my comments to. I'll be copying comments that I previously made on Groklaw, Yahoo Finance, and section 4 of the Wiki page to the proper place in the outline over the next few days. When I find a related article or comment, I'll add a link to the appropriate place in the outline, together with a short summary of the content. I invite others to do the same.

Also, if anyone wants to give me or everyone permission to copy any of their comments into the outline, please respond to this post with the permission.

To see an outline of the top page, just click here.

[ Reply to This | # ]

SCO's Reply Memorandum Re Discovery - as text
Authored by: blacklight on Monday, July 19 2004 @ 10:47 PM EDT
SCOG's reply memo is pretty much an admission that their goose is cooked with
the evidence that they currently have. In addition, the very scope of the
discovery they are asking for, which crosses the line into abuse of discovery,
is a tacit admission that they just don't have much of anything to hang IBM on -
SCOG clearly went to court against IBM with little more than a pack of lies. In
my opinion, the SCOG memo does not contain any new information, and is
essentially a replay attack.

[ Reply to This | # ]

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 )