Here is Sandeep Gupta's Redacted Declaration in Support of SCO's Opposition to IBM's Cross-Motion for Partial Summary Judgment [PDF], as text, which we earlier discussed in this article. Our thanks go to Scott David Daniels for doing the transcription.
It's quite a perfomance by Mr. Gupta. So much is redacted, it's hard for us to know what he said in detail, but Dr. Brian Kernighan, IBM's expert, did get to read it all, and he answers Mr. Gupta point-by-point in scathing terms in the recently unsealed Declaration of Brian W. Kernighan [PDF -- exhibits here]. In fact, unless I have misunderstood, he as much as says that Mr. Gupta improperly (may I even conclude he implies dishonestly or is it just incompetence being alleged?) cobbled bits and pieces of code from all over the place to make it look like a block of similar code:
Furthermore, in places, Mr. Gupta's conclusions of similarity depend on his selecting isolated lines of code from disparate places and putting them together as if contiguous blocks of code were involved (which they are not) and important differences did not exist (which they do).
Ouch. So Gupta tried to create something
out of nothing by a sleight-of-hand, identifying 300-odd lines that
are similar across the whole kernel, and then starting to discuss it
as if it was a solid block of lines? The impression given is that it's as if Gupta had been locked
in a room and told not to come out until he finds some substantially
In conclusion, he says that Mr. Gupta's declaration "contains errors of methodology and fact." His conclusions are "flawed" because he fails to exclude unprotectable elements first and he uses an "indefensible standard for what qualifies as 'substantially similar' code." Had he excluded unprotectable elements and used an appropriate standard, he says, "there is no similarity between the six parts of Linux identified by Mr. Gupta and the allegedly copyrighted works."
For the cherry on top, he says that if you put all the code Mr. Gupta imagines is similar or identical, even if he were right, it doesn't add up to 300 lines of code, so it's insignificant. How would you like to read this about your work?:
17. Mr. Gupta does not describe the methodology by which he arrives at his conclusions. Even so, it is clear that Mr. Gupta's methodology, and therefore his conclusions, are indefensible.
Indefensible. Considering Dr. Kernighan's qualifications, reputation, and accomplishments in the field of computer science, it must feel much like getting an F from the most admired teacher in your university, in your favorite subject, and being publicly accused of cheating to boot.
Mr. Gupta begins by telling the court what he hopes to do with his declaration:
3. In this declaration, I will explain why I believe that several routines and several groupings of code for which SCO has copyright protection were copied into the Linux operating system. Specifically, this declaration will (1) describe how the Read-Copy-Update routine in Linux is substantially similar to a routine in UNIX; (2) describe how the user level synchronization (ULS) routines in Linux are substantially similar to routines in UNIX; (3) describe how Linux version 2.4.20 contains code that is either an identical or substantially similar copy of SCO's UNIX System V IPC code; (4) identify identical and substantially similar copying of SCO's copyrighted UNIX "header and interfaces" in Linux; (5) describe how Linux version 2.6 contains code that is an identical copy of SCO's UNIX System V init (SYS V init) code; and (6) identify identical copying of SCO's UNIX Executable and Linking Format (ELF) code in Linux.
The declaration will discuss these topics of copyright infringement in the order just described. Although I am not an expert in copyright law, I believe these topics either show copying of code or raise significant factual issues that need to be explored further.
Either-or, eh? Could be, or maybe not? If you are wondering which it is, consider Dr. Kernighan's testimony.
First, he says, Mr. Gupta failed to filter out unprotectable elements, but even putting that aside, "much of what Mr. Gupta is willing to call 'substantially similar,' or even 'identical,' plainly is not, even to an untrained eye. In some instances, code that Mr. Gupta discusses as if it were a single block is in fact his own composite of code scattered throughout a large body of code, sometimes even coming from different files.
Finally, the amount of code at issue is an insignificant portion of the whole -- not only quantitatively but also qualitatively."
If you added up everything Gupta lists in his declaration, it adds up to "a total of less than three hundred lines." Therefore, he concludes that the "allegedly infringed portions of the allegedly copyrighted works are not significant or important parts of the allegedly copyrighted works, considered as a whole -- either quantitatively or qualitatively."
Regarding RCU and ULS, he devastatingly says this:
21.21. Two allegedly copied regions (described by Mr. Gupta as the "RCU routine" and the
"ULS routines") are unprotectable ideas or processes expressed at a very high level of
abstraction, not protectable expression. Mr. Gupta's own language makes the point,
labeling the material at issue a "routine" (¶ ¶ 3,5,10) and "method" (¶ ¶ 6,7). He also
describes the routines at issue as "perform[ing] the same five acts" (¶ 11) and
"includ[ing] the same none (9) acts" (¶ 36), but each of these acts is generic, far removed
from a specific expression. Moreover, the actual code that Mr. Gupta says is
"substantially similar" is not similar at all. Mr Gupta's own exhibits A, H and I
illustrate the point -- even to a non-programmer, the Linux code is completely different
from the Unix Code -- and detailed examination of the code shows no relationship.
As for IPC header files and ELF, he says that IPC material is in the public domain, because it was included in Unix System V 2.0 and 3.2 without copyright notices and distributed before 1989. Even if it were not, and "to the extent it is even original," IPC material constitutes ideas, concepts, merger material and scènes à faire material.
ELF is "classic scènes à faire material", he continues. "The contents of the file are determined by software standards, target industry practice and demands and computer industry practices. Indeed, the substantive content in the ELF header file comes from a published and widely distributed standard -- the 'Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification', version 1.2, attached as Exhibit XVI -- material that explicity grants permission for use in the interests of interoperability, by an industry consortium that included SCO's alleged predecessor-in-interest, The Santa Cruz Operation, Inc."
And finally, as far as SYS V init code is concerned, it's not in the Linux kernel. If it were, it would suffer from the same defects outlined for all the rest of Mr. Gupta's findings.
I think Gupta's declaration was introduced for the limited purpose of trying to survive IBM's motion for partial summary judgment, just throwing up items that at least look like facts in dispute to someone without Dr. Kernighan's knowledge. The judge postponed matters, however, telling IBM to refile or renew once discovery is finished, which I'm sure they will. It isn't hard to see why Judge Kimball wrote what he did about SCO's astonishing lack of evidence, and I am increasingly starting to believe that SCO's yearning for more and more code had more to do with defensive discovery regarding IBM's counterclaims (not to mention Red Hat's claims), trying to find some justification for their litigation. You can't help but ask at this point, is this all they have?
One fact in dispute that Mr. Gupta doesn't mention is whether or not SCO actually owns these copyrights at all. Does it even matter, with respect to RCU and the other items in Gupta's declaration, though, after reading Dr. Kernighan's? Could the stupidest jury in the country fail to understand what is what here?
You may be curious about why Mr. Gupta so specifically mentions persons he believes had access to Unix source code. It's because under copyright law, you have to either prove factually that someone copied, or if you can't do that, if you can prove access the court can infer infringement if there is also substantial similarity. Here's how the judge put it in the famous case Lotus v. Borland [PDF]:
To establish copyright infringement, a plaintiff must prove "(1) ownership of a valid copyright, and (2) copying of constituent elements of the work that are original..... a plaintiff must first prove that the alleged infringer copied plaintiff's copyrighted work as a factual matter; to do this, he or she may either present direct evidence of factual copying or, if that is unavailable, evidence that the alleged infringer had access to the copyrighted work and that the offending and copyrighted works are so similar that the court may infer that there was factual copying (i.e., probative similarity). Engineering Dynamics, 26 F.3d at 1340; see also Concrete Mach., 843 F.2d at 606. The plaintiff must then prove that the copying of copyrighted material was so extensive that it rendered the offending and copyrighted works substantially similar.
I explained all that back in the very early days of Groklaw, in July of 2003, before SCO's position was as clear as it is now, before most of you were here, and before I knew much about HTML, I'm afraid, but if this interests you, you will find other links in this article on the different purposes of patents and copyrights. As for scenes à faire, you might find this article by Ivan Hoffman instructive on the subject. Basically, it means that if there is only one way to do something, you can't copyright it:
Likewise, when similar features of a work are “as a practical matter indispensable, or at least standard, in the treatment of a given idea, they are treated like ideas and are therefore not protected by copyright.”
Here's another definition from an article on Cyberlaw:
The doctrine of “scenes a faire” similarly states that when external constraints limit the options for expression, copyright protection is precluded. “In the computer-software context, the doctrine means that the elements of a program dictated by practical realities… may not obtain protection.”
Reading that, it occurs to me that SCO needs to read that article too, actually. They might learn not to waste our time with poppycock. And from Dr. Kernighan's description of what happened here, that is a mild word.
Update: Here are the Unsealed Exhibits to the Declaration in Support of SCO's Opposition to IBM's Cross Motion for Summary Judgment [PDF], Docket 197.
Brent O. Hatch (5715)
Mark F. James (5295)
HATCH, JAMES & DODGE
[address, phone, fax]
Stuart H. Singer (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
[address, phone, fax]
Robert Silver (admitted pro hac vice)
Edward Normand (admitted pro hac vice)
Sean Eskovitz (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
[address, phone, fax]
Stephen N. Zack (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
[address, phone, fax]
Attorneys for The SCO Group, Inc.
IN THE UNITED STATES DISTRICT COURT
FOR THE DISTRICT OF UTAH
THE SCO GROUP, INC.
DECLARATION IN SUPPORT OF
SCO'S OPPOSITION TO IBM'S
CROSS-MOTION FOR PARTIAL
[Docket No. 197]
(REFILED IN REDACTED FORM)
Case No. 2:03CV0294DAK
Honorable Dale A. Kimball
Magistrate Judge Brooke C. Welles
DECLARATION OF SANDEEP GUPTA
1. My name is Sandeep Gupta and I am employed by The SCO Group, Inc. My
office is located at [address]. Unless
otherwise noted or evident from the context, this declaration is based on my
personal knowledge and information available to me from reliable sources. To
the best of my knowledge, information and belief, the facts set forth herein are
true and correct.
2. I submit this Declaration in support of the SCO's Opposition to IBM's Cross-Motion for Partial Summary Judgment, in the lawsuit entitled The SCO Group,
Inc. v. IBM, Civil No. 2:03-CV-0294 DAK (D. Utah 2003).
3. In this declaration, I will explain why I believe that several routines and several
groupings of code for which SCO has copyright protection were copied into the
Linux operating system. Specifically, this declaration will (1) describe how the
Read-Copy-Update routine in Linux is substantially similar to a routine in
UNIX; (2) describe how the user level synchronization (ULS) routines in Linux
are substantially similar to routines in UNIX; (3) describe how Linux version
2.4.20 contains code that is either an identical or substantially similar copy of
SCO's UNIX System V IPC code; (4) identify identical and substantially
similar copying of SCO's copyrighted UNIX "header and interfaces" in Linux;
(5) describe how Linux version 2.6 contains code that is an identical copy of
SCO's UNIX System V init (SYS V init) code; and (6) identify identical
copying of SCO's UNIX Executable and Linking Format (ELF) code in Linux.
The declaration will discuss these topics of copyright infringement in the order
just described. Although I am not an expert in copyright law, I believe these
topics either show copying of code or raise significant factual issues that need to
be explored further.
4. SCO claims ownership of copyrights to UNIX software, source code, object
code, programming tools, documentation related to UNIX operating system
technology, and derivative works thereof. These materials are covered by
numerous copyright registrations issued by the United States Copyright Office
(the "Copyright Registrations"). These registrations have been obtained by
SCO and its predecessors in interest and are owned by SCO. Included among
such registrations are:
TITLE||REG. No.||REG. DATE|
|1 ||Unix Operating System Edition 5|
and Instruction Manual
|| Unix Operating System Edition 6 |
and Instruction Manual
| TXu-511-236 || 04/07/92
Unix Operating System Edition 32V |
and Instruction Manual
| TXu-516-704 || 05/15/92
Unix Operating System Edition 7 |
and Instruction Manual
| TXu-516-705|| 05/15/92
|5|| Operating System Utility Programs || TXu-301-868 ||11/25/87
|6||UNIXWARE 7.1.3 || TX-5-787-679 || 06/11/03
|7|| UNIX SYSTEM V RELEASE 3.0 || TX-5-750-270 || 07/07/03
|8|| UNIX SYSTEM V RELEASE 3.1 || TX-5-750-269 || 07/07/03
|9|| UNIX SYSTEM V RELEASE 3.2 || TX-5-750-271 || 07/07/03
|10||UNIX SYSTEM V RELEASE 4.0 || TX-5-776-217 || 07/16/03
|11|| UNIX SYSTEM V RELEASE 4.1IES || TX-5-707-356 || 06/30/03
|12|| UNIX SYSTEM V RELEASE 4.2 || TX-5-762-235 || 07/03/03
|13||UNIX SYSTEM V RELEASE 4.1 || TX-5-762-234 || 07/03/03
|14||UNIX SYSTEM V RELEASE 3.2 || TX-5-750-268 || 07/09/03
|15|| UNIX SYSTEM V RELEASE 4.2 MP || TX-5-972-097 || 6/29/2004 |
5. I believe that the Read-Copy-Update ("RCU") routine in Linux version 2.6.5
and in patches to Linux (hereinafter referred to as Linux RCU) are substantially
similar to the RCU version in SCO's copyrighted work, specifically UNIX
SVR4.2 MP. UNIX SVR4.2 MP is part of a registered copyright of SCO
entitled UNIX System V Release 4.2 MP (also known as 4.2 ES/MP)
(registration No. TX 5-972-097).
6. A problem may occur in a multiprocessing computer environment when
multiple entities such as processors attempt to access data in a shared
memory. For example, a user of the data, such as a "process" in the operating
system, may attempt to update a particular piece of data at the same time that
another process is attempting to read the same data. In this scenario, the process
attempting to read the data will see the data in a partially updated state, or in a
non-updated state, rather than in the updated state being supplied by the other
process. To address this situation, programmers have devised various
synchronization methods that allow access to data by multiple processors at the
same time, and that maintain synchronization by directing all processes -- at the
appropriate time -- to the updated data.
7. RCU (Read-Copy-Update) is one of the methods used to synchronize access to
shared data in a multiprocessing environment.
8. Because RCU provides for synchronized access to shared data in a
multiprocessing environment, RCU provides substantial performance
enhancements to an operating system and is thus a very important part of any
multiprocessing operating system.
9. SCO's version of RCU first appeared in UNIX SVR4.2 MP and is referred to
herein as UNIX RCU.
10. The Linux operating system includes a routine, Linux RCU, that is substantially
similar to UNIX RCU.
12. There are several ways to synchronize data updating and sharing without using
the five acts just described. In other words, synchronizing access to shared data
in a multiprocessor environment can be expressed in ways other than the
expressions in UNIX RCU.
13. For example, synchronizing access to shared data can be expressed with mutual
exclusion locks (mutex). Mutual exclusion locks may be used to lock a data
location so that only one operating system process can have read/write access to
that data location at one time. If another operating system process needs to
access the same data location, the second operating process has to wait until the
data location has been unlocked. Using mutual exclusion locks, access to
shared data can also be expressed with reader/writer locks. Using reader/writer
locks, multiple processes can acquire read access to a data location, but only
one process at a time can acquire write access to update that data location.
14. UNIX RCU and Linux RCU perform the same five acts in the same sequence,
and UNIX RCU and Linux RCU have the same structure and organization.
15. Each of the five acts of the UNIX RCU -- and of the Linux RCU -- routine is
expressed in one or a fewer lines of code.
16. The first act, "allocating a new data structure of a certain size," is expressed in
UNIX RCU and Linux RCU by a single line of nearly identical code. From a
software programmer's perspective, the UNIX RCU expression of the act of
allocating a new data structure has been identically copied into Linux RCU. As
can be seen in attached exhibit A, the Linux RCU code (column 4) for the first
act is nearly identical to the UNIX RCU code (column 1) for the first act.
21. In Linux RCU, in contrast, the fifth act of deferred deletion is achieved by a
callback function that is automatically called when no current users remain so
that the old data structure may be deleted.
22. Although the fifth act in Linux RCU and in UNIX RCU are expressed
differently, they both achieve deferred deletion of the old data structure.
23. In my opinion, Linux RCU is substantially similar to UNIX RCU, and appears
to be derived from UNIX RCU.
24. As represented to me, contributors to Linux had access to UNIX RCU.
Showing access to UNIX RCU is a two step process. First, UNIX RCU was
copied into Dynix, which is Sequent's version of UNIX, and then the UNIX RCU
was released from Dynix into Linux. Sequent Computer System, Inc.'s
(Sequent) software engineers could have accomplished the first step -- of
developing a Dynix RCU based on the UNIX RCU -- when they worked under
the Multiprocessor Software Cooperation Agreement (the "MP Agreement" --
Exhibit B) with Unix System Laboratories, Inc. (USL) engineers to develop the
UNIX version of RCU. The MP Agreement was signed in September of 1990.
USL is a predecessor of SCO.
25. Jack Slingwine and Paul McKenney are the credited authors of Dynix RCU, and
were both Sequent employees. At least Mr. Slingwine was involved in the
UNIX development work under the MP Agreement. At least Mr. Slingwine had
access to the UNIX RCU work because of his involvement in the UNIX
development work. I believe that Mr. Slingwine would have used that access to
UNIX development to review UNIX RCU because of his clear interest in RCU.
Regarding his clear interest in RCU, Mr. Slingwine and Mr. McKenney
authored a paper on RCU, "Read-Copy Update : Using Execution History To
Solve Concurrency Problems," which refers to "work performed at Sequent."
See Exhibit C. In this paper Mr. Slingwine and Mr. McKenney thank (among
others) Bren Kingsbury, and Mr. Kingsbury was one of the authors of a design
document for UNIX which discusses, among other things, UNIX RCU.
26. As represented to me, evidence that the Sequent RCU work was performed
during the same time frame that the MP Agreement was operative is clear.
Specifically in that regard, the MP Agreement, signed in September 1990,
appears to terminate in November 1992. It took two years to develop UNIX
RCU under the MP Agreement, from late 1990 to late 1992. On July 19, 1993,
a patent application related to the RCU entitled "Apparatus and Method for
Achieving Reduced Overhead Mutual Exclusion and Maintaining Coherency in
a Multiprocessor..." was filed listing Mr. Slingwine and Mr. McKenney as co-inventors. The patent issued on August 19, 1995 as U.S. Patent No. 5,442,758
and lists Sequent as the assignee. See Exhibit D.
27. In sum, at least Mr. Slingwine (and perhaps Mr. McKenney) had access to
UNIX developments during the USL/Sequent collaboration under the MP
Agreement which included development of UNIX RCU, and both showed great
interest in RCU by filing a patent application (as co-inventors) relating to RCU
immediately after the MP Agreement collaboration.
28. Thus, I believe that UNIX RCU was copied into another version of UNIX
known as Dynix by engineers who worked for Sequent at the time and who later
worked for IBM when IBM acquired Sequent.
29. As far as the second step, IBM thereafter released Dynix, with a copied and
modified UNIX RCU in Dynix, into Linux. More specifically, the Dynix
version of RCU was used by IBM employee (and former Sequent employee)
Dipankar Sarma to create a software patch for placing a substantially similar
version of RCU into Linux. I believe that the first patch appears to be for Linux
version 2.4.1 and was contributed by Mr. Sarma. See Exhibit E. A paper
entitled "Read-Copy Update" also lists Mr. Sarma along with Mr. McKenney
and others as authors. See Exhibit F. Another patch was also provided to Linux
version 2.5.44 by IBM employee Mingming Cao. See Exhibit G. This patch
appears to be incorporated into the Linux version 2.6.
30. I will now describe the user level synchronization (ULS) routines that are used
for blocking and unblocking of processes.
31. The ULS routines in Linux are commonly referred to as FUTEX (Fast User
Mutex), but will be called Linux ULS here.
32. The ULS routines in UNIX are sometimes referred to as usync, but will be
called UNIX ULS here.
33. The main purpose of the ULS routines is to facilitate inter-process
synchronization by blocking and unblocking processes attempting to access
34. Synchronization of user level processes accessing shared data is important to
prevent two processes from modifying the same data at the same time. The
blocking and unblocking of access to shared data by ULS allows only one
process at a time to use the shared data. ULS is a very significant piece of code
because it is a very important part of any operating system to synchronize
access by processes to shared data.
35. SCO's version of ULS first appeared in UNIX SVR4.2 MP.
47. There are several ways to implement the blocking and unblocking for ULS.
Therefore, the result of ULS can be achieved in several other ways.
48. Another alternative implementation of blocking and unblocking for ULS is the
Linux implementation that existed prior to Linux copying the UNIX ULS
implementation. This ULS alternative implementation is described in the article
attached as Exhibit K. In this article, Rusty Russell, of IBM, describes how the
earlier Linux ULS implementation was improved by Jamie Lokier and Hugh
Dickins in the new Linux ULS implementation.
49. While working on changing the Linux ULS, Mr. Lokier learned of the UNIX
ULS implementation, may have had access to it, and may have incorporated the
infringing code into Linux. Some evidence of this is the changelog to the
current Linux ULS code which designates Mr. Lokier as author of the Linux
ULS code. Mr. Lokier's author's notes in the changelog give special thanks to
Mr. Russell of IBM and to Hugh Dickins (a former SCO employee) for help
with the patch to Linux ULS code which Mr. Lokier authored. I believe that
the collaboration between Jamie Lokier and Hugh Dickins to improve the Linux
ULS code benefited from access to and knowledge of the UNIX ULS
50. I now turn to instance of copying in Linux of UNIX System V IPC routines.
51. IPC stands for Inter-Process Communication.
53. With regard to the organization of Linux SysVIPC and UNIX System V IPC,
both consist of three mechanisms: message queues, semaphore, and shred
memory. There is no reason for the organization to be identical other than the
fact that Linux SysVIPC has been copied from UNIX System V IPC.
62. SCO owns valid copyrights for UNIX System V IPC header file code. As can
be seen from Tables 1-6, SCO's UNIX System V IPC header file code has been
identically copied into Linux. Slight variations in some of the terms are
insubstantial differences in programming. As to access, UNIX System V IPC
header file code was included in any system running a UNIX System V derived
operating system. Therefore, anyone having access to a system installed with
UNIX System V or one or more of its derivatives could have had access to
UNIX System V IPC header file code.
2063. I will now describe certain System V headers and interfaces that are
copied either identically or substantially similarly in Linux.
64. Regarding access to this header and interface code, UNIX header and interface
source code is available in SCO-copyrighted documentation, such as manual
pages. These manual pages are published on the Internet with copyright
notices. Also, UNIX header and interface code is available to any entity having
a license to UNIX, or who can otherwise access the UNIX code.
65. A header file is a programming source file containing declarations of interfaces
that facilitate communication between different regular source files that
comprise the program. The interfaces can come from the program itself, or
from libraries. The libraries provide (define) the interfaces that are intended to
be used elsewhere, typically in an application.
73. I now turn to instances of copying in Linux of SCO's copyrighted SYS V init
code. Linux version 2.6 contains code that is an identical copy of SYS V init
74. SYS V init was accessible for copying because the manual pages defining SYS
V init features, for example init and inittab, are published as electronic
documents and are available to anyone with an Internet browser. These manual
pages, however, carry appropriate copyright notices. Using the manual pages, a
skilled programmer could copy the structure, sequence, and organization of
SYS V init routines. SYS V init and inittab were included in documentation
with each release of UNIX System V as manual pages init(1M) and inittab(4),
respectively. See Exhibits Z and AA. Also, SYS V init code is available to any
entity having a license to UNIX, or who can otherwise access the UNIX code.
77. I will now describe certain UNIX Executable and Linking Format (ELF) code
that is copied either identically or substantially similarly in Linux.
78. The ELF code is used for processing executables and object code.
In the code presented in Tables 7 - 11, comments (i.e., text
beginning with "/*" and ending with "*/") and other irrelevant information have
been omitted for clarity. Also, in some cases, the code lines and/or code
sections have been reordered for convenience. The code with comments and
other information can be seen in the attached Exhibits CC (UNIX code) and DD
81. The data shown in Tables 8 - 11 are additional examples of copying of UNIX
code in Linux.
Moreover, the portions of Linux that are direct copies of UNIX are the
meaningful, functional portions of the code
I declare under penalty of perjury that the foregoing is true and correct.
July 7, 2004
CERTIFICATE OF SERVICE
Plaintiff, The SCO Group, hereby certifies that a true and correct copy of
DECLARATION IN SUPPORT OF SCO'S OPPOSITIION TO IBM'S CROSS-MOTION
FOR PARTIAL SUMMARY JUDGEMENT was served on Defendant International Business
Machines Corporation on the 9th day of July, 2004, as follows:
By HAND DELIVERY:
Alan L. Sullivan, Esq.
Todd M. Shaughnessy, Esq.
Snell & Wilmer L.L.P.
Evan R. Chesler, Esq.
Cravath, Swain & Moore LLP
Donald J. Rosenberg, Esq.
CERTIFICATE OF SERVICE
Plaintiff/Counterclaim Defendant, The SCO Group, hereby certifies that a true
and correct copy of the foregoing was served on Defendant IBM on the 5th day of July, 2005
by U.S. Mail to:
David Marriott, Esq.
CRAVATH, SWAIN & MOORE LLP
Donald Rosenberg, Esq.
Todd Shaughnessy, Esq.
SNELL & WILMER L.L.P.