|
SCO's Reply Memorandum Re Discovery - as text |
|
Monday, July 19 2004 @ 01:41 AM EDT
|
Here is SCO's Reply Memorandum re Discovery as text, thanks to Steve Martin. It's the document where SCO tells the judge, in effect, that they need to go through all of IBM's garbage going back to 1989 and reconstruct all shredded materials and unlock private diaries and get the key to the safe and unfettered access to headquarters' executive lounge closets and everybody's file cabinets and rip up the carpets and feel behind the toilet bowls because they just might find one unstudied word or casual phrase that they can hang IBM by. They don't know exactly what they are looking for, but they're sure something will turn up. One thing is for sure. If IBM filed for summary judgment not so much because they figured it'd work but rather to flush SCO out from hiding behind the bushes, it worked. SCO's hand is now face up on the table. It was never about Linux, about Linus not having a process to block out infringing code. That was all for headlines, for stock price, for Congress, and to please Microsoft, I expect. But the reality is, this case is about a contract dispute. Linux got dragged into it as hostage. SCO is holding Linux by the neck, pointing a gun at its head, and telling IBM, "Do what I tell you, or I'll shoot your little friend."
Not such a pretty picture, is it? And all the sophisticated lawyering is the legal team justifying such behavior. SCO must do this to protect their holy IP, after all. Why, it's required, nay, the American way, nay, noble. Then they go out for a drink afterward and have a sophisticated laugh. And they are all too sophisticated and cynical and clueless about tech to see that they are threatening the country's ability to compete in developing software. That's the trouble with cynics. They can't see past their own sophisticated noses and their own short-term gain. Or they don't care. SCO started out imagining that if they brought a lawsuit, they could go on a discovery fishing expedition, find the copyright infringement they believed they'd find and then.... Profit! However, Linux is clean as a whistle. They tried and failed to find any literal copying. IBM successfully blocked them from getting every version of AIX by pointing out quite correctly that SCO had System V and it had all versions of Linux, which are publicly available, so if there was copying, all they needed was to look. Flustered and frustrated in their plan, and in danger of losing everything, SCO now shifts gears and says this is actually just a contract dispute, and they really want all those versions of AIX to look for violations of contract claims, not copyright infringement. Discovery is liberal as long as it is relevant. They have written these 30 pages to make a case that the discovery is relevant to the contract claim. That's all this is. The name-calling is just for effect. Then they pretend they didn't tell the world for a couple of years that they'd already done a comparison of System V and Linux and found mountains of infringing code. That was then. This is now. Now, the story is that they've never accused IBM of copyright infringement. It's news to them that this is part of this lawsuit. It's only IBM that interjected that alien thought, with its 10th counterclaim. Being a new thought, SCO can't be expected to have done any discovery on *that* subject, now, can they? They need to start afresh now, and it'll take a long time, thousands of man years, to compare all the code to look into this copyright business IBM has suddenly interjected into this contract lawsuit. And to do that comparison, oh, by the way, Your Honor, we need every version of AIX and Dynix from the founding of the world. And time. More time. Lots of time. Every SCO filing seems to ask for that. According to their interpretation of the contract, there is no excape from System V's derivatives embrace. It's all restricted by the contract, so let's all forget copyright law. We're not talking about that, SCO tells us, straight-faced. Whatever gave you that idea? This is about contracts, which give us more control than copyright law. And by the terms of said contract, they own IBM's every breath forever, and if IBM didn't mean to give them that control over their breathing, they shouldn't have signed the contract to begin with. IBM views the contract differently, because it remembers the side letter and echo and all those after-contract refinements, but SCO, blinders firmly in place, sticks to the original contract, so that means they are entitled to discovery on such a vast scale. Why, they need to X-ray IBM's very colon. Something could have been swallowed, after all, to hide it from SCO's IP Police Squad hunting for contract breakers. Except for one thing. This is exactly what they have asked for from the very first day. And so far, Judge Wells has never been willing to go that far. There are limits to discovery. SCO asks for the moon. I gather they've decided to go for broke. They have nothing to lose so they present the same old request in more sophisticated language than we are used to seeing. But it's the same wolf, still in grandma's cap and gown. There is one additional factor. They swore to the court that they had complied with discovery. One thing IBM had asked in discovery was for SCO to tell them all infringing code in Linux, no matter who put it there. Since they didn't come up with anything, and signed off, now IBM is asking the court for a declaratory judgment of non-infringement. Additionally, SCO noticed that IBM mentioned moving for summary judgment on the contract claims later. So the SCO cavalry was called in and this is their bugle blast as they swarm over the hill. "We are entitled to try for more discovery", is their call. "Don't cut us off at the pass! We'll be ruined." We'll see if the judge buys it. One thing is for sure. They didn't see IBM's strategy coming at them until it was almost too late. Maybe too late, period. And they are charging full steam ahead and giving it all they've got. I have never seen anything like it. Nauseating as it is, I can't help but acknowledge the cleverness. I don't admire cleverness without morality, personally, but I know cleverness when I see it. And I see it, starting with calling this a "Reply Memorandum in further support of its
Memorandum dated May 28, 2004, filed pursuant to the Court's Order of March 3, 2004
(the 'March Order'), identifying relevant discovery that SCO has requested, but has not
received, from IBM," and pretending that a summary judgment on the contract claims is before the court, so they should be given all the discovery they want to be able to defeat it. They also attack IBM, as if it were IBM who is responsible for the Court's earlier denials of SCO's requests. "IBM shouldn't be allowed to dictate to this court," SCO blusters. All IBM did was present its view, and the court accepted it. How is that IBM dictating? It isn't, and SCO knows it. But this is psychology. They figure it will work better to put it like that than to say, "Judge Wells, you refused us before, and we want you to change your mind and give us all the versions of AIX and Dynix from the founding of the world, even though you said you wouldn't." Red Hat accused SCO's lawyers of saying whatever they think will work, from place to place, courtroom to courtroom. Here, they are telling the judge and the world that we should all forget about that Linux copyright baloney. It's all about the contracts, so SCO's failure to show any copied or infringed code means nothing. Why, they say, they not only don't have to show any literal copying, now they don't even have to show any nonliteral copying. With their contract, they don't have to show copying period: "IBM argues that SCO needs only to compare UNIX System V source code with Linux
source code to make its case and, therefore, that the discovery SCO seeks is irrelevant. But
IBM's argument ignores the fact that SCO's principal claims are, as they have been since the
beginning of this litigation, for breach of IBM's contractual obligations under the IBM and
Sequent Software Licensing Agreements. Under these contracts, which prohibited IBM from
contributing AIX or Dynix/ptx source code into Linux (because such contributions consisted of
derivative works and/or "methods or concepts" of protected works), SCO is not required to show
literal or non-literal copying of UNIX System V source code into Linux. . . . SCO can prevail on its contract claims
without proving IBM's liability for copyright infringement." To which the only conceivable response must be: Why then did you waste our time? Speaking of situational slickness, remember at the AutoZone hearing on July 12th, SCO's attorney telling the judge that IBM was unlikely to prevail on its summary judgment re the 10th counterclaim because they hadn't argued that there were no issues of material fact? That was there. This is here: "In a similar vein, IBM
has already moved for summary judgment on its own recently-filed Tenth Counterclaim, arguing
that SCO cannot demonstrate any issues of material fact regarding copyright infringement by
IBM in any of its (vast and continuously expanding, but only partially enumerated) "Linux
activities."
Another example for Red Hat's collection that SCO's legal team will say one thing in one court and the opposite in another. That only works for a short while, before everybody starts to catch on.
*****************************************
Brent O. Hatch (5715)
HATCH, JAMES & DODGE
[address, phone]
Stephen N. Zack (admitted pro hac vice)
Mark J. Heise (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
[address, phone, fax]
Robert Silver, Esq. (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
[address, phone, fax]
Frederick S. Frei (admitted pro hac vice)
Aldo Noto (admitted pro hac vice)
John K. Harrop (admitted pro hac vice)
ANDREWS KURTH LLP
[address, phone, fax]
Attorneys for Plaintiff The SCO Group, Inc.
IN THE UNITED STATES DISTRICT COURT
FOR THE DISTRICT OF UTAH
THE SCO GROUP, INC.
Plaintiff/Counterclaim Defendant
vs.
INTERNATIONAL BUSINESS
MACHINES CORPORATION,
Defendant/Counterclaim Plaintiff
|
REPLY MEMORANDUM
REGARDING DISCOVERY
Case No. 2:03-CV-0294 DAK
Honorable Dale A. Kimball
Magistrate Judge Brooke C. Wells
|
The SCO Group, Inc. ("SCO") through its respective counsel of record respectfully
submits this Reply Memorandum Regarding Discovery.
Plaintiff the SCO Group, Inc. ("SCO") submits this Reply Memorandum in further support of its
Memorandum dated May 28, 2004, filed pursuant to the Court's Order of March 3, 2004
(the "March Order"), identifying relevant discovery that SCO has requested, but has not
received, from IBM.
PRELIMINARY STATEMENT
SCO here asks the Court to order IBM to produce the source code of the multiple
versions of the AIX and Dynix computer operating systems and related documents that SCO
has sought for over a year. These discovery requests remain at the heart of this litigation,
because they are directly relevant to, and reasonably calculated to lead to the discovery of
admissible evidence concerning, SCO's contract claims — which are based on IBM's copying of
AIX and Dynix/ptx code into Linux — as well as IBM's recently-added counterclaim — which
seeks a broad declaratory judgment that none of IBM's Linux activities infringe any SCO
copyright.
IBM has incorrectly resisted producing earlier versions of AIX and Dynix/ptx on the
stated ground that SCO need only compare UNIX System V code to Linux code and, therefore,
these two sources of code are everything SCO needs to support its claims. But IBM's argument
overlooks the pivotal point that the heart of SCO's complaint — the contract claims — requires no
proof of any copying from UNIX System V to Linux. Rather, while IBM focuses on copyright
law, the license agreements at issue here expressly provided greater protections, ensuring that
any subsequent derivatives of UNIX System V derivatives and/or any "methods or concepts"
contained in UNIX System V or any such derivatives receive the same protection under the
license agreements as the original licensed System V product. Thus, the license agreements, on
their face, clearly provide SCO with far greater protection than the copyright law affords; indeed,
the agreements' language would have been surplusage if they had mirrored the copyright
protections already provided by operation of law.
IBM's contract argument provides further compelling reasons for SCO's entitlement to
design documents, white papers, and programming notes related to the prior versions of AIX and
Dynix/ptx. Because IBM's contract argument departs substantially from the language of the
operative license agreements, it will be necessary to rely on extrinsic evidence. Although SCO
believes that the unambiguous meaning of the contracts will preclude IBM's attempt to vary their
terms through such extrinsic evidence, to the extent such evidence is permitted, the parties'
performance under and understanding of the agreements will undoubtedly be relevant. Thus,
SCO is entitled to discover facts showing, for example, that IBM and Sequent understood the
restrictions of the contracts to have protected more than distribution of literal UNIX source code,
that they gave weight to the language of the contracts, and that they had incentives to breach the
contracts.
IBM wants to hold this evidence back, even though (as it elsewhere tells the Court) IBM
intends to move for summary judgment on those same contract claims. Apparently, IBM wants
the Court to accept its version of the case as a matter of law, yet shield from discovery the very
material that could show that at the times that mattered, the licensees themselves did not believe
what IBM would now ask the Court to conclude.
IBM also wants to hold back substantial evidence that could show that IBM (and
Sequent) breached the contracts in question. It is undisputable that the purpose of those contracts
was to allow IBM and Sequent to make and market products based on UNIX System V. The
contracts, granting the licensor more protection than copyright would have done without any
agreement, expressly treated the first IBM or Sequent version as subject to the same restrictions
that applied to System V itself — as "the original software product." Any subsequent version,
based on that contractually redefined "original software product" would be subject to the very
same restrictions — the restrictions that stand at the center of this case, and that would have
prevented the ultimate transfer to Linux of the IBM and Sequent programs at issue. IBM wants
to shut off access to all of the early development history of AIX and Dynix, even to the early
distributed releases of these programs. But this is the very material that would show just how the
contractual restrictions applied, something that cannot be shown if access to evidence only
begins comparatively late in the development process — as opposed to the point when the
contracts and the process began.
IBM's claim that this material is irrelevant — when this material could contain proof of
one instance after another of breach -- is indefensible. IBM is arrogating to itself the power to
tell the Court what evidence it should be allowed to see in order to test the validity of IBM's own
versions of the facts.
Wholly apart from SCO's contract claims, the discovery that SCO seeks is now relevant,
and indeed critical, to SCO's ability to defend against IBM's recently-added copyright claim.
The inordinately time-consuming and labor-intensive task of investigating the entirety of UNIX
System V and Linux for evidence of non-literal copying — an issue central to IBM's counterclaim —
is not practical for anyone to perform without leads. The basic discovery that SCO seeks but
has not received — such as the identities and precise contributions of AIX and Dynix
programmers which this Court has already ordered IBM to produce — would permit SCO
sensibly to identify the key programmers for deposition. Then, based on such deposition
testimony concerning the programmers' access to UNIX source code and the similarity between
that code and derivative code in AIX or Dynix, SCO could streamline its investigation by
prioritizing and targeting specific areas of code for analysis. By depriving SCO of basic
information concerning the contributions of its programmers, IBM seeks to force SCO to
undertake this laborious investigation in the most inefficient way possible.
In this and other regards (further detailed below), IBM misapprehends the essence of the
discovery process. Discovery is designed to make the investigative process efficient and
conducive to truth-finding. IBM has no more right to undermine these goals by blocking
discovery than it does to tell the Court what evidence the Court and the jury may see to test the
validity of IBM's own claims. Moreover, the question with respect to SCO's requested
copyright discovery is not whether SCO possesses some "minimum" amount of evidence that
might permit it to prove or defend the claims at issue. Rather, SCO is entitled to the production
of all admissible evidence and materials reasonably calculated to lead to the discovery of
admissible evidence, unless the burden to IBM outweighs this broad right in a legally and
factually significant manner.
In light of the centrality of this evidence to the claims and counterclaims in this case,
IBM is hard-pressed to establish any substantial burden that could justify its failure to produce
such material. Most of the materials SCO has requested are stored electronically in a centralized,
readily accessed system, and, for those that are not, IBM has afforded SCO no opportunity to
meet and confer in order to address the issue of producing hard copies. With respect to
Dynix/ptx, IBM makes no burden argument of any kind; with respect to AIX, after telling the
Court that it would take "many, many months" to meet the request, IBM now says it would take
only "weeks". Almost every aspect of discovery in this case has taken "weeks" -- over fifty
weeks have passed since SCO requested the materials, for example, and over twelve weeks have
passed since the Court ordered IBM to produce certain of the documents.
IBM further asserts that all of the paper documents SCO seeks (such as programmer's
notes, design documents and white papers) are too burdensome to produce. IBM makes these
statements even though (i) at least a great number of the documents created by programmers are
electronically stored, and IBM took the position that SCO would not receive even electronically
stored documents, making clear that IBM did not intend to produce any of the discovery to SCO;
(ii) when faced with the same issue, SCO agreed to produce documents to IBM in an electronic
format; and (iii) by its own admissions, IBM can produce the requested materials in a compact,
electronic format. These facts belie any suggestion that IBM is concerned about the burden
involved in searching for hard copies, and demonstrate that IBM refuses to produce the
discovery at issue in any format.
IBM has repeatedly (and erroneously) argued to this Court and to Judge Kimball that
SCO only wants to delay and prolong this litigation in order to further an alleged scheme to
create "fear, uncertainty and doubt." IBM Resp. at 3-4. IBM created this cloud over Linux
when it copied AIX and Dynix/ptx code into that program in derogation of its express
contractual obligations. And when IBM, to increase its profits and advance its strategic
objectives, encouraged numerous entities to migrate to Linux, it imposed the risk it had created
for itself on them as well. Here, IBM again tries to shift responsibility, this time claiming that
when SCO seeks basic discovery and IBM stonewalls for a year, the resulting delay is somehow
part of SCO's "scheme" to extend the litigation process.
For a year, SCO has sought, and continues to seek, critical discovery to which it is
entitled under the Federal Rules in order to present its strongest case to a jury. If IBM has
nothing to hide (as it claims), and actually wishes to expedite this litigation (as it also claims), it
should produce the materials SCO has requested and attempt to establish its defense (as well as
its new copyright counterclaim) on their merits.
ARGUMENT
I. SCO'S DISCOVERY REQUESTS ARE RELEVANT AND RESONABALY
CALCULATED TO LEAD TO ADMISSIBLE EVIDENCE TO SUPPORT ITS
CONTRACT CLAIMS AND TO DEFEND AGAINST IBM'S COPYRIGHT
COUNTERCLAIM.
SCO has properly requested all versions of AIX and Dynix/ptx; the names of all principal
contributors to AIX and Dynix; and revision information including access to CVMS, all
programmer notes, design documents, and white papers. All that IBM has produced are actual
commercial releases of AIX and Dynix since 1999 -- releases that IBM characterizes as
"distributed". Thus, SCO has not even been given commercially distributed versions prior to
1999. Nor has IBM produced any of the other requested materials, even though most of that
material is stored electronically.
Under Federal Rule of Civil Procedure 26, SCO is entitled to this discovery — which is
not only directly relevant, but potentially dispositive of central claims in the case — unless IBM
can show that producing the evidence would constitute such an undue burden that even plainly
relevant material should be withheld. Fed. R. Civ. P.26(b)(1). IBM does not and cannot make
any such showing.
As an initial matter, IBM incorrectly claims in its latest discovery memorandum that it
has produced all "distributed" versions of AIX and Dynix since 1999. IBM Resp. at 6, 10-11.
But IBM has still indisputably failed to provide at least one distributed version of AIX — version
5.0, see Initial Memo. at 6, n.7; Declaration of Chris Sontag dated July 12, 2004 ("Sontag
Discovery Decl.") ¶ 13 — and IBM offers no explanation for this deficiency. Moreover, SCO's
request for all iterations and versions of AIX and Dynix was not limited to "distributed"
products. IBM's claim that it has complied with SCO's request because AIX consists only of
distributed versions is flatly contradicted by IBM's own discovery requests in this case, which
expressly acknowledge that AIX is not limited to distributed versions, but that AIX is "the
UNIX-branded operating system distributed and/or developed by IBM, including all prior
versions, releases, and maintenance modifications." IBM's First Request for the Production of
Documents at 16, ¶ 1 (emphasis added).
A. The Information SCO Seeks Is Discoverable to
Support SCO's Contract Claims
IBM argues that SCO needs only to compare UNIX System V source code with Linux
source code to make its case and, therefore, that the discovery SCO seeks is irrelevant. But
IBM's argument ignores the fact that SCO's principal claims are, as they have been since the
beginning of this litigation, for breach of IBM's contractual obligations under the IBM and
Sequent Software Licensing Agreements. Under these contracts, which prohibited IBM from
contributing AIX or Dynix/ptx source code into Linux (because such contributions consisted of
derivative works and/or "methods or concepts" of protected works), SCO is not required to show
literal or non-literal copying of UNIX System V source code into Linux.(1).
Contracts, of course, may be used to secure greater legal protection than that afforded by
copyright law alone. See, e.g. Bowers v. Baystate Technologies, Inc, 320 F.3d 1317, 1327
(Fed. Cir. 2003) (affirming jury verdict of breach of contract where "[t]he shrink-wrap license
agreement prohibited, inter alia, all reverse engineering of [plaintiff's] software, protection
encompassing but more extensive than copyright protection, which prohibits only certain
copying"); Dispatch Automation, Inc. v. Richards, 280 F.3d 1116, 1120-21 (7th Cir. 2002)
("contractual alternatives to copyright may give an owner of computer software more protection
than copyright would"); Nat'l Car Rental Sys., Inc. v. Computer Assocs. Int'l, Inc., 991 F.2d
426, 431-35 (8th Cir. 1993) (finding that party alleging infringement was in actuality asserting
that the infringer violated a licensing agreement by processing data for third parties, which was
not an infringement of an exclusive right to the copyright holder and that "Absent the parties'
agreement, this restriction would not exist").
The IBM and Sequent License Agreements secured such additional protections for SCO;
if they had not, the express protective language of the agreements would have no meaning,
constituting inexplicable surplusage. Consequently, SCO can prevail on its contract claims
without proving IBM's liability for copyright infringement.
IBM therefore misses the point when it claims that prior versions of AIX and Dynix are
irrelevant on the grounds that "[a] derivative work based on an original work may be so
transformed that it no longer is a derivative work and no longer infringes any copyright of the
original work." IBM Response at 14 & n.5. IBM's argument assumes that only copyright law
applies. But SCO's Linux-related claims in this case are contract claims, and the contracts at
issue were expressly worded to give SCO the protection that IBM claims copyright law would
not.
This is also precisely the reason why earlier versions of AIX and Dynix are so critical to
SCO's contract claim proof. Specifically, under Paragraph 2.01 of the IBM and Sequent license
agreements, "modifications and derivative works based on" UNIX System V are treated as if
they were part of the original licensed "SOFTWARE PRODUCT," so that any transfer by IBM
of such a modification or derivative work — even if it was included in an early version of AIX
and Dynix — would violate the License Agreements. Similarly, under the Sequent License
Agreement, IBM is specifically prohibited from disclosing "any or all of such SOFTWARE PRODUCTS
[i.e., UNIX System V and, pursuant to Paragraph 2.01, AIX and Dynix] (including
methods or concepts utilized therein) to anyone," so that any disclosure by IBM of any portion,
method, or concept of Dynix — even if it was included in an early version of the program — would
violate the Sequent agreement.
SCO's need for this discovery is especially critical in light of IBM's stated intention to
seek summary judgment on SCO's contract claims. See IBM SJ Mem. at 5 n.4. If and when
IBM brings such a motion, it will argue (as it must) that SCO has not produced sufficient
evidence to raise any issues of material fact regarding its contract claims. In a similar vein, IBM
has already moved for summary judgment on its own recently-filed Tenth Counterclaim, arguing
that SCO cannot demonstrate any issues of material fact regarding copyright infringement by
IBM in any of its (vast and continuously expanding, but only partially enumerated) "Linux
activities."
IBM's litigation two-step has thus become clear. First, IBM systematically withholds
relevant discovery materials in the face of SCO's requests and this Court's Orders. Then it
moves for summary judgment, arguing that SCO cannot produce evidence sufficient to raise a
fact issue on its claims. IBM's method of defense litigation runs contrary to both the letter and
spirit of the Federal Rules of Civil Procedure and this Court should order IBM to comply with its
discovery obligations.
1. The Requested Materials May Contain IBM
Admissions of Contract Liability.
In its Initial Memorandum, SCO requested not only intermediate versions and iterations
of AIX and Dynix/ptx, but also revision history information about these programs, as well as
programmers' notes, design documents, and white papers. These materials will provide SCO
with extensive information about IBM's programmers and their involvement with AIX and
Dynix/ptx. Declaration of Chris Sontag submitted July 8, 2004 ("Sontag SJ Decl.") ¶¶ 51-53.
The materials SCO seeks may also contain evidence that is not only probative, but dispositive of
IBM's liability for breach of contract, such as:
-- admissions concerning the meaning of, and limitations imposed by, the license agreements;
-- admissions regarding IBM's liability for breaching those contracts; and
-- admissions that the development of AIX and Dynix/ptx depended on UNIX System V.
It is difficult to understand IBM's claim that such materials are not relevant to this case --
when they could easily be dispositive of this case. It is even harder to understand how IBM
could continue to try to withhold this material, when it has told the Court that it plans to move
for summary judgment on the contract issues, and when all of these materials could readily
contradict the very claims that IBM will be asking the Court to then accept as undisputed.
2. SCO's Requested Discovery is Directly Relevant to Whether IBM's
Disclosure of AIX and Dynix Violated the Software License
Agreements.
The License Agreements in question allowed IBM and Sequent to use System V source
code to prepare operating systems (AIX and Dynix/ptx, respectively) based on System V, subject
to several restrictions. Critically, Paragraph 2.01 of the License Agreements provides that any
modifications or derivative works based on System V code are to be treated as "part of" System
V (and thus subject to the restrictions applicable to System V) under the Agreements. Because
of this clause in the Agreements, IBM is no more free to disclose, export, or publish any
derivative version of AIX or Dynix/ptx than it is to disclose, export, or publish System V itself.
Accordingly, one way for SCO to prove that IBM breached the License Agreements is
for SCO to demonstrate that versions of AIX and/or Dynix/ptx are derivatives of System V
within the meaning of the Agreements, and that IBM disclosed, exported, or published those
derivatives. As the plain language of the License Agreements makes clear, a modification or
derivative of System V is subject to the same confidentiality restrictions as System V itself.
Thus, the restrictions in the Agreement apply to each successive iteration of the derivative
program and not to System V alone.
To illustrate, suppose that Dynix version 1 is a derivative of System V. Under Paragraph
2.01, every provision in the License Agreement that applies to System V also applies to Dynix
v.1 (including Paragraph 2.01 itself). Thus, if Dynix v.2 is a derivative of Dynix v.1, it too must
be treated as part of System V for the purposes of the Agreements. Assuming that each version
of Dynix is created as a derivative of the previous version, the most recent version of Dynix is
every bit as much a derivative of System V under the License Agreements as is Dynix v.1.
Accordingly, SCO's request for each iteration and version of AIX and Dynix is discoverable
under its breach of contract claims; if SCO can trace the evolution of AIX and Dynix clear back to
System V it will be able to prevail on those claims without making any additional showing.
But there is no way for SCO to make this showing without the early history of AIX and
Dynix — the very material that IBM is dead set against providing.
IBM, of course, disputes SCO's interpretation of the contracts and argues that, at some
(as yet undefined point), AIX and Dynix ceased being derivatives of System V. The analysis in
Dispatch Automation, 280 F.3d 1116, demonstrates that the requested materials are discoverable
even under IBM's theory of the License Agreements. In that case, Judge Posner explained the
inherent difficulty in determining the point at which a computer program ceases to be derived
from an old program, and instead becomes so transformed that it is a new work:
To decide ... whether a successive version of a computer software product is a
merely incremental improvement or a breakthrough would be like determining the
exact moment at which day becomes night. ... How for example to decide
whether to compare the latest version of a product with the immediately preceding
version or with the original version? Compared to the former, it might seem
incremental, while compared to the original version it might seem discontinuous,
a radical or fundamental change. The first approach would invite the proliferation
of meaningless intermediate steps designed to disguise novelty; but the second would
ignore the obvious fact that a process of unmistakable, indeed quite
gradual, development can have an end point radically different from its beginning,
as in the case of the oak and the acorn it grew from.
Id. at 1119-20.
By resisting SCO's discovery, IBM would arrogate to itself the authority to select
evidence with which to test the validity of its claim that at some point AIX and Dynix/ptx ceased
to be modifications or derivative works "based upon" SCO's UNIX System V and were no
longer subject to the restrictions of the License Agreements. In other words, IBM itself would
select that point, without ever allowing the Court, SCO, or the jury to see any evidence that IBM
did not want it to see — any evidence of the intermediate stages of development. IBM would also
decide how to deny SCO the discovery it needs to prove where the actual point should be
located.
If this approach to discovery were permissible, there would be no reason for licensors
ever to enter carefully worded license agreements, because they would be literally worthless.
Another factor makes IBM's approach even less appropriate; SCO's License Agreements are
worded precisely to avoid the complexity of this very evolutionary determination. That is,
SCO's contracts with IBM and Sequent make every modification and derivation part of the
original "SOFTWARE PRODUCT" and subject to all of the contract's prohibitions and
limitations. Following Judge Posner's analogy, accepting IBM's position would be attempting to
determine "the exact moment at which day becomes night" with all the blinds drawn. Id. That is
the exact type of determination the licensing agreements were drafted to avoid.
3. The Requested Discovery is Relevant to and Will Aid SCO in
Determining Whether IBM Disclosed Contractually-Protected System
V "Methods or Concepts."
Paragraph 7.06 of the Sequent License Agreement prohibits IBM from disclosing any
portion (let alone the entirety) of any "SOFTWARE PRODUCT" (i.e., original System V and
derivative (Dynix/ptx)), "including methods or concepts utilized therein." Therefore, SCO will
prevail on its breach of contract claims if it can demonstrate that IBM in fact disclosed protected
"methods or concepts." The most efficient and straightforward way for SCO to discover if IBM
made such disclosures is through access to Dynix/ptx programmers and their particular
contributions.
In its March Order, this Court directed IBM to produce, among other things, the identities
and precise contributions of Dynix programmers. See 3/3/04 Order at 5. SCO has now
attempted to obtain this information from IBM in several ways: by serving an interrogatory,
filing a motion to compel, and filing a renewed Motion to Compel (on July 6, 2004). Up to this
point, IBM has resisted these efforts and withheld this essential discovery. Accordingly SCO
requests that IBM again be ordered to produce materials that will reveal the identities and precise
contributions of Dynix programmers.
In the first instance, this information would allow SCO to take depositions of the
principal Dynix contributors. These depositions could result in admissions of IBM's reliance on
protected SCO material, clearly relevant to IBM's potential contract liability. Programmers and
engineers can be deposed regarding the following issues:
-- the identify of Linux contributors;
-- specifics about their own Linux contributions;
-- assistance given to Linux contributors; and
-- whether any protected "methods or concepts" were ever disclosed.
This type of testimony will also assist SCO in identifying other former IBM employees
contributing to Linux, who may be valuable witnesses.(2)
Accordingly, SCO's requested discovery is clearly relevant to, and reasonably calculated
to lead to the discovery of admissible evidence concerning, SCO's contract claims in this case.
In fact, the requested material may well contain much that is not only probative — but dispositive
— of SCO's contract claims. IBM's argument that such material is not relevant reduces, again, to
a demand that IBM be allowed to tell the Court what evidence should be allowed to be used to
test the validity of IBM's own claims.
B. SCO's Requested Information Is Discoverable to
Defend Against IBM's Recently-Added Copyright Claims.
SCO's case against IBM consists primarily of breach of contract claims. SCO's only
copyright claim arises out of IBM's breach of the IBM and Sequent licensing agreements.(3)
Nowhere in SCO's complaint is there a Linux-based copyright claim.
On March 29, 2004, however, IBM injected Linux copyright issues into this case through
its Tenth Counterclaim, which seeks a broad declaration that none of its Linux activities infringe
any of SCO's copyrights. Less than two months later, IBM filed its motion for summary judgment
wherein it asserts that SCO must be limited to facts contained in SCO's discovery
responses from January 12 and April 19 of this year. IBM SJ Mem. at 7, 23, 28, 30. Thus,
having recently introduced new Linux-related copyright claims into this case, IBM is seeking to
prevent SCO from conducting any discovery on IBM's new Tenth Counterclaim.
While IBM may prefer such an arrangement, its interests do not dictate the rules of
discovery. SCO's discovery requests at issue in this memorandum, though initially made to
support its contract claims, are now clearly relevant and necessary to SCO's defense against
IBM's copyright claim.
The principal way in which IBM could defeat IBM's declaratory judgment counterclaim
is by showing that IBM has copied literal code — or elements of non-literal expression — from
SCO's copyrighted material. In refusing to comply with SCO's discovery requests, IBM tries to
limit SCO to the least efficient and most time-consuming of all possible manners of investigating
IBM's copyright counterclaim. IBM's position is indefensible as a matter of law, would be
unjustifiable even if IBM had not injected the copyright claim into the case only recently and
then even more recently moved for summary judgment on that claim, and is particularly
inexplicable in light of IBM's constant complaints about delay. Indeed, the discovery SCO
requested over a year ago would allow it to streamline, narrow, and prioritize its discovery
analysis, and thereby speed up the litigation process.
While there are a number of ways to show that IBM copied SCO's protected material,
perhaps the most obvious is for SCO to demonstrate that protected material, whether UNIX
System V code — or non-literal expression — is present in Linux. IBM would then be liable as an
end-user of Linux and possibly as a contributor to Linux as well. To do this, SCO must
undertake a complex and laborious comparison of Linux and UNIX System V. Sontag SJ Decl.
¶¶ 9-14. This is a monumental task. Both the UNIX and Linux operating systems are large and
complex computer programs with many millions of lines of code. In addition, SCO needs to do
more than merely examine the two programs for literal, line-for-line character similarity, a
daunting process in its own right. That literal comparison must be supplemented by an even
more time-consuming second order review. Even IBM does not (because it cannot) contest that
copyright law protects more than literal line-for-line copying — that it also protects copying of
structures and sequences, even absent any copying of literal code. Review for such structure and
sequence copying is even more time-consuming and laborious, if forced to be done without the
aid of discovery, which is what IBM is trying to accomplish here.
Initially, each of the millions of lines of Linux code must be compared with each of the
millions of lines of UNIX System V code, line-by-line, or in groups of lines according to the
structure, sequence, or function of the code. SCO can use an automated tool to perform the
initial literal comparison, but automated tools do not work well in the absence of identical
copying. Sontag SJ Decl. ¶¶ 10-13. Those tools identify only exact or nearly-exact literal
matches, thereby excluding evidence of non-literal copying.
These inherent limitations of automated code comparison tools mean that most code
comparison between Linux and UNIX will require a manual review by a skilled programmer or
expert, an extremely time-consuming process. The time required to complete the code
comparison without some shortcut — such as a roadmap or list of "hotspots" in Linux — is
staggering, on the order of thousands of man-years.(4) SCO needs to use discovery to streamline,
narrow, and prioritize this manual review in order to avoid what could otherwise be an
unrealistically difficult and time-consuming effort.
Many shortcuts to completion of the code comparison are theoretically available,
including: (1) reviewing directory and file structures; (2) searching for similar file names, and (3)
reviewing the AIX and Dynix development history, including reviewing interim and
published versions of AIX and Dynix/ptx, as well as the associated documents, such as the
version control systems (e.g., IBM's CMVC system), bug tracking logs, white papers, design
documents, and programming notes. Sontag SJ Decl. && 26-35, 51-53.
SCO has already investigated the viability of the first two shortcuts and, even though
those tools are helpful, the breadth of the analysis remains daunting.(5) The third shortcut,
however, can greatly streamline SCO's further discovery. Specifically, by reviewing the
development of AIX and Dynix/ptx, and their associated documents, SCO would be able to: (1)
track original UNIX System V code into Linux and thereby focus its efforts by matching up
original UNIX code with its Linux counterpart and (2) identify IBM and Sequent programmers
and engineers who can provide deposition testimony that would also allow SCO to focus and
prioritize its efforts to locate Linux code substantially similar to UNIX System V code. Sontag
SJ Decl. ¶¶ 15-25.
As noted in the accompanying Declaration of Christopher Sontag, IBM's version control
system (VCS) — the Configuration Management/Version Control (CMVC) system — can help
SCO identify the programmers and engineers familiar with relevant UNIX-based code that IBM
or third parties contributed to make Linux enterprise-hardened and multiprocessor-capable.
Sontag Discovery Decl. ¶¶ 4-5, 7. SCO can then take their depositions and use that information
to focus its analysis of UNIX System V and Linux.
The VCS will also allow SCO to examine the development of AIX and Dynix/ptx. By
examining the source code in successive versions of AIX and Dynix, SCO can trace its UNIX
System V code through to current versions of AIX and Dynix and determine where in Linux
SCO's UNIX System V code is copied.(6) Then, SCO will know exactly which portions of UNIX
System V and Linux to group together for comparison. This will significantly streamline SCO's
efforts to find code in Linux that is substantially similar to UNIX System V code.(7)
IBM contends that because SCO has UNIX System V code and access to Linux code,
SCO does not require interim versions or revision history information and, therefore, needs
nothing further to make its copyright infringement case. IBM Resp. at 13-14.(8) But IBM
fundamentally misconstrues its discovery obligations. SCO is entitled to the production of all
materials relevant or reasonably calculated to lead to the discovery of admissible evidence,
unless IBM can show some undue burden. Fed. R. Civ. P. 26(b)(1).
Indeed, IBM cites no authority requiring that SCO be limited to only one method in
undertaking to prove that UNIX System V and Linux are substantially similar. That limitation
would be the outcome of the decision IBM seeks. SCO would be precluded from knowing the
precise contributions made to AIX and Dynix and would therefore be precluded from deposing
the significant authors of AIX and Dynix. It would thus be unable to streamline, narrow, and
prioritize its searches for code and non-literal elements in Linux that originated in UNIX.
Without this discovery, the investigation is much more time consuming, costly, and needlessly
inefficient.
The rules of discovery are designed to increase efficiency and to enhance the likelihood
that the truth will be brought out. The rules are not, by contrast, designed to give one party the
prerogative to make the investigative process as inefficient as conceivably possible and to
enhance the likelihood that if the truth ever comes out, it will be long after the claims against it
have been adjudicated. IBM has no more right to use the discovery rules to this end than IBM
does to tell the Court what evidence the Court and the jury may see to test IBM's own claims.
II. IBM FACES NO SIGNIFICANT OR UNDUE BURDEN IN PRODUCING
THE CRUCIAL DISCOVERY SCO HAS SOUGHT FOR OVER A YEAR.
The party opposing discovery carries the burden of showing that "the burden or expense
of the proposed discovery outweighs its likely benefit" under Fed. R. Civ. P. 26(b)(iii). See, e.g.,
Simpson v. Univ. of Colo., 220 F.R.D. 354, 359 (D. Colo. 2004) (holding that "when the
discovery sought appears relevant," the party resisting disclosure on the ground of
burdensomeness must demonstrate that its purported burden "would outweigh the ordinary
presumption in favor of broad disclosure") (internal quotation marks and citations omitted)).(9)
The party opposing discovery must demonstrate some "plainly adequate" reason not to produce
relevant material. 8 C. Wright et al., Federal Practice and Procedure § 2035 (2003). With
respect to electronically available information, "whether production of documents is unduly
burdensome or expensive turns primarily on whether it is kept in an accessible or inaccessible
format." Zubulake v. UBS Warburg LLC, 217 F.R.D. 309, 318 (S.D.N.Y. 2003).
IBM fails to show that the requested discovery is inaccessible, or that its burden in
producing the discovery would be significant or would outweigh the crucial information (as
outlined above) that SCO seeks through the discovery.
IBM Claims No Burden as to Dynix/ptx. While IBM contends that producing the
requested information about AIX that is electronically stored would take "many weeks," IBM
makes no claim that there would be any similar burden involved in doing so for Dynix. With
respect to AIX, IBM's principal argument is that the CMVC on which AIX source code is stored
does not permit IBM easily to copy that code for production to SCO -- thus the requirement of
"weeks" of work. IBM Resp. at 18-19. At the same time, IBM makes no argument that the
version control system on which Dynix source code is stored, Revision Control System
(RCS), precludes IBM from easily copying that code for production to SCO. IBM's supporting
affidavit, required to support a claim of burden, see, e.g.,, Super Film of Am., Inc. v. UCB Films,
Inc., 219 F.R.D.649, 657 (D. Kan. 2004), makes no mention of RCS and Dynix. In the absence
of any argument on the issue, IBM necessarily fails to meet its burden with respect to Dynix,
including all of the electronically stored programmer notes and design documents and other
requested documents, and the identities and precise contributions of programmer contributors to
Dynix (which are also the subject of a renewed motion to compel before this Court).
IBM's Claim Cannot Avoid Producing AIX Versions and Related Electronically Stored
Documents By Contending That It Would Take "Weeks" to Do So. IBM previously told this
Court that it would take "many, many months" for IBM to produce the information, 2/6/04 Tr. at
37:10-14, which IBM now claims would take "many weeks" for IBM to produce (but
presumably not a full month). Even assuming IBM is now correct, this burden of "weeks" is not
a remotely adequate basis under the law for allowing IBM to withhold the requested materials.
Almost every aspect of discovery in this case has taken "weeks" -- over fifty weeks have passed
since SCO requested the materials, over twelve weeks have passed since the Court ordered IBM
to produce certain of the documents, and the deadline for fact discovery is eight months away.
On these bases alone, under the circumstances, IBM does not face a significant burden. The
materials are a likely source of probative -- and dispositive -- evidence with respect to SCO's
contract claims; the material in fact stands at the center of the case. The material also is essential
to streamlining an otherwise unnecessarily time-consuming investigation into non-literal
copyright violations, on claims IBM has recently introduced into the case. The proposal by IBM
that it should be able to withhold such material from the Magistrate Judge, the Court, and the
jury because producing it would inconvenience IBM by a matter of "weeks" is simply not a
serious argument.
IBM's Claim Regarding the "Number" of Documents Is Inapposite. IBM claims that the
information sought by SCO "amounts to millions of pages of documents," created by
programmers and "40 million additional pages of paper" for additional source code. IBM Resp.
at 3. IBM makes these statements notwithstanding that (i) at least a great number of the
documents created by programmers are electronically stored, and IBM took the position that
SCO would not receive even electronically stored documents, making it clear that IBM did not
intend to produce any of the discovery to SCO; (ii) when faced with the same issue, SCO agreed
to produce documents to IBM in an electronic format; and (iii) by its own admissions, IBM can
produce the requested materials in a compact, electronic format. Thomas Decl. ¶ 11. These facts
belie any suggestion that IBM is concerned about the burden involved in searching for hard
copies, and demonstrate that IBM refuses to produce the discovery at issue in any format.
The foregoing points -- without more -- are independently sufficient to preclude IBM's
claims of "burden". It makes no claim with respect to Dynix. Its claims on AIX are trivial,
measured against the importance of the evidence, the other discovery tasks in the case, and
simply against the kinds of efforts IBM has forced SCO to pursue just to try to obtain
rudimentary discovery requested at the very outset of the case (burdens that have required SCO
to renew motions to compel and spend much more than "weeks" of effort). But as shown below
there are even further problems with IBM's claims.
IBM's Claim of "Weeks" to Produce Certain Discovery is Inaccurate. To the extent the
period of "many weeks" is even significant, the question as to AIX is whether it would actually
take IBM, one of the world's largest computer companies, that much time to produce earlier
versions of the AIX source code. One reason to doubt IBM's representation is that, as noted
above, IBM originally told the Court that it would take "many, many months" for IBM to
produce the information. 2/6/04 Tr. at 37:10-14. Indeed, IBM's prior production in this case
illustrates how long it would take IBM to copy AIX from data tapes onto DVDs or CDs: when
IBM produced versions of AIX in unreadable format on March 4, 2004, SCO sought and
received replacement CDs three weeks later.(10)
IBM's own pre-litigation statements further belie its current assertion that CMVC faces
significant limitations that would make the production of AIX source code difficult:
-
IBM promotes CMVC to its customers based on CMVC's flexibility and
sophistication, and IBM touts the use of automated scripts to incorporate fixes and
changes daily. IBM-Siebel Marketing at 23 (Sontag Decl. Exh. 5).
-
IBM states that "CMVC is broad in its application, thorough in its implementation,
and very flexible." IBM's Redbook, Did You Say CMVC?, Sept. 1994, at 65 (Sontag
Decl. Exh. 2).
-
According to IBM, "The most important thing to understand about CMVC is that you
do not need to understand all of it, before you begin using some of it. ... CMVC
provides many mechanisms to help you accomplish your SCM [software
configuration management] goals, but it does not dictate exactly how you should use
them, nor does it require that you use them all if you only use some of them." Id.
-
IBM also claims that "CMVC ensures that an audit trail is maintained for every file
by identifying for any file change: when the change occurred, who was responsible,
and why the file was modified." Id. at 9.
-
One IBM employee explained that the "VC" (Version Control) function of CMVC
"eliminates confusion when looking for a particular source code file belonging to a
particular product," which describes what SCO seeks to do here. Email from Adrian
Mitu of IBM Canada, Aug. 19, 1993 (located at ) (Sontag Decl. Exh.3).
-
The same employee indicates that CMVC data may be accessed remotely implying
that IBM could simply grant SCO remote access to CMVC data to respond to SCO's
discovery requests. Id.
-
IBM also acknowledges the possibility of granting users remote access to CMVC
data, as long as the user has CMVC software. IBM's Redbook at 209-10.
Other, confidential IBM documentation further explains why it would not be burdensome for
IBM to access source code and documentation from CMVC. See Sontag Discovery Decl. ¶¶ 5-7,
11-12.(11)
If the foregoing leaves any room for doubt, SCO demonstrates in the accompanying
declaration of Chris Sontag that IBM grossly exaggerates the burden it will have to undertake to
provide CMVC material. IBM can easily provide its CMVC system, including AIX source code
and associated documentation, Thomas Decl. ¶ 7, in electronic format -- IBM admits that the
total file size is manageable, on the order of 40 gigabytes, id. ¶ 10. This amount of materials
could easily fit onto a laptop computer's hard drive, a portable hard drive, or a few optical disks.
CMVC is arranged using IBM's SCCS hierarchy, see IBM's Redbook at 40, which permits IBM
easily to design and run searches (accomplished by short computer programs called "scripts") to
identify AIX source code. See Sontag Discovery Decl. ¶¶ 18-26. In the alternative, IBM can use
standard archival tools to determine the locations of the one or more SCCS directory hierarchies
related to AIX, and make copies. See Sontag Discovery Decl. ¶ 27. Contrary to the assertion in
Mr. Thomas's declaration, Thomas Decl. ¶ 9, IBM engineers need not conduct a manual search
for the components that are part of AIX, Sontag Discovery Decl. ¶ 29.
IBM also takes pains to describe each step it would take to manually produce the
responsive materials from CMVC (IBM Resp. at 9-10), but such steps are unnecessary to
accomplish the end result electronically. See Sontag Discovery Decl. ¶¶ 18-28. IBM further
claims that to copy AIX information from data tapes onto DVDs or CDs would take "many
additional weeks", after the "many weeks" already taken to collect the information. IBM Resp.
at 10; Thomas Decl. ¶ 11. In fact, the data extraction and transfer process should not take more than
two or three days, if IBM follows standard industry practices of maintaining and
downloading its CMVC data. See Sontag Discovery Decl. ¶ 34.
IBM's Claim that SCO Merely Seeks "Delay" Is Baseless. IBM finally contends that
SCO's requests are designed to "lay the groundwork for further delay." (IBM Resp. at 19.) The
claim is remarkable to say the least, give that SCO here seeks the most basic types of discovery,
which it has sought for over a year and has recently filed a Renewed Motion to Compel to ask
the Court to order (again) IBM to produce.
The assertion also ignores IBM's (plain) responsibility for the delay in the discovery at issue here.
IBM could have participated in a meet and confer process to eliminate or
dramatically reduce the perceived burden it believed it faced. Further, IBM declined to meet
SCO at least partway on SCO's requests for programmers' notes, design documents and white
papers, making a blanket claim that all such documents were too burdensome to produce. IBM's
conduct has been inconsistent with their stated intent to avoid "delay."
As set forth in SCO's opposition to IBM's motion for summary judgment on its Tenth
Counterclaim, a pattern to IBM's conduct has emerged. IBM repeatedly tells the Court (and the
world) that SCO has no case and that SCO seeks only to delay. But a defendant who truly
believes its adversary has no case, who truly wishes to avoid delay, does not:
-- take every possible step — even in the face of court orders — to withhold access to
the information needed to test its position, thereby ensuring great delay; and
-- then ask the Court to cut off all work so that its position can never be tested,
thereby ensuring that even a plaintiff with a very strong case could never prosecute it.
Discovery battles are common and, to some extent, unavoidable in complex civil litigation. This
pattern is not.
SCO submits that for the foregoing reasons, and as also set forth SCO's Renewed Motion
to Compel dated July 7, 2004, IBM faces no significant or undue burden in producing the
discovery SCO requests.
CONCLUSION
SCO respectfully requests, for the reasons set forth above, that the Court order IBM to
produce the materials set forth above and in SCO's opening memorandum.
Dated this 12th day of July, 2004.
_______[signature]_______
HATCH, JAMES & DODGE, P.C.
Brent O. Hatch
BOIES, SCHILLER & FLEXNER LLP
Robert Silver
Stephen N. Zack
Mark J. Heise
Counsel for Plaintiff/Counterclaim defendant
ANDREWS KURTH LLP
Frederick S. Frei
Aldo Noto
John K. Harrop
Of Counsel
-
For the reasons explained in Part 1.B below, IBM's argument would be wrong even if this case were based entirely
on a Linux-related copyright claim like the one IBM added in its Tenth Counterclaim (but SCO has never asserted).
-
IBM claims that programmer information is contained in the AIX and Dynix programs themselves and that,
consequently, IBM need not provide such information independent of AIX code. SCO shows why IBM's claim is
wrong in its renewed Motion to Compel (July 6, 2004) regarding its Interrogatory No. 5.
-
SCO's copyright claims are based on claims that IBM transferred UNIX code to India, a country where the
licensing agreement prohibited its use, and that IBM continued to use and distribute UNIX after SCO had
terminated the licensing agreement.
-
To execute the code comparison, SCO and its experts must compare page after page of code. The 4 million lines
of Linux kernel code, which is the core portion of UNIX, takes up 66,000 pages; the UNIX kernel comprises 3.4
million lines of code and takes up 58,000 pages. A simple manual comparison would involve placing the pages of
code side by side in some ordered manner and then looking for the same or similar structure, sequence, and
organization of the code. Assuming each page comparison takes one minute, and that there are 66,000 x 58,000
comparisons, this "initial" review could take on the order of 25,000 man-years. Following the initial review, SCO
and its experts must conduct a detailed comparison of likely copying candidates. This "second-level" review would
also require extraordinary human labor and consume enormous time. See Sontag Decl. ¶ 14.
-
One shortcut to comparing the UNIX and Linux code might be comparing similar directory structures of the
UNIX and Linux operating systems. For example, version 2.4 of the Linux kernel contains 530 subdirectories and
about 8750 source and assembly files. See Understanding The Linux Kernel, Bovet. Assuming each of the 8750
files requires on an average one day to investigate (some files are small, but others contain thousands of lines of code),
about thirty-five man-years would be required to review all the Linux kernel files in detail. However, this
calculation ignores the possibility that the two operating systems use different file names and a different file layout,
and that similar code sequences may reside in entirely different files. See Sontag Decl. ¶ 15.
-
Software (i.e., source code) undergoes many changes during its initial development and later over its operational
life. Changes may occur as frequently as daily and can continue for years. Software changes typically are driven by
the need to correct "bugs," to improve features, or to add new features. Because of changes made to source code
over time, a current code version may "look" different than the initial code version, making identification of the
initial code version difficult; and substantial similarity and derivation more difficult to establish.
-
The Sontag Declaration describes how such an examination of code lineage would streamline SCO's discovery
efforts. Mr. Sontag provides an example of SCO's UNIX System V source code for a print error function
(perror.c), illustrating accumulated modifications over time. The first version of the code appeared in 1981, and by
the time the seventeenth version appeared more than ten years later, the perror.c code sequence was almost
unrecognizable from the initial version. Yet a careful review of the code reveals that the seventeenth and the initial
versions have the same structure, sequence and organization — the accepted test to show substantial similarity. See
Gates, F.3d at 836-839. Table 1, which shows the incremental change to perror.c code over time by way of code
difference plots, makes explicit what SCO contends here; access to IBM's CMVC system would greatly streamline
SCO's discovery efforts. See Sontag Decl. ¶¶ 37-42.
-
In support of its argument that SCO needs no further discovery, IBM relies on the plainly inapposite case of
Gemisys Corp. v. Phoenix Am., Inc., 186 F.R.D. 551 (N.D. Cal. 1999). IBM Resp. at 14. In Gemisys, the plaintiff
sought to depose three witnesses for a second time in the apparent hope that they would change their testimony, and
to depose an undisclosed number of other witnesses on issues about which it had already obtained information
through prior depositions. Id. at 565-66. In a Rule 56(f) motion, the plaintiff requested this redundant discovery
based on its mere "hope that further evidence will develop prior to trial." Id. at 566. In contrast, SCO's request is
not based on a speculative hope that evidence will develop, but on SCO's specific demonstration of the relevance of
the discovery material to SCO's case and the lack of burden IBM will bear in producing it. Moreover, SCO requests
discovery thus far withheld by IBM in contravention of SCO's requests and this Court's Orders, and does so through
a motion to compel, where "the concept of relevance should be construed very broadly." 3/3/04 Order at 3
(quoting Gohler, IRA et al. v. Wood et al., 162 F.R.D. 691, 695 (D. Utah 1995)).
-
Magistrate Judge Boyce often remarked that a showing of undue burden sufficient to defeat a request for
relevant discovery must be akin to "cleaning the Aegean stables."
-
Given that IBM initially defended its decision to produce the code on DDS tapes and refused to provide
them in the DVD format, it obviously took less than three weeks to make the necessary transfer once they
had decided to provide them to SCO in the correct format.
-
IBM further states that it "does not maintain revision control information for AIX source code prior to
1991" Thomas Decl. ¶ 5 (emphasis added), but does not state whether they possess pre-1991 revision
control information for AIX source code. Even if pre-1991 AIX revision control information is
unavailable, that does not mean IBM cannot produce pre-1991 notes, white papers and design documents,
as well as releases and versions of AIX.
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 02:27 AM EDT |
PJ, you are a poet. [ Reply to This | # ]
|
|
Authored by: Philip Stephens on Monday, July 19 2004 @ 02:28 AM EDT |
Gads, this is such a slimy document it almost makes me physically ill to read
it.
It disgusts me that SCO wants the entire case to hinge on one poorly worded
paragraph of the contract. Everything else they write is wholly dependant on
their interpretation being the correct one--without that, it all falls apart
like a house of cards.
Would it be reasonable to assume that now that IBM has managed to get SCO to
admit that their case is entirely about the contract, that they're getting ready
to either file their own memo or argue on August 4th that Judge Kimbell should
pospone all discovery pending a decision from him regarding the meaning of the
contract? Or that discovery should be limited to those areas that relate to the
interpretation of the contract?
I sure hope so, otherwise this damn case is just going to drag on and on while
no progress is made towards resolving the actual issues in the case.[ Reply to This | # ]
|
|
Authored by: Vaino Vaher on Monday, July 19 2004 @ 02:32 AM EDT |
Being a Linux fan, I am more interrested to see the copyright issue resolved. If
IBM has a contract problem with SCO then that is secondary to me.
However, to the best of my knowlege IBM never signed a UNIX license NewSCO.
Before NewSCO can ask for all of this discovery, doesn't it have to prove that
they are successor of interest?
To me it would mean:
- Show that Novell bought UNIX from AT&T.
- Show that OldSCO bought Unix from Novell.
- Show that Caldera bought Unix from OldSCO.
- Show that the rights were transfered from Caldera to the re-incorporated
NewSCO.
Before showing that paper trail, how can they ask for any discovery at all? And
why does IBM let them go on like this?[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 02:35 AM EDT |
PJ: "They didn't see IBM's strategy coming at them until it was almost too
late."
This reminds of how I (sometimes) play chess with my
father-in-law.
He (like IBM) plays well, knows tactics and strategy, and
out-thinks me so I don't see what's coming.
I (like SCO) start out all
clever, but soon start to lose. I then throw every piece I have, trading, hoping
to win an advantage.
I won once using that strategy. But I think
he had a cold.
Hey, maybe IBM is using Deep Blue.
That
explains why they are 'playing' so well.
M.[ Reply to This | # ]
|
|
Authored by: thorpie on Monday, July 19 2004 @ 03:09 AM EDT |
8th paragraph - Excape
First Heading after ARGUMENT in the memoranda - RESONABALY
---
The memories of a man in his old age are the deeds of a man in his prime -
Floyd, Pink[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 03:09 AM EDT |
This isn't about SCO or SCO's morality, this is about FUD and time to Longhorn.
SCO is bought and paid for by M$, no doubt on a week by week basis and when SCO
gets shot down the money stops. That is why they are trying every trick in the
book to perpetuate this farce. The SCO company is dead meat no matter what
happens. It is only WHEN IT HAPPENS that makes any difference to the SCO
players.[ Reply to This | # ]
|
|
Authored by: Totosplatz on Monday, July 19 2004 @ 03:12 AM EDT |
This is amazing. If SCO is serious about this not being about copyright they
should not oppose a judgement confirming that there is no copyright
issue.
It seems obvious that IBM is on solid ground in regard to the
contract because of the side letter and the echo article. Frustrating. IBM
should move for summary judgement on the contract claims as well, right now. Why
not?
Even if the judge does not grant IBM's request now I believe this
will work out fine in the end. it seems that TSCOG has admitted a lot here which
would be hard to deny in the future. --- All the best to one and all. [ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 03:12 AM EDT |
Let's try yo have a nice and organized page !
Loïc[ Reply to This | # ]
|
- OT GrokLaw needs to do some optimisation - Authored by: Franki on Monday, July 19 2004 @ 03:30 AM EDT
- Hostage analogy - Authored by: amcguinn on Monday, July 19 2004 @ 06:17 AM EDT
- ..Tom Yager made an intresting observation on Sun and Apple's Java in his blog. - Authored by: Anonymous on Monday, July 19 2004 @ 07:06 AM EDT
- The open source project JBoss get J2EE 1.4 certification from Sun. - Authored by: penguins_4ever on Monday, July 19 2004 @ 08:15 AM EDT
- Shame on first posters! - Authored by: Anonymous on Monday, July 19 2004 @ 08:49 AM EDT
- SCOCON: - Authored by: Anonymous on Monday, July 19 2004 @ 08:52 AM EDT
- SCOCON: - Authored by: Weeble on Monday, July 19 2004 @ 10:02 AM EDT
- SCOCON: - Authored by: Anonymous on Monday, July 19 2004 @ 11:04 AM EDT
- Upcoming Legal Events - Authored by: Anonymous on Monday, July 19 2004 @ 09:05 AM EDT
- When OS Companies get it right. - Authored by: archonix on Monday, July 19 2004 @ 10:33 AM EDT
- City of Haarlem (Netherlands) switched to Open Office - Authored by: Anonymous on Monday, July 19 2004 @ 10:41 AM EDT
- SUN Microsystems for sale? - Authored by: clark_kent on Monday, July 19 2004 @ 10:55 AM EDT
- SCO Claims Linux Lifted ELF - Authored by: olly on Monday, July 19 2004 @ 12:08 PM EDT
- Microsoft pays to end Lindows suits - Authored by: Fractalman on Monday, July 19 2004 @ 03:05 PM EDT
- M$ cleanup? - Authored by: Anonymous on Monday, July 19 2004 @ 04:15 PM EDT
- Interesting speculation on BayStar and regulatory changes - Authored by: Anonymous on Monday, July 19 2004 @ 04:12 PM EDT
- Blazing Saddles reference - Authored by: chrisbrown on Monday, July 19 2004 @ 04:52 PM EDT
|
Authored by: dht on Monday, July 19 2004 @ 03:15 AM EDT |
OK, it's just a contract case. SCO claims it "controls" anything and
everything that has ever been placed in AIX or Dynix regardless of it's source.
IBM's interpretation is quite a bit different of course, based on the side
letter and the AT&T echo newsletter clarification.
IBM has admitted as facts that they have contributed their own AIX code to
Linux.
The issue narrrows down to "is IBM allowed to contribute their own
copyrighted code to Linux?" SCO says no, IBM says yes.
Now just why would SCO need further discovery for this? IBM has already
admitted all the essential facts required for SCO to persue their case (as they
see it). I always thought discovery was meant to unearth facts (disputed or
undisputed) relevent to the case. As it stands now, IBM has already stipulated
as fact all the items nessasary for SCO to "make" their case on a
simple contract dispute. The only issue left is the interpretation of the
contract as written.
I just don't get it.. If it was just a contract dispute over who
"controls" IBM written and copyrighted code all along, and IBM
stipulated from early on that they did in fact contribute their own code to
Linux, then why the need (and continuing need) for every single version of AIX
and Dynix in history?
They don't need all the versions of AIX and Dynix to "prove" IBM
contributed IBM copyrighted code to Linux, IBM has already admitted it, and the
very existance of such code in Linux is all the proof SCO needs. The very lack
of such code, or anything like it, in SCO's UNIX should "prove" it
came from somewhere other than SCO IP (methods, code, and ideas). So this
massive discovery request is in support of - what???
Finally, SCO is able to certify that HP and Sun are totally clean in their
contributions to Linux (based on the same Unix IP contract) without any such
massive discovery requests. How did they do this magical trick when they can't
do it for IBM?
The only reason they could need this level of discovery is to show that code
that was in orginally in Unix, somehow "evolved" into something that
was contributed to Linux in an unrecognized form. And that is back to a
copyright issue, not a contract issue.
This may be a clever document, but if you step back and look at the big picture
it makes even less sense than all the claims they have made to date.. Maybe they
are hoping to snow the courts with details and get them to forget the big
picture. I doubt they will succeed, or that IBM will fail to point out the
inconsistencies in the big picture.
I won't get into the merits of their claims, contract or copyright (worthless),
but it seems to me that this memo supporting their need for massive discovery is
totally inconsistent with the case as it was and how it stands today..
[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 03:17 AM EDT |
If SCO admit that, then there should be no problem whatsoever in granting a
summary judgement that IBM's Linux activities do not infringe SCO's "IP
rights" - whatever those rights actually turn out to be.
Also, despite SCO continuing to claim that IBM breached a contract, SCO do not
have any contract with IBM. They are depending on a contract that IBM had with
AT&T.
Both IBM and AT&T say that that contract does not encumber any code IBM
writes. IBM code belongs to IBM, and that was the understanding between the
parties to the contract, and there is considerable evidence in writing to show
that that was indeed the understanding.
newSCO's view on what the AT&T - IBM contract means is both totally
irrelevant and totally wrong.
IMO, IANAL.[ Reply to This | # ]
|
|
Authored by: bruce_s on Monday, July 19 2004 @ 03:31 AM EDT |
OT and other issues here, please
Bruce S. [ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 03:36 AM EDT |
SCO argues that the whole thing is about a contract. All right, fine. What is
the problem then with the summary judgement in relation to copyright? Just get
it over and done with, it won't change the case anyway. Also, if SCO doesn't
need to show any infringing code at all (it's about a contract, remember), why
the heck have they been wasting court's time on getting all that AIX code and
why on earth do they want more of it?
It should be clear as a bell, right? If it's a contract issue, and if the
contract says that IBM isn't allowed to disclose or use any code that ever
touched Unix in any other way, why are we here? It is an undisputed fact that
JFS, JFS2, RCU etc. are all part of AIX, which is Unix. Why isn't IBM writing
cheques to SCO?
But it isn't all that clear, is it? And, the charade continues... And in the
end, SCO will have absolutely nothing to show - not a single thing. Not in
relation to copyright, not in relation to contract and trade secrecy has already
been dealt with. Did I mention they don't actually own the damn thing at all?[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 03:41 AM EDT |
From TSG's lawyer in the Autozone hearing:
Basically, it's
SCO's position that certain companies, one of them being IBM, contributed code
and other types of materials that are protected by not only licensing agreements
but copyright laws to Linux for its own business purposes in order to create a
competitor to the Microsoft software and the Unix software, which SCO owns and
which SCO receives millions and millions of dollars in royalties from every
year.
SCO still accusses IBM from copyright infringement
in Linux.
But I assume they say that they don't sue them over it.
H@ns [ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 03:42 AM EDT |
What about the depositions of former AT&T
executives? Have there been any ? They could
easily shed light on the whole "derivative
theory" thing, should the echo letter not be
enough. [ Reply to This | # ]
|
|
Authored by: RedBarchetta on Monday, July 19 2004 @ 03:48 AM EDT |
"But IBM's argument ignores the fact that SCO's principal claims
are, as they have been since the beginning of this litigation, for breach of
IBM's contractual obligations under the IBM and Sequent Software Licensing
Agreements." -- Brent Hatch, SCO2 Attorney
As far as I'm
concerned, this is yet another admission by SCO2's counsel that Darl McBride,
Chris Sontag and Blake Stowell were lying through their teeth regarding code in
Linux. This will definitely help IBM with it's
counterclaims.
Just in case Brent Hatch forgot, since the
beginning of Litigation (March, 2003), the SCO2 executives have made the
following damning statements:
"[..] IBM has been happily
giving part of the AIX code away to the Linux community, but the problem is
that they don't own the AIX code," McBride said. "It's a huge problem for us. We
have been talking to IBM in this regard since early December and have reached an
impasse. This was thus the only way forward for us." --
Darl McBride
March 10,
2004
"You don't have to be a programmer at all to see
copying had occurred. It wasn't just ten lines of code, that example was
over 80 to 100 lines of code. Later some of the Linux people said that code
shouldn't have been there, Bruce Perens said it was development problem and
'we've taken it out.' My analogy is [that's] like a bank robber with posse in
pursuit swinging back by the bank and throwing the money back in...
[...] It's kind of hollow words that we are not showing
code,
because we have shown examples and if we keep showing it, they'll just take that
out and say 'no harm no foul.' That doesn't solve the problem."--
Chris Sontag
Nov. 18, 2003
"In other words, SCO will present this
evidence (code) to the jury, the judge and to the defendant [IBM], but it
will remain confidential. No one in the public will get to see this code [..]"
-- Blake Stowell
Dec. 16, 2003
--- Collaborative
efforts synergise. [ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 03:58 AM EDT |
SCO compared to a wolf?
Please PJ, you shouldn't disgrace the poor noble beasts like this ;)
If you have to use an animal analogy, perhaps a better pick is
"vulture": circling in the sky, oppurtunistically waiting for the
moment when someone has fallen or weakened, at which time they can feast on them
undisturbed.[ Reply to This | # ]
|
- Wolf - or louse - Authored by: john82a on Monday, July 19 2004 @ 04:59 AM EDT
- Wolf - Authored by: inode_buddha on Monday, July 19 2004 @ 07:07 AM EDT
- Dog - Authored by: Anonymous on Monday, July 19 2004 @ 08:17 AM EDT
- longhorn - Authored by: seanlynch on Monday, July 19 2004 @ 10:02 AM EDT
- longhorn - Authored by: darthaggie on Monday, July 19 2004 @ 11:15 AM EDT
- longhorn - Authored by: Anonymous on Monday, July 19 2004 @ 12:01 PM EDT
- Wolf - Authored by: Anonymous on Monday, July 19 2004 @ 10:59 AM EDT
- Wolf - Authored by: Anonymous on Monday, July 19 2004 @ 12:18 PM EDT
- OT: The persistent part of the argument - Authored by: johan on Monday, July 19 2004 @ 01:23 PM EDT
- I still think - Authored by: Tim Ransom on Monday, July 19 2004 @ 01:29 PM EDT
- Wolf - Authored by: Anonymous on Tuesday, July 20 2004 @ 04:57 AM EDT
|
Authored by: Anonymous on Monday, July 19 2004 @ 04:05 AM EDT |
Assume SCO proves that IBM's contributions to Linux are
prohibited by the IBM-ATT contract. What would the damages
be? The symbolic dollar?[ Reply to This | # ]
|
|
Authored by: Philip Stephens on Monday, July 19 2004 @ 04:15 AM EDT |
I'm wondering if we're misinterpreting SCO's real agenda in filing this
memorandum.
Think back a year, when Darl McBride and Chris Sontag were shooting off their
mouths to the press about how they want to turn Linux into a non-free OS, one
that they can collect royalties on every copy.
What was their justification for this? That Linux was an unauthorised
derivative of their System V UNIX, so they deserved to be compensated for their
"IP" being in Linux. They seemed supremely confident that their
"IP" was so thoroughly diffused throughout Linux that it could not be
removed.
Now, if the case SCO brought against IBM was truly a contract dispute, why
should SCO care if IBM was granted a summary judgement that Linux doesn't
infringe on SCO's UNIX copyrights? Surely there can only be one answer: despite
what SCO says in this current memorandum, they want to be able to pursue a
copyright infringement case against Linux sometime in the future.
Why else would they need unfetted access to everything related to AIX and Dynix,
except to build up "proof" that certain System V code
"morphed" into certain AIX code, and that same AIX code was then
donated to Linux, causing Linux to become a derivative of System V in the eyes
of copyright law.
We all know that case law doesn't support this creative interpretation of
derivative works. But what if McBride and Sontag have convinced themselves that
they can actually CREATE new case law that allows them to claim Linux as a
derivative of System V?
If this is what they are thinking, then the last thing they want is for a judge
to declare that Linux does not infringe on System V copyrights. They are so
desperate for this not to happen, they have been forced to argue that their case
against IBM is purely a contract dispute, thus the summary judgement should not
even be considered.
We all know that SCO do not need to see the entire history of AIX and Dynix to
support their interpretation of the contract. They only want this information
so that when (in their minds) they have the judge rule that IBM breached it's
contract, they can then file a whole new lawsuit against Linux distributors that
they're infringing on System V copyrights by virtue of AIX code appearing in
Linux.
Now, I don't know whether it's legal to use the discovery from one case to
support other cases, but it seems to me this is what SCO is trying to do. But
SCO has mismanaged the IBM case badly, because they pretty much revealed their
intentions in some of the original filings, where they whined about how Linux
was an unauthorised derivative of UNIX. IBM was smart enough to see what SCO
was trying to do, and gradually turned the screws on SCO until they were forced
to write this memorandum.
Anyway, that's my theory. I'm sure someone can shoot some holes in it, so fire
away... ;-)[ Reply to This | # ]
|
|
Authored by: inode_buddha on Monday, July 19 2004 @ 04:47 AM EDT |
"...but automated tools do not work well in the absence of identical copying.
Sontag SJ Decl. ¶¶ 10-13. Those tools identify only exact or nearly-exact
literal matches, thereby excluding evidence of non-literal copying." (Sec. 3 B,
SCO's Requested Information Is Discoverable to Defend Against IBM's
Recently-Added Copyright Claims., para. 6.) I thought that *literal*
copying, or substantial similarity, was required for copyright claims?
(Excluding fair use). But wait! This is a *contract* case, isn't
it? "...The 4 million lines of Linux kernel code, which is the core portion
of UNIX, takes up 66,000 pages..." (ibid., footnote 4) Er, since when was
the Linux kernel the core of UNIX? --- "When we speak of free software,
we are referring to freedom, not price." -- Richard M. Stallman [ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 04:48 AM EDT |
The issue now seems to be "IBM has improperly contributed its own code to
Linux in violation of a contract". Since it is not in dispute that IBM has
contributed code to Linux, that would seem to boil down to an argument over
whether SCO has rights over any or all of that code on the grounds of being a
derivative work.
Now if I find my GPL code distributed with the copyright removed, I know there's
a violation. And that applies also to derivative works under the GPL. So if I
*suspect* violation I may need discovery to determine whether it is a derivative
work under the GPL.
The direction this is going will set a precedent that will certainly be cited in
any major GPL trial under US law. So if SCO isn't granted all the discovery
it's asked for, that'll be a useful precedent for, say, M$ to deny discovery
when someone accuses them of GPL violation.[ Reply to This | # ]
|
|
Authored by: rand on Monday, July 19 2004 @ 05:38 AM EDT |
"The contracts, granting the licensor more protection than copyright would
have done without any agreement..."
Please recall that in the early days of UNIX, AT&T did not rely on
copyright, but on trade-secret status. That's the reason for the contracts.
The original IBM/AT&T agreement was signed in 1985, the year before the 1986
BSD-AT&T License, and well before USL first registered UNIX in 1992.
SCOGroup has declared that there are no trade-secret issues, even though they
now assert that due to "...Contractually-Protected System
V 'Methods or Concepts'", "...IBM is no more free to disclose, export,
or publish any derivative version of AIX or Dynix/ptx than it is to disclose,
export, or publish System V itself." That sounds like a trade secret claim
to me.
---
carpe ductum -- "Grab the tape" (IANAL and so forth and so on)[ Reply to This | # ]
|
|
Authored by: Jude on Monday, July 19 2004 @ 06:05 AM EDT |
...that IBM's contributions are only a small part of Linux, and that no amount
of AIX or Dynix discovery is going to help SCO find any infringment in the parts
of Linux that were not contributed by IBM.
There's also no need to look at all AIX and Dynix code to investigate IBM's
contributions. Only the ancestry of the contributed code should be subject to
discovery.
I think even more discovery could be obviated by getting an early decision on
SCO's "ladder" theory. SCO seem to be saying that any chain of
derivation makes all child nodes derivatives of the parent, but if the court
does not accept this theory then SCO's discovery will gain them nothing.
[ Reply to This | # ]
|
|
Authored by: micheal on Monday, July 19 2004 @ 06:23 AM EDT |
"But IBM's argument ignores the fact that SCO's principal claims are,
as they have been since the beginning of this litigation, for breach of IBM's
contractual obligations under the IBM and Sequent Software Licensing Agreements.
"
What are SCO's secondary claims? Copyright
violations?
--- LeRoy -
What a wonderful day. [ Reply to This | # ]
|
|
Authored by: micheal on Monday, July 19 2004 @ 06:36 AM EDT |
"arguing that SCO cannot demonstrate any issues of material fact regarding
copyright infringement by IBM in any of its (vast and continuously expanding,
but only partially enumerated) "Linux activities.""
If IBM has a
proprietary program that runs on Linux, would that program be considered a
"Linux activity"? If it is and that program contains code that is validly
copyrighted by TSG then IBM's 10th CC would clear (invalidly) IBM of copyright
violation. That is a basis for rejecting he 10th CC. IBM should have been
specific what they meant by "Linux activities".
--- LeRoy -
What a wonderful day. [ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 06:56 AM EDT |
So, they've come out and said it. (paraphrasing) Dynix 1 is a
derivative
of UNIX, and
therefore covered by the UNIX licensing agreement. Dynix 2 is a
derivative of
Dynix 1, therefore of UNIX, and therefore covered by the UNIX
licensing
agreement. Repeat ad nauseum. Fair enough. I don't remember
anyone
arguing that this was not the case.
Now that's out in the open,
if gives IBM some mighty fine
ammunition. What I can see happening here is
this:
- IBM say, "Yeah, Dynix & AIX are derivatives of UNIX. So
what?"
- SCO say, "But you gave Dynix and AIX code to Linux. You're in
the
wrong"
- IBM say, "No, we gave IBM code to Linux. Code that
we may
have added
to Dynix and / or AIX as well, but IBM code
nonetheless. Code we
developed
here independently of UNIX."
- SCO
say, "But if it's been in an UNIX derivative, it's ours. QED"
- IBM say,
"Cobblers. The SCO themselves state:
under Paragraph 2.01 of the
IBM and Sequent license agreements,
"modifications and derivative works based
on" UNIX System V are treated as if
they were part of the original licensed
"SOFTWARE PRODUCT,"
this is code that was added
to Dynix and / or AIX, code
that was developed by us. It is neither a
modification nor a derivative of any
code existing in UNIX. The specific
interface from UNIX derivative to our code
is a derivative to our code, not
that of the UNIX derivative in question. The
core code is most definitely
ours, to do with as we wish."
- SCO say, "but we don't know that.
So we need every copy of AIX
and Dynix ever created, plus all your other code,
just in case."
- IBM say, "Ah. But you have the original UNIX code. And
you have access
to every version of Linux ever created. From the Linux source,
you can see all
and any code submitted by IBM. You also have many versions of
AIX and
Dynix. From the original UNIX code, you should be able to find any
UNIX
code that may possibly have slipped into Linux, as you have the source to
both. After all, you claimed to have 'mountains' of literal copying in Linux,
well before you asked for or received the AIX or Dynix source. If you have
that literal copying, and you can tie it to specific IBM contributions, you may
have a case. Hell, if you could tie something specific that IBM contributed to
a piece of code that may have its roots in UNIX, we could go on. But
as you seem unwilling to produce even that, we must conclude that you have
no
case, no evidence, and we must therefore ask the judge for summary
dismissal on
both the copyright and contract issues."
- Judge says, "Sounds fair to
me"
- SCO say, "But.... But.... Damn. But... But, if Chewbacca lives
on Endor,
and..."
Well, it's unlikely to go exactly like that
(except, perhaps, for the last
defense
of SCO), but I can't see that any sane
judge is going to accept the SCO
derivatives theory - it goes against all case
law that I know of, and would
create a most unpleasant
precedent.
Frankly, I hope the Judge reams SCO a new one, to coin a
phrase.
Simon [ Reply to This | # ]
|
|
Authored by: MadScientist on Monday, July 19 2004 @ 06:58 AM EDT |
This is a reposting of something I wrote on SCO contract theory. Aplogies to
anyone who read this before for this reposting but it seems to me that this
might(?) help any one having trouble with SCO contract claim.
BTW the trade secrets claim has gone away - so ignore this bit please. Also
wearing a tine foil hat while optional is recommened.
++++++++++++++++++++
As I presently understand the non copyright issues here this is a contract
dispute between IBM and SCO. SCO claim thier SOFTWARE PRODUCT (SysV) encompases
all derivative works based upon it and that in addition IBM were bound by thier
contract not to divulge any of the SOFTWARE PRODUCT code to anyone. This I
understand to be the basis of the trade secrets claim.
And that this case has made in in the door is because of the side letter - which
under court proceedings allows parol evidence (material outside the writing) to
be included.
++++++++++++++++++++++++
To review the situation again
In effect SCO claim that IBM and Sequent both agreed to work for AT&T as
part of their contract to use the SOFTWARE PRODUCT. The consideration on the
part of AT&T was that IBM and Sequent could use the SOFTWARE PRODUCT.
In addition to effectively working for hire IBM and Sequent agreed to licence
the use of the SOFTWARE PRODUCT. It is this contract that allows SCO (sucessors
in interest to AT&T) to lay claim to all of IBM's work since 1995 on SysV
and related products - to wit Aix and Dynix.
The royalty buyout that IBM concluded only relieved IBM of the need to pay
further licence fees but did not relieve IBM of the obligation to work for
Novell for no further consideration.
In addition to donating all the copyrights to the IBM created code to AT&T,
IBM has bound its sucessors to this contract. This in addition means that IBM
releasing the new code to anyone else is a breach of the contract because of the
requirement in the contract to keep secret those thing that should be kept
secret.
According to this contract then IBM and Sequent have been working effectively as
SCO employees/contractors since 1995. IBM are in breach of their contract
because they have released SCO owned code to third parties and released trade
secrets (the code itself) again to third parties.
Because of the side letter parol evidence is needed to establish exactly what
the contract meant originally. Hence the need for the depositions etc.
+++++++++++++++++++
Now needless to say I have more than a few problems with this.
Firstly the consideration on the part of AT&T and it sucessors seems to be
highly inequitable. In return for pemission to use the SOFTWARE PRODUCT IBM et
al are bound in perpetuity to donate code to AT&T. And have to pay for the
priviledge. Tricky one that. Wonder if the court will uphold it. Hmm.
Secondly based on the premises of the above paragraph, the uniform comercial
code (UCC) requires a contract that cannot be fulfilled in less than one year to
be reduced to writing. Strange - I missed that in the contract.
Thirdly in general what one creates is one's own copyright - the main exceptions
being works for hire. Unless the contract can be intrepreted to be a contract
for hire, IBMs own code is IBM's.
That is unless there is a 204 assignment. There have been no 204 assignments
produced to date by SCO. Given this one must assume that SCO have understood the
AT&T contract to be one for hire and that somewhere in the provisions it is
stated that IBM (and Sequent) have agreed to work for AT&T without fee for
perpeuity as part of the price for using the SysV code. (See the above
paragraph)
IBM and Sequent by conviently forgetting to mention this in 1995 are in clear
breach of the obligations to the SEC and their shareholders.
+++++++++++++++++++++
What would a "reasonable man" make of this?
Comercial cases are on the "balance of probability" - not "beyond
all reasonable doubt".
First IBM and Sequent essentially sell themselves to AT&T without telling
anyone. And no one realises this for almost 10 years. All the AT&T, IBM,
Sequent and Novell lawyers missed this. All the SEC officials missed this. The
shareholders missed this. The stock market analysts et al missed this deal. That
*is* curious.
Is it *just* possible that that contract never really said that?
That the contract just said that IBM & Sequent could use the SysV code in
return for a licence fee and could study the code as long as the SysV code
itself was kept secret from non employees/contractors. And that the royalty
buyout as essentially the end of the matter as far as IBM were concerned -
except for the secrecy bit which still stands.
And that IBM own thier own code. And that it is IBM owned code that has been
contributed to Linux? And that AT&T, Novell, Sequent & IBMs lawyers were
not wrong. And the shareholders were not wrong. And the SEC were not wrong.
And is it possible that just maybe SCO is the one who is wrong - because their
lawyers have forgotten their contract law?
+++++++++++++++++++
Or is it I myself who has it all totally wrong here?[ Reply to This | # ]
|
|
Authored by: soronlin on Monday, July 19 2004 @ 07:05 AM EDT |
3. The Requested Discovery is Relevant to and Will Aid SCO
in
Determining Whether IBM Disclosed Contractually-Protected System
V "Methods
or Concepts."
This section makes no mention about AIX,
only Dynix/ptx. Why? Because IBM is allowed to use Unix Methods and Concepts in
any of their other products and services. The relevant clause of the licence is
7.06(a):
7.06 (a) LICENSEE agrees that it shall hold all parts
of the SOFTWARE PRODUCTS subject to this Agreement in confidence for AT&T.
LICENSEE further agrees that it shall not make any disclosure of any or all of
such SOFTWARE PRODUCTS (including methods or concepts utilized therein)
to anyone, except to employees of LICENSEE to whom such disclosure is necessary
to the use for which rights are granted hereunder. LICENSEE shall appropriately
notify each employee to whom any such disclosure is made that such disclosure is
made in confidence and shall be kept in confidence by such employee. If
information relating to a SOFTWARE PRODUCT subject to this Agreement at any time
becomes available without restriction to the general public by acts not
attributable to LICENSEE or its employees, LICENSEE'S obligations under this
section shall not apply to such information after such time.
However the side-letter modified that clause as
follows:
7.06(a) LICENSEE agrees that it shall hold SOFTWARE
PRODUCTS subject to this Agreement in confidence for AT&T. LICENSEE further
agrees that it shall not make any disclosure of such SOFTWARE PRODUCTS to
anyone, except to employees of LICENSEE to whom such disclosure is necessary to
the use for which rights are granted hereunder. LICENSEE shall appropriately
notify each employee to whom any such disclosure is made that such disclosure is
made in confidence and shall be kept in confidence by such employee. Nothing
in this agreement shall prevent LICENSEE from developing or marketing products
or services employing ideas, concepts, know-how or techniques relating to data
processing embodied in SOFTWARE PRODUCTS subject to this Agreement, provided
that LICENSEE shall not copy any code from such SOFTWARE PRODUCTS into any such
product or in connection with any such service and employees of LICENSEE shall
not refer to the physical documents and materials comprising SOFTWARE PRODUCTS
subject to this Agreement when they are developing any such products or service
or providing any such service. If information relating to a SOFTWARE
PRODUCT subject to this Agreement at any time becomes available without
restriction to the general public by acts not attributable to LICENSEE or its
employees, LICENSEE's obligations under this section shall not apply to such
information after such time.
Note also 7.06(b) and its
side-letter commentary:
(b) Notwithstanding the provisions of
Section 7.06(a), LICENSEE may distribute copies of a SOFTWARE PRODUCT, either in
modified or unmodified form, to third parties having licenses of equivalent
scope herewith from AT&T (or a corporate affiliate thereof) for the same
SOFTWARE PRODUCT, provided that LICENSEE first verifies the status of any such
third party in accordance with specific instructions issued by AT&T. Such
instructions may be obtained on request from AT&T at the correspondence
address specified in Section 7.11(b). LICENSEE may also obtain materials based
on a SOFTWARE PRODUCT subject to this Agreement, provided that LICENSEE treats
such materials as if they were part of such SOFTWARE PRODUCT.
Regarding
Section 7.06(b), this section covers the situation where one of our licensees
wishes to furnish its modified version of our source code for a SOFTWARE PRODUCT
to another of our licensees for the same product. The last sentence of this
section makes clear that you may receive source code from another such
licensee, provided you treat such source code as if it were the source code we
furnished to you. This language is not intended to refer to an object-code
product that you obtain from another of our licensees pursuant to that
licensee's sublicensing rights.
So the modified subsection
(a) obviously defines what IBM can do with Dynix/ptx after they received it from
Sequent. They can use "ideas, concepts, know-how or techniques" from Dynix/ptx
in any way they like so long as they don't directly copy, or use the manuals.
Sequent before the takeover was bound by the original version of 7.06(a), and
therefore could not divulge Unix methods or concepts.
[ Reply to This | # ]
|
|
Authored by: jmc on Monday, July 19 2004 @ 07:14 AM EDT |
Why doesn't IBM seek a declaration from the court invalidating the whole of
SCO's mega-viral derivative work theory?
All of the recent rants about discovery would be put to bed wouldn't they?
[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 07:21 AM EDT |
In arguing that copyright was never part of the case, purely contractual, and so
on, aren't they ignoring the IBM discovery requests completely?
IBM requested details of all rights (which obviously includes copyrights) which
SCO claimed in Linux. In November, SCO had a chance to argue before the court
that such information was overly broad for discovery, that there were no
copyright claims in the case and so they shouldn't have to produce all that.
They could have argued that it should be changed to "all code over which
SCO claims rights under the licensing agreement" for instance.
I don't remember them making that argument, probably because with the broader
but vaguer order they got, they could pretend they were complying with discovery
while doing no such thing.
Presumably they had another chance to argue it in March when they were ordered
to produce the same information again, as they were prepared to argue everything
else. :)
So my point is, didn't SCO (or, if SCO made the arguments and my memory is at
fault, the court) already concede that there were potential copyright issues in
the case, that copyrights in Linux were (or could be) at issue by agreeing that
IBM's discovery requests were reasonable and likely to turn up relevant
information?[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 08:03 AM EDT |
IBM essentially said: "if giving scox some AIX code, and some more time,
will put an end to scox's whining, then sure, we'll give scox some code."
By doing that, IBM gave credibility to the idea that scox, for some reason,
needs AIX code. If scox needs this portion of AIX code, then why not another
portion as well?
I think scox may have won this battle. IBM stepped right into scox's little
trap. Scox now has justification for one delay after the next.
[ Reply to This | # ]
|
|
Authored by: julianne on Monday, July 19 2004 @ 08:10 AM EDT |
For a long time, I have sat through code reviews, thinking that looking for
"real or substantive changes" should be easier to find than wading
through tons of diff listings. Having reviewed the Gates case and the theory of
"non-litteral copying," I thought the very same thing. What is
required is a tool that I would call "code-diff" that parses the
sources in question and looks for differences in the parse trees of the two.
With the parse differences, the program can go back and highlight the sections
that contain the differences. In that way, one can identify such things as
variable renaming, parameter type changes, modifications of control flows, etc.
Since most of the code in question in the SCO vs World cases is written in C,
the challenge is great in finding the way around all of the C-isms that make it
hard to read/maintain (ifdefs, defines, redefs, etc.) However, the preprocessor
stuff can be the subject of further structural comparison.
With a tool like this, this whole thousands-of-years claim could be put to bed
rather quickly, having the ability to do searches as rapidly as the traditional
text diff. All this being said, how does the non-litteral copying theory hold
up when one finds examples of expressions that can only be done a few ways (as
discussed in previous threads)?
Even if this doesn't have much impact on the current case, maybe it's time to
bring a tool like this into the FOSS collection.[ Reply to This | # ]
|
|
Authored by: Totosplatz on Monday, July 19 2004 @ 08:16 AM EDT |
It seems clear that TSCOG thinks that the term SOFTWARE PRODUCTS means the
original code package obtained from AT&T as well as each successive stage of
development made by the recipient.
I think that IBM thinks that the term
SOFTWARE PRODUCTS refers to only the original code package obtained from
AT&T.
So which is it? Or am I missing something
here? --- All the best to one and all. [ Reply to This | # ]
|
|
Authored by: Totosplatz on Monday, July 19 2004 @ 08:54 AM EDT |
It is abundantly, redundantly clear that code originated by a licensee of
Sys-V UNIX belongs to the originator, forever.
IBM happily admits that
it added code to Linux, and that some or most of that code "came from" AIX (or
Dynix) or was substantially similar to code in AIX (or Dynix.)
So if IBM
would just identify the several thousand places where they added code to Linux,
all one would have to do is look in SYS-V UNIX to see it there is any SYS-V UNIX
code as part of what IBM added to Linux.
Therefore: just check IBM's
additions only, no Sys-V code amongst those additions, case
closed!
I know - much too simple!
--- All the best to one and
all. [ Reply to This | # ]
|
|
Authored by: julian on Monday, July 19 2004 @ 09:38 AM EDT |
I remember that IBM requested in discovery that SCO list all IBM contract
violations and to state what part of the contract IBM's behavior violated. If
SCO didn't respond fully or gave their theory on derivitives IBM should have an
easy declaritory judgement for contract violations. I tried finding the
origional doc in "Legal Docs" but couldn't find it.
---
John Julian[ Reply to This | # ]
|
|
Authored by: blacklight on Monday, July 19 2004 @ 09:47 AM EDT |
I haven't read SCOG's latest memo yet, but I will get to it - Work is getting in
the way. In the meantime, the sheer scope of their discovery requests amount to
as explicit a case of attempted discovery abuse as any or all of us have yet
seen. And that scope is a strong and clear indicator as to the lack of evidence
that they have. Otherwise, why would SCOG go through this rigmarole rather than
push the trial schedule forward? The sooner SCOG wins, the sooner SCOG gets its
$5 bils, right?[ Reply to This | # ]
|
- Nitpick - Authored by: Anonymous on Monday, July 19 2004 @ 02:57 PM EDT
|
Authored by: Anonymous on Monday, July 19 2004 @ 09:54 AM EDT |
It seems to me that if the court ever finds for SCO, SCO's agument that all
IBM's AIX/Dynix code is controlled by SCO may come back to bite them in the
end. After all, if Novell succeeds in showing that it never transferred Unix
copyrights to SCO, then SCO's argument would lead one to believe that Novell
actually controls any additions that SCO made to System V.[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 10:20 AM EDT |
Novell has already told IBM they can do whatever they want so now we will
probably see the Novell card get played.[ Reply to This | # ]
|
|
Authored by: darthaggie on Monday, July 19 2004 @ 11:26 AM EDT |
So the SCO cavalry was called in and this is their bugle blast as
they swarm over the hill. "We are entitled to try for more discovery", is their
call. "Don't cut us off at the pass! We'll be ruined." We'll see if the judge
buys it.
One thing is for sure. They didn't see IBM's strategy coming at
them until it was almost too late. Maybe too late, period.
My
first mental picture was that of the charge of the Light
Brigade:
Cannon to right of them,
Cannon to left of
them,
Cannon in front of them
Volley'd and thunder'd;
Storm'd at
with shot and shell,
Boldly they rode and well,
Into the jaws of
Death,
Into the mouth of Hell
Rode the six hundred.
Lord
Tennyson
Methinks they're walking into a trap. They may win a
stay on CC10, but they're in the process of handing IBM more material to lob
back at them when the time is right. There's only so long they can keep changing
their story before they get beaten up for it. [ Reply to This | # ]
|
|
Authored by: RealProgrammer on Monday, July 19 2004 @ 12:21 PM EDT |
Something bothers me between ¶2.01 and ¶7.06(a) of
the The 1985
AT&T-IBM Software Agreement, but I can't quite pin it down:
2.01AT&T grants to LICENSEE a personal, nontransferable and nonexclusive
right to use in the United States each SOFTWARE PRODUCT identified in the one or
more Supplements hereto, solely for LICENSEE'S own internal business purposes
and solely on or in conjunction with DESIGNATED CPUs for such SOFTWARE PRODUCT.
Such right to use includes the right to modify such SOFTWARE PRODUCT and to
prepare derivative works based on such SOFTWARE PRODUCT, provided the
resulting materials are treated hereunder as part of the original SOFTWARE
PRODUCT.
7.06 (a) LICENSEE agrees that it
shall hold all parts of the SOFTWARE PRODUCTS subject to this Agreement in
confidence for AT&T. LICENSEE further agrees that it shall not make any
disclosure of any or all of such SOFTWARE PRODUCTS (including methods or
concepts utilized therein) to anyone, except to employees of LICENSEE to whom
such disclosure is necessary to the use for which rights are granted hereunder.
LICENSEE shall appropriately notify each employee to whom any such disclosure is
made that such disclosure is made in confidence and shall be kept in confidence
by such employee. If information relating to a SOFTWARE PRODUCT subject to
this Agreement at any time becomes available without restriction to the general
public by acts not attributable to LICENSEE or its employees, LICENSEE'S
obligations under this section shall not apply to such information after such
time.
(emphasis added)
-
Paragraph 2.01
says only that the "resulting materials" be treated "hereunder" (i.e, in a
subsequent part of the agreement) as part of the original product
-
I
don't read that to say that the modifications themselves must be treated as part
of the product
-
Since Caldera/SCO released Ancient UNIX (pre SysV) code
under a no-fee
license (pdf) to the general public, none of the code, concepts, or methods
represented there apply after Jan 23, 2002
-
Since Caldera/SCO published
Linux before, during, and after the IBM AIX contributions to Linux
allegedly took place, the restrictions in 7.06(a) do not apply.
Therefore, IBM was allowed to contribute its own AIX code to Linux.
Even if it were not allowed, Caldera/SCO published the alleged materials itself,
nullifying any restrictions on disclosure.
I see the holes in my
reasoning (such as if "resulting materials" is really the individual IBM-written
piece and not the whole derived product), but I think there's something between
paragraphs 2.01 and 7.06(a).
--- (I'm not a lawyer, but I know
right from wrong) [ Reply to This | # ]
|
|
Authored by: Neil Dunbar on Monday, July 19 2004 @ 12:28 PM EDT |
OK, confused UK reader without knowledge of jurisdiction wants to know -
If this is just a contract dispute, and not primarily a copyright issue, then
why isn't it in state court? SCO2 made such a song and dance in the Novell case
that it should be remanded to state court because it wasn't about copyrights.
Surely, then, if it's primarily a contract dispute, it should be in the Utah
state courts. Or is this because the parties are incorporated in different
states that it elevates to the federal level?
Neil[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 12:38 PM EDT |
Why would IBM not stipulate the following:
"SCO code fragment x appears somewhere in a sequence like:
a) Package w internal release a.
<Code not there>
b) Package w internal release b.
<Code not there>
....
c) Package w internal release b+n.
<Code there>
d) Package w internal release b+n+1
<Code removed when inadvertant copying detected.>
e) Package w internal release b+n+2
<Code not there>"
The idea being that they could stipulate that this
sequence of events happened at least once. One occurance
would preclude all the discovery nonsense and get right to
the legal issue on which SCO has built its house of cards.
Damages would depend on scope but that would be a separate
issue once the legal principle has been decided. Couldn't
IBM stipulate those events with the reservation that the
stipulation is not enought to determine damages? Once the
legal theory is determined, the trial can then go on to
assess damages based on the result. As I understand it,
"indirect copying" could occure if a programmer had recreated SCO code
independently and there is no practical
way of determining if the code was deliberately copied
from SCO or not. It seems to me the worst case could be
stipulated in order to test SCO's theories without prejudicing damages.
[ Reply to This | # ]
|
|
Authored by: Anonymous on Monday, July 19 2004 @ 02:00 PM EDT |
Ha! Linux may be the hostage all right... but it's Mongo.
'No no, don't do that. If you shoot him, you'll just make him mad.'[ Reply to This | # ]
|
|
Authored by: ihawk on Monday, July 19 2004 @ 02:52 PM EDT |
Okay, so let me get something straight here...
SCO says IBM violated the contract with AT&T which stated that IBM needed to
maintain confidentiality of UNIX trade secrets (basically). The contract didn't
have to do with copyright since much of the UNIX source code was not copyrighted
and could not be subsequently copyrighted. So it's a trade secret issue, right?
Methods and structures and stuff, right?
So at some earlier date, SCO or its predecessor in interest released
"ancient" Unix sources to the public. Even though this is an earlier
version of Unix, it's the same trade secrets, the same methods and structures.
That would tend to sort of obviate the trade secrets status of pretty much all
version of Unix, wouldn't it? I mean, they can hardly claim that a method or
structure that was made public in v32 Unix still be held secret in SVRx, can
they? I understood that once a trade secret was dicslosed, no matter how, it
could no longer hold trade secret status. So what's to be held confidential?
Also, SCO can hardly insist that original development by IBM be held as trade
secret if IBM wants to make it public. They are trying to say that new
development by IBM is a derivative of Sys V - which is pretty much completely
ridiculous - and has to be treated as confidential under the terms of the
original AT&T license even though AT&T made it explicit and perfectly
clear that there was no such connection.
So I am now officially and completely mystified as to what SCO is saying IBM did
wrong by contributing their own code to Linux.
..ihawk..
[ Reply to This | # ]
|
- Yabut.... - Authored by: Anonymous on Monday, July 19 2004 @ 03:05 PM EDT
|
Authored by: tredman on Monday, July 19 2004 @ 02:54 PM EDT |
"Why doesn't IBM seek a declaration from the court invalidating the whole
of SCO's mega-viral derivative work theory?"
I think it's amusing that you should use the apropos term "mega-viral"
to describe TSG's derivative works theory. Wasn't Darl McBride one of those who
was harping on the fact that the GPL was unsuitable for use because of it's
viral nature? The GPL doesn't have anything on Darl's tripe.
Tim[ Reply to This | # ]
|
|
Authored by: tredman on Monday, July 19 2004 @ 03:59 PM EDT |
Am I reading that first paragraph correctly? Is TSG explaining, in a motion
before a federal court for the United States of America written in their
butchered legalese, that they have absolutely no evidence, and that they need
AIX source code to find some?
Nooooo....say it isn't so.
Tim[ Reply to This | # ]
|
|
Authored by: kjb on Monday, July 19 2004 @ 04:15 PM EDT |
I needed to reread the original complaint to compare the two documents. I reread
Sco's Reply Memorandum. After reading Sco's Reply Memorandum preliminary
statement again, it seems that the two documents have little or nothing in
common. Am I that far off or is it just wishful thinking?
kjb
---
"No! Try not. Do, or do not. There is no try."
- Yoda[ Reply to This | # ]
|
|
Authored by: blacklight on Monday, July 19 2004 @ 04:52 PM EDT |
"But the reality is, this case is about a contract dispute. Linux got
dragged into it as hostage. SCO is holding Linux by the neck, pointing a gun at
its head, and telling IBM, "Do what I tell you, or I'll shoot your little
friend."" PJ
or "... Do what I tell you, or the penguin gets it." Darl McBride?
Hey, Darl. If you really want to make the penguin scream, point the gun at your
groin ...
[ Reply to This | # ]
|
|
Authored by: Thomas Frayne on Monday, July 19 2004 @ 06:46 PM EDT |
I have organized my comments related to discovery compliance, CC10, PSJ, and
compel orders in two ways, and put the results in LQWiki pages starting
with
LQWiki:
SCOvIBM-PSJ
I am trying to get an organized discussion of the arguments
which should go into the remaining briefings before, and oral arguments at, the
August 4 hearing. The page starts with a list of major court filings, organized
by groups of related filings. Next comes a discusion of arguments related to
the PSJ and IBM-205's context, organized by the topics argued. Finally, there
is a discussion of arguments related to the PSJ, organized by the topics
argued.
Section 1 is up to date, and allows finding the filings, including
the text in Groklaw. Sections 2 and 3 are just outlines, so far, but they link
to detail pages that I am adding my comments to. I'll be copying comments that
I previously made on Groklaw, Yahoo Finance, and section 4 of the Wiki page to
the proper place in the outline over the next few days. When I find a related
article or comment, I'll add a link to the appropriate place in the outline,
together with a short summary of the content. I invite others to do the
same.
Also, if anyone wants to give me or everyone permission to copy any of
their comments into the outline, please respond to this post with the
permission.
To see an outline of the top page, just click here.
[ Reply to This | # ]
|
|
Authored by: blacklight on Monday, July 19 2004 @ 10:47 PM EDT |
SCOG's reply memo is pretty much an admission that their goose is cooked with
the evidence that they currently have. In addition, the very scope of the
discovery they are asking for, which crosses the line into abuse of discovery,
is a tacit admission that they just don't have much of anything to hang IBM on -
SCOG clearly went to court against IBM with little more than a pack of lies. In
my opinion, the SCOG memo does not contain any new information, and is
essentially a replay attack.[ Reply to This | # ]
|
|
|
|
|