Here is SCO's Redacted Memorandum in Support of Its Motion for Reconsideration of the Order Denying SCO's Motion for Relief for IBM's Spoliation of Evidence, as text, thanks to Groklaw member
caecer. And this is the Order SCO would like Magistrate Judge Brooke Wells to reconsider, where she ruled that IBM did *not* spoliate evidence.
SCO asserts that Wells misapprehended the facts, so it lays them out at length again. What it says sounds to me very much like what it told her the first time, so I'm not clear why they think this will work any better. More cases. More detail. You never know. But you're not supposed to reargue a motion, unless there really is some mistake on the part of the judge.
What came to my mind as I read it is Americans who shout at people who don't speak English and thus didn't understand them the first time. It misses a basic truth. The truth here is that you are not supposed to file motions for reconsideration unless you have a foundation for doing so, and it can't just be that you don't like the result you got the first time. This one is borderline, I'd say, at best.
So here's its motion for reconsideration. What it wants is a default judgment, that IBM be essentially inferred guilty of infringement as a sanction. I think we can agree that SCO probably can't prove significant copyright infringement, if any, using the evidence it has put on the table. SCO's trying to get IBM sanctioned, so that it wins via a back door. Again with a back door. In essence, it's arguing that maybe it could have found more evidence of specific lines of code proving methods and concepts were infringed, if only this evidence were still available to it. Therefore, the court should punish IBM and declare SCO the winner after all on a technicality. One of SCO's problems is that according to IBM, the evidence is, in fact, still available. Another is that SCO hasn't got any specific lines of code listed, that I know about, proving methods and concepts in the case. That's the other back door, also being reargued, where SCO is trying to introduce an entirely new theory of the case after discovery ended, via experts reports.
We've been through all of this before at the end of last year. SCO filed a spoliation motion back then, with media fanfare -- remember the Dan Lyons Forbes piece that ended up used as evidence, his interview with SCO lawyer Brent Hatch? (Here's IBM's memo in opposition to that motion, and SCO's reply, if you enjoy repetition.)
When I reread the Lyons reference, I realized that this event is perhaps why SCO came up with the false allegations about IBM feeding me documents and the Kevin Bacon 3-degrees-of-separation-ibiblio story, to defend themselves against the very clear example of one of SCO's lawyers speaking directly to Lyons about the case after Judge Wells told the parties to tone it down. It was, as I recall, Lyons who first brought up the issue of ibiblio and the documents allegation. And then *he* ends up an exhibit. From their standpoint, it maybe didn't feel so right. So they came up with a "you're another" defense. If it causes me some headaches and some expense, who cares about that? Certainly not SCO.
Here's how IBM used that Forbes interview in a discussion as to whether Wells's order was dispositive:
Despite Judge Wells' admonition about discussing this case in the press, SCO is quoted in the press criticizing Judge Wells' decision and discussing its effect. (Ex. 25.) Of particular relevance here, counsel for SCO is quoted in Forbes Magazine — only a week after filing its objections — as stating that, despite the Order, all SCO's claims and damages remain intact:
Hatch concedes the Wells ruling represented a setback for SCO. But he says SCO still has a strong case.
* * *
"If the judge had thrown out the case, that would be a real downer. But the claims are still there. The damages are still there," Hatch says.
(Ex. 12.) If, as SCO says, its claims and damages remain in the case after the Order, then it could not possibly be considered dispositive.
That was in IBM's Memo in Opposition to SCO's Objections to another order SCO didn't like, the Wells June 28, 2006 order. I guess it stung them, and being SCO, they decided to attack IBM unjustly to "even" the score. I'm just the drive-by victim, then, in such a scenario. On the other hand wasn't it Lyons who wrote that corporations should attack bloggers?
BASH BACK. If you get attacked, dig up dirt on
your assailant and feed it to sympathetic bloggers. Discredit him.
ATTACK THE HOST. Find some copyrighted text that
a blogger has lifted from your Web site and
threaten to sue his Internet service provider
under the Digital Millennium Copyright Act. That
may prompt the ISP to shut him down. Or threaten
to drag the host into a defamation suit against
the blogger. The host isn't liable but may skip
the hassle and cut off the blogger's access
anyway. Also:Subpoena the host company, demanding
the blogger's name or Internet address.
SUE THE BLOGGER. If all else fails, you can sue
your attacker for defamation, at the risk of
getting mocked. You will have to chase him for
years to collect damages. Settle for a court
order forcing him to take down his material.
Say, isn't that pretty much what has been happening to me? You think? Except instead of feeding alleged dirt to bloggers, it's been fed to mainstream media. That would seem to indicate that I am precisely the target, I'd have to conclude. Now, if I were SCO, I would call a press conference and tell them there's a conspiracy to unjustly bash me. Well. Actually, I think there is. And on that copyright DMCA "legal" advice from Lyons, I believed Diebold tried that trick and ended up paying $125,000 in damages. You probably don't want to follow legal advice from a journalist on how great it would be to file false accusations. And stop and think in a First Amendment context for a second. Suppose a journalist, say one at Forbes, wrote a piece about, say, HP. HP, let's say, didn't like it, so it hired detectives to try to dig up some dirt on the journalist to feed it to the media and/or threatened Forbes with a DMCA takedown. Starting to see the implications? Don't these people have any respect for the Constitution? The press? Human dignity? Fair play? I could go on, but I think you catch my drift.
Update: It seems Mr. Lyons has abandoned Floating Point, his attack-PJ-and-Groklaw blog, at least on WordPress, as he relates in this Forbes piece:
I've also operated a blog on a third system called WordPress. WordPress is an open-source program, meaning it's created by volunteers and anyone can read, copy and hack at the program's underlying source code. WordPress is free, and it's fairly easy to get started. But it is not so easy to figure out how to use the software. Techie types love WordPress because supposedly you can make it do whatever you want, if you know what you're doing. Which I, um, don't. Even posting photos--which in every other program is a brainless procedure--could be a pain in the neck on WordPress.
There is a help button, but it takes you to an almost impossible to navigate list of frequently asked questions. In frustration I ordered a manual called WordPress 2 Visual QuickStart Guide. But when the book arrived, I just sat there looking at it and then abandoned my WordPress blog.
I'd call that the alibi article, personally. Here's a Declaration of Todd Shaughnessy in support of IBM. And here's the hearing held in January. Man, it's getting so complicated to give you the context nowadays, because SCO is doing everything twice lately. It is losing, and it would rather not, I gather.
If you would like to see a more normal spoliation motion and a judge's explanation of the elements of a successful one, here you go. By normal, I mean somebody actually did something wrong. And here's part of why SCO wants to win this motion, laid out plainly.
What is SCO's purported basis for this motion? It claims the Magistrate Judge misunderstood the facts. She held that whatever evidence was erased is still available in CMVC and RCS, the code change control systems for AIX and Dynix/ptx respectively. Not so, says SCO. We wanted the early *drafts* of Linux code, the stuff that didn't make it into CMVC (Linux code doesn't go into CMVC), and we wanted to know which programmers retained some AIX and Dynix code in their sandboxes, so we could show that the programmers referred to AIX and Dynix when they transitioned to doing Linux code. (Question to SCO: Does Linux code compile in an AIX sandbox?) Yes, my friends, we are back to methods and concepts, which to date are not even in this litigation. But that's another ruling SCO is trying to get reversed. All very serpentine. If SCO had eggs, it could make ham and eggs. If it had ham. Here's what IBM's attorney Todd Shaughnessy told the court at the hearing, as related by one of Groklaw's reporters at the hearing:
Shaugnessy described the IBM (management) meeting in 2003 which preceeded the cited email. IBM was starting a specific project related to Linux on PowerPC on which eight former AIX developers would be working. In that meeting a question was asked if those eight developers still had access to AIX's CMVC (which access would not be needed for the new project). It was determined that they did not, but perhaps they still had AIX sandboxes, but they didn't know. After that meeting, the email was sent.
He said that SCO has not identified any code from that project that was an improper contribution to Linux. SCO has not identified any lines of code from any of these eight developers. These developers were writing new, original, code unrelated to any of SCO's claims. The only AIX code identified as misused is JFS, completely unrelated to these developers' project.
Shaughnessy provided a copy of the deposition of Dr. Frye to Judge Wells and referred to it. He indicates that during his deposition Dr. Frye stated six seperate times that nothing was destroyed. Even SCO's deposition lawyer characterized Dr. Frye's testimony as that nothing was destroyed. He said that SCO has to demonstrate bad faith and SCO's briefs offer nothing to demonstrate it.
Shaughnessy said SCO's original claim in this motion was that IBM destroyed code. We see, and SCO now concedes, none was destroyed. Now SCO's theory is that they don't know what code the developers had access to. If SCO *really* wanted to know what code the developers had, they could have looked up the names of people in the LTC (provided by IBM) turned on the CMVC machine they've had for over two years in their office and see what code they checked out. But they didn't.
SCO's lawyer at that hearing argued pretty much the same thing that SCO argues here, to my eyes, that while source code is available, what SCO wanted was information on who had what code and when:
James replied for SCO and cited Judge Steward, Adams v. Gateway case, that "bad faith is not generally required... in order to find spoliation" (other than bad inference). Here we have an email talking about destruction of evidence, he said. It's clear from the deposition that the instruction was given. James reiterated his opening comments and claimed that CMVC does not provide information on who had what code and when, that it only shows the source code.
SCO argued this back then, but their view is that Wells just didn't understand it properly, so it's once around the mulberry bush again.
I guess you could stretch the "misapprehension of the facts" standard as covering this. They are saying the judge just didn't get it. It's very possible she did, though, that she heard their argument, understood it perfectly, and didn't accept it. Since there is no code in this case tracing to these particular coders in the litigation, what does it have to do with the price of tea in China? And just maybe she noticed that the alleged deed was done back in the spring of 2003, and SCO apparently took no great steps to find the evidence in any way during discovery other than that Frye deposition, and then brought a motion for spoliation instead in 2007. Things that make judges go hmm. SCO does tell a tale of not really knowing about it in full or something. After a while my brain gets tired explaining SCO's thinking. I don't mean that the motion is necessarily hopeless, just that it ought to be, in a just universe.
IBM has told the court that the Linux Technology Center programmers don't use sandboxes, but AIX guys do. That is impossible, SCO argues. They all *must* use sandboxes, although there is no evidence to support that supposition offered. And IBM says they don't. That is the kind of thing that SCO could and should have pursued in discovery, but instead it has its experts opining that most people use sandboxes, as if that proves anything here. That's not evidence to me. If you are going to call someone a liar in a court of law, you do need some evidence. SCO says the special project was for Linux, and they were told to clean out their sandboxes, so they must use them. Um. OK. But they were not LTC programmers. It was a special project for PowerPC. And they were AIX guys who *would* have sandboxes, and that is what they were told to clean out, not Linux sandboxes, and anyway, most of them apparently didn't do it anyhow. So...
Then it argues that the evidence it can't now get is what a programmer on that special project might have retained. So, why didn't SCO just ask them? That is what discovery is for. Well, it did depose one of them, who testified, IBM explained at the hearing, six times that no evidence was destroyed.
One of SCO's experts compares the sandboxes to an auto body shop. Someone steals a car, strips it of various components and then repaints it, puts in new upholstery, etc., and that makes it hard to identify it as the stolen car. I gather AIX and Dynix/ptx are the stolen car, the auto body shop is the sandboxes at IBM, in SCO's mind anyway, and the new upholstered vehicle is Linux. This development fantasy of SCO's is very enduring. So much of this case is about what SCO thinks must somehow be true, like Linux couldn't happen so fast without Unix code or I must be a committeee of IBM lawyers. SCO's methods and concepts ladder theory is like that. Somewhere, in a universe far, far away, it *could* have happened like this. SCO just can't put its finger on it, so it concludes IBM must be at fault somehow.
But if SCO wanted to prove it, why didn't they just depose people, or ask for the computers and do forensics? It's puzzling. And since the only code from IBM in this litigation is JFS, which isn't what the special project guys were working on, the auto body analogy hits the wall and bursts into flames. Maybe you'll read it differently.
I know. SCO hopes its other motions for reconsideration/objections/motions to amend will somehow get all their methods and concepts material into the litigation. I doubt that will happen, so this is all kind of moot. But it must take a special kind of IBM patience to carefully answer each and every SCO allegation, which seem to be like the widow's oil that just kept pouring and pouring, without any apparent limit. It drives me bananas just reading the filings. Imagine having to answer them.
And the ultimate reason why you are not supposed to ask for reconsideration just to get another bite at the apple is because it's not fair. Think about motion practice. You follow the ABA format. SCO files the motion, IBM puts in a memo in opposition, then SCO replies. So if you do a motion for reconsideration that reargues the same points, in effect you have SCO speaking 4 times, and IBM only gets to speak twice. Also after the initial motion is argued, you find out all the arguments the other side presented, and so if you get to reargue the same points, you will do better, of course. It becomes your better version, extended from the original, and that is fundamentally unfair. In fact, SCO does a better job here than in the first motion that was denied. Naturally, it would, and that is no doubt part of the strategy. There is, as usual, no "fair and square" in this picture, not that I can discern, just another throw-it-at-the-wall-and-see-if-it-sticks motion, which requires IBM to go to the time, effort and expense of responding. And as with any motion, you can never totally guarantee that bad things won't happen. I have no doubt that IBM is taking the new cases and arguments seriously, as it must in order to answer it carefully, leaving no stone unturned.
Brent O. Hatch (5715)
Mark F. James (5295)
HATCH, JAMES & DODGE
Stuart H. Singer (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
Robert Silver (admitted pro hac vice)
Edward Normand (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
Stephen N. Zack (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
Attorneys for The ScO Group, Inc.
IN THE UNITED STATES DISTRICT COURT FOR THE DISTRICT OF UTAH
|THE SCO GROUP, INC.
|SCO'S MEMORANDUM IN
SUPPORT OF ITS MOTION FOR
RECONSIDERATION OF THE
ORDER DENYING SCO'S MOTION
FOR RELIEF FOR IBM'S
SPOLIATION OF EVIDENCE
FILED IN REDACTED FORM
[ORIGINALLY FILED UNDER SEAL]
Case No. 2:03CV0294DAK
Honorable Dale A. Kimball
Magistrate Judge Brooke C. Wells
TABLE OF CONTENTS
||RECONSIDERATION IS WARRANTED WHERE THERE IS A
MISAPPREHENSION OF FACTS OR CONTROLLING LAW
||CMVC DOES NOT CONTAIN THE EVIDENCE THAT SCO CONTENDS
||IBM's Representation That Sandboxes Are Only
Used by AIX Developers Is False.
||IBM's Representation That CMVC Contains the Same Evidence As
the Sandboxes Is False.
||SCO's Claims Regarding Evidence Lost in the Sandbox Purge Are
Consistent with Statements Made by SCO When it Moved to Compel
Production of CMVC.
||IBM Has Not Followed Though on The Magistrate Court's
Request to Identify Where in CMVC the Evidence SCO Contends Was
Destroyed Can Be Found.
||SCO HAS SUBMITTED COMPELLING PROOF THAT DESTRUCTION
OF RELEVANT EVIDENCE OCCURRED.
||SCO WAS PREJUDICED BY IBM'S DESTRUCTION OF EVIDENCE.
||SCO SHOWED THAT IBM ACTED IN BAD FAITH
TABLE OF AUTHORITIES
|Adams v. Gateway, Inc.,
2006 WL 2563418 (D. Utah 2006)
|Brown & Williamson Tobacco corp. v. Jacobson,
644 F. Supp. 1240 (N.D. Ill. 1986)
|Brown & Williamson Tobacco Corp. v. Jacobson,
827 F.2d 1119 (7th Cir. 1987)
|Cabinetware, Inc. v. Sullivan,
Civ. S. 90-313, LKK 1991 WL 327959 (E.D. Cal. 1991)
|Computer Associates Int'l, Inc. v. Am. Fundware, Inc.,
133 F.R.D. 166 (D. Colo. 1990)
|Hancock v. City of Oklahoma City,
857 F.2d 1394 (10th Cir. 1998)
|In re Napster, Inc. Copyright Litig.,
462 F. Supp. 2d 1060 (N.D. Cal. 2006)
|Mantle Ranches, Inc., v. U.S. Park Serv.,
950 F. Supp. 299 (D.Colo. 1997)
|Price v. Philpot,
420 F.3d 1158 (10th Cir. 2005)
|Servants of the Paraclete v. Does,
204 F.3d 1005 (10th Cir. 2000)
|United States v. Maxfield,
No. 04CR00149, 2007 WL 121128, at *1
Plaintiff, The SCO Group, Inc. ("SCO"), by and through undersigned
this Memorandum in Support of its Motion for Reconsideration of the
Order Denying SCO's
Motion for Relief for IBM's Spoliation of Evidence.
The Magistrate Court denied SCO's Motion for Relief for IBM's
Spoliation of Evidence
"for the reasons set forth by the Court at the hearing held on January
18, 2007." (March 2, 2007
Order.) At the January 18 hearing, the Magistrate Court said:
I am going to find that based upon the evidence before me,
put into context, reflects that SCO's motion will be denied. It
cannot show that any evidence was lost or destroyed. In fact, I
find that it is available and has been available through CMVC.
The evidence before me, when seen in context, does not show that
IBM acted in bad faith nor does the evidence show that it has been
prejudiced because the evidence, as I indicated, has been and is
reasonably available. So the motion regarding spoliation and the
adverse inference instruction will be denied.
(1/18/07 Hrg. Tr., Ex. 1 at 56:2-11.)
SCO respectfully submits that this decision was based on a
misapprehension of fact and
law, and should be reconsidered on the following grounds:
First, the primary basis for the ruling — that the
evidence SCO contends IBM destroyed
"is available and has been available through CMVC" — is not
correct. IBM's representations at
the January 18 hearing in this regard are false. Neither CMVC (the AIX
change control system
referenced by the Magistrate Court) nor RCS (the Dynix/ptx change
control system) contains the
evidence SCO contends IBM destroyed.1
CMVC and RCS could not possibly show whether that code
had been retained on programmers' systems when they transitioned to
work on Linux, or
what particular subparts or versions of the operating system had
been retained by the
programmer. Furthermore, those systems could not possibly contain drafts
of Linux code.
Second, SCO submitted substantial proof in the form of IBM
executive and programmer
emails and deposition testimony that IBM destroyed relevant evidence,
and that evidence should
be reconsidered now that SCO has shown that the destroyed evidence was
Third, the Court's finding that SCO was not prejudiced was
based on the mistaken
conclusion that the evidence was still available to SCO elsewhere. In
reality, the evidence
destroyed by IBM was not available to SCO in CMVC or RCS. In addition,
destroyed is directly relevant to SCO's claim that IBM's Linux
programmers referred to AIX and
Dynix/ptx code while programming for Linux and to SCO's efforts to
identify the AIX and
Dynix/ptx source code behind IBM's disclosures to Linux, including IBM's
disclosures of methods and concepts.
Fourth, the Court's finding that IBM did not act in bad faith,
for purposes of the adverse
inference instruction requested by SCO, was also based on the mistaken
conclusion that the
evidence was still available to SCO elsewhere. In fact, SCO has shown
that IBM directed that
highly relevant and original evidence be destroyed just a
after the instant lawsuit was
filed. Bad faith must be inferred from this conduct.
I. RECONSIDERATION IS WARRANTED WHERE THERE IS A
MISAPPREHENSION OF FACTS OR CONTROLLING LAW.
Reconsideration is warranted "where the court has misapprehended the
facts, a party's
position, or the controlling law." Servants of the Paraclete v.
204 F.3d 1005, 1012 (10th
Cir. 2000). Neither a change in law nor new evidence is required.
Mantle Ranches, Inc., v.
U.S. Park Serv., 950 F. Supp. 299, 300, 302 (D. Colo. 1997)
(granting in part motion to
reconsider, though no change in law or new evidence existed). A district
court has the discretion
to reconsider any "order short of a final decree." Price v.
Philpot, 420 F.3d 1158,
1167 n.9 (10th
Cir. 2005). The consideration of the merits of a motion for
reconsideration is squarely within
that discretion. See United States v. Maxfield, No.
04CR00149, 2007 WL 121128,
at *1 (Ex. A)
(D. Utah Jan. 11, 2007) (citing Hancock v. City of Oklahoma
857 F.2d 1394,1395 (10th
IBM previously sought relief through a Motion for Reconsideration
before this Court in
similar circumstances (in a February 11, 2005 motion), and such relief
was granted in part (in an
April 20, 2005 order). Accordingly, it is well within the discretion of
the Magistrate Court to
reconsider the denial of SCO's Motion for Relief for IBM's Spoliation of
Evidence on the
grounds raised herein.
II. CMVC AND RCS DO NOT CONTATN THE EVIDENCE THAT SCO
CONTENDS IBM DESTROYED.
Contrary to IBM's representations at the January 18 hearing, the
evidence that SCO
contends IBM destroyed in programmer sandboxes is not available. At the
hearing, IBM made
the following representations to support its contention that, if IBM
Linux Technology Center
("LTC") programmers were in fact instructed to purge their sandboxes
or other computer
workspaces, no evidence was actually destroyed: (1) sandboxes are only
used by AIX
developers, not by IBM's Linux developers; (2) the CMVC system contains
the same evidence
that SCO contends was destroyed in the purging of programmer sandboxes;
and (3) SCO had
previously said CMVC had this evidence. The Magistrate Court ultimately
representations as a core element of the decision, finding that the
evidence SCO contends was
destroyed "is available and has been available through CMVC." Yet, each
of these IBM
representations is false, for the reasons set forth below.
Considering the importance of IBM's representations, moreover, the
directed IBM to assist SCO in identifying in CMVC where the duplicate
evidence could be
found — that is, the evidence lost in the purging of the
IBM has not done
this, and SCO contends that it cannot be done: Neither CMVC nor RCS
contain the evidence
that was destroyed in the purging of the programmer sandboxes. The
following evidence thus
underscores the reasons IBM did not follow up on the request that the
Magistrate Court made.
A. IBM's Representation That Sandboxes Are Only Used by AlX
Sandbox is a term used to describe private computer workspaces in
can draft and test code on which they are working without impacting the
entire system. At the
hearing, IBM made the following representation to the Court: "Sandboxes,
Your Honor, are a
development tool that is used in AIX. They are not used in Linux. They
are not used in the
Linux Technology Center." (Ex. 1 at 37:7-9.) This IBM argument overlooks
the facts that the
instruction was given to Linux programmers to purge their
This instruction would
have made no sense if, as IBM suggests, Linux programmers did not
have or use sandboxes.
Moreover, also contrary to IBM's representation, those sandboxes or
other similar workspaces
would have had to have been used by those programmers to develop
their code for Linux.
Indeed, IBM's representation that its Linux programmers did not use
contradicted by a public interview given by one of IBM's own
programmers. (Ex. 2,
http://kerneltrap.org/comment/rep1y/80 .) IBM programmer William Lee
Irwin III explained that
he had been employed by Sequent and IBM since 2000, and that he worked
on Dynix/ptx, then
AIX, and then Linux. When asked whether he had "any tips for the
aspiring kernel hacker"
(Linux programmer), Mr. Irwin responded:
A more effective approach appears to be creating a
the data is disposable and the system nonessential and running the
code and figuring out what went wrong when the system
(Id.) Directly contrary to IBM's representations, this IBM
Linux programmer shared his
experience on using sandboxes when developing for Linux and
advised others to do
SCO's computer science expert Marc Rochkind has also confirmed that
programmers for Dynix/ptx and Linux, as well as AIX, would have had to
use sandboxes, or
other similar workspaces, to draft, revise and implement computer code
for those systems."
(Declaration of Marc Rochkind dated 3/16/07 ("Rochkind Decl."), ¶
8.) He explains:
[I]t would be incredibly difficult, if not impossible, to
revise computer code without using a separate workspace, such as
a sandbox, in which to implement and test those revisions. It is
essential that all details of a proposed operating feature or patch be
worked out in an environment separate from the online or
copy of the source code. This separate environment, the
programmer workspace, is often called a sandbox.
(Id. ¶ 7.)
SCO's computer science expert Evan Ivie has also confirmed that "IBM
Dynix/ptx and Linux, as well as AIX, used sandboxes, or other similar
programming environments, to draft, revise and implement computer
software for those
systems." He explains:
Any creative process requires an environment and facility
that creative process can take place. An artist creates paintings in
a studio. A woodcarver creates carvings in a woodshop. Artisans,
craftsmen, and skilled workers develop facilities where they can
perfom their work: workbenches, body shops, bakeries, etc.
Programmers are no different.
* * *
If IBM had not adopted and/or developed some type of suitable
environment for their programmers, it would have taken them back
to the late 1950's and early 1960's and would have made
programming an incredibly inefficient and slow process. This
would be like taking a tractor away from a farmer and giving him a
shovel. Even if IBM had tried it, programmers would have
resisted the move.
(Declaration of Dr. Evan Ivie dated 3/16/07, "Ivie Decl.", ¶ 2
¶ 5 respectively.)
Accordingly, IBM's argument that sandboxes are not used in Linux
sense and cannot not somehow amend its instruction to its Linux
programmers to purge
their sandboxes. That instruction would have impacted all IBM
programmers working in
B. IBM's Representation That CMVC Contains the Same Evidence As the
Sandboxes Is False.
At the hearing, IBM further argued that ihe evidence that had been
in the purged
sandboxes was still available to SCO on the CMVC system that IBM had
produced to SCO.
IBM made the following representations at the hearing regarding the CMVC
system it produced
Now [SCO's] premise is, well, we may not have lost source
but what we lost is the ability no figure out which particular
programmers had looked at or had access to which particular AIX
or Dynix source code. That Your Honor, is wrong. SCO has that
information in spades. Precisely as you pointed out that was the
purpose of producing CMVC. If SCO really cared, if SCO really
wanted to know what code a particular developer had on their
machine, it would be a very simple exercise to find out. SCO
could have easily taken the list of individuals we provided of
people who made contributions to AIX and Dynix and compared it
to anyone of the other lists we provided them that identified people
who made Linux contributions or who worked in the LTC and
could have determined if any names were the same. Having
determined that names were the same, SCO could have but chose
not to turn the [CMVC] machine on and look at it. Because had
they done so, they would have been able to figure out exactly what
developer X looked at and when, what was checked out, when it
was checked out, and what developer X did to it.
(Ex. 1 at 45:13-46:8.) IBM further represented that destruction of
evidence in a sandbox was "a
bit like Your Honor having discarded a courtesy copy of a motion you
ruled on a year ago
knowing that Matt has a copy." (Id. at 35:23-25.)
This is simply not accurate. Fundamentally, code on CMVC or RCS is
not a copy of
code in programmer sandboxes. The type of evidence found in CMVC or RCS
different from what would be on a programmer sandbox. While IBM has
contended that a
change management control system, such CMVC or RCS, shows what code had
out" by programmers, those systems could not possibly show whether
that code had been
retained on programmers systems when they transitioned to work on Linux,
or what particular
subparts or versions of the operating system had been retained by
the programmer. The specific
AIX or Dynix/ptx code that a Linux programmer chose to retain on his
programming for Linux would have provided important evidence in that SCO
that particular code to the programmers' Linux disclosures. The fact
that some code the
programmer chose to retain on his system might be duplicated
somewhere on a code repository
entirely misses the point.
SCO's computer science experts Marc Rochkind and Evan Ivie have
impossibility of CMVC or RCS containing the evidence IBM now claims they
[N]either CMVC (as to AIX) nor RCS (as to Dynix/ptx)
would show whether Linux programmers had retained AIX and
Dynix/ptx on their systems when developing code for Linux, and if
so, what parts of the AIX and Dynix/ptx operating systems they
[A] sandbox is the only place where the progression of
code drafts can be viewed. For AIX code, CMVC shows the initial
code that was checked out, and the final code that was checked
back in, but not all the steps in between. The RCS system for
Dynix/ptx provides even fewer details than CMVC. Yet it is these
steps, these intermediate drafts, — saved only on programmers'
sandboxes — that would have been so important to develop further
proof of IBM's copying.
(Rochkind Decl. ¶¶ 12-13.) Similarly, Dr. Ivie explains:
There are several fundamental flaws in the use [of] a
change control system, such as CMVC or RCS, to track a software
development effort. A typical change control system allows a
programmer to "check out" a module, to modify and test it
some unspecified amount of time, and then when satisfied to
"check it back in" to the system. Perhaps this might be compared
to trying to see what is going on in a darkened room with a strobe
light. However, the strobe only illuminates a small part of the
room (the code checked in and out) and the strobe is controlled by
a programmer who may or may not want you to see all that is
going on (visibility only at check-in time).
For example, let us assume that the programmer is
developing a module for Linux, but is basing it on a module that
comes from a contractually-protected operating system owned by
another company. If the only visibility that we have is the module
after it has been appropriately disguised, then tracing the source
becomes much more difficult. Perhaps one could compare this to a
body shop for processing stolen cars. It is much easier to prove
auto theft if one can find the body shop being used. After a paint
job, changes to upholstery, options, accessories, and careful
modification of the engine and body numbers, it is much more
difficult to identify the theft.
(Ivie Decl. ¶¶ 8-9).
Using another analogy, Mr. Rochkind explains that CMVC is like a
library, and the AIX
files in CMVC (or Dynix files in RCS) are like books in a library.
(Rochkind Decl. ¶ 14.) Just
as a library has records of which books have been checked out, when they
were checked out,
who checked the books out, and when they were checked back in, a change
system like CMVC or RCS might have records of which files in AIX or
Dynix/ptx were checked
out, when they were checked out, who checked them out, and when they
were checked back in.
What a library does not record, and could not record,
is what was
done with the books
during the time they were checked out. The records in a library will not
show: whether the pages
of book were copied while the book was checked out; whether the reader
retained pages he
copied from the book he checked out long after checking the book back
in; whether the reader
later used those pages to write another book; or what the progression
of drafts of the readers'
other book looked like, such as whether the first drafts were similar to
the library book he had
copied, and then became progressively dissimilar. (Id. ¶
Similarly, Mr. Rochkind explains, none of this information is
present in CMVC or RCS.
(Id. ¶ 16.) Like a library system, CMVC and RCS do not show
what the programmers
the AIX or Dynix/ptx files on their systems (their "sandboxes") after
they checked them out, or
even after they checked them back into CMVC or RCS. Specifically; CMVC
and RCS do not
show: whether the AIX or Dynix/ptx files were copied or saved to the
after being checked out; whether the programmer retained the copied AIX
or Dynix/ptx files on
his system long after checking the completed files back into CMVC;
whether the programmer
ever referred back to those AIX or Dynix/ptx files when he was
developing for another operating
system, such as Linux; what the progression of drafts of the
programmers' code for the other
operating system, such as Linux, looked like — whether the first
similar to the AIX or
Dynix/ptx files he had copied and retained on his system, and then
dissimilar, until the final version actually bore little resemblance to
the AIX or Dynix/ptx files on
which it had been based; or whether other programmers made use of the
checked-out code by
obtaining it in already-checked-out form from the programmer who
originally checked it out and
saving it to their sandboxes. (Id. ¶ 16).
In contrast, Mr. Rochkind and Dr. Ivie explain, a programmers'
sandbox would show all
of this information. (Id. ¶ 17; Ivie Decl. ¶ 12.)
It would show whether AIX and Dynix/ptx files
were present and available to the programmer as he worked on Linux, and
if so, which particular
code the programmer retained and accessed. It would also show his
drafts of code and the
progression of drafts after that initial draft,
leading to the final version. Plainly, drafts of Linux
code would not be available on CMVC or RCS.
In summary, CMVC and RCS simply would not and could not contain the
would have been available on IBM Linux programmer sandboxes or other
C. SCO's Claims Regarding Evidence Lost in the Sandbox Purge Are
Consistent with Statements Made by SCO When It Moved to Compel
Production of CMVC.
At the January 18 hearing, the issue also arose whether SCO, in
moving to compel IBM
to produce the CMVC system, had previously stated that CMVC contained
the same information
SCO now contends was destroyed in the purging of programmer sandboxes.
Specifically, at the
hearing, the Magistrate Court noted that counsel for SCO had in February
2004 represented that
the CMVC system would enable SCO to "get every version, every iteration
[of AIX]" and that
counsel further stated that a confidential IBM document regarding CMVC
"gives a simplified
description at the bottom saying what it boils down to is that all
levels of all files are
stored on a
central server and are available for updating by those with proper
authority." (Ex. 1 at 29:17-
SCO correctly represented at that February 2004 hearing that CMVC
information that was important to the development of SCO's case as to
IBM's misuse of AIX
technology in Linux. SCO did not represent that such information
was coterminous with the
information SCO now contends IBM destroyed in programmer sandboxes. SCO
contended in 2004 that CMVC or RCS would show which Linux
programmers retained AIX or
Dynix/ptx code on their systems when programming for Linux, or what
particular code they
retained. SCO counsel also plainly never contended in 2004 that
CMVC or RCS would have had
drafts of Linux code. Thus, SCO's prior representations regarding
CMVC or RCS have no
relevance to SCO's contention in the instant motion that the purging of
destroyed relevant evidence.
In connection with this issue, IBM also repeatedly said at the
hearing that SCO must not
have even used the CMVC system that was produced — implying that
SCO would not know
whether it contained the information SCO contends was destroyed in the
purging of programmer
sandboxes. IBM stated that "it appears that SCO has done absolutely
nothing with CMVC," and
"SCO could have but chose not to turn the [CMVC] machine on and look at
it." (Ex. 1 at 34:24-
25 and 46:3-4, respectively.) These statements are baseless. SCO did use
At his deposition, Marc Rochkiid clearly testified: "My analysis of AIX,
as I say in my report,
was based on the CMV — CMVC system that was provided by IBM in the
form of an actual
physical computer, and all of my access to AIX source during the period
when I was preparing
my original report came off of that system." (Ex. 4 at 242:3-8.) Mr.
Rochkind further explained
in his declaration his extensive use of CMVC to identify material
misused by IBM. (Rochkind
Decl. ¶ 3.) Nevertheless, as set forth above, neither CMVC nor RCS
is a substitute for the
evidence that would have been contained in the programmer sandboxes.
D. IBM Has Not Followed Through on the Magistrate Court's
Identify Where in CMVC the Evidence SCO Contends Was Destroyed Can
Considering the representations that IBM made regarding the
availability of evidence on
CMVC, the Magistrate Court asked IBM to assist SCO in locating the
evidence in CMVC that
SCO contends was destroyed by virtue of the instruction to purge
Specifically, the Magistrate Court directed:
The standard I think is reasonably available. I am going
IBM, in the spirit of cooperation, Mr. Shaughnessy, to do what you
can or have others do it to see if you can assist in identifying it.
That doesn't mean that anything is going to change in terms of the
deadlines and the scheduling order cutoffs. But if there is
somebody who readily has that information, I would ask you to
assist in doing that.
(Ex. 1 at 58:ll-18.) Notwithstanding this request by the Magistrate
Court, and the clear
importance of IBM's representations on this regard to the Magistrate
Court's conclusions, IBM
has not taken any steps to assist SCO in identifying in CMVC (or RCS)
the evidence SCO
contends was destroyed. IBM's inaction in this regard speaks volumes
about the very
representations that were so central to the Magistrate Court's
conclusions. Moreover, SCO has
submitted the clear evidence discussed above that plainly rebuts IBM's
and RCS — while useful for many purposes — simply do not
show the particular AIX or
Dynix/ptx files that Linux programmers' systems retained on their
systems after they began
programing for Linux, and do not contain intermediate drafts of Linux
III. SCO HAS SUBMITTED COMPELLING PROOF THAT DESTRUCTION OF
RELEVANT EVIDENCE OCCURRED.
SCO submitted substantial proof in the form of IBM executive and
and deposition testimony that IBM destroyed relevant evidence, and that
evidence should be
fully considered since SCO has established that the destroyed evidence
was not available
Swanberg Email On April 8, 2003 — one month after SCO's
lawsuit was filed and
shortly after the decision to restrict access to AIX and Dynix/ptx
source code had been made —
Randal Swanberg, a senior IBM executive, sent the following email to IBM
managers and team
leaders relaying additional instructions:
Daniel Frye Deposition Testimony: The decision described in
the Swanberg email was
then carried out more broadly within IBM. Daniel Frye instructed Linux
IBM's LTC to "purge" or "delete" AIX and Dynix/ptx source code from
their local machines
and sandboxes. Dan Frye testified:
(Ex. 6 at 92:lO-93:l (emphasis added).) In short, programmers within
the LTC, who had
previously had access to AIX and Dynix/ptx code, and who had had that
access removed, were
then further instructed to purge or delete all such code
from their machines
and to purge and
delete the contents of their sandboxes.
Paul McKenney Testimony: Linux programmer (and former
Paul McKenney confirmed that he deleted Dynix/ptx source code from his
machine in response
to such an instruction. He testified:
In short, Mr.
McKenney confirmed that he followed the directive of the OSSC and Dan
Frye, and deleted code
from his computer following SCO's lawsuit.
IV. SCO WAS PREJUDICED BY IBM'S DESTRUCTION OF EVIDENCE.
The Magistrate Court's finding that SCO was not prejudiced was based
on the mistaken
conclusion that the evidence was still available to SCO. Because SCO has
shown the destroyed
evidence is in fact not available on CMVC or RCS, SCO asks that this
reconsidered. The evidence destroyed by IBM is highly probative to SCO's
claims and its
destruction creates clear prejudice.
The presence of AIX and Dynix/ptx code in the sandboxes of
programmers in IBM's
LTC — at their very fingertips — would have further refuted
IBM's ongoing assertion that its LTC
programmers did not access or rely on Dynix/ptx and AIX source code when
programming code for Linux. Moreover, the particular subparts and
version of the Dynix/ptx or
AIX operating systems that the programmer chose to retain would have
enabled SCO to provide
more specific identification of the AIX or Dynix/ptx code on which the
disclosures was based. Finally, intermediate drafts of Linux code from
the sandboxes would
have most clearly demonstrated the progression of code from the initial
AIX or Dynix/ptx code
on the sandbox to the final code that was ultimately disclosed to Linux.
Mr. Rochkind has
explained this prejudice: "Even by reviewing only the final
contributions of code to Linux, I
identified a significant instance of AIX code in Linux and multiple
instances of Dynix/ptx code
in Linux. The availability of drafts from sandboxes would have shown
whether even more
instances of direct copying existed." (Rochkind Decl. ¶ 18.) Dr.
(Ivie Decl. ¶ 15.)
The prejudice to SCO from this destruction is particularly
severe in light of the fact that
Dynix/ptx methods and concepts improperly disclosed to Linux were
stricken from SCO's case
because SCO was not able to identify the Dynix/ptx source code behind
the methods and
concepts with more specificity. This is because the source code
deleted from Linux programmer
sandboxes would have substantially helped SCO identify the specific
Dynix/ptx source code
behind these methods and concepts. By showing what Dynix/ptx code
IBM Linux programmers
had at their fingertips, the sandboxes or similar workspaces (if they
had not been purged) could
have substantially narrowed the scope of code that SCO had to review to
particular code the progmmmer had in his mind when he disclosed the
method and concept to
Linux. This would have made that process of identification of code
underlying methods and
concepts significantly more practicable. Thus, IBM's destruction of this
sandbox evidence is
particularly prejudicial to SCO in light of the June 28, 2006 Order
striking Dynix/ptx methods
and concepts from SCO's case (affirmed in November 2006, pending a
An excellent example of this (just one example of many) is the IBM
Irwin. SCO identified Mr. Irwin as making improper disclosures to Linux
in Item Numbers 38,
167, 171, 172, 175 of SCO's December 2005 Submission. These items were
all stricken for
insufficient specificity. SCO contends that Mr. Irwin's sandbox would
have facilitated the
identification ofthe Dynix/ptx code behind the methods and concepts he
disclosed — the very
information SCO was sanctioned for not providing.
SCO has identified numerous other former Dynix/ptx programmers whom
transferred to the LTC to program for Linux, and who, SCO contends,
methods and concepts to Linux.6
Like Mr. Irwin, each of these programmers would likely have
used sandboxes, or similar workspaces, in developing Linux. These
sandboxes or workspaces
would have confirmed (had they not been purged) whether these
programmers maintained access
to old Dynix/ptx code (as their emails and other comments suggested they
did) and which parts
of Dynix/ptx they retained. The sandboxes also would have contained the
drafts of these
programmers' code disclosures to Linux, from which copying could more
directly be proven.
Accordingly, the evidence destroyed in the purging of the sandboxes
is highly relevant to
SCO's claims. The importance of the initial source code from which later
drafts were developed,
and the prejudice flowing from its destruction, was recognized in a
similar case involving
copyright infringement. In Cabinetware, Inc. v. Sullivan, No.
Civ. S. 90-313 LKK 1991, WL
327959 (E.D. Cal. 1991) (Ex. B), the defendant destroyed source code
after receiving a
document request for such code. The magistrate judge found that
"computer programs can be
easily modified to disguise the copying of source codes and that a
comparison of [the
defendant's] initial source code with [the plaintiff's] source code is
of critical importance in this
case." Id. at *2. Therefore, the magistrate judge recommended
that an adverse instruction be
given. The district court agreed that the evidence that was destroyed
was "essential to plaintiff's
case" of copyright infringement, and entered a default judgment on
the issue of liability against
the defendant. Id. at *2, 4. As in the Cabinetware case,
the code in IBM Linux programmers'
sandboxes was important to SCO's case, because computer programs can so
"easily be modified
to disguise the copying of source codes."
V. SCO SHOWED THAT IBM ACTED IN BAD FAITH.
SCO also seeks reconsideration of the decision that SCO did not show
that IBM acted in
bad faith. Bad faith can and should be inferred from the circumstances
directive to purge programmer sandboxes or workspaces. As IBM became
involved in Linux,
IBM repeatedly and publicly boasted that its experience in and
disclosures from AIX and
Dynix/ptx was the critical difference in evolving Linux from a hobbyist
system to a
commercially-hardening operating system. For example, in an interview
with Linux Magazine
about the state of the Linux kernel in 2001, IBM programmer Patricia
Gaughen stated that Linux
another example, Dan Frye, the Director of the LTC, confirmed in an
interview with the
Consulting Times that the LTC "wanted skills from across IBM, and
we have people from AIX,
and OS2 . . . and PTX, and Research and so on." (Consulting Times,
Inside IBM — Dan Frye and
the Linux Technology Center, Ex. 9.) Frye also discussed the porting
of IBM's proprietary
technology to Linux, stating "[IBM] just add[s] arms and legs and skills
to make [projects within
Linux] go faster." (Id.)
When SCO realized that IBM was improperly using these Unix-derived
works in Linux,
SCO confronted IBM regarding the problem without success, and then filed
the instant lawsuit
against IBM on March 6, 2003. SCO's initial complaint against IBM made
clear that the,
conduct of the LTC in making disclosures to Linux development was at the
heart of the lawsuit.
IBM's destruction of evidence then ensued as a direct response to
the lawsuit. After SCO
filed its lawsuit, IBM immediately determined that access by its Linux
programmers to AIX and
Dynix/ptx code should be removed. This shows that there was no confusion
on IBM's part as to
the significance of the AIX and Dynix/ptx code to which its Linux
programmers had access and
the nature of the problem alleged by SCO in its complaint. However, IBM
did not stop there.
IBM's OSSC then decided that Linux programmers whose access had been
removed should also
"purge" their sandboxes or similar workspaces. That OSSC decision was
then implemented in
IBM's Linux Technology Center — the very organization within IBM
that was tasked with
developing the code for Linux that was at issue in SCO's lawsuit.
This rapid succession of events from SCO's lawsuit to the destruction
of the sandbox
evidence necessarily creates an inference of bad faith. IBM cannot
reasonably contend that its
destruction of evidence was accidental or coincidental. Rather, the
destruction was an
intentional act taken in response to the filing of SCO's lawsuit. This
establishes willfulness and
bad faith. Furthermore, IBM spent the next two years after the lawsuit
resisting efforts of SCO
to obtain access to the code repository systems CMVC and RCS that it now
claims absolve it of
any culpability for destroying evidence in 2003.
At the January hearing IBM argued that SCO has not satisfied the bad
because "SCO has not come forward with a shred of evidence that any
member of the LTC, or
Mr. Swanberg, ever entertained the thought that what they were doing by
making this very
simple request was destroying evidence." But this argument goes far
beyond what the law
requires of SCO to show bad faith. Bad faith can be clearly inferred
evidence. Adams v. Gateway. Inc., No. 2:02-CV-106 TS, 2006 WL
2563418, at *3 (D. Utah
2006) (Ex. C). In parlicular, courts have found the timing of the
destruction of evidence —
whether evidence is destroyed after notice that it could be relevant in
probative to bad
faith. See. e.g., In re Napster. Inc. Copyright Litig., 462 F.
Supp. 2d 1060, 1070,
Cal. 2006) (finding duty to maintain and not destroy relevant email and
other documents after
notice of litigation, and that destruction after notice of litigation is
relevant to determination of
willfulness or bad faith); Computer Associates Int'l. Inc. v. Am.
133 F.R.D. 166,
169-70 (D. Colo. 1990) (finding deletion of source code by computer
program developer in
copyright action merited spoliation sanction of default because timing
of destruction after notice
of litigation); Brown & Williamson Tobacco Corp. v. Jacobson, 644
F. Supp. 1240, 1248-49
(N.D. Ill. 1986) (noting under a totality of the circumstances analysis
that selective destruction
after notice that a lawsuit is pending may serve as basis for finding
bad faith spoliation);
Brown & Williamson Tobacco Corp. v. Jacobson, 827 F.2d 1119,
1134-35 (7th Cir. 1987)
(affirming jury finding in trial court on same).
The decision in Computer Associates International. Inc. v.
American Fundware. Inc., 133
F.R.D. 166, 169-70 (D. Colo. 1990), is particularly instructive. In that
Associates ("CA") alleged that the defendant, American Fundware ("AF"),
improperly copied its
software in violation of their agreement. As in the SCO case, CA brought
these issues to AF's
attention and, when a resolution could not be reached, filed suit
against AF. Id. at 168. Before
that time, AF had been destroying all previous versions of the software
at issue, other than the
current version, and AF continued this practice after the litigation had
commenced. Id. CA
moved for sanctions based on this spoliation of evidence. The court
imposed a default judgment
on AF for its destruction — even though the court found that the
practice of deleting
"is commonly followed in the industry, for legitimate reasons, and is
not inherently wrongful."
Id. The Court persuasively explained: "It is inconceivable
that after the October 1986
[pre-litigation] meeting, AF did not realize that the software in its
possession would be sought
through discovery. Certainly commencement of the action settles any
Id. at 169
(emphasis added). Therefore, the court concluded that the destruction
was willful and in bad
faith, and that the destruction of source code, the "best evidence" of
copying, inflicted "the
ultimate prejudice." Id. at 170. In this case —
where IBM actually undertook the destruction of
evidence in response to the litigation and with clear notice that the
evidence would be relevant to
SCO's claims — bad faith should be inferred.
Based on the foregoing, SCO respectfully requests that the Magistrate
the March 2, 2007 Order, and grant the relief requested by SCO.
DATED this 16th day of March, 2007.
HATCH, JAMES & DODGE, P.C.
Brent 0. Hatch
Mark F. James
BOIES, SCHILLER & FLEXNER LLP
Stuart H. Singer
Stephen N. Zack
CERTIFICATE OF SERVICE
Plaintiff/Counterclaim-Defendant, The SCO Group, Inc., hereby
certifies that a true and
correct copy of the foregoing REDACTED SCO'S MEMORANDUM IN SUPPORT
MOTION FOR RECONSIDERATION OF THE MARCH 2, 2007 ORDER DENYING
SCO'S MOTION FOR RELIEF FOR IBM'S SPOLIATION OF EVIDENCE was
Defendant/Counterclaim-Plaintiff, International Business Machines
Corporation, on this
of March, 2007, via CM/ECF to the following:
David Marriott, Esq. ([Email])
Cravath, Swaine & Moore LLP
Todd Shaughnessy, Esq. ([Email])
Snell & Wilmer LLP
The Magistrate Court only referenced CMVC, which is an AIX code
repository. CMVC does not
contain any Dynix/ptx code, so could not possibly have contained
duplicates of any
Dynix/ptx code that SCO contends was destroyed. Therefore, SCO also
IBM's anticipated argument that any destroyed Dynix/ptx code would have
on the Dynix/ptx change control system, RCS, comparable to AIX's CMVC.
This same IBM programmer was identified in SCO's December 2005
Submission as a significant
contributor of misused material to Linux.
The hearing referenced was a February 6, 2004 hearing. (Ex. 3 at
The Read Copy Update (or RCU) technology is one of the major items of
Dynix/ptx technology SCO
contends was improperly disclosed by IBM.
This is remarkable testimony since Mr. McKenney was, at this time, a
Linux programmer and not a
The group includes: Dipankar Sarma, Paul McKenney, Jack Vogel,
Michael Hohnbaum, Gerrit Huizenga, Patricia Gaughen, Martin Bligh,
Suparna Bhattacharya, Badari
Pulavarty, Hanna Linder, Tim Wright, James Cleverdon, and Dave Hansen.