decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal


User Functions

Username:

Password:

Don't have an account yet? Sign up as a New User

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Sandeep Gupta's Redacted Declaration of July 2004 - as text
Monday, July 18 2005 @ 06:26 AM EDT

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

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:

TITLEREG. No.REG. DATE
1 Unix Operating System Edition 5
and Instruction Manual
TXu-510-02803/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
6UNIXWARE 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
10UNIX 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
13UNIX SYSTEM V RELEASE 4.1 TX-5-762-234 07/03/03
14UNIX 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

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

4

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.

11.

REDACTED

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

5

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.

6

17.

REDACTED

18.

REDACTED

7

19.

REDACTED

20.

REDACTED

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

8

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,

9

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

10

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.

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

37.

REDACTED

38.

REDACTED

12

39.

REDACTED

40.

REDACTED

41.

REDACTED

42.

REDACTED

13

43.

REDACTED

44.

REDACTED

45.

REDACTED

46.

REDACTED

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.

REDACTED

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

14

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

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

REDACTED

51. IPC stands for Inter-Process Communication.

REDACTED

15

52.

REDACTED

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.

REDACTED

16

54.

REDACTED

55.

REDACTED

17

56.

TABLE 1

REDACTED

57.

TABLE 2

REDACTED

18

58.

TABLE 3

REDACTED

59.

TABLE 4

REDACTED

19

60.

TABLE 5

REDACTED

61.

TABLE 6

REDACTED

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.

20

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

66.

REDACTED

67.

REDACTED

68.

REDACTED

21

69.

REDACTED

70.

REDACTED

71.

REDACTED

22

72.

REDACTED

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

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

76.

REDACTED

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.

REDACTED

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 (Linux code). 79.

REDACTED

24

80.

TABLE 7

REDACTED

25

REDACTED

26

81. The data shown in Tables 8 - 11 are additional examples of copying of UNIX code in Linux.

82.

TABLE 8

REDACTED

27

83.

TABLE 9

REDACTED

84.

TABLE 10

REDACTED

85.

TABLE 11

REDACTED

28

86.

REDACTED

Moreover, the portions of Linux that are direct copies of UNIX are the meaningful, functional portions of the code

REDACTED

29

I declare under penalty of perjury that the foregoing is true and correct.

July 7, 2004

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

30

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.
[address]

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

Donald J. Rosenberg, Esq.
[address]

___[signature]___

31

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
[address]

Donald Rosenberg, Esq.
[address]

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

___[signature]___

32


  


Sandeep Gupta's Redacted Declaration of July 2004 - as text | 255 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections Here
Authored by: feldegast on Monday, July 18 2005 @ 07:10 AM EDT
So PJ can find them

---
IANAL
The above post is (C)Copyright 2005 and released under the Creative Commons
License Attribution-Noncommercial 2.0
P.J. has permission for commercial use

[ Reply to This | # ]

OT materials here please
Authored by: MadScientist on Monday, July 18 2005 @ 07:18 AM EDT
Thanks

[ Reply to This | # ]

OT: appeal permission?
Authored by: john hrdo on Monday, July 18 2005 @ 07:37 AM EDT
Friday, July 15, was the deadline
for SCO to seek permission to appeal
against Judge Kimball's decisions of
July 1.

Have they, have they not?

[ Reply to This | # ]

Sandeep Gupta's Redacted Declaration of July 2004 - as text
Authored by: Steve Martin on Monday, July 18 2005 @ 07:53 AM EDT

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.

So let me get this straight: Gupta is saying that, because man pages describing such things as the inittab contents are available for public viewing on the Internet, this makes the source code for "init" readily copyable? As PJ says, "Puh-leese!"

---
"When I say something, I put my name next to it." -- Isaac Jaffee, "Sports Night"

[ Reply to This | # ]

Sandeep Gupta's Redacted Declaration of July 2004 - as text
Authored by: kinrite on Monday, July 18 2005 @ 08:05 AM EDT
"Basically, it means that if there is only one way to do something, you
can't copyright it:"

Is this the reason that companies are trying to patent software features,
because the ideas they are trying to gain control of would not be copyrightable?

---
"Truth is like energy...it can not be created, nor destroyed"

[ Reply to This | # ]

Is he an expert witness or not?
Authored by: elronxenu on Monday, July 18 2005 @ 08:08 AM EDT
If he is not an expert witness then I see a substantial number of places in that declaration where he says something which is just his opinion or an attempt to justify some conclusion:

  • "I believe these topics either show copying of code or raise significant factual issues"...
  • "As represented to me, contributors to Linux had access to UNIX RCU" ...
  • "I believe that Mr. Slingwine would have used that access to UNIX development to" ...
  • "As represented to me, evidence that the Sequent RCU work was performed during the same time frame" ...
  • "Thus, I believe that UNIX RCU was copied into" ...

This is really a pitiful document. IBM was right to ask for it to be stricken from the record. Did the judge rule on that?

I have to wonder why SCO can't find a bona-fide expert who can testify on their behalf. Sandeep Gupta, an SCO employee, cannot pretend to have even a shred of impartiality in this case.

[ Reply to This | # ]

Using the manual pages...
Authored by: ff5166 on Monday, July 18 2005 @ 08:57 AM EDT
"Using the manual pages, a skilled programmer could copy the structure, sequence, and organization of SYS V init routines."

What is he talking about? I think he means infer not copy.
How can you copy something you can't see?

[ Reply to This | # ]

Sandeep Gupta's Redacted Declaration of July 2004 - as text
Authored by: Anonymous on Monday, July 18 2005 @ 08:59 AM EDT
I find this part to be rather funny.

24. [...] 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.[...]

So what came first, the chicken or the egg. Was there a UNIX RCU before the Sequent engineers developed a UNIX version of it?
Reading this makes it sounds like USL developed RCU and then hired Sequent to implement it. Or you of course go further and and trash his entire argument by saying that Sequent developed it outside of the OS framework and added it later after the fact, thus not in any way shape or form a derivative product.

[ Reply to This | # ]

Would a jury care?
Authored by: Anonymous on Monday, July 18 2005 @ 09:06 AM EDT

This is the big danger.

We all know the facts of all these cases should make
an SCO defeat a slam dunk.

But juries are free to ignore the facts. Will an average
juror be able to follow all this? This is why SCO is
telling lie after lie. A jury won't know the difference.



[ Reply to This | # ]

This just struck me..
Authored by: pooky on Monday, July 18 2005 @ 10:42 AM EDT

This just struck me:

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

Could this explain perhaps what SCO is actually aiming for? They might claim that since IBM programmers virtually made Linux into a business class OS, and that since IBM programmers almost certainly had unabated access to protected UNIX source code, and that since Linux is so similar to UNIX in functionality (in fact IBM stated this was a goal), that there must be infringement going on?

Maybe this is their fallback to get to court, claiming IBM won't turn over the infringing material and pleading this legal standard.

-pooky

---
Many Bothans died to bring us this information.

[ Reply to This | # ]

Sandeep Gupta's Groupings
Authored by: artp on Monday, July 18 2005 @ 10:47 AM EDT
Par. 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. "

That's a strange word to use - groupings.

Why does it make me think of pasting letters on a sheet of paper to spell out a
message? It's almost like a ransom note.

Or perhaps he was subconsciously thinking of groping for facts to support his
thesis.

[ Reply to This | # ]

Sandeep Gupta's Redacted Declaration of July 2004 - as text
Authored by: frk3 on Monday, July 18 2005 @ 11:59 AM EDT
<P>Mr. Sandeep:

<P>"5. I believe that ...."

<P>I believe that, Mr. Sandeep has no idea what he is talking about and
his "belief" about "substantial similarity" are absolutely
worthless in the context of (new)SCO's lawsuit. Not relevant and, his testimony,
since he is <i>not</i> and expert, should be completely tossed.

[ Reply to This | # ]

Maybe SCO should sue J K Rowling
Authored by: kawabago on Monday, July 18 2005 @ 12:29 PM EDT
I'm sure they could find just as much evidence that SCO Unix was copied into
Harry Potter and what a cash cow that has proved to be!


---
TTFN

[ Reply to This | # ]

New Readers Start Here
Authored by: Anonymous on Monday, July 18 2005 @ 12:33 PM EDT
Here is the CV of Sandeep (now Sandy) Gupta in two parts: firstly nearly up to joining SCO, and from then up to the time of making the Declaration.

Alan(UK)

[ Reply to This | # ]

Sandeep Gupta's Declaration's Real Value
Authored by: lightsail on Monday, July 18 2005 @ 12:38 PM EDT
This declaration has real value to Darl and others: It is the keystone of a defense against criminal charges.

Yes, we believed Sandeep Gupta and honestly thought that there was copyright infringment in the Linux kernel.

While this analysis will be of little value in the current civil lawsuits, it will be very valuable if this charade moves to the criminal courts.

[ Reply to This | # ]

Sandeep Gupta's Redacted Declaration of July 2004 - as text
Authored by: Anonymous on Monday, July 18 2005 @ 01:03 PM EDT
I read this as

it was copied
[redacted]
it was copied
[redacted]
it was copied
[redacted]
it was copied
[redacted]
it was copied
[redacted]
it was copied

All the meat cut out, nothing to show. There can only be one reason for this to
be put out in this state and that is FUD, pure and simple FUD. It merely
expresses opinion with NO facts. It is for external consumption not the courts.

Tufty

[ Reply to This | # ]

Sandeep is an expert? Who are SCO's others?
Authored by: Anonymous on Monday, July 18 2005 @ 01:17 PM EDT
Will SCO be forced to declare who it's expert witnesses are that it is going to
be
using besides Sandeep Gupta?

As I recall, IBM moved to strike Gupta as an expert witness. SCO tried to keep

him as a lay person giving testimony. However, this may not hold up once
discovery ends.

[ Reply to This | # ]

Sandeep Gupta's Redacted Declaration of July 2004 - as text
Authored by: seanlynch on Monday, July 18 2005 @ 01:24 PM EDT
Thanks for the text version.

While reading through this I kept imagining a loud 'beep' every time I
encountered the word 'REDACTED'.

It made reading the declaration like watching a version of a Quentin Tarantino
film edited for network broadcast.

More time spent 'beep'-ing than talking.

[ Reply to This | # ]

Off Topic RIAA & MPAA
Authored by: Anonymous on Monday, July 18 2005 @ 01:25 PM EDT
Digital Citizens: The film-maker
By Darren Waters
BBC News entertainment
reporter
http://news.bbc.co.uk/2/hi/entertainment/4100284.stm

Everybody knows the RIAA and MPAA are headed down the
wrong road but few
realize why.

Look at this BBC to see what armatures can do without the
MPAA's input.

Now consider that these people could have been from
anyplace on the earth and could be anyplace. Then consider
the relevance of
the MPAA and RIAA to this production.
Also consider if by some magical law
shaking scam that the
RIAA and/or MPAA manage to obtain IP rights to this
story
that in no diminishes the concept as all that would happen
is that
the story would be replaced with another one in
which the RIAA and/or MPAA
had no control.

[ Reply to This | # ]

It looks remarkably like a version of 'What Dogs Hear' by G. Larsen (n/t)
Authored by: Anonymous on Monday, July 18 2005 @ 01:54 PM EDT
.

[ Reply to This | # ]

This is hilarious...
Authored by: AHGrayLensman on Monday, July 18 2005 @ 02:39 PM EDT
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.
(Emphasis mine.)

Note what Gupta doesn't say. He doesn't say that the code from UNIX's SysV IPC implementation was copied into (or substantially similar to) Linux's SysV IPC implementation. He apparently doesn't understand the difference between implementing an interface and copying code.

--Troy

---
"You are finite, Zathras is finite, this... is wrong tool. No, not good, never use this!" --Zathras, "War Without End (pt. 2)", Babylon 5

[ Reply to This | # ]

Too Much Redaction?
Authored by: darkonc on Monday, July 18 2005 @ 03:28 PM EDT
They seem to have redacted all of the Linux code that was accused of being a copy. This is too bad, since this would possibly allow some people who know Linux well to figure out pinpint exactly where the code came from and how it was created.

---
Powerful, committed communication. Touching the jewel within each person and bringing it to life..

[ Reply to This | # ]

Reference for init, sysV ipc, etc.
Authored by: DebianUser on Monday, July 18 2005 @ 07:33 PM EDT
The claim that access to copyrighted sources is needed in order to come up
with code that behaves like a commercial Unix (or POSIX system) is clearly
false. Just look at:

"The Design of the Unix Operating System", by Maurice J. Bach, ISBN
0-13-201799-7 025, published by Prentice Hall, 1986.

As regards the spurious SCO claims now under discussion, this book contains
pseudocode for init.c, the format of /etc/inittab, as well as a chapter-length
discussion of the implimentation of SysV ipc, commonly called shared memory ipc
and semaphores.

The book generally discusses Unix system structure, and in particular
discusses subtle implimentation considerations. To claim any such information is
_not_ widely known and publically available is simply ridiculous.

[ Reply to This | # ]

What happened in Feb 2003?
Authored by: Anonymous on Monday, July 18 2005 @ 08:42 PM EDT
I've been trying to work out what happened between Jan 27, 2003 when SCO's 10K
was favorable towards linux and IBM, even including them as a strategic partner,
and March 6, 2003 when SCO files a lawsuit against IBM.

I also noted SCO have a habbit of putting stuff in their SEC filings that are
outsite the dates the filings are ment to cover.

Here's the timeline as I found it so far.

August 13, 2002 Michael Davidson email Saying no infringement found.

August 28, 2002 Jeff Gerhardt talks about Caldera/SCO name change.
http://www.linuxjournal.com/article/6293

From article: According to McBride, "obviously Linux owes its heritage to
UNIX, but not its code. We would not, nor will not, make such a claim."

January 27, 2003, 10K filed covering financial year ending October 31, 2002
indicating SCO still loved linux, IBM, and everyone else.

March 6, 2003 SCO Files Suit against IBM.

March 14, 2003, 10Q filed covering financial quarter ending January 31, 2003
indicating SCO announced on March 7, 2003 that it had filed suit against IBM for
misappropriation of trade secrets, tortuous interference, unfair competition and
breach of contract. In this filing SCO still loved linux, but not as much
indicated by the reduction in funding for reseach and developement into linux.

June 13, 2003, 10Q filed covering financial quarter ending April 30, 2003
indicating SCO suspended it linux sales, in May it sent out letters to 1500
companies basically saying their use of linux exposes them to
"unanticipated liability". Also the 10Q states "we became
concerned generally about the existence of UNIX source code in the Linux
operating system." SCOsource is also 1st mentioned in this 10Q. Also SCO
talks about suspending IBM's UNIX license in reguards to AIX.

[ Reply to This | # ]

Sandeep Gupta's Redacted Declaration of July 2004 - as text
Authored by: blacklight on Tuesday, July 19 2005 @ 05:22 AM EDT
Yep. Sandeep Gupta made his allegations of copying based exclusively on his
eyeballing of the Linux code. He did not apply ANY legal filtration standard
including Gates Rubber. The non-literal copying methodology that he used is
simply something that he pulled out of his butt.

On the basis of his credentials, Sandeep Gupta is a nobody. On the basis of what
he has done to prove copying, he has done nothing. On the basis of his
conclusions, he is dead wrong. To sum up, he is a nobody who has done nothing.
And he lied.

[ Reply to This | # ]

SCO's evidece found - at last
Authored by: Anonymous on Tuesday, July 19 2005 @ 12:13 PM EDT
From line 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'

A 'single line of nearly identical code'! There you have it,folks. That's
SCO's evidence of copyright violations.

[ Reply to This | # ]

  • Beg pardon... - Authored by: Anonymous on Tuesday, July 19 2005 @ 03:12 PM EDT
Have we missed something here?
Authored by: DaveJakeman on Tuesday, July 19 2005 @ 05:35 PM EDT
"I declare under penalty of perjury that the foregoing is true and
correct."

Hence the extensive use of the subjunctive and qualifying terms like "I
believe..."

The declaration comes across as either incredibly naïve, or he was told what its
conclusions were in advance and somehow had to make his findings fit those
prescribed conclusions.

"I declare under penalty of perjury that the foregoing is true and
correct."

Hmmm...

He repeatedly makes the substantial jump in logic that "A is substantially
similar to B, therefore B was copied from A", when in fact the only
conclusion one could accurately draw, if it were true, is that "A is
substantially similar to B".

If it were true.

Anyway, now to my point:

Take two 100,000 line programs written in Fortran. It doesn't matter what they
do, nor who wrote them. In both those programs, you would find coding
statements that were "substantially similar". Statements like:

X = 0.

J = 0

I = I + 1

DO I = 1, n

10 CONTINUE

9000 FORMAT (X,A)

That's not routines, or methods, or processes, but actual lines of code,
identical or similar, in two entirely different programs written by different
people to fulfill different requirements. These are statements that are to some
degree written under the free choice of the programmer. I dare say that in two
such programs of 100,000 lines, you might find 50 or more lines that were
"substantially similar" or even identical. But what does that prove?

In any given programming language, there are a large number of ways of
expressing (implementing) different ideas (almost as many as there are different
ideas), but the number of variations on a particular line of code is severely
restricted by the language syntax itself. Lines of code are not like the
complete sentences in this paragraph, which you might not find anywhere else on
the internet, for example (unless it's been copied without my permission!); a
line of code is typically short and its structure and content greatly
constrained by the programming language. Much more so than the English
language, which is rich in its various forms of expression. For example, one
could write, "I = I + 1; J = J + 1", which might make some sense in
English, but not in Fortran. In Fortran, it would need to be simpler for the
compiler to interpret it successfully. So of course, in two substantial
programs written in the same language, "substantially similar" or
identical lines of code will appear. That's the nature of programming languages
and the constraints imposed by them.

Now how many lines of code are there in the Linux kernel?

---
Should one hear an accusation, first look to see how it might be levelled at the
accuser.

[ Reply to This | # ]

Whatever happened to Wolfgang Bauer?
Authored by: Anonymous on Tuesday, July 19 2005 @ 11:43 PM EDT
Sandeep Gupta is the Vice President of Engineering. Apparently he replaced
Wolfgang Bauer, who was the VP on Engineering until July 2004. Coicidentially,
Sandeep's promotion occured the same month as his declaration.

Does anyone know if Wolfgang Bauer made a declaration? Whatever happened to
Wolfgang Bauer?

According to a press release...

Bauer will retire from SCO on July 31, 2004, ending a 45-year career in the
computer business. He's worked with AT&T Bell Labs, Bellcore (Telcordia),
and Northern Telecom. His employment has involved work for the US Army, US Air
Force, US Postal Service and other engineering applications. Bauer has been an
integral part of the SCO engineering team for many years. His experience with
working on the UnixWare operating system since 1990 has benefited SCO's
engineering team and furthered its progression.

The same press release says...

Michael Davidson, SCO operating system architect, has contributed greatly to
SCO's development since 1987 and will now report to Gupta.

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )