The whole point of Magistrate Judge Brooke Wells' order was that there was no proof before her that there was any evidence lost or destroyed by IBM, as she expressed it [PDF] at the hearing on SCO's motion on January 18th:

I am going to find that based upon the evidence before me, as it's 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.

SCO would like to change her mind, and Ivie's job is to support the idea that the materials IBM deleted were vital to his task of parsing out IBM's evil-doing.

IBM told the court that their Linux programmers don't use sandboxes for Linux development. Ivie says he thinks they do. He presents no evidence of that, but he presents his supposition that they must, because in his mind developing without a sandbox would be "like taking a tractor away from a farmer and giving him a shovel." He also states that "any sizable software development effort requires the use of a change/version management and control system", and from his extravagant description of what a sandbox can do, they are certainly more useful than any CMVC-type of system. According to Ivie, every programmer's squiggle, doodle or false start is carefully preserved to time indefinite in those sandboxes where programmers play with their code. If you look at the sandbox, you could trace every move they've ever made. Isn't that exactly how it is with your sandboxes?

Snort.

Look. We have all played in sandboxes as kids. We built castles one day, then knocked them down the next to build a fort, with the same sand. Or if the castle wasn't quite what we imagined it would be, and we didn't like it, what did we do? We immediately knocked it down and started over. That is what a sandbox is, a transitory play area where resources are used and then reused. Programmers use a sandbox to try things out and test things and then if it works, it gets added to the code base. If it doesn't work, you erase and try again. But either way, *it doesn't stay there*. To trace all the versions, just look at the CMVC or whatever system the working code goes into. That is where all the versions of the code will be found.

Here's what else he doesn't factor in, beyond the simple truth that sandboxes get cleaned out regularly to make room for further development and the obvious fact that no one needs to preserve code that didn't work out or that has been put into a CMVC type of system for preservation. Linux is different. It isn't developed like AIX or Dynix or Vista. Thank heaven. It's developed by many individual volunteers from all over the world and it just happens that IBM doesn't own or control Linux or host the main development process. Linux is not Unix, SCO fantasies to the contrary. It isn't controlled by any vendors. Not that they wouldn't love it. AIX code goes into CMVC, with check in and out notations, but Linux code doesn't and what was erased wasn't Linux code in any case, so whatever Mr. Ivie is looking for can be found there in CMVC. That is because IBM controls that code, SCO contract theories notwithstanding. But Linus controls Linux, not IBM. Might that give us a clue?

Linux is revolutionary in its development method, which is maybe why SCO claimed, falsely, back in 2003 that it wasn't possible to control what went into it. Now, their expert would like us to believe that IBM *must* be able to control every passing byte its Linux programmers so much as think about. It *must be* possible to control it, IBM *must* actually control it, and so IBM must be lying, implies this expert. And since he can't find evidence sufficient to support that statement the way he wanted to, therefore, they must have deleted the evidence that would have proven their guilt. Ivie imagines scenarios that in his mind *could* happen that *could* result in copying and opines how valuable it would be if he could have had access to the sandboxes that IBM has already said it didn't use that Ivie assures the judge they must have used.

That is what Judge Wells "misapprehended". She goofed by not hopping on to SCO's Magical Mystery Tour Bus so they could take her for a ride. So there you are. The shifting sands of SCO. Ah. Now there's an appropriate saying.

Did you know you could be sued over thin air? Over some paid expert's mere suppositions of what could have or might have happened based on his ideas of what most folks probably do? And may I ask the obvious? If this was SCO's theory, when it first heard years ago that some computers had been cleaned out, why didn't it ask to forensically examine those computers? Or at least depose the folks that used the computers in question? Maybe because this is all silly?

After all these years of what felt like interminable discovery, and SCO telling the court that if it could gain access to CMVC it could find the allegedly infringing code, and getting access to all that code, this is what SCO's expert puts on the judge's table. Litigation by supposition, by imagined wrongdoing. Who needs evidence? It must be so, and therefore it is. If there is no evidence, it must have been erased. Off with their heads. This wouldn't even work in a kangaroo court. Well. I guess it could there, but in the US legal system, you are supposed to provide actual evidence. The idea is that you can only get in trouble for what you actually did. What a concept.

SCO, in my opinion, misrepresents Ivie's Declaration when it writes this in its Memorandum in Support of its Motion for Reconsideration:

SCO's computer science expert Evan Ivie has also confirmed that "IBM programmers for Dynix/ptx and Linux, as well as AIX, used sandboxes, or other similar workspaces or programming environments, to draft, revise and implement computer software for those systems.

Is that true? Compare that characterization with what he actually said:

4. Thus, contrary to IBM counsel’s representation, I believe that IBM programmers for Dynix/ptx and Linux, as well as AIX, used sandboxes, or other similar workspaces or programming environments, to draft, revise and implement computer software for those systems.

The first, SCO's version, makes it sound like a fact in evidence. The actual quotation is a speculation. And that, in a nutshell, is precisely what is wrong with this Declaration.

Some of us are not programmers, including me, so I thought it would be worthwhile to ask one what he thinks of Ivie's suppositions, so I contacted a guy with some 35 years' experience as a programmer and I asked if what Dr. Ivie states as being the one and only way to program is in fact an accurate portrayal. He disagrees with Dr. Ivie, telling me that "there are many methods for accomplishing development tasks that are not as Dr. Ivie portrays them but are not a reversion to 1950-1960 development styles." He says he always feels free to delete false starts or earlier versions, to free up resources for further development, so if you took a look at his workspaces, you wouldn't find anything other than what you'd find in the source code control systems he used. For that reason, he tells me, looking at the finished product would be at least as useful, and actually more so, than looking at the workspace.

I've put his remarks^* after SCO's filing, in a second annotated version. His comments are indented and in blue text. Feel free to add your thoughts and experiences, those of you who are also programmers. But the bottom line is, he fully contradicts Dr. Ivie's suppositions.

I want to apologize for all the down time over the weekend. Yes, more hardware troubles. I think we have a solution coming soon, but for the moment, things are rather delicate, so bear with us, please.

UPDATE:

I have the text of the January 18th hearing^** on SCO's original motion regarding spoliation done. The hearing is the first exhibit attached by SCO to this motion [PDF] asking for reconsideration. I think it really helps to understand the entire matter more clearly. Until now, we had our eyewitness reports, but this is the exact transcript. There were two motions heard that day, and I'll post the entire transcript at some point, but I didn't want you to have to wait for this part of it, so I'll put this at the very end, after a double row of stars. As usual, we present it as is, and in this case the transcript repeatedly spells Linux as Lunux and spoliation as spoilation, so don't let it bug you.

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

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

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

Devan V. Padmanabhan (admitted pro hac vice)
DORSEY & WHITNEY LLP
[address, phone, fax]

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

Stuart Singer (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER 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,

v.

INTERNATIONAL BUSINESS
MACHINES CORPORATION,

Defendant/Counterclaim-Plaintiff.

___________________________

DECLARATION OF EVAN IVIE IN
SUPPORT OF SCO’S MOTION FOR
RECONSIDERATION BY THE
MAGISTRATE COURT OF THE
ORDER DENYING SCO’S MOTION
FOR RELIEF FOR IBM’S SPOLIATION OF EVIDENCE

Case No. 2:03CV-0294DAK

Honorable Dale A. Kimball
Magistrate Judge Brooke C. Wells

Programming Environments (e.g. Sandboxes) Were Used by IBM Linux and Dynix/ptx Programmers

2. I understand that counsel for IBM represented that sandboxes were not used for Linux development. Any creative process requires an environment and facility where 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 perform their work: workbenches, body shops, bakeries, etc. Programmers are no different.

3. At Bell Labs I decided to use Ken Thompson’s newly developed Unix operating system as the basis for a Programmer’s Workbench (PWB), a facility where programmers could create software. Unix was an ideal environment for such work when enhanced with the set of tools that we developed. Within Bell Labs, and at a number of other companies, the PWB became the standard environment for software development at that time. Whether you call this workspace a programmer’s workbench, a sandbox, or some other name, it is essential to the software development process. IBM has used the term “sandbox” in a number of depositions and other documents.

2

5. 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.

Information in Programming Environments (e.g. Sandboxes)

6. An adequate programming environment provides a place where all of the basic functions involved in software development can be performed. This includes the storage space to keep code, data, documents, and other information. It also includes suitable tools to perform the functions needed to create a software system. Below is a list of some of the activities performed in a programming environment or sandbox:

• the creation of design documentation specifying the functionality of each module, routine, subsystem, etc.;

• the definition of interfaces between software entities including arguments, parameters, flags, sequencing, etc.;

• the specification of structures, file formats, databases, constants, variables, etc.;

• the approach to be used in the testing each function, subroutine and module; • the plan for subsystem and system level testing;

• the specific tests to be undertaken, the test scenarios, the test data, etc.;

• the capability to perform such tests in the context of the total system;

3

• the creation of code modules, the compiling of that code, and the linking of it together;

• the reasoning, behind algorithms and the motivation behind the various designs;

• all of this documentation for each software entity at each level of abstraction; and

• suitable backup to protect the system and so that when programmers hit a roadblock the system can be rolled back to an earlier state and development can begin again there.

7. In addition to the sandbox or programming environment functionalities enumerated above, any sizable software development effort requires the use of a change/version management and control system. The SCCS system developed by Marc Rochkind is the granddaddy of such systems. Other such systems involved in this case include CMVC, RCS, CVS, and bitkeeper. ¹² A source code control system is one good source of information when trying to track a software development effort, and I did a number of searches of revision control information in these systems. One example of my use of this information is found paragraph 98 of my expert report where I note that a CMVC entry admits that JFS is based on System V Unix.

CMVC and Other Such Systems Are Not a Substitute for Programming Environment Information

8. There are several fundamental flaws in the use 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 for some unspecified

4

9. 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.

10. It should be noted that a developer’s computer can hold more than one sandbox. They could be different versions of the same project, or they could be different projects. Take for example a computer with both an AIX and Linux sandbox. This creates the capability for a programmer to copy code from one sandbox (that had been checked out from the change control system) and use it in developing code for another sandbox.

11. Another specific example of valuable information that would have been in a programming environment or sandbox, but not in a change control system such as CMVC or RCS, is the timing of access to code files. Most computers, including Unix and Windows,

5

12. The claim that SCO did not need access to the programming environment/sandbox information because the code was available in CMVC (or RCS) ignores the following basic problems:

• CMVC and RCS would not show whether code from AIX and Dynix/ptx was copied, retained, and used by IBM Linux programmers in the development of IBM contributions to Linux, or what particular code was copied, retained, and used.

• A programming environment or sandbox is the only place where the progression of code drafts can be viewed, from the initial version to subsequent versions. 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. RCS, the system on which Dynix/ptx code is saved, shows even less. These intermediate drafts, – saved only on programmers’ sandboxes or similar workspaces –would have been important to develop further proof of IBM’s copying.

Importance of Programming Environment Information to SCO/ IBM Case

13. Despite the loss of programming environment and sandbox information through the destruction initiated by IBM management, we were able to find numerous cases where code from Dynix/ptx and AIX found its way into IBM’s disclosures to Linux. This effort would have been significantly easier if the evidence in programming environments and sandboxes had not been destroyed.

6

15. If I had access to drafts of programmers’ Linux code from programming environments and sandboxes that also contained AIX or Dynix/ptx code, I could have identified even more specifically the copying that occurred.

7

Signed this 16th day of March 2007 at Nauvoo, Illinois.

[ signature ]

Dr. Evan Ivie

¹ “What is your preferred revision control system, http://www.perlmonks.org/?displaytype=print;node_id=394350;replies=1

² “ List of Revision Control Software, http://en.wikipedia.org/wiki/List_of_revision_control_software

³ "Unix records three file times in the inode, these are referred to as ctime, mtime, and atime. The ctime field refers to the time the inode was last changed, mtime refers to the last modification time of the file, and atime refers to the time the file was last accessed." http://userpages.umbc.edu/~jack/ifsm498/filesystem.html

8

CERTIFICATE OF SERVICE

Plaintiff/Counterclaim-Defendant, The SCO Group, Inc., hereby certifies that a true and correct copy of the foregoing was served on Defendant/Counterclaim-Plaintiff, International Business Machines Corporation, on this 20th day of March 2007, via CM/ECF to the following:

David Marriott, Esq. [email]
Cravath, Swaine & Moore LLP
[address]

Todd Shaughnessy, Esq. [email]
Snell & Wilmer LLP

/s/ Edward Normand

9

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

This is the version^* with comments by Groklaw's MumbleGrumble in blue text, with the headers and footnotes left out for simplicity:

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

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

Devan V. Padmanabhan (admitted pro hac vice)
DORSEY & WHITNEY LLP
[address, phone, fax]

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

Stuart Singer (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER 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,

v.

INTERNATIONAL BUSINESS
MACHINES CORPORATION,

Defendant/Counterclaim-Plaintiff.

___________________________

DECLARATION OF EVAN IVIE IN
SUPPORT OF SCO’S MOTION FOR
RECONSIDERATION BY THE
MAGISTRATE COURT OF THE
ORDER DENYING SCO’S MOTION
FOR RELIEF FOR IBM’S SPOLIATION OF EVIDENCE

Case No. 2:03CV-0294DAK

Honorable Dale A. Kimball
Magistrate Judge Brooke C. Wells

Programming Environments (e.g. Sandboxes) Were Used by IBM Linux and Dynix/ptx Programmers

2. I understand that counsel for IBM represented that sandboxes were not used for Linux development. Any creative process requires an environment and facility where 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 perform their work: workbenches, body shops, bakeries, etc. Programmers are no different.

3. At Bell Labs I decided to use Ken Thompson’s newly developed Unix operating system as the basis for a Programmer’s Workbench (PWB), a facility where programmers could create software. Unix was an ideal environment for such work when enhanced with the set of tools that we developed. Within Bell Labs, and at a number of other companies, the PWB became the standard environment for software development at that time. Whether you call this workspace a programmer’s workbench, a sandbox, or some other name, it is essential to the software development process. IBM has used the term “sandbox” in a number of depositions and other documents.

2

5. 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.

Item 5 draws conclusions without supporting evidence. First, as I point out below there are many methods for accomplishing development tasks that are not as Dr. Ivie portrays them but are not a reversion to 1950-1960 development styles. Second, I would not venture a guess as to what IBM developers would resist or not resist as I was not there at the time. Was Dr. Ivie?

Information in Programming Environments (e.g. Sandboxes)

6. An adequate programming environment provides a place where all of the basic functions involved in software development can be performed. This includes the storage space to keep code, data, documents, and other information. It also includes suitable tools to perform the functions needed to create a software system. Below is a list of some of the activities performed in a programming environment or sandbox:

• the creation of design documentation specifying the functionality of each module, routine, subsystem, etc.;

• the definition of interfaces between software entities including arguments, parameters, flags, sequencing, etc.;

• the specification of structures, file formats, databases, constants, variables, etc.;

• the approach to be used in the testing each function, subroutine and module; • the plan for subsystem and system level testing;

• the specific tests to be undertaken, the test scenarios, the test data, etc.;

• the capability to perform such tests in the context of the total system;

3

• the creation of code modules, the compiling of that code, and the linking of it together;

• the reasoning, behind algorithms and the motivation behind the various designs;

• all of this documentation for each software entity at each level of abstraction; and

• suitable backup to protect the system and so that when programmers hit a roadblock the system can be rolled back to an earlier state and development can begin again there.

There are many assumptions made in paragraph 6 that are not necessarily true. The developer’s workspace does not always contain:

1) Design documents.
2) The approach used for unit testing.
3) The subsystem and system level test plans.
4) The testing results.
5) The documentation for the use of the code.

Indeed, in many organizations I have worked for over the last 35 years:

1) Design documents (including requirements, functional specifications and detailed designs) have been written by people different that the actual code developer and stored in document control and database systems that were wholly separate from the source code control and product build systems.

2) In my experience it is a very good idea for a different person than the code developer to write the test plan and the unit test code (if unit test code is required at all; some development does not require it.) This tends to insure more complete test coverage and often points out missing elements in the developer’s thinking.

3) Usually subsystem and system level test plans are written by people who are NOT the developers of the code. The reasons given immediately above apply here also but so does the fact that subsystem and system level testing must incorporate thinking and information about the entire subsystem and/or system which is often not available to the individual developers during their development cycle. Indeed, the entire subsystem and/or system code may not be available to the individual developers as it may not all be complete at the same time. Code may also come from several physically diverse locations and require an integration team to put the various pieces together (including third party software) prior to its being ready for subsystem and/or system level testing.

4) Documentation may be developed by an information development team which, of course, might have its own development tools, workspaces, documentation control and delivery systems.

7. In addition to the sandbox or programming environment functionalities enumerated above, any sizable software development effort requires the use of a change/version management and control system. The SCCS system developed by Marc Rochkind is the granddaddy of such systems. Other such systems involved in this case include CMVC, RCS, CVS, and bitkeeper. ¹² A source code control system is one good source of information when trying to track a software development effort, and I did a number of searches of revision control information in these systems. One example of my use of this information is found paragraph 98 of my expert report where I note that a CMVC entry admits that JFS is based on System V Unix.

CMVC and Other Such Systems Are Not a Substitute for Programming Environment Information

In my experience the source control system is likely to be the most complete repository of the code development history. The workspaces I have used rarely, if ever, had a history of the various code changes I made with each edit. However, I often checked the code back into the source code control system prior to completion to insure that, should some thing happen to me or the computer on which my workspace was resident, the code would not be lost.

In addition, I have always felt free to delete from my workspaces files containing “false starts” and/or files that I may have modeled my new code after. Examining my workspaces long after my projects were complete would rarely, if ever, provide more information that examining the code I delivered in the source code control systems I used. Indeed, examining the delivered product would be far more useful than examining my workspaces.

Finally, I have always felt free to delete the entire workspace once I delivered the code and it was integrated into the product. Since workspaces consume vital computer system resources it has often been necessary to delete old workspaces to free up those resources for further development.

8. There are several fundamental flaws in the use 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 for some unspecified

4

9. 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.

10. It should be noted that a developer’s computer can hold more than one sandbox. They could be different versions of the same project, or they could be different projects. Take for example a computer with both an AIX and Linux sandbox. This creates the capability for a programmer to copy code from one sandbox (that had been checked out from the change control system) and use it in developing code for another sandbox.

11. Another specific example of valuable information that would have been in a programming environment or sandbox, but not in a change control system such as CMVC or RCS, is the timing of access to code files. Most computers, including Unix and Windows,

5

Assuming that the developer did not delete the files from their work space and did not touch them in some way that would alter the times, this might be true. However, I fail to see how this information would be of more use than the code checked into the source code control system. This item appears to me to be a “red herring”. Does anyone else see something I have missed?

Also, as mentioned above, by the time the code makes it to a field release of the product, I have almost always deleted my workspace to recover the resources so all the information listed above would be lost.

12. The claim that SCO did not need access to the programming environment/sandbox information because the code was available in CMVC (or RCS) ignores the following basic problems:

• CMVC and RCS would not show whether code from AIX and Dynix/ptx was copied, retained, and used by IBM Linux programmers in the development of IBM contributions to Linux, or what particular code was copied, retained, and used.

• A programming environment or sandbox is the only place where the progression of code drafts can be viewed, from the initial version to subsequent versions. 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. RCS, the system on which Dynix/ptx code is saved, shows even less. These intermediate drafts, – saved only on programmers’ sandboxes or similar workspaces –would have been important to develop further proof of IBM’s copying.

As I believe I have made clear there are conclusions drawn in item 12 that are based on supposition of what might have been in the workspaces and not based on known facts. Certainly, in workspaces I have used for development, the information would have never been available.

Importance of Programming Environment Information to SCO/ IBM Case

13. Despite the loss of programming environment and sandbox information through the destruction initiated by IBM management, we were able to find numerous cases where code from Dynix/ptx and AIX found its way into IBM’s disclosures to Linux. This effort would have been significantly easier if the evidence in programming environments and sandboxes had not been destroyed.

6

15. If I had access to drafts of programmers’ Linux code from programming environments and sandboxes that also contained AIX or Dynix/ptx code, I could have identified even more specifically the copying that occurred.

I am no legal expert but 13, 14 and 15 appear to be conclusion based of what might have been in the workspaces and not based on known fact.

7

Signed this 16th day of March 2007 at Nauvoo, Illinois.

[ signature ]

Dr. Evan Ivie

¹ “What is your preferred revision control system, http://www.perlmonks.org/?displaytype=print;node_id=394350;replies=1

² “ List of Revision Control Software, http://en.wikipedia.org/wiki/List_of_revision_control_software

³ "Unix records three file times in the inode, these are referred to as ctime, mtime, and atime. The ctime field refers to the time the inode was last changed, mtime refers to the last modification time of the file, and atime refers to the time the file was last accessed." http://userpages.umbc.edu/~jack/ifsm498/filesystem.html

8

CERTIFICATE OF SERVICE

Plaintiff/Counterclaim-Defendant, The SCO Group, Inc., hereby certifies that a true and correct copy of the foregoing was served on Defendant/Counterclaim-Plaintiff, International Business Machines Corporation, on this 20th day of March 2007, via CM/ECF to the following:

David Marriott, Esq. [email]
Cravath, Swaine & Moore LLP
[address]

Todd Shaughnessy, Esq. [email]
Snell & Wilmer LLP

/s/ Edward Normand

9

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

Before the Honorable Brooke Wells

January 19, 2007

Motion Hearing^**

[beginning with page 16]

Court: Let's go on to the second motion now, which is SCO's motion related to spoliation.

MR. JAMES: Good morning again, Your Honor. I will try and be as brief as possible and then maybe take a few minutes on reply, if that's okay with Your Honor.

THE COURT: I've always let everybody reply.

MR. JAMES: I am aware of that and I appreciate that. Thank you.

As Your Honor indicated, this is SCO's motion for relief for what SCO believes spoliation of evidence has occurred in this case. SCO initially initiated this action, Your Honor, in March of 2003. Prior to that time, SCO has had a number of discussions with IBM regarding the subject matter of its complaints and ultimately SCO initiated the litigation.

About a month later, April 8th, 2003, Randy Swanberg, an IBM representative, sent an e-mail that was addressed to eight different individuals. The e-mail has been marked confidential in the litigation. It's been provided to Your Honor. I won't quote from it in open court. However, as Your Honor will note, the e-mail was explicit. It instructed the

16

THE COURT: What is the exhibit number again?

MR. JAMES: It's G to the opening memorandum of SCO. And I think, Your Honor, it's indisputable that the instruction that was issued was for the destruction of evidence that is relevant to this case. IBM does not contend that the evidence that is addressed by the e-mail is not otherwise relevant.

Central to several of SCO's claims, in fact, in this case is SCO's allegation that IBM made contributions to Lunux development of source code, methods and concepts in violation of IBM's contractual obligations and other obligations to SCO.

The Tenth Circuit has made very clear that a litigant has a duty to preserve evidence that he knows or should know is relevant to imminent or ongoing litigation, and it made that statement in the Jordan F. Miller Corporation v. American Eagle Insurance case in 1998.

The United States Supreme Court even has recognized the spoilation sanctions may be imposed as part of the inherent power of a district court, and that is a legal principle that federal courts, including the Tenth Circuit, uniformly recognize.

In the Jordan Miller case, the Tenth Circuit stated, as a general rule, the bad faith destruction of a document relevant to proof of an issue at trial can give rise to an inference that production of the document would have been unfavorable to the party responsible for its destruction. Judge Stewart indicated in the Adams v. Gateway case in this district that bad faith can be inferred from

17

The Tenth Circuit, and this district as well, has indicated the bad faith is not required when spoilation has occurred in order to impose a sanctions -- an imposition of sanctions other than for the negative inference. And so while bad faith is required for a negative inference, a spoilation sanction is not required for any other type of spoilation sanction.

THE COURT: Okay. We're presuming something here, and we're presuming destruction.

MR. JAMES: We are, and I'm going to talk about that, Your Honor, here in a minute as part of the presentation.

THE COURT: All right. Then I will let you go ahead.

MR. JAMES: Thank you.

In determining what the appropriate sanction is where there has been spoilation of evidence, courts have considered a variety of factors. There are two that courts have primarily looked at, the degree of culpability of the party who has destroyed evidence and the degree of prejudice to the other party. And, again, when we talk about the degree of culpability, from SCO's perspective we are not talking about circumstances where evidence was negligently destroyed or where there was a failure to give an instruction to preserve evidence, we're talking about, in our view, intentional destruction of evidence. There is no question, Your Honor, that the prejudice that occurred to SCO as a result exists in this case, and I will talk about that in a few minutes.

18

Now, let me talk for a few minutes about IBM's arguments, Your Honor, and the declarations submitted and hopefully in that context we can talk about whether, in fact, evidence was or was not destroyed. And that is the first argument, in fact, that IBM makes, it says that SCO cannot show that IBM destroyed anything. In fact, it contends that Mr. Swanberg's e-mail was intended really for only eight developers, none of whom were part of IBM's Lunux TechnologyCenter.

IBM has submitted the declarations of those eight developers to whom it says the e-mail at issue was intended, four of whom said they did not destroy anything despite the instruction that they do so. As to the other four developers to whom Mr. Swanberg indicated the e-mail was intended, those developers can't recall whether they deleted anything. But they claim that if they did, it otherwise would have been available on the IBM CMVC database which has been produced in this case.

Well, Your Honor, there is no foundation, when you look at those statements in the declarations or on any other

19

And IBM wants the Court to focus on eight developers who worked for one of the eight managers to whom this e-mail was addressed. If you look back, Your Honor, at that e-mail, what you will see is the e-mail was directed again to eight IBM managers or team leaders, not to any of the eight developers for whom IBM has submitted the declarations. IBM just wants the Court to assume, without any evidence, that e-mail meant nothing to the other managers and the developers who worked under those managers to whom that e-mail also was directed.

While IBM has submitted the declaration of Mr. Swanberg in which he asserts in paragraph 6 of his declaration that what he really intended was that only three of the individuals listed on the e-mail communicate the information that was communicated or that was directed in that e-mail, nowhere in Mr. Swanberg's declaration or in the e-mail is that intent communicated or even suggested, and it simply defies common sense that someone would send an e-mail to eight people and later claim that it really wasn't intended for those eight people, but only for developers of two or three of those eight people.

Recall, Your Honor, also that the e-mail that Mr. Swanberg sent was an e-mail that originated from IBM's open source steering committee. That's where the instruction originally came from. That committee was charged with the oversight of all of IBM's contributions to open source

20

Let me talk for a minute about Daniel Frye. He is an IBM executive that testified as both the 30(b)(6) representative and in his personal capacity in this case. He testified that developers in the Lunux Technology Center were given a similar direction to that contained in Mr. Swanberg's e-mail.

And if you look at pages 4 and 5, and, again, that is testimony that has been marked as confidential, so if you look at pages 4 and 5 of SCO's reply memorandum, we quote quite extensively, Your Honor, from Mr. Frye's deposition testimony, and then we go on in the next three or four pages to talk quite extensively in detail about the questions that were asked and the fact that those questions reflect absolutely no confusion and the answers were absolutely clear, that contrary to the claim made in Mr. Frye's subsequent declaration that IBM now has submitted, he clearly testified about that instruction that was consistent with the instruction contained in the e-mail being sent to all of the developers in the Lunux Technology Center.

There was every opportunity on the part of IBM's counsel to address through cross-examination any ambiguity or confusion that may have existed at the time Mr. Frye was deposed. That did not occur.

IBM also claims that Paul McKenney, whose deposition testimony SCO also cites, was confused, and that his confusion arose from SCO's counsel asking Mr. McKenney the same question twice during the deposition, as if that doesn't occur over and over again in depositions, Your Honor. And, again, that's filed under seal. We've addressed that in detail on pages 9,

21

And, again, during Mr. McKenney's deposition, IBM's counsel made no effort to correct or clarify any alleged confusion. He had the opportunity to correct his deposition after it was over, make any changes that he felt were appropriate. None of the changes were made. Now IBM comes back with the declaration of Mr. McKenney who says, I was confused at the time, I didn't understand, you can't rely on the deposition testimony I gave, here is really what I meant.

And, Your Honor, in September of this past year, Judge Cassell of this court issued an opinion in a case entitled Juarez v. Utah Department of Health-Family Dental Plan, and in that case Judge Cassell talked about the case law that addresses the submission of what the case law refers to as sham affidavits or sham declarations. And he noted in that regard that while the Federal Rules of Civil Procedure allow nonmaterial changes to deposition testimony, material changes are allowed only in certain circumstances.

And he referred to the test that the Tenth Circuit has adopted and articulated in Burns v. Board of County Commissioners, and the Franks v. Nimmo case, and he said that there are three factors that a court looks at in determining whether to accept an affidavit or a declaration that is contrary to or inconsistent with testimony given in a deposition: First, whether the party was cross-examined when giving the prior sworn testimony; second, whether the contested evidence was newly discovered or whether the party had access to the evidence at the time of the previous testimony; and,

22

Judge Cassell went on to state, again, quoting from Tenth Circuit law this time, the Garcia v. Pueblo Country Club case, if Rule 30(e) -- which allows changes to depositions after the deposition has been taken -- if Rule 30(e) were interpreted to allow individuals to alter the statements they made under oath, one could merely answer the questions with no thought at all and then return home and plan artful responses. Depositions differ from interrogatories in that regard. A deposition is not a take home examination.

And I submit, Your Honor, if you look back at the briefing and the deposition testimony that we have attached to our memoranda, the deposition testimony at the time was clear. There were no ambiguities in the answers that these gentlemen gave. And IBM's counsel had the opportunity to cross-examine. Whether they took that opportunity or not, as Judge Cassell says, is irrelevant. They had it. And the affidavits or declarations that IBM now has submitted in which they try to alter the deposition testimony, that we think clearly demonstrates instructions to destroy evidence, that doesn't rely on any newly discovered evidence or anything that doesn't exist at the time of the deposition.

Your Honor, it is our contention that the clear deposition testimony is much more reliable and should be accepted over affidavits or declarations that have been submitted after the fact in opposition to SCO's motion.

THE COURT: Okay. Counsel, let's presume that I do accept the original testimony. The question still is based upon what arguably did happen, how does that get us to the

23

MR. JAMES: Okay. I was slowly getting to that.

THE COURT: That's where -

MR. JAMES: Far more slowly than Your Honor wanted me to.

THE COURT: That's where my interest is. Let me just tell you, so you can address that. Yesterday, as I was preparing for this hearing, I ran across a portion of the transcript of the hearing on February 4th of 2004. And Mr. Heise, representing SCO at that hearing, stated, and I don't know exactly what page it is, but he's talking about -- he's handing to me a document from IBM that has been marked confidential. It is regarding an item called the CMVC, which stands for configuration management version control. It says in the beginning that AIX development organization and through the highlighted portions identified that configuration management as a process of identifying managing software modules as they change over time. In other words, we would be able to get every version, every iteration. Control is the storage of multiple visions in a single file along with information versions. Then it gives a simplified descriptionat 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.

What that gets me to is whether or not the information you are talking about has, in fact, been destroyed for purposes of giving you the relief you are asking for or whether it has been transferred and is otherwise reasonably available.

MR. JAMES: I think, Your Honor, that is an excellent

24

It has been IBM's position in this case that its developers did not rely on AIX or Dynix/ptx code in developing Lunux software. Our position is that they did. The problem that we have is whether software or source code exists out there in a databank in the form of the CMVC doesn't answer that question. We need to know what developers at a given time have what on their computer, on a particular developer's computer, and we can't know that.

THE COURT: But what I need to determine is whether you can show that any evidence was lost or destroyed.

MR. JAMES: The evidence that was lost or destroyed is what particular developers at a given time had what access on their sandboxes in their own computer when they were working on Lunux code. When you take all that code and take it away and dump it into a database, it doesn't do us any good because the issue isn't whether the code exists or doesn't exist now, the issue is access by developers at a given time, particular developers at a given time to the code at issue. We can't tell

25

THE COURT: But it has not been destroyed.

MR. JAMES: What has been destroyed is our ability from the evidence to determine what developer had access to what particular source code at a given time. We do not have that information, we cannot have that information. If IBM had maintained the sandboxes of their developers, we would have that information.

So while the code itself has not been lost, apparently, the evidence of what code existed with respect to particular developments in a particular location has been. We can never get that back. That is absolutely probative to SCO's claims in this case.

We have alleged in this case that IBM developers have relied on and used AIX, Dynix, or derivatives thereof in the formulation of Lunux source code. Just because we now have a database that has a bunch of information in it regarding source code, doesn't tell us in any respect, Your Honor, what developers had what access when they were working on their computers on the Lunux code, and we can't get that back because it's been destroyed.

And I think relying even on probably what is the principal case that IBM cites on this issue, the Gates Rubber case, what that case says is that given the fact -- let me back up. Given the fact that programmers were instructed to destroy information that was in their sandboxes, again, from the Gates Rubber case stating, there is at least a reasonable possibility based on concrete evidence here, the deposition testimony and

26

And, Your Honor, let me just very briefly address just the waiver issue. They have raised that. It is our position this is not a discovery dispute or a discovery issue. We do not contend that the discovery was inadequate. By IBM's own admission, there is no evidence or documents leading to discoverable evidence responsive to SCO's request that IBM could turn over if ordered by the Court. We can't seek the production of evidence that no longer exists in the form we needed it.

IBM claims, based on the stipulation, it relies on the following language, the parties have reviewed one another's document production, then it conferred and agreed that there are no discovery disputes between them. As indicated, this isn't a discovery dispute. IBM cannot produce what it does not have because it destroyed it. Waiver is the intentional relinquishment of a known right. Nothing in the language of the stipulation suggests that SCO relinquished the right to bring an evidentiary motion.

Your Honor, we've asked for two different sanctions, Your Honor is aware of that, one of which is an inference based on what we think is bad faith and the other one doesn't require bad faith. We think both are appropriate. And if you don'thave any further questions at this time, I will be back on reply. Thanks.

MR. SHAUGHNESSY: Thank you, Your Honor.

SCO claims that IBM intentionally and in bad faith

27

In addition, Your Honor, the particular sanction that SCO is requesting here, an adverse inference instruction along with an evidentiary presumption, are the most severe sanctions, short of dismissal, that a court can impose. For that reason, as SCO concedes, the Court has to make an explicit finding of bad faith before those sanctions can be imposed.

Now I disagree with Mr. James about whether bad faith is required for both an adverse inference and an evidentiary presumption. If bad faith is required for an adverse inference, then the argument for requiring it for an evidentiary presumption, which is something even greater than an adverse inference, is even stronger.

Your Honor, this motion is being made in the face of a discovery record from IBM that can only be characterized as vast. We have produced to SCO documents from more than 260 separate custodians. We've produced more than 3.3 million pages of documents. We have produced to SCO billions and billions of lines of source code, including every version or iteration of AIX since 1991, every version or iteration of Dynix/ptx, hundreds and hundreds of thousands of program notes, thousands of design documents.

Your Honor, the production, as you know, to SCO of just the CMVC and the RCS systems took work by more than 400 IBM employees spending more than 4,700 hours. Now it bears noting, Your Honor, that despite the time the Court spent with that particular issue and despite the enormous amount of time

28

Your Honor will recall that the whole basis, as Mr. Heise was talking about in the particular hearing you mentioned, for SCO needing CMVC is they had to have CMVC in order to be able to figure out what improper contribution to technology IBM had made to AIX. As we stand here today, coming on the second year anniversary of having produced CMVC, SCO has identified one and only one improper contribution from AIX, Your Honor, and it's a contribution that is identified in their complaint.

Like SCO's claims with respect to the need for CMVC, Your Honor, this motion in the end is truly much ado about nothing. The motion is based upon assertion and speculation. The only party who has come forward to offer the Court evidence is IBM. And the evidence, I respectfully submit, Your Honor, shows, number one, IBM never, I repeat, never directed developers in the LTC to destroy anything. As counsel for SCO has now conceded, no original source code has been destroyed and SCO has no evidence that it has.

That what we are left with, Your Honor, at the end of the day, at the very most, is four developers who might have had old copies of source code on their machines. They are not sure. And who, if they did, might have deleted them. That, Your Honor, to put it in a more familiar context, is 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, knowing that Judge Kimball's chambers has a copy, and knowing that the clerk's office has a copy. That, Your Honor, is not bad faith.

29

Now with respect to Mr. Swanberg's e-mail, context is incredibly important here, Your Honor. In April of 2003, IBM's open source steering committee had a meeting to discuss a particular project, a particular issue concerning the Lunux for PowerPC project. At the time of that meeting, Your Honor, eight AIX developers had been assigned to do the work on that project. The work that those eight AIX developers were doing was writing entirely new code specific to IBM's PowerPC hardware.

These eight developers, since they were writing new code, had no need for access to AIX. During the course of this meeting, the question came up about whether these eight developers' access to CMVC had been removed. It had. Mr. Swanberg knew that it had and advised the people at the meeting that was the case.

The question then came up about whether any of these developers might have local copies of AIX in their -- what are referred to as sandboxes. Sandboxes, Your Honor, are a development tool that is used in AIX. They are not used in

30

So they check out of CMVC, they do the work, they fix the bug, whatever it is they are doing. And if they are successful in what they are doing, they check it back in to CMVC. As Your Honor correctly noted, every time they do, it's tracked, when they did it, what they did, when they checked it out, and when they checked it back in. Mr. Swanberg, as I said, knew that these eight developers didn't have access to CMVC, but he didn't know one way or the other, and to this day doesn't know one way or the other, whether any of those eight developers may have had sandboxes. So out of an abundance of caution, they said, well, like CMVC, let's make sure they don't have access, so have them get rid of those sandboxes as well.

Now, Your Honor, that was an eminently reasonable, rational decision. The developers didn't need access to AIX for the work they were doing. The developers, if they had, again, if they had code on their machine, would have been the exact same code that existed in CMVC.

Mr. Swanberg had no intent, absolutely no intent to destroy evidence. 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. Now, as I said, Mr. Swanberg had no idea whether any

31

It turns out that Mr. Swanberg was exactly right, four of the developers didn't delete anything at all. Your Honor, that presumably means they didn't have a sandbox to delete. The other four can't remember today, more than three years ago, whether they had a sandbox or whether they deleted it. But what they do know and what they are perfectly clear about in their declarations is if they did, whatever they deleted was a copy of what is in CMVC.

In short, Your Honor, what the open source steering committee was talking about, what Mr. Swanberg's e-mail was addressed to is a question of access to code. It is not addressed to an issue of deleting or destroying evidence.

Now, Your Honor, to put this particular issue in context, these eight developers and the PowerPC project on which they were working had absolutely nothing to do with any of SCO's claims in this case.

SCO has not identified a single line of this code as having been misused. As I told Your Honor, the only thing they have identified has having been misused from AIX is JFS, something they identified in their complaint, apparently without the benefit of looking at CMVC. SCO has not identified any one of these eight developers as having made an improper contribution to Lunux. Each of the developers, Your Honor, has testified that he or she never looked at or referenced any such code or any code they may have had on their machines in making any contributions to Lunux.

32

Now SCO's motion as it relates to Mr. Swanberg's e-mail and these eight developers is a dead end. They can't meet their burden or come close to meeting their burden with respect to any of the three elements. They can't show that anything was destroyed. We've demonstrated, Your Honor, exactly the opposite. They can't show that IBM acted in bad faith. Indeed, Your Honor, they haven't even tried. They can't show, Your Honor, that there has been any prejudice. The work these eight developers were doing and the project they were working on has absolutely nothing to do with any claim in this case.

And, Your Honor, SCO agrees. If you look at their papers, you listen to the arguments of counsel, they do not even attempt to tell Your Honor that this particular project or these eight developers are at issue in the case. Instead, Your Honor, this motion works for SCO only if SCO is able to leverage the Swanberg e-mail into the LTC. So what we're talking about here is a claim by SCO that instruction was given to the LTC to delete copies of source code.

To make out this claim, Your Honor, SCO relies exclusively on what I submit is ambiguous testimony from Dan Frye, which I will discuss in a moment. But what is really remarkable, Your Honor, to me is what SCO doesn't offer you.

33

Equally remarkable, Your Honor, they haven't offered you the testimony of a single person who says I was told to delete documents and I did. SCO has taken depositions of dozens of people who work in the LTC, and I can tell you the issue of spoilation has never been far from SCO's mind throughout this case. They could have asked, they should have asked and certainly if they got any testimony they thought was helpful, they would have shared it with you.

Now, they rely instead, Your Honor, on Mr. Frye's testimony.

May I approach, Your Honor?

What SCO ignores, Your Honor, is testimony that Mr. Frye gave during his deposition. If you turn to tab one, I have excerpted here, Your Honor, the instances in which Mr. Frye was asked directly the question about whether anything was destroyed. And I won't read them, Your Honor, but you can see that he said during his deposition no less than six times, six separate occasions that it didn't happen.

Your Honor, his testimony on this subject was so clear and so precise and so well understood that if you turn to tab two, you can see that SCO's lawyer, who took that deposition, acknowledged that that was precisely what Dr. Frye had said. SCO's counsel acknowledges, in the excerpt you see there, that the witness has testified nothing has been destroyed.

34

Now, what does SCO say about the testimony that I have just outlined for you? If you read their opening brief, they say not a word. Counsel's arguments today haven't even mentioned it. If you read their reply brief, they make a statement that, Your Honor, I can only say is truly remarkable. Although we laid this evidence out in detail, all the numerous instances in which, during his deposition, Dr. Frye said it didn't happen, we laid it out in detail, SCO says at page 12 of its reply memorandum, quote, other than Mr. Frye's declaration, which directly contradicts his sworn testimony, IBM submits no evidence to refute the direct evidence showing that IBM did direct LTC members to delete such material.

Your Honor, that is sticking your head in the sand. SCO chose in its reply memorandum and in its arguments today not even to address the numerous repeated instances in which Dr. Frye testified that no destruction occurred.

Now, Your Honor, this is not a case of a witness testifying in deposition that the light was red and submitting a declaration saying that the light was green. This, Your Honor, isn't close. This is a case of a witness testifying in deposition that the light was green not once, not twice, but six times, then testifying that a different light was red and submitting a declaration that says, when I testified in my deposition six times that the light was green, I meant the light was green.

35

Your Honor, SCO's motion with respect to Dr. Frye's testimony and the Lunux technology doesn't even get out of the chute. SCO has utterly failed in its burden to show that anything was destroyed. It relies on one line of testimony from Dr. Frye, which he explains in his declaration had three ideas enmeshed in it and, if you read it carefully, that is exactly what it does, and that he didn't give as precise a testimony as he should. And, Your Honor, that is certainly true. But what he did do in the very same deposition is give as precise a testimony as he could have possibly given, six times on this particular subject, evidence that SCO has chosen entirely to ignore.

Now, Your Honor, Mr. James said in his opening comments that the Court should accept clear deposition testimony, if I have written it down correctly. You know what, he's absolutely right. What you have right here is as clear a deposition testimony as you can possibly get, and Your Honor should accept it.

Now with respect to SCO's burden with respect to Lunux Technology Center and Dr. Frye's testimony, SCO has shown, as I said, nothing, has provided you no evidence that anything was destroyed. Beyond this, Your Honor, SCO has to prove that IBM acted in bad faith and the Court has to make explicit findings of bad faith. So what has SCO said on this subject, what guidance have they given Your Honor about how to go about making a finding of bad faith? Well, if you look at their reply brief,

36

Your Honor, in short, other than acknowledging that it has to prove bad faith, SCO's briefs are entirely silent. They offer Your Honor nothing by which you could possibly make a finding that IBM acted in bad faith.

That is true, Your Honor, both with respect to Dr. Frye's testimony and the Lunux Technology Center, but it is true across all of the claims that are being made.

Finally, Your Honor, SCO has to prove that it was prejudiced, and it comes nowhere close. The original premise of this motion as it was filed was that original source code has been lost, we no longer have ability to look at it. In our opposition, we demonstrated and SCO now concedes that nothing was lost. And, in fact, the very source code that SCO claims was lost has been sitting in its counsel's office on the CMVC.

So now, Your Honor, there is a revised premise, there is a new premise of this motion. It's no longer about, well, we now lost source code and don't have the ability. Now the premise is, well, we may not have lost source code, 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

37

Having determined that names were the same, SCO could have but chose not to turn the 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.

Your Honor, you are precisely right, they didn't make any effort to look at the information that we provided them to show that they were prejudiced. But, Your Honor, I submit that SCO isn't really interested in the evidence. What SCO is really interested in is having you make a ruling that will get them to a point that the evidence can't.

Your Honor, with respect to Paul McKenney, I will be brief because this one is truly silly. Tab six reproduces the disputed Paul McKenney testimony. As I say, I won't read through it. You see that the discussion here is all about overriding drafts and source code. Just so Your Honor can appreciate the true gravity of what it is we're talking about here, Dr. McKenney, when he writes source code, will write it and then he runs it through a little program to check to make sure it doesn't have obvious mistakes, letters or numbers transposed, things like that. If it does, then he fixes it. He doesn't create a whole new version of it, he fixes the

38

And since no molehill isn't worth trying to dress up as a mountain, we've now got lengthy testimony and all kinds of argument about what was going on here. I won't read through the testimony, Your Honor, you can do that should you deem it necessary to do so, but what I will say, it is crystal clear, both from the testimony itself and from what Dr. McKenney has submitted in the form of his declaration, that he misheard the question.

And, Your Honor, if you turn to the second page of that, I direct your attention to a portion of that that appears emboldened. And, Your Honor, this doesn't appear in the written transcript of the deposition. This, however, is recorded in the audio version of the transcript, which I have included in the event the Court wishes to look at it. What you can see is that after Dr. McKenney answers these series of questions, SCO's lawyer, during the deposition, realizes that there is an inconsistency, realizes that there is some inconsistency in what the witness has just said.

What does SCO's lawyer taking the deposition do? He asks Dr. McKenney two follow-up questions. Those two follow-up questions are absolutely fatal to the arguments that SCO is making about the destruction of evidence. SCO's lawyers asked the follow-up that was necessary to clarify Dr. McKenney's deposition, and they did that, Your Honor, with full knowledge

39

Your Honor, finally, a very brief word on the timing of this motion. During the weeks preceding the close of fact discovery, I had numerous conversations, countless conversations with SCO's counsel, the purpose of which was to try and work through the long, long list of discovery issues that were pending between the parties and to resolve as many of them as possible. And to the extent they could not be resolved, to preserve both parties' abilities to go forward with those issues.

Your Honor, we attempted to put to bed all of the outstanding discovery issues other than those that really mattered to the parties. We signed a stipulation that did exactly that on March 17th of 2006. And, Your Honor, I participated in every one of those conversations. And SCO never once during any of those conversations ever raised any issue about needing to bring a claim about spoilation of evidence.

SCO's response is spoilation isn't a discovery motion. And, Your Honor, if a motion that seeks to sanction a party for failing to produce evidence in discovery because it's been destroyed isn't a discovery motion, then I don't know what is.

But, Your Honor, there is a problem with timing of this motion that goes beyond the fact that they stipulated it away, and the problem is this: SCO didn't file this motion after fact discovery closed. SCO waited to file this motion until after expert discovery closed. Now having waited until expert discovery closed, SCO argues in its papers that they have been prejudiced because

40

Your Honor, respectfully, there is no basis for granting the motion that SCO has filed and I would request that it be denied.

THE COURT: Thank you, Mr. Shaughnessy. Mr. James.

MR. JAMES: Your Honor, I am going to ask the Court to do what I think is fair, and that is set aside the rhetoric, set aside the discussion about SCO having stuck its head in the sand, set aside all of the talk about remarkable, credible and knowing the mind of Dr. Frye, and look at the evidentiary record in this case.

I am going to start, Your Honor, with the issue that Mr. Shaughnessy started with on bad faith. He has told you that spoilation sanction of any type requires a finding of bad faith. I am going to read to you from Judge Stewart's opinion in the Adams v. Gateway case. He says, referring to Magistrate Nuffer and a finding, he said that bad faith is not generally required when considering other sanctions for spoilation of evidence. The court finds that case was accurately cited, is helpful in discussion of factors to be considered, and he says in that case that bad faith is not required in order to find

41

Your Honor, when you look at the case law, and there has been a lot of case law cited, none of the case law talks about specifically what constitutes bad faith. That's obviously a determination that the Court has to find. But in this case what we have is an e-mail that specifically is talking about resulting from the initiation of litigation instructing the destruction of evidence. What happens is IBM now comes and says that doesn't even matter, none of these guys, these eight developers, none of whom were even listed on the e-mail at issue, those guys weren't in the Lunux Technology Center and therefore it doesn't even matter. If it didn't matter, why did IBM instruct the destruction, the purge of that evidence.

And, Your Honor, if you go back and you look at Dr. Frye's testimony on the instruction that was given to the LTC, the Lunux Technology Center, we cite that I think very succinctly and carefully at the bottom of page 5 of our reply memorandum, you will see that his testimony was absolutely clear that that instruction was, in fact, given. And, Your Honor, I think if you step back, you say, wait a minute, wait a minute, if the developers didn't need this access from their sandboxes, why do we have an instruction to purge their sandboxes. The appropriate instruction would be to save that information and remove access, not destroy that information. And the problem that we have is we have counsel getting up here saying you can go to CMVC and find anything and everything that has been lost. And, Your Honor, I submit that

42

We have been denied the ability to know what access a particular developer had and was using at a given time and you cannot find that on the CMVC. And Mr. Shaughnessy wants to tell you that you can. There is no declaration, there is no evidence whatsoever in the record of that representation to the Court.

The e-mail, Your Honor, at issue originated with IBM's open source steering committee. It was addressed to eight different team managers or team leaders. The deposition testimony of Mr. Frye is unambiguous that a similar instruction was given to developers in the Lunux Technology Center. Both Dr. Frye and Mr. McKenney had the opportunity and did make corrections to their deposition testimony before this motion ever arose. They made no corrections making the type of clarifications and marked changes that they have made in the declarations that have now been submitted by IBM in opposition to this motion.

The value of the sandbox, once again, Your Honor, to SCO is to show developers had access to AIX and Dynix/ptx as they were developing Lunux source code. Our ability to show that access has been destroyed because IBM plainly and clearly instructed developers to purge their computers of that information and you cannot get that information from the CMVC.

THE COURT: Why?

MR. JAMES: Because the CMVC doesn't show the information of who had access and what was in a sandbox at a given time with respect to a given developer. All the CMVC shows is all of the source code that was available. It doesn't

43

Your Honor, this is not something much ado about nothing. This is much ado about something. The something is a very clear instruction to purge, to destroy evidence after this lawsuit was filed, an instruction that came down from the IBM committee -- open source steering committee that oversaw IBM's contribution to all open source software.

Your Honor, IBM wants to stand up here and tell you how many hours they have spent producing information, how many millions of pages of documents they have given to SCO. That's not the issue and that is not what spoilation talks about. The issue before Your Honor is the fact that evidence that is probative, that is important has been destroyed. And whatever that evidence ultimately may mean, whatever it ultimately - what impact it has on the case, the fact that IBM destroyed that evidence, that is what spoilation is all about. The theory says that the party who destroys that evidence is the party who has to bear the risk that that evidence would be negative to their case, otherwise what is the point of the spoilation doctrine at all.

Your Honor, Mr. Shaughnessy has made a number of representations to the Court about SCO having done nothing with CMVC, and what SCO has and hasn't done. And, Your Honor, I respectfully simply just disagree with that. And I think those are representations by counsel. I can stand up and tell you everything that I think SCO has done with the information from CMVC, all of the things that -- details of the JFS disclosure from AIX that are in December submissions that are beyond those

44

You know what, we can get up here and argue all day, and that is not the point. The point is this: There is a clear record we've submitted to the Court in the form of our opening memorandum, along with the e-mails and declarations and deposition testimony in opposition and the information that IBM provided to you in that context and the reply. In our reply we go through in a very detailed way and address the very same arguments that Mr. Shaughnessy has made to you today. It's a little difficult to get into that in open court because of the confidentiality concerns and the protective order, but we've laid that testimony out in the reply memorandum and we have talked about how that testimony came down.

When Your Honor -- if you have had a chance -

THE COURT: I have.

MR. JAMES: -- to look at that, I submit that deposition testimony, particularly the deposition testimony of Dr. Frye, was clear. There was ample opportunity on the part of IBM's counsel if they thought it wasn't clear at the time to clear it up, and they didn't do that. What the courts say is you look at the deposition testimony and does it reflect confusion or doesn't it. If it doesn't reflect confusion, then it's not appropriate to be trying to make significant marked changes in that deposition after the fact.

Your Honor, clearly I think when you look at the e-mail and when you look at the testimony in this case, there was evidence that was destroyed. The fact that it was done intentionally pursuant to an instruction one month after the litigation was filed, the fact that it was done as a result of an open steering meeting, I submit satisfies the bad faith -

45

Short of that, there clearly has been spoilation I believe. We have been deprived of knowing who had access to what. And as a result of that, even if a bad faith spoilation inference is not given in this case, that kind of an instruction, the Court should still give the spoilation sanction that SCO has requested that does not require the bad faith finding. Thank you, Your Honor.

THE COURT: Thank you, Mr. James. Mr. Shaughnessy anything further?

MR. SHAUGHNESSY: Despite being very tempted, Your Honor, I would not say anything further.

THE COURT: All right.

I am going to find that based upon the evidence before me, as it's 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 spoilation and the adverse inference instruction will be denied.

MR. JAMES: Your Honor, based on Mr. Shaughnessy's representations, would Your Honor have any objection to asking or ordering IBM to tell us how we find that in CMVC because this is something that is absolutely new to us. If it's in CMVC, we sure haven't been able to figure out how to get it.

THE COURT: That's why I pointed out to you the testimony that I found yesterday which indicated that as early

46

MR. JAMES: Okay. Maybe I had a little different understanding when you read what Mr. Heise said about the understanding of what CMVC potentially could do. I may have misunderstood that. If I did, I apologize, Your Honor.

THE COURT: Anything further?

MR. SHAUGHNESSY: Nothing further, Your Honor.

THE COURT: Now I'm going to ask you, Mr. Shaughnessy, to answer that question: What if anything is IBM willing to do or do you have an obligation -

MR. SHAUGHNESSY: Your Honor, the day for asking for that passed a long time ago. That discovery in this case is closed. SCO has had that now for almost two years. And they were the ones who came in and told you, Your Honor, that they had to have this and that it would have the very information you just described. We have given them detailed instructions on how to use it.

And what you haven't heard, Your Honor, very curiously, is SCO comes in and says, well, we haven't offered evidence that, in fact, you can find this in SCO. What they haven't done, Your Honor, is they haven't attempted to come in and say to Your Honor in some evidentiary admissible form, we tried it and we couldn't do it. But at the end of the day, Your Honor, that day has passed. Fact and expert discovery in this case are closed. To the extent that information was important for those purposes, it should have been investigated and looked into long, long, long before now.

MR. JAMES: Just, finally, Your Honor, and I don't want to drag this out longer than it has to be, but it seems to

47

THE COURT: The standard I think is reasonably available. I am going to ask 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.

MR. SHAUGHNESSY: Your Honor, if the Court would like us to do that, I'm happy to undertake that. What I want to make sure we're very, very clear about, Your Honor, is that we are not reopening discovery.

THE COURT: I think I just said that.

MR. JAMES: I think Your Honor made that very clear.

THE COURT: I don't think that's open to question. So with that having been said and, Mr. Shaughnessy, if you will prepare a proposed order.

MR. SHAUGHNESSY: We would do that, Your Honor.

48

THE COURT: I did not ask. I will ask SCO to prepare the order on the first motion.

MS. BORUCHOW: We would be happy to, Your Honor.

MR. SHAUGHNESSY: Thank you, Your Honor.

THE COURT: Thank you. And we'll be in informal recess. Thank you.

(Whereupon, the proceeding was concluded.)

49