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 similar code.

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.

Plaintiff/Counterclaim-Defendant,

v.

INTERNATIONAL BUSINESS
MACHINES CORPORATION,

Defendant/Counterclaim-Plaintiff.

___________________________________

DECLARATION IN SUPPORT OF
SCO'S OPPOSITION TO IBM'S
CROSS-MOTION FOR PARTIAL
SUMMARY JUDGEMENT
[Docket No. 197]

(REFILED IN REDACTED FORM)

Case No. 2:03CV0294DAK
Honorable Dale A. Kimball
Magistrate Judge Brooke C. Welles

1

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.

2

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	TXu-510-028	03/25/92
2	Unix Operating System Edition 6 and Instruction Manual	TXu-511-236	04/07/92
3	Unix Operating System Edition 32V and Instruction Manual	TXu-516-704	05/15/92
4	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

3

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

4

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.

11.

REDACTED

5

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.

6

REDACTED

REDACTED

7

REDACTED

REDACTED

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

8

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,

9

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

10

30. I will now describe the user level synchronization (ULS) routines that are used for blocking and unblocking of processes.

REDACTED

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 shared data.

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.

36.

REDACTED

11

REDACTED

REDACTED

REDACTED

12

REDACTED

REDACTED

REDACTED

REDACTED

13

REDACTED

REDACTED

REDACTED

REDACTED

REDACTED

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

14

50. I now turn to instance of copying in Linux of UNIX System V IPC routines.

REDACTED

REDACTED

15

REDACTED

REDACTED

16

REDACTED

REDACTED

17

TABLE 1

REDACTED

TABLE 2

REDACTED

18

TABLE 3

REDACTED

TABLE 4

REDACTED

19

TABLE 5

REDACTED

TABLE 6

REDACTED

20

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.

66.

REDACTED

REDACTED

REDACTED

21

REDACTED

REDACTED

REDACTED

22

REDACTED

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.

75.

REDACTED

23

REDACTED

78. The ELF code is used for processing executables and object code.

REDACTED

REDACTED

24

TABLE 7

REDACTED

25

REDACTED

26

82.

TABLE 8

REDACTED

27

TABLE 9

REDACTED

TABLE 10

REDACTED

TABLE 11

REDACTED

28

REDACTED

REDACTED

29

July 7, 2004

---[signature]----
Sandeep Gupta

30

CERTIFICATE OF SERVICE

By HAND DELIVERY:

Alan L. Sullivan, Esq.
Todd M. Shaughnessy, Esq.
Snell & Wilmer L.L.P.
[address]

Evan R. Chesler, Esq.
Cravath, Swain & Moore LLP
[address]

Donald J. Rosenberg, Esq.
[address]

___[signature]___

31

CERTIFICATE OF SERVICE

David Marriott, Esq.
CRAVATH, SWAIN & MOORE LLP
[address]

Donald Rosenberg, Esq.
[address]

Todd Shaughnessy, Esq.
SNELL & WILMER L.L.P.
[address]

___[signature]___

32