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 Memorandum on Discovery - as text
Thursday, June 03 2004 @ 01:27 AM EDT

Here is SCO's Memorandum Regarding Discovery as text. Our thanks to Steve Martin for transcribing and coding.

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

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

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

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

Attorneys for Plaintiff

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
PLAINTIFF/COUNTERCLAIM
DEFENDANT SCO'S
MEMORANDUM REGARDING
DISCOVERY

Case No. 2:03-CV-0294 DAK

Honorable Dale A. Kimball
Magistrate Judge Brooke C. Wells

On March 3, 2004, this Court directed International Business Machines Corp. ("IBM") to produce certain AIX and Dynix files. March 3, 2004 Order ("March Order") at 4, ¶ 1. It also directed The SCO Group, Inc. ("SCO") to explain whether and how these files supported its position in this case, and further stated that it would consider ordering IBM to produce additional code upon SCO's identification of additional files and the reasons for such requests (id.). SCO states as follows in response to the March order.

I. BACKGROUND

SCO needs the discovery requested in this Memorandum for at least three reasons:

  1. To respond further to IBM's discovery requests. IBM claims discovery misconduct and delay by SCO in providing discovery responses, while IBM has the information SCO needs to respond.

  2. To gather evidence relevant to IBM's theory of SCO's contract claim, under which IBM appears to assert that to establish IBM's breach of the Agreement at issue, SCO requires specific evidence of derivation from UNIX System V lines of code through the versions of AIX and Dynix code to Linux.

  3. To gather relevant evidence in support of SCO's theories of its contract case against IBM, including without limitation: (a) that every transfer from AIX and Dynix, as whole programs, into Linux constitutes a breach of the Agreement, and/or (b) that AIX and Dynix are derivative works of UNIX System V, and consequently, IBM's contributions to Linux from AIX and Dynix are breaches of the Agreement.

A. SCO's Breach of Contract Claims.

SCO claims that IBM breached its software agreement (AT&T Technologies, Inc. Software Agreement, executed on Feb. 1, 1985 ("Agreement") [Exh. 1]) by, among other actions, distributing parts of the AIX and Dynix operating system software programs to Linux. Because the Agreement does not permit IBM to lease or transfer any parts of the AIX and Dynix programs, IBM's contribution of AIX and Dynix code to Linux violates that Agreement. (1) Such contributions to a public forum also violate the requirement to maintain the "resulting materials," AIX and Dynix, as confidential. Id. at § 7.06.

SCO also claims that IBM's contribution of parts of AIX and Dynix to Linux breached the Agreement because both the AIX and Dynix programs, as whole programs, are modifications or derivative works of UNIX System V, so no parts of those programs may be sold, leased or otherwise transferred. See note 3. Again, for example, because the Agreement prohibits the transfer of software programs in whole or in part, IBM's contributions to Linux from AIX and Dynix -- as derivative works of UNIX System V -- violate the Agreement. SCO is entitled, under the Federal Rules, to evidence relevant to these claims.

B. IBM's Apparent Assertions as to Proof SCO Must Offer to Establish IBM's Breach of Contract, SCO's Entitlement to Establish Liability under Alternate Theories, and SCO's Entitlement to Relevant Discovery.

IBM is apparently taking the position that in order for SCO to succeed on its contract claims, SCO must prove copyright infringement. This position -- if taken as a description of the sole basis for IBM's liability for breach -- confuses contract with copyright and thereby essentially eliminates the protections of the contract for SCO. Nevertheless, SCO recognizes that the rules of discovery obligate it to respond, to the best of its ability, to IBM's discovery requests. And in any event, SCO, like any plaintiff, is entitled to proceed under alternate theories of liability, and to obtain the discovery needed to allow it to do so.

SCO must have access to the requested discovery to (1) show, in one of many possible ways, that AIX and Dynix are modifications of and derivative works based on UNIX System V; (2) obtain evidence that IBM donated AIX and Dynix into Linux, and to prove the origin and extent of such donations; (3) have access to all relevant information regarding IBM's contributions to Linux through AIX, ptx, Dynix/ptx, and Dynix(2); and (4) review all relevant sources reasonably calculated to lead to the discovery of admissible evidence (Fed. R. Civ. P. 26(b)(1)).

C. IBM's Discovery Demands and SCO's Entitlement to Obtain Evidence Relevant to Responding to those Demands.

IBM's broad discovery requests relating to the derivation of Linux from AIX and Dynix code require SCO to do a detailed code analysis. The means for conducting such an analysis and presenting proof, however, is solely in IBM's hands.

SCO must have access to IBM's revision control systems, to interim versions of AIX and Dynix which IBM has declined to produce, to programmer notes and design documents related to modifications and revisions to the programs, and to other materials which will allow SCO to provide complete answers to IBM's interrogatories asking for the lines of code from UNIX System V from which IBM's contributions from AIX and Dynix/ptx were derived; to defend against IBM's Cross-Motion for Partial Summary Judgment on its Claim for Declaratory Judgment of Non-Infringement; and to supplement SCO's response to the Court's March Order (see March Order at 2, ¶¶ 2-3).(3)

Further, IBM has argued that "SCO does not need any AIX and Dynix source code for its analysis" -- and that "IBM has met all of its discovery obligations".(4) To the contrary, SCO needs revision control system information(5) and versions of AIX and Dynix to further respond to IBM's discovery demands, and to counter IBM's argument that SCO has "delayed in providing full and complete responses to IBM's discovery requests". IBM Opp. at 4. Without the listed items (see Section II infra), to which only IBM has access, SCO will not have the information to which it is entitled under the Federal Rules, nor will it be able to further respond to IBM's interrogatories. (6)

D. IBM's Previously Produced Files

The files previously produced by IBM pursuant to this Court's March Order show that IBM improperly contributed code to Linux, but these materials are only partial responses to SCO's requests for information and materials. IBM has produced selected pieces of AIX and Dynix, consistently refusing to produce all requested versions of AIX and Dynix,(7) or the revision control systems for either program. Because Dynix code contains some historical commentary, SCO has been able to trace some sources of contributions to Dynix code. This research has revealed that Dynix contains material and significant UNIX System V code.

AIX almost certainly has a similar history, but because AIX's code does not contain any historical comments, or at least the AIX code provided did not, SCO has had difficulty determining all the portions of AIX that were taken from UNIX System V. To trace the foundations of AIX source code, and to have a complete understanding of Dynix's source code origins, SCO must have access to all interim and final versions of AIX, Dynix and ptx; to programmer notes and design documents that reveal the work behind the revisions to the programs; and most importantly, to all revision control systems that track changes to AIX and Dynix, thus exposing the sources of IBM's current AIX and Dynix code and revealing what portions of UNIX System V made their way from AIX and Dynix into Linux.

E. SCO's Efforts to Respond to IBM's Allegations Without Complete Production from IBM.

IBM has selected snapshots of AIX and declined to provide either the change-log information or the revision control information showing the changes between the various snapshots. Consequently, it is difficult if not impossible to find the original sources of the improper contributions of SCO's contractually protected code. Without the listed items, SCO has spent countless hours, and sometimes fruitless effort, trying to track the improper use of UNIX System V code in Linux through AIX and Dynix.

In the absence of the code, programs and other materials requested, the following tasks and efforts have been undertaken by SCO:

  • Identification of all publicly available code patches contributed by IBM/Sequent engineers to Linux, to the extent identified on IBM's web site and in Linux forums.

  • Tracing of code in available code patches to versions of AIX and Dynix.

  • Identification of all publicly available categories in Linux that are or have been worked on by IBM/Sequent engineers, to the extent identified on IBM's web site or obvious from Linux forums.

  • Identification of IBM's role in Open Source Development Laboratory (OSDL), and IBM's role in Carrier Grade Linux project and Data Center Linux project, as described in the OSDL website.

  • Review of all publicly available sources to identify the modules of UNIX System V code improperly misappropriated into Linux by non-IBM sources, to the extent possible.

  • Identification of IBM's public statements regarding its roadmap for building Linux and its technology contributions to Linux.

  • Identification and tracing of certain UNIX System V file system code, including structures, sequences, and interfaces in UNIX System V code, that became modified or derivative file system (JFS1) code in AIX; identification and tracing of the same file system code (JFS1) in AIX to modified, derivative file system (JFS2) code also in AIX; and identification and tracing of the same file system code (JFS2) to modified, derivative file system code in Linux, to the extent possible based on the limited production made available by IBM.

  • Identification and tracing of certain multiprocessor lock-avoidance code (RCU) from Dynix/ptx to become modified, derivative multiprocessor lock-avoidance code (RCU) in Linux that appears to be based on proprietary UNIX-based code, methods or concepts.

  • Identification and tracing of certain multiprocessor memory access code (NUMA) from Dynix/ptx to a code dump made available to Linux that appears to be based on proprietary UNIX-based code, methods or concepts.

  • Identification of substantial activity by former Sequent engineers and IBM engineers in SMP design, locking and performance enhancement in Linux that appears to be based on proprietary UNIX-based code, methods or concepts.

  • Identification tracing of substantial activity by former Sequent engineers and IBM engineers in debugging, testing and logging information for use by other Linux engineers in improving Linux performance in other areas that appears to be based on proprietary UNIX-based code, methods or concepts.

  • Identification and review of all design documents related to multiprocessor technology created by USL engineers, or as work for hire by Sequent engineers for USL relating to multiprocessor technology ("ES/MP design documents").

  • Identification of the areas in Unix System V ES/MP code base that contain multiprocessor technologies based on the proprietary ES/MP design documents.

  • Identification of, to the extent possible from IBM's production, the former Sequent engineers who had access to System V and to Dynix, and have made contributions to Linux.

  • Identification of, to the extent possible from IBM's production, the AIX engineers and contractors who had access to System V and to AIX, and have made contributions to Linux.

  • Identification of, to the extent possible from IBM's April 19, 2004 document production, the general areas of Unix SVR4 code, methods and concepts adapted for use by IBM in AIX 5.1, AIX 5.2 and AIX5L. (Detailed code review has not yet occurred.)

These efforts have not, however, yielded much of the information required for SCO to further respond to IBM's discovery demands. SCO has attempted to follow IBM's scattered path through the winding history of countless alterations, derivations, and revisions, but the task is nearly impossible without a map, a map so easily accessible to IBM, so clearly relevant to this case, and so absolutely essential to SCO that IBM's withholding of it and subsequent filing of a summary judgment motion is unconscionable.

II. ADDITIONAL ITEMS REQUESTED(8)

SCO requests that this Court order IBM to produce the following:

  • all revision control system information (including documents, data, logs, files, and so forth) for AIX, Dynix/ptx, ptx, and Dynix from 1984 to the present

  • source code and log information for all interim and released versions of AIX, Dynix, ptx, and Dynix/ptx from 1984 to the present

In addition, SCO requests that this Court order IBM to produce all design documents, whitepapers and programming notes, created from 1984 to the present, related to the following:

As to AIX:

  • Journaled File Systems (including PFS, JFS, and J2) and all other file systems used or developed by IBM in AIX (including System V file system)

  • Extended Volume Management System (EVMS)

  • Async Input/Output (I/O)

  • MPIO

  • Standard I/O

  • symmetric multiprocessing (SMP) and other multiprocessing (MP) functionality

  • documents related to performance measurement and management

  • SVR4 features in AIX

  • debugging and statistics gathering for both kernel and user-space functionality

  • inter-process communications

As to Dynix, ptx, and Dynix/ptx:

  • read-copy update (RCU)

  • non-uniform memory access (NUMA)

  • Async I/O, MPIO and Standard I/O

  • SMP and all other changes related to MP functionality

  • performance enhancement tools and methods

  • SVR4 features in Dynix and/or PTX

  • debugger and statistics gathering for both kernel and user-space functionality

  • inter-process communications

  • hot swapping

  • virtual file system

  • MP enhancements to network file system

  • System V file system

Each of these items falls within previous SCO requests to IBM, but IBM has resisted production without SCO's filing of this Memorandum. See Letter from Christoper Kao to Mark Heise, dated April 14, 2004 [Exh. 2].

III. ARGUMENT

A. The Listed Materials are Relevant and Necessary

Under the Federal Rules, parties "may obtain discovery regarding any matter, not privileged, which is relevant to the subject matter involved in the pending action" or "reasonably calculated to lead to the discovery of admissible evidence." Rodgers v. Hyatt, 91 F.R.D 399, 402 (D. Col. 1980), citing Fed. R. Civ. P. 26(b). This rule is to be liberally interpreted. Id.

"'[O]nce a party has requested discovery, the burden is on the party objecting to show that the discovery is not relevant....'" Smith v. MCI Telecommunications Corp., 137 F.R.D 25, 27 (D. Kan. 1991) (citations omitted). This is a difficult burden to satisfy, especially in the discovery stage of litigation. Id., citing Miller v. Doctor's General Hospital, 76 F.R.D. 136, 138- 39 (W.D. Okla. 1977) ("Relevancy is broadly construed at the discovery stage of the litigation and a request for discovery should be considered relevant if there is any possibility the information sought may be relevant to the subject matter of the action."); Gohler v. Wood, 162 F.R.D. 691, 695 (D. Utah 1995) ("[A]t the discovery stage, the concept of relevance should be construed very broadly.").

Not only are the revision materials highly relevant to this litigation, but they are also necessary for SCO to further answer IBM's interrogatory requests (IBM's Second Set of Interrogatories to SCO, Interr. Nos. 12-13; Fourth Set, Nos. 15-16), which require SCO to list lines of code which were derived from UNIX System V. Also, this Court has ordered SCO to make these identifications. March Order at 2, ¶ 3. Unless and until IBM produces the requested materials, SCO cannot complete these discovery tasks.

SCO's need for the materials is especially evident because IBM's discovery requires SCO to compare one thing to another. In Weahkee v. Norton, 621 F.2d 1080 (10th Cir. 1980), Weahkee had sued the EEOC for discrimination, and requested the personnel files of EEOC employees whom he contended were hired or promoted in discriminatory preference over him. The Court refused to compel their production. Finding that this refusal constituted an abuse of discretion, the Tenth Circuit honed in on the plaintiff's need for access to those files so that they could be compared to his: "[t]he qualifications and job performance of these employees in comparison with the plaintiff's qualifications and performance is at the heart of this controversy." Id. at 1082 (emphasis added). SCO's need for the revision trees is of a kind with Weahkee's, in that IBM believes SCO must compare UNIX System V, AIX, Dynix, and Linux side-by-side and show derivation. Due to the constantly evolving nature of these operating systems, mere snapshots in time (what IBM has provided) are not enough.

Finally, the requested materials are not available from any source other than from IBM. Of course:

[A] court may limit discovery where "the discovery sought is ... obtainable from some other source that is more convenient, less burdensome, or less expensive." Fed. R. Civ. P. 26(b)(2)(i). The court also may limit discovery if "the burden or expense of the proposed discovery outweighs its likely benefit." Fed. R. Civ. P. 26(b)(2)(iii).
American Medical Systems, Inc. v. National Union Fire Ins. Co. of Pittsburgh, PA, 1999 WL 562738, at *2 (E.D. La. Aug 2, 1999). However, none of these apply to limit discovery here: the discovery SCO has requested from IBM is not available from any other source, nor will IBM bear any burden or expense in producing the requested materials that outweighs the benefit of the discovery (See Section III.C, infra).

SCO Needs the Materials to Respond to IBM's Allegations.

IBM argues that SCO must list lines of code which were obtained from UNIX System V (IBM's Second Set of Interrogatories to SCO, Interr. Nos. 12-13; Fourth Set, Nos. 15-16), and that without providing such information, IBM is entitled to summary judgment on noninfringement of SCO's copyrights. One way SCO can unequivocally establish derivation and modification -- and defeat IBM's arguments -- is by examining AIX and Dynix source code directly.(9) Without access to AIX and Dynix source code, SCO has little IBM code to compare to UNIX System V source code. The AIX and Dynix source code that IBM has already provided shows derivation and modification in the sense that UNIX System V code is present in those versions. See Exhibits E and F to Letter from Brent Hatch to Todd Shaugnessy, dated April 19, 2004 ("Hatch April Letter") [Exh. 3]. To this extent, these files support SCO's position that AIX and Dynix are modifications of, and derivative works based on, UNIX System V.

SCO alleges in its contract claim that IBM contributed AIX and Dynix to Linux in violation of its Agreement. SCO also alleges that AIX and Dynix, considered as whole programs, are derivative works of UNIX System V, and again -- under the Agreement -- cannot be split into parts and distributed. To establish that AIX and Dynix are derivative works of UNIX System V and that their source code was contributed to Linux, SCO must be able to compare UNIX System V, AIX and Dynix, and Linux source codes. The source code that IBM has produced has allowed SCO to make such a comparison, and to find tens of thousands of lines of code from AIX and Dynix that were copied to places in Linux. See SCO's Revised Supplemental Response to IBM's Interrogatory 1, filed Jan. 12, 2004 [Exh. 4], and Exhibits B and C to Hatch April Letter [Exh. 5]. This establishes that IBM donated AIX and Dynix source code to Linux, and supports SCO's breach of contract claim.

In short, the files that IBM produced pursuant to this Court's Order of March 3, 2004, directly support SCO's defenses to IBM's contentions in this case. But those files are incomplete, and the proof they offer is, in some cases, inferential. For example, while it is possible to state that File A from AIX (or Dynix) was the origin of File B in Linux (see attached code comparison of Dynix v4.6.1 and the patches IBM placed in Linux 2.4.1 [Exh. 6]), it is nearly impossible to find the original source of File A (the code contribution to Linux) due to IBM's incomplete production. Only complete production by IBM of AIX and Dynix source trees will enable SCO to find the additional intermediary versions of code which must exist.

Additionally, complete production by IBM will enable SCO to tell the entire story of AIX's derivation from UNIX System V. This story began when IBM obtained access to UNIX System V through the licensing agreements it reached with AT&T in 1984. Also, full disclosure by IBM will allow SCO to complete the tracking and identification of AIX-based contributions to Linux. This task includes identification of direct code copying, identification of copying of sequences and structures, and identification of methods and concepts traced from AIX (including design documents) into Linux, or otherwise made available to Linux by IBM.

Comprehensive production by IBM will also allow SCO to complete the tracking of Dynix and ptx-based contributions to Linux. This task includes identification of direct code copying, identification of copying of sequences and structures, and identification of methods and concepts traced from Dynix and ptx (including design documents) into Linux, or otherwise made available to Linux by IBM. Id.

SCO will also be able to complete the following when in possession of the request materials:

  • Provide a more detailed identification of IBM's improper contributions of AIX code, methods and concepts to Linux.

  • Provide a more detailed identification IBM's improper contributions of Dynix/ptx code, methods and concepts to Linux.

  • Provide a more detailed identification of IBM's improper use of SCO's copyrighted information improperly contributed to Linux by others.

  • Conduct a detailed evaluation of the code similarities between System V ES/MP code base and all produced versions of Dynix/ptx, which will yield a view of the subset of System V code that is contained in the Dynix/ptx code.

  • Conduct a detailed evaluation of the code similarities between System V ES/MP code base and all AIX/AIX5L code bases, which will yield a view of the subset of recent SVR4 code recently added to AIX and AIX5L by IBM.

Accordingly, in order for SCO to fully trace the derivation of AIX and Dynix from UNIX System V, IBM must produce their revision control systems in a format that will allow SCO to track the derivation and modification of UNIX System V source code in AIX and Dynix. Id.

C. The Burden on IBM is Negligible.

Without access to AIX's and Dynix's revision control systems, SCO will labor at a substantial disadvantage in this case since it will be unable to adequately investigate and independently substantiate IBM's improper contributions to Linux (and if necessary, to counter IBM's copyright noninfringement argument). In sharp contrast to the potential burden to be shouldered by SCO, IBM's production of all versions of AIX and Dynix and of the complete revision control systems will be a small matter. As IBM explains in an internal document, all levels of all files are stored on central servers, and should be easily available for downloading and production to SCO. See IBM's Configuration Management Version Control (CMVC) Introduction (1710058191-92) [Exh. 7].

This situation thus closely resembles the one in Dynamic Microprocessor Assoc. v. EKD Computer Sales, 919 F. Supp. 101 (E.D.N.Y. 1996). One of the claims in that case required the comparison of two versions of a program called pcAnywhere. The plaintiff, who controlled the source code, did not want to produce it. The defendant's experts testified as to the prejudice this refusal caused them:

We need the original source code for Versions 3 and 4 of pcAnywhere in order to render a professional opinion on the issues posed to us. Without the source, we can only speculate and the facts cannot be known with any certainty. In addition, since [the plaintiff] and any experts it engages will obviously have access to the source code, we would be placed at a considerable and unfair disadvantage in evaluating any opinions tendered by them.
Id. at 104. Recognizing the defendant's "substantial disadvantage ... if it is unable to adequately investigate and counter [plaintiff's] claims through its own experts," the court ordered the plaintiff to produce the source code. Id. at 105.

IBM develops and maintains source code through what are arguably the world's most sophisticated set of tools for that purpose. The task's complexity is not measured by the number of lines of code, or the number of files to be produced: producing a million lines of code is not materially different, in this context, from producing ten lines, or ten million lines. IBM keeps them neatly organized in servers designated for that purpose. Gathering these materials is, for a competent engineer, a rather trivial task. Considered alongside the fact that SCO has no other possible source for this information and requires it for many aspects of this case, IBM's burden is negligible.

IV. CONCLUSION

AIX's and Dynix's revision control systems are the histories of those operating systems. They trace their development in detail. They will reveal IBM's contributions to Linux; they will show that AIX and Dynix are derivative works of UNIX System V. Thus, SCO respectfully asks this Court to compel IBM to produce, in a usable format,(10) the revision control systems for AIX and Dynix.

WHEREFORE, SCO requests that pursuant to this Court's March Order, IBM be ordered to produce all revision control systems for AIX and Dynix, all versions of AIX and Dynix code, and other revision-related materials; specifically, the items listed in Section II, supra.

DATED this 28th day of May, 2004.

Respectfully submitted,
By: (signature)
Brent O. Hatch
Mark R. Clements
HATCH, JAMES & DODGE

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

Counsel for Plaintiff/Counterclaim Defendant



[1] Section 7.10 of the Agreement [Exh. 1] states:
Except as provided in Section 7.06(b), nothing in this agreement grants to LICENSEE the right to sell, lease or otherwise transfer or dispose of a SOFTWARE PRODUCT in whole or in part.

[2] In the mid-1980s, Dynix had a sister program called ptx. The two were later merged into Dynix/ptx, sometimes referred to as simply "Dynix" or "PTX".

[3] IBM has been aware of SCO's position on this point for quite some time. SCO informed IBM's counsel on April 19, 2004 that without interim versions of the AIX and Dynix/ptx code and the revision control systems that tracked derivations and modifications, it was difficult if not impossible for SCO to respond to IBM's theory of its noninfringement of SCO's copyrights. See Letter from Brent Hatch to Todd Shaughnessy, dated April 19, 2004, ¶ 3 [Exh. 2]. See also Letter from Mark Heise to David Marriott, dated April 7, 2004 [Exh. 2].

Despite SCO's clear statement of its position that IBM's production remained incomplete, IBM has tried to use its own failure to respond adequately to SCO's discovery requests as the basis for a Cross-Motion for Partial Summary Judgment on its Claim for Declaratory Judgment of Non-Infringement, dated May 18, 2004. IBM should not be allowed to rely on its own discovery shortcomings in order to obtain partial summary judgment against SCO. To respond to IBM's charges in its Cross-Motion, SCO must have access to the materials requested in this memorandum.

[4] IBM's Opposition to SCO's Motion to Amend the Scheduling Order ("IBM Opp.") at 14- 15 (emphasis original). IBM's Opposition also claims that SCO has engaged in "discovery misconduct" and is the sole cause of delay in this case. Id. at 2.

[5] Examples of revision control systems include RCS (revision control system), SCCS (source code control system), and CVS (concurrent versioning system) files and/or trees with unexpurgated log information.

[6] Notably, in addition to needing this information to respond to IBM's allegations that SCO has engaged in "discovery misconduct," (IBM Opp. at 2), SCO needs this information simply to defend against IBM's copyright counterclaim (if it remains in this litigation).

[7] For example, IBM has refused to produce AIX version 5.0, without adequate explanation. See Letters between Mark Heise and David Marriott/Christopher Kao, dated March 29, April 2, April 7, and April 14, 2004 [Exh. 2].

[8] This list contains many items, but as explained in Section III.C, infra, the burden on IBM to produce these materials is negligible.

[9] Of course, another way is for IBM simply to admit that AIX and Dynix are derived from UNIX System V. In this litigation, IBM has declined to do make this admission, thereby contradicting IBM's own public statements and internal documents. IBM's inconsistent position need not be fully addressed here, but it will certainly be addressed in this litigation.

[10] IBM's initial production of AIX to SCO was in a non-standard format. It was not until March 25, 2004 that IBM produced AIX source code in a format SCO could use. ISO-9660 DVDs or CD-ROMs are the current standard interchange format.


  


SCO's Memorandum on Discovery - as text | 125 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Missing the point
Authored by: Anonymous on Thursday, June 03 2004 @ 03:45 AM EDT
Surely (2) at least is SCO missing the point. The reason that IBM have requested
they show everything they claim to have rights to in Linux is not for the breach
of contract phase, but for the IBM counterclaim that SCO have misrepresented
their ownership rights to linux (Lanham act stuff, since this potentially
impacts IBM's business)

If that were not the case IBM would be going for summary judgement on the
Contract issues as well as the IBM Copyright Declaratory Judgement issue.

It seems so transparent that IBM will point this out (Again) that whereas at
first I thought the lawyers were just trying to confuse this issue, I'm now more
convinced that they simply don't get it.

[ Reply to This | # ]

SCO's share price
Authored by: AndyC on Thursday, June 03 2004 @ 04:05 AM EDT
Did anyone else notice that the share price opened at an absurdly high price
yesterday? I think this was based upon the sale of about 30-50,000 shares at a
very high price ($5.50 I think). This is only my supposition, but could this
have been SCO massaging the share price?

Just my 2p.

[ Reply to This | # ]

We require another 10 files
Authored by: Anonymous on Thursday, June 03 2004 @ 04:08 AM EDT
(Weeks pass)
We require another 10 files.
(Weeks pass)
We require...

I think you get the idea. Perhaps the best thing IBM could do would be to just
give them the code. All of it. All version, all RCS comments, everything, and
invite them to knock themselves out. Unless the case is dismissed with
prejudice, you know SCO are going to appeal. Do we really want to hear this
"Just a little more code" line repeated again at appeal?

[ Reply to This | # ]

Footnote 10 is interesting
Authored by: Drew on Thursday, June 03 2004 @ 04:15 AM EDT
Footnote 10 is interesting and might explain the discrepancy we´ve noticed
in the timing of discovery. What format did IBM deliver it in originally?

[ Reply to This | # ]

Precis (very Short) of SCO's Memorandum on Discovery
Authored by: kurzon on Thursday, June 03 2004 @ 04:20 AM EDT
<sarcasm>
Until IBM provide us with proof that they have done all the things that we say
they have done then discovery cannot be complete.
</sarcasm>
Isn't this a bit like accusing someone of stealing something because they were
in your house (even though a previous occupant invited them, and some people say
it's not really your house) but you're not quite sure what it was. So please
could they provide a complete inventory of their house because they have nice
stuff and some of it must be ours!

OK bad analogy but their arguments would fly a bit better if they could say
'Look, we have solid proof that they did X - here it is, it may only be a small
thing but we're pretty sure that they have done a lot of other things because
they're bad people'.

Unfortunately for them they have not convinced anybody that they have any solid
evidence. They've repeatedly said they have but they 'refuse' to show it on the
grounds that it's 'trade secrets' but they want IBM to show them everything IBM
have ever done.

Sheesh...

[ Reply to This | # ]

Sympathy
Authored by: Anonymous on Thursday, June 03 2004 @ 05:03 AM EDT

From my handy Webster's:

sympathetic magic, magic predicated on the belief that one thing or event can affect another at a distance as a consequence of a sympathetic connection between them. Cf. contagious magic.

contagious magic, magic that attempts to affect a person through something once connected with him, as nail clippings, a cloth containing the sweat from his bodya, or a footprint left in the sand; a branch of sympathetic magic based on the belief that things once in contact are in some way permanently so, however separated physically they may subsequently become.

[ Reply to This | # ]

  • Same rules in security - Authored by: jesse on Thursday, June 03 2004 @ 09:04 AM EDT
  • Sympathy - Authored by: Anonymous on Thursday, June 03 2004 @ 12:28 PM EDT
    • Sympathy - Authored by: Anonymous on Thursday, June 03 2004 @ 02:22 PM EDT
SCO's Memorandum on Discovery - as text
Authored by: DeepBlue on Thursday, June 03 2004 @ 05:38 AM EDT
SCO has attempted to follow IBM's scattered path through the winding history of countless alterations, derivations, and revisions
In other words it has changed so much it is no longer anything like the Unix code we are claiming it to be a derivative of!!

---
Even David needed some stones in his sling to topple Goliath ........

[ Reply to This | # ]

Did IBM say AIX and Dynix are derived from SysV?
Authored by: be2weenthelines on Thursday, June 03 2004 @ 05:47 AM EDT
Footnote 9 claims they did, in both "public statements and internal
documents". It seems quite possible to me that they did say something like
this, although not meaning it in the precise sense of "derivative
works" required for SCO's legal theory. Can we figure out what public
statements SCO is referring to?

be2

[ Reply to This | # ]

SCO's Memorandum on Discovery - as text
Authored by: blacklight on Thursday, June 03 2004 @ 05:53 AM EDT
Basically, SCOG is implicitly admitting that they have very little to no
evidence and that they need to go on this fishing expedition to get the evidence
that they need. It is troubling that despite the fact that IBM provided SCOG
with 242 versions of its products, SCOG has "discovered" just
"tens of thousands of lines of code" that it admits don't add up to
anything. I believe that IBM has already provided far more code than would be
justified by whatever evidence SCOG originally claimed to have. At the risk of
stating the obvious, SCOG is trying to drive up IBM's costs of litigation, and
create a delay so that they can try to push the Autozone case ahead of IBM's.

[ Reply to This | # ]

Corrections Here for PJ
Authored by: Steve Martin on Thursday, June 03 2004 @ 06:11 AM EDT
(Please check before posting a correction, there are one or two mistakes in the
original PDF, which I left in.)


---
"When I say something, I put my name next to it." -- Isaac Jaffee, "Sports
Night"

[ Reply to This | # ]

SCO's Memorandum on Discovery - as text
Authored by: Khym Chanur on Thursday, June 03 2004 @ 06:37 AM EDT
To gather evidence relevant to IBM's theory of SCO's contract claim, under which IBM appears to assert that to establish IBM's breach of the Agreement at issue, SCO requires specific evidence of derivation from UNIX System V lines of code through the versions of AIX and Dynix code to Linux.

Heee! SCO is acting like IBM is asking them to trace the history of a piece of SysV code as it winds it way through AIX, morphs, and then winds up in Linux. But IBM is actually saying that if the AIX code they donated to Linux is a derivative of SysV, it must contain SysV to be called a derivative, and thus that SysV code must show up in Linux. If SCO can't find any SysV code in Linux, then IBM couldn't have contributed any derivate code to Linux, at least not by the normal standards of what a "derivative work" is. But if you buy SCO's version of derivative works, then SCO does indeed have to trace the history and mutations from pristine SysV code to whatever code ended up in Linux... Which would mean that SCO would have to have the complete source repository (CVS/RCS type database) to see what was going on. How convenient for SCO.

I wonder if, upon reading this, the magistrate was amused or angered.

---
Give a man a match, and he'll be warm for a minute, but set him on fire, and he'll be warm for the rest of his life. (Paraphrased from Terry Pratchett)

[ Reply to This | # ]

Even if they're right, they're wrong
Authored by: soronlin on Thursday, June 03 2004 @ 06:53 AM EDT
Suppose for an instant that there is direct textual copying from Unix Sys V
through AIX to Linux. SCOGs argument seems to be that they cannot detect that
copying without intermediate versions.

But does not copyright law state that in order to infringe the included portion
must itself be sufficient to fall under copyright law?

If SCOG's team cannot detect derivation between Unix and Linux, then the
portions of copied software must be unrecognisable.

How can copyright law forbid making a derivation so obscure that it is not
recognisably a derivation?

[ Reply to This | # ]

Ruling on definitions?
Authored by: soronlin on Thursday, June 03 2004 @ 07:01 AM EDT
Can IBM ask for a ruling on the definition of "derivatives and
modifications" as used in the licence? Something like "... are defined
according to copyright law."

[ Reply to This | # ]

Non-standard formats?
Authored by: eriktorbjorn on Thursday, June 03 2004 @ 07:01 AM EDT
[10] IBM's initial production of AIX to SCO was in a non-standard format. It was not until March 25, 2004 that IBM produced AIX source code in a format SCO could use. ISO-9660 DVDs or CD-ROMs are the current standard interchange format.
That's ironic. Didn't they argue that paper was the preferred format for human-readable source code back in November?

[ Reply to This | # ]

DUH, who is the Plaintiff in this case?
Authored by: Anonymous on Thursday, June 03 2004 @ 07:38 AM EDT
"This situation thus closely resembles the one in Dynamic Microprocessor
Assoc. v. EKD Computer Sales, 919 F. Supp. 101 (E.D.N.Y. 1996). One of the
claims in that case required the comparison of two versions of a program called
pcAnywhere. The plaintiff, who controlled the source code, ..."

Is not SCO the plaintiff?

Granted that IBM is the counterclaim plaintiff, but the discovery issue in play
here is based on SCO's original complaint.

Garbage argument.

[ Reply to This | # ]

SCO's Memorandum on Discovery - as text
Authored by: Anonymous on Thursday, June 03 2004 @ 08:57 AM EDT
source code and log information for all interim and released versions of AIX, Dynix, ptx, and Dynix/ptx from 1984 to the present

By asking for source code of all interim versions of IBM's Unix offerings, have they not just given IBM a license to swamp them with an unmanageable amount of data?

For instance, assuming that on average 25 changes were made per day, 5 days a week, and that each change creates a new "interim version", that's abour 130000 interim versions of AIX alone since 1984. One version per CD, makes for about one-and-a-half tonnes of stuff.

I almost hope they get it...

Phil

[ Reply to This | # ]

Unbelievable!
Authored by: Anonymous on Thursday, June 03 2004 @ 09:18 AM EDT

Sweet Zombie Jesus, I can't believe that SCO has the gall to put this into their filing:

[3] IBM has been aware of SCO's position on this point for quite some time.

Yeah, and SCO has been aware of the court's position on this, which is that SCO's position is wrong. I believe the exact words were "you've made your point, I'm just not sure if I agree with it."

Do they think that the judge has Alzheimer's or something, and won't remember what she said to them?

[ Reply to This | # ]

SCO's Memorandum on Discovery -What are they REALLY asking for??
Authored by: savage on Thursday, June 03 2004 @ 09:27 AM EDT
If you read carefully, they are trying to trace SYS V code in AIX. WHY????

examples :
SCO must have access to the requested discovery to (1) show, in one of many
possible ways, that AIX and Dynix are modifications of and derivative works
based on UNIX System V

SCO must have access to IBM's revision control systems, to interim versions of
AIX and Dynix which IBM has declined to produce, to programmer notes and design
documents related to modifications and revisions to the programs, and to other
materials which will allow SCO to provide complete answers to IBM's
interrogatories asking for the lines of code from UNIX System V from which IBM's
contributions from AIX and Dynix/ptx were derived

If you can't compare SYS V or AIX with Linux and find the answers, why would
showing all the recoding that I.B.M. did to the source to make it work help? The
driv. works idea would only work if you can show how idea "x" relates
to idea "y" .... not how idea a morphs into idea b that morphs into
idea c that .... etc

just my .02

---
Savage

In the 60's everyone took acid to make the world appear wierd
today everyone takes prozak to make the world appear normal

[ Reply to This | # ]

Why not?
Authored by: overshoot on Thursday, June 03 2004 @ 09:33 AM EDT
Why, we might ask, didn't IBM just fork over the whole shebang?

I propose that it was precisely to force SCOX to file this, which finally (after more than a year!) lays out at least part of a rebuttable legal theory that IBM can mock before Judge Kimball.

[ Reply to This | # ]

Take it from a CM guy, all versions will not be an easy request.
Authored by: WayneStPaul on Thursday, June 03 2004 @ 10:37 AM EDT
I never worked on a CM system that did not periodically archive all the old
versions, baselines, and revision informaiton from the CM system onto tape, then
delete all of that information from the on-line system. The primary reason for
this was to keep the size of the database smaller (CM systems never seem to be
small), thus keeping the performance of the system nice and quick.

The last CM system I worked on used a relational database and did not need this
periodic purge of data as much, but older systems did. Since much of this code
goes back to the 70's? I suspect that IBM will have to struggle to re-import the
revision control history for this software. It would not surprise me that the
revision control information is in a format that current versions of their
revision control software cannot import. The QIC format mentioned in footnote
10 is only half the issue. The format of those files could very wel be an
issue also.

On the other hand, this may not be as bad as I first thought, as IBM probably
used an IBM CM tool, so they should have the source code to rebuild the tool
that can read the old CM archive formats. Althought how they would deliver
these logs to SCO in any format SCO can use is another question.

[ Reply to This | # ]

SCO's Memorandum on Discovery - as text
Authored by: Anonymous on Thursday, June 03 2004 @ 10:52 AM EDT
SCO lays most of their argument here on:
  1. AIX and Dynix being derivate works taken in their entirety (no argument there)
  2. The contract requiring that IBM treat derivatives as if they were the original software.
  3. The contract prohibiting IBM from transferring a piece of the software.
Can anyone point out what parts of the contract these last two parts refer to and how likely is SCO's reading of them compared to other possible readings?

[ Reply to This | # ]

MPIO -- what the heck?!?!
Authored by: AHGrayLensman on Thursday, June 03 2004 @ 10:59 AM EDT
If this is the MPIO I think they mean (the I/O part of the MPI-2 parallel programming API, co-developed by IBM and Argonne National Lab in '94 or '95 IIRC), I'd love to know how they claim it's part of SVr4. Besides which, all the "design documents" are publicly accessible from the mailing list archives on the MPI forum web site.

---
"You are finite, Zathras is finite, this... is wrong tool. No, not good, never use this!" --Zathras, "War Without End (pt. 2)", Babylon 5

[ Reply to This | # ]

SCO's Memorandum on Discovery - as text
Authored by: belzecue on Thursday, June 03 2004 @ 11:02 AM EDT
"...but the task is nearly impossible without a map, a map so easily
accessible to IBM..."

[pounds table]

"...so clearly relevant to this case...

[pounds table!]

"...and so absolutely essential to SCO that IBM's withholding of it and
subsequent filing of a summary judgment motion is unconscionable..."

[POUNDS TABLE!... table splinters in two]

I'm not even a lawyer and I'm embarrassed at the juvenile antics of SCO's legal
team.

[ Reply to This | # ]

Sale of Dynix to IBM illegal?
Authored by: RabidChipmunk on Thursday, June 03 2004 @ 11:24 AM EDT
SCO is claiming that "the Agreement" says they can't sell or transfer Dynix. However, Dynix was sold to IBM. Is SCO challenging the earlier transfer of Dynix?
Does Dynix only become part of "the Agreement" after IBM buys it?
If Dynix was originally under an equivalent agreement, doesn't its transfer to IBM prove that "the Agreement" allows transfers?
[I.A.2]SCO also claims that IBM's contribution of parts of AIX and Dynix to Linux breached the Agreement because both the AIX and Dynix programs, as whole programs, are modifications or derivative works of UNIX System V, so no parts of those programs may be sold, leased or otherwise transferred. See note 3. Again, for example, because the Agreement prohibits the transfer of software programs in whole or in part, IBM's contributions to Linux from AIX and Dynix -- as derivative works of UNIX System V -- violate the Agreement. SCO is entitled, under the Federal Rules, to evidence relevant to these claims.

[ Reply to This | # ]

SCO's Memorandum on Discovery - as text
Authored by: TechnoCat on Thursday, June 03 2004 @ 12:11 PM EDT
The request-for-Discovery requiring all version control seems odd in light of the basic copyright claim.

The claim is essentially, "IBM copied our code into Linux. We see it in Linux." The request for Discovery implies, "We don't see our code recognizably in any version of Linux, so we want to look elsewhere."

Trouble is, elsewhere isn't the topic of the lawsuit.

[ Reply to This | # ]

SCO's Memorandum on Discovery - as text
Authored by: Anonymous on Thursday, June 03 2004 @ 12:31 PM EDT
Could not TSCOG just as well argue that IBM is in violation of the GPL by taking
programs released under that open-software license and then re-releasing them
under a proprietary license (requiring non-disclosure of source code)?

Just a thought.

[ Reply to This | # ]

SCO's Memorandum on Discovery - as text
Authored by: rand on Thursday, June 03 2004 @ 12:49 PM EDT
"Provide a more detailed identification of IBM's improper use of SCO's
copyrighted information improperly contributed to Linux by others."

That one makes my head spin.

So now SCOGrop is claiming that IBM, which has (had, according to them) a full
UNIX license, is improperly using UNIX code taken from Linux but put into Linux
by someone else? This is a new copyright claim -- sholdn't it require an
amended-amended-amended complaint?

And I thought copyright was not on the table any more (at least according to
SCOGroup).



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

[ Reply to This | # ]

SCO's Memorandum on Discovery - as text
Authored by: rvergara on Thursday, June 03 2004 @ 12:50 PM EDT
I believe we have been reactive in this whole process. We should counter
attack.

I am sure that several proprietary products, including our friends in Redmond
have included Open Source coding in their product. As an example, there is a
strong suspicion that the TCP/IP stacker in windows was implemented using BSD
code (Since BSD is not GPL I have to admit I am not sure this would be allowed
by the BDS license). I am sure this is not the only case.

My proposal is that we should gather info on all suspicious usage of GPL code by
proprietary software providers (this site would be perfect to receive this
information) and initiate action against those companies.

It is time to take the offensive, we should not just be sitting ducks waiting
for the next hit.

Comments?

[ Reply to This | # ]

SCO's atomic theory
Authored by: Anonymous on Thursday, June 03 2004 @ 01:52 PM EDT
The intent of the AT&T/IBM agreement is clear - all SysV code, pure or modified, is to be kept confidential. SCO contends that this rule extends to non-SysV code because, for some unspecified reason, it can't be divided from SysV code:

SCO also alleges that AIX and Dynix, considered as whole programs, are derivative works of UNIX System V, and again -- under the Agreement -- cannot be split into parts and distributed. [emphasis mine]

On what basis does SCO claim that AIX is a "whole program" that can't be divided? The agreement certainly doesn't say anything about this.

What criteria are they using to claim that code X can't be divided from code Y? If they're in the same function? If they're in the same source file? If they get statically linked? If they get dynamically linked? If they're sold in the same product? In the same suite of products?

SCO doesn't specify, and for good reason. Once they're clear on what criteria they're using, they will have to explain:
  • What part of the agreement, or what precedent, justifies their criteria.
  • Why they aren't consistent in their application thereof. For instance, if they claim that linking one module with another makes them both part of the same "whole program," then why are they not claiming that every application ever ported to AIX is a derivative work?

[ Reply to This | # ]

Sick and Tired
Authored by: GLJason on Thursday, June 03 2004 @ 03:07 PM EDT
SCOG's whole case is based on a reading of the contract where any code that touched AIX would be considered part of AIX and a derivative work of Unix SYSV, even if it didn't contain any Unix SYSV code. Since the contract contains the phrase 'derivative work', copyright law on derivative works should be used to interpret the contract. Copyright law clearly states that to be a 'derivative work', a work must contain protected elements of the preexisting work. That eradicates SCOG's claims right there. You don't even have to bring in the AT&T side letter or the $echo newsletter to show the intent of the parties. The language of the contract is plain and unambiguous and the judge could make a ruling on that.

SO WHY IN THE HELL DOESN'T IBM ASK THAT THE JUDGE RULE ON THIS ISSUE AS A MATTER OF LAW? There is no issue of fact that would need to be saved for a jury. SCOG's repeated claims are confusing. Couldn't IBM ask the judge to rule that in order to show breach of contract that SCOG would need to show how Unix SYSV code was missappropriated and that anything IBM wrote that didn't contain Unix SYSV code was IBM's property to do with as they see fit?

[ Reply to This | # ]

SCO's Memorandum on Discovery - as text
Authored by: Anonymous on Monday, June 07 2004 @ 03:48 PM EDT
Sorry kids. If it isn't in the public release, it doesn't count.

If I download a copy of "Alice in Wonderland" and then type on top of
it my own fantasy book by replacing paragraphs willy-nilly, so long as you can't
point to any copying of any sort in the published version of my book, there's no
problem. (If "Alice" were in copyright, which it is not.)

If IBM has license to copy your stuff for internal use, and then copies it and
rewrites it so that there's no comparison to the original and then releases
that, then there's no derivation. Not that I think they'd do anything so
careless.

Similarly, if I write a chapter and stick it in a version of "Alice"
it's still my chapter to do with as I please, providing I don't sign it over to
the publisher or something.

Of course, rebutting any of SCOX's theories is next to useless, since they
change all the time are are ambiguous to begin with. The only common ground, of
course, is that none have any grounding in reality.

Really, is SCOX selling the theory that there's a revision control comment
somewhere saying "inserting code form The SCO Group (r) so as to willfully
infringe copyright; fixing typo in error message"?

[ 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 )