|
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:
-
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.
-
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.
-
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.
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
Authored by: Anonymous on Thursday, June 03 2004 @ 10:52 AM EDT |
SCO lays most of their argument here on:
- AIX and Dynix being derivate
works taken in their entirety (no argument there)
- The contract requiring
that IBM treat derivatives as if they were the original software.
- 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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
|
|
|