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

Gear

Groklaw Gear

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


You won't find me on Facebook


Donate

Donate Paypal


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
Randall Davis' Declaration - as text
Friday, September 10 2004 @ 01:57 AM EDT

Here is the Randall Davis Declaration in all its glory, as text, thanks to David Truog, who transcribed and did the HTML, and constant, who did the proofreading for us. It is submitted in support of IBM's motion for partial summary judgment of non-infringement of copyright with respect to IBM's Linux activities, which will be heard next week.

The purpose of this document could be summed up quite simply: to refute Chris Sontag's claims that SCO needs more time for discovery and more information from IBM and third parties.

If they want to do a code comparison (which of course they told the media last year they had already done every which way but Tuesday), then they have all the code they need already. They have their copyrighted code (assuming arguendo that they actually own the copyrights), and Linux is publicly available. Compare the two and you're done.

In point of fact, he says, "Mr. Sontag's own declaration acknowledges that SCO has used one or more of the existing tools to do the requisite comparisons" of the Unix and Linux code, but tellingly this world-renowned expert says, "SCO has yet to present any credible examples of substantial similarity." If they have already done the comparison, why do they ask for more time? And, adds Mr. Davis, this is about IBM's Linux activities, not AIX or Dynix. So SCO's request for more than 2 billion more lines of AIX and Dynix code isn't going to help them find similarities between Linux and SCO's Unix. They don't own the copyright on AIX and Dynix, and this motion is about non-infringement of their copyrights, so however much SCO pines to look at all versions of AIX and Dynix, they are not relevant to the task at hand.

The general rule is that if you fail to bother to do discovery, you can't cry for more time when the clock runs out. So if they didn't do the comparison, the question will be why not, and was it negligent enough that they deserve to lose their chance now? Alternatively, if they are sitting on discovery materials, pretending they don't have anything, in order to delay or perhaps hoping for a dramatic Perry Mason moment later, things may not work out well for them in the end, since that would be a discovery no-no.

One of the most important things he explains to the judge is that obfuscation is easier said than done. It's one thing to copy a sentence in a book, change a word or two, and call it your own. That might work just fine in literature, if you have no pride and no conscience. The sentence still works. But in software, he says, "purposeful obfuscation on a large scale is nearly impossible", and you can't just grab some Unix code and toss it in Linux and expect it to work. The slightest change can bring the entire house of code falling down, and the larger the program, and the more complex it is -- and Linux is both large and complex -- the greater the likelihood of breaking things. In short, he pretty much tells the court that Sontag is greatly mistaken at best. The opening section isn't bragging, by the way. It's how you establish an expert's credentials. If Mr. Davis eventually testifies at trial, for example, they will start by asking him questions to elicit the same biographical information. It's legal, not PR.

We made one alteration to this document, by adding links to the web pages cited in the table and to the web sites and cases listed in the references. I normally don't change a thing in the legal documents filed, but in this case, it seemed useful, as long as you know that the paper version obviously doesn't do that.

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


SNELL & WILMER LLP
Alan L. Sullivan (3152)
Todd M. Shaughnessy (6651)
[address, phone, fax]


CRAVATH, SWAINE & MOORE LLP
Evan R. Chesler (admitted pro hac vice)
David R. Marriott (7572)
[address, phone, fax]


Attorneys for Defendant/Counterclaim-Plaintiff
International Business Machines Corporation


IN THE UNITED STATES DISTRICT COURT
FOR THE DISTRICT OF UTAH

THE SCO GROUP, INC.

     Plaintiff/Counterclaim-Defendant,

-against-

INTERNATIONAL BUSINESS
MACHINES CORPORATION,

     Defendant/Counterclaim-Plaintiff
DECLARATION OF
RANDALL DAVIS


Civil No. 2:03CV-0294 DAK

Honorable Dale A. Kimball

Magistrate Judge Brooke C. Wells

I. INTRODUCTION

1. I am a professor of Computer Science at the Massachusetts Institute of Technology in Cambridge, Massachusetts. Exhibit I provides more details of my technical background and experience, a list of publications, and a list of cases in which I have testified or been deposed. I received my undergraduate degree in Physics from Dartmouth College in 1970 and a Ph.D. in Computer Science from Stanford in 1976.

2. I have published some 50 articles on issues related to artificial intelligence and have served on several editorial boards, including Artificial Intelligence, AI in Engineering, and the MIT Press series in AI. I am a co-author of Knowledge-Based Systems in AI.

3. In recognition of my research in artificial intelligence, I was selected in 1984 as one of America's top 100 scientists under the age of 40 by Science Digest. In 1986 I received the AI Award from the Boston Computer Society for contributions to the field. In 1990 I was named a Founding Fellow of the American Association for AI and in 1995 was elected to a two-year term as President of the Association. From 1995-1998 I served on the Scientific Advisory Board of the U.S. Air Force.

4. In addition to my work with artificial intelligence, I have also been active in the area of intellectual property and software. Among other things, I have served as a member of the Advisory Board to the US Congressional Office of Technology Assessment study on software and intellectual property, published in 1992 as Finding a Balance: Computer Software, Intellectual Property, and the Challenge of Technological Change. I have published a number of articles on the topic, including co-authoring an article in the Columbia Law Review in 1994 entitled "A Manifesto Concerning Legal Protection of Computer Programs" and an article in the Software Law Journal in 1992 entitled "The Nature of Software and its Consequences for Establishing and Evaluating Similarity."

5. From 1998-2001 I served as the chairman of the National Academy of Sciences study on intellectual property rights and the emerging information infrastructure entitled The Digital Dilemma: Intellectual Property in the Information Age, published by the National Academy Press in February, 2000.

6. I have been retained as an expert in over thirty cases dealing with alleged misappropriation of intellectual property, such as the allegations raised in this case, and have done numerous comparisons of code. I have been retained by plaintiffs who have asked me to investigate violations of intellectual property, by defendants who have asked me to investigate allegations made against them, and by both sides to serve as the sole arbiter of a binding arbitration.

7. In 1990 I served as expert to the Court (Eastern District of NY) in Computer Associates v. Altai, a software copyright infringement case that articulated the abstraction, filtration, comparison test for software. I have also been retained by the Department of Justice on its investigation of the INSLAW matter. In 1992 (and later in 1995) my task in that engagement was to investigate alleged copyright theft and subsequent cover-up by the Federal Bureau of Investigation, the National Security Agency, the Drug Enforcement Agency, the United States Customs Service, and the Defense Intelligence Agency.

8. I have been retained by counsel for IBM in this lawsuit and am being compensated at a rate of $550 per hour.

II. SUMMARY OF FINDINGS

9. I have been asked by counsel for IBM to evaluate the opinions set out in the declaration of Chris Sontag submitted in opposition to IBM's motion for partial summary judgment of non-infringement of copyright with respect to its Linux activities. Specifically, I have been asked to address Mr. Sontag's conclusions concerning what information is required in order to determine whether there is substantial similarity between Linux and SCO's allegedly copyrighted works.

10. My analysis and conclusions are based upon the principles described in Gates Rubber v. Bando, 9 F.3d 823 (10th Cir. 1993), which I understand to describe the appropriate methodology for determining substantial similarity and therefore to suggest what information is required to determine substantial similarity. My analysis and conclusions are also based upon my experience and expertise in the field of computer science.

11. In summary, I find fundamental errors in Mr. Sontag's conclusions. He grossly exaggerates what is required to determine whether there is substantial similarity between Linux and SCO's allegedly copyrighted works. In fact, the materials necessary to determine substantial similarity have been available to SCO for years (at least since it acquired access to the allegedly copyrighted works in 2001). Tools capable of efficiently evaluating that material have also been publicly available to SCO for years. The task Mr. Sontag says could take 25,000 man-years to complete should take capable programmers no more than several months.

12. The first section of this report describes my background and qualifications to address the issues addressed herein, while the second analyzes Mr. Sontag's declaration and demonstrates the errors in his conclusions concerning the magnitude of the effort required to determine substantial similarity.

III. ANALYSIS OF THE SONTAG DECLARATION

13. Mr. Sontag correctly concludes that determining substantial similarity requires a comparison of the Unix and Linux kernels. (¶¶6-8.) He is incorrect, however, in concluding that the comparison requires a Herculean effort and that the only way SCO can feasibly conduct the comparison is if it is provided large quantities of additional information from IBM and from third parties.

14. As Mr. Sontag states in paragraph 8 of his Declaration: "To show that Linux code is substantially similar to Unix code requires a comparison of that code..." Common sense supports that statement. Moreover, the Gates Rubber case is clear that determining substantial similarity requires a comparison of the works under consideration. 9 F.3d at 838-39.

15. Mr. Sontag acknowledges that SCO has access to both Linux and the allegedly copyrighted works. (¶¶19-23.) This is of course no surprise, as Linux is publicly available to everyone, and at least until recently, SCO was itself a distributor of Linux. As the alleged copyright holder, SCO must have copies of the allegedly copyrighted works.

16. Mr. Sontag goes on, however, to characterize as essentially impossible the task of comparing Linux to the allegedly copyrighted works, at one point suggesting that comparing just one version of the Linux kernel to one version of the Unix kernel "could take on the order of 25,000 man-years." (¶ 14.) He then proposes a "shortcut" (¶ 15): "comparing similar directory structures of the Unix and Linux operating systems," and immediately indicates that this "shortcut" would still take "about 35 man-years," and then only if the file names and the organization of all of the Linux kernel code were identical to the file names and organization of the Unix kernel code.

17. As I explain below, (1) the task of comparing Unix to Linux (for purposes of determining substantial similarity) is a manageable undertaking that could be accomplished by capable programmers, with the materials that have been available to SCO for years, in no more than several months; and (2) the additional materials that Mr. Sontag says are required so that the comparison will not endure for 25,000 more years are in fact absolutely unnecessary. The reasons offered by Mr. Sontag to explain why SCO has not been able to complete the task of determining substantial similarity are untenable.

III. 1 Feasibility of the Task

18. As stated, SCO has had, since before the initiation of this case, all the raw material it needs to find any alleged substantial similarity between Linux and Unix. It of course has all relevant versions of Unix; it can get any version of the Linux kernel from publicly available web sites. As one example, www.linuxhq.com contains every version of the Linux kernel since the original 1.0.0 and a complete history of every change made to every kernel file over its entire development history. Exhibit II contains a sample listing from that site, showing the entire development history for the file /fs/inode.c through 1081 kernel versions.1

19. There are a number of tools that are publicly available (in both executable and source code form) to compare large, complex programs for the purpose of determining substantial similarity. Three common varieties of tools used successfully in a number of cases like this one include:

  • Comparing an exhaustive list of identifiers from both programs. It is a simple matter technically to assemble a complete list of every "word" in a body of source code (i.e., every variable name, function name, data structure name, field name, etc.), even one as large as those in use here. A list is created for each program and then compared (by the computer) to find words that show up in both lists. That list of terms in common can then be scanned to find "unusual" words (i.e., words not routinely found in code, or in the application in question), and the places where those unusual words are found in the text then become places to look for possibly copied code. As this process typically includes the (English) text contained in comments in the code, it at times even finds places where code has been changed, but comments left unchanged. As a result, it uncovers instances of copying that infringers may have thought they had obscured.
  • Using tools that do literal or near-literal comparisons (e.g., COMPARATOR [1]). There are a variety of tools available to do this; they can be "tuned" to, for instance, ignore differences in spacing and layout (an issue raised by Mr. Sontag ¶ 11), ignore comments in the code, etc. SCO acknowledges using such tools, but misrepresents their utility. They are in my opinion quite effective.
  • Using tools that do syntactic comparisons (e.g., SIM [2]). By syntax I mean the structure of the code, analogous to notions of noun, verb, adjective, etc., in English. Such tools find code with the same structure, ignoring entirely the actual names that have been used, and hence can be very effective even where code has been modified.

20. In an attempt to show that SCO could not possibly compare the works at issue without more time and information, Mr. Sontag states that existing tools may not detect minor changes in the code (¶ 11), are subject to false positives (¶ 13) and will require years to implement unless SCO is afforded more information (¶¶ 14-15).

21. First, the existing tools are entirely adequate, even accepting the observation (¶ 11) that minor changes can prevent an absolutely literal matching process from being effective. There are several reasons why the existing tools will do the job. Despite SCO's implication, one cannot casually change punctuation, rename variables, change spelling, alter the text (whatever that means), or insert, delete, or reorder lines of code (¶ 11). Code is extremely brittle and thus is in some respects quite similar to a complex and intricately designed mechanical device, like a finely made wristwatch. One can no more casually change punctuation, insert, delete, or reorder lines of code than one could casually insert, delete, or reorder the parts in the watch and still expect it to work.

22. Software development is difficult in large part exactly because the code has to be just right. In the C language (in which both Unix and Linux are written), for example, a semicolon means something very different from a comma: substituting one for the other changes the modified code completely (and very likely breaks it). Similarly, a single equal sign '=' means one thing, but two of them in a row '==' mean something entirely different. Hence even a minor typo can go unnoticed (because it can produce a syntactically valid program), yet wreak havoc on program behavior. Programmers routinely have the experience of serious and obscure malfunctions arising out of the simplest typographical mistake, or out of the well-intentioned act of making a small change to code. Code is sensitive to even slight alterations; changes are not easy to make.

23. This is one reason why, while it is in principle possible to copy code and then purposely obscure its origin, that practice is generally carried out on programs at the scale of freshman homework assignments (where it is more easily detectable than freshmen think), not sections of multi-million line operating systems. Especially where large, complex programs are concerned, changes are that much more difficult to make, and purposeful obfuscation on a large scale is nearly impossible.

24. Second, while all of these tools are subject to the problem of false positives, i.e., suggesting copying where none exists, with appropriate tuning and use the percentage of false positives can be kept well within reasonable bounds. Despite SCO's claims, checking those false positives need not be labor intensive: programs are easily created to present the alleged matches in a side-by side fashion on the screen, allowing an experienced programmer to determine with little more than a glance whether each match is worth further study. An experienced programmer can quickly scroll through a substantial amount of information to find any plausible matches.

25. Third, the existing tools could have been employed here in a reasonably short time period without any additional information. In fact, based on my experience, I estimate that the task would take experienced programmers a matter of months.

26. Fourth, the existing tools have been designed by experienced programmers who are aware of the kinds of modifications that can be made to code that may make its origin less obvious. The tools are capable of dealing with the sorts of things that concern Mr. Sontag (¶ 11), such as differences in spacing and layout, variations in uppercase vs. lowercase, and comments in the code. The tools thus do both literal and non-literal matching, and are not misled by a variety of changes. There are also tools like SIM, noted above, that match based on syntax and hence are not misled by such things as renaming a variable, changing spelling, etc. (¶ 11). The existing tools are thus fully capable of doing the job. Given the claimed volume of the alleged copying, finding any copying that exists should not be a difficult task.2

27. Mr. Sontag poses the problem as if no results will be known until the entire comparison task is complete. Even if the entire task were daunting (which it is not), if "much" of SCO's 3.5 million lines of code were copied (¶ 47), this would imply that there must be thousands of examples waiting to be found, and hundreds able to be found after a modest amount of effort. Mr. Sontag's own declaration acknowledges that SCO has used one or more of the existing tools to do the requisite comparisons (¶¶ 18, 21-23), but SCO has yet to present any credible examples of substantial similarity.

28. It would appear, in fact, that SCO completed months ago some of the very comparisons that Mr. Sontag says might take 25,000 man years. For example, on June 10, 2003, a SCO representative stated that it "was able to uncover the alleged violations by hiring three teams of experts, including a group from the MIT math department, to analyze the Linux and Unix source code for similarities" and that '"[a]ll three found several instances where our Unix source code had been found in Linux'". (Robert McMillan (quoting SCO), "SCO shows Linux code to analysts," IDG News Service, June 10, 2003.)

29. Having concluded (incorrectly, I believe) that it is impossible as a practical matter to determine whether there is substantial similarity in the Unix and Linux kernels, Mr. Sontag states that the only way for SCO to determine substantial similarity is to get a vast amount of additional materials from IBM and a number of other individuals or entities. In fact, none of this additional material identified by Mr. Sontag is necessary to the substantial similarity task.

III.2.1 No Additional Information from IBM Is Needed

30. Mr. Sontag states (¶¶ 43, 50) that SCO requires the following additional materials from IBM:

  • all version control system and bug tracking information (including documents, data, logs, files and so forth) for AIX, Dynix/ptx, ptx, and Dynix from 1984 to the present,
  • source code and log information for all interim and released versions of AIX, Dynix, ptx and Dynix/ptx from 1984 to the present,
  • depositions as appropriate for programmers identified from the foregoing,
  • all design documents, white papers, and programming notes, created from 1984 to the present.

31. This information is irrelevant to SCO's task in the current context, which is showing that IBM's Linux activities infringe SCO's alleged copyrights in Unix software. The similarity to be demonstrated is between the claimed Unix software and Linux; the history of AIX and Dynix development plays no part in this judgment.

32. Having access to all of the materials concerning AIX and Dynix to which Mr. Sontag refers in his declaration (which appears to be a huge amount of information) would not, in my opinion, be of any assistance in determining whether Linux is substantially similar to Unix. Those materials are not useful for the task at hand.

33. As I understand the concept, and as is only logical, substantial similarity must be a determination about two bodies of code as they are, not a question of their heritage. Any given segment of Linux code either is or is not substantially similar to a given body of Unix code; it is irrelevant to the determination of similarity how the Linux code came to look the way it does. So even if it is true that some code that came to be included in Linux originated in AIX or Dynix, that is simply not important to the analysis of whether that Linux code is in fact similar to any Unix code.

34. To suggest otherwise leads to the absurd notion that one work can be considered similar to another even if the two are currently completely different, if only one can show a (perhaps very long) sequence of small changes that lead from one to the other. This would be like playing the game of "telephone," in which a sentence is successively whispered from one person to the next in a long line, and claiming that, even though the sentence that emerged was totally different from the one that started the process, they were "substantially similar" because the last was the result of many small changes to the first. Similarity means just that—similarity. And the determination of similarity is made on the code as it is, independent of how it got that way.

35. Yet this is not what Mr. Sontag apparently has in mind, as he claims that "By viewing each version of the Dynix/AIX code, SCO will be better able to determine if the structure, sequence, and organization of the corresponding Linux code matches that of Unix." (¶ 35.) The structure, sequence and organization of some Linux code either does or does not match that of some part of Unix code; that judgment is surely not dependent on the derivation history of the code. Again, information relating to AIX and Dynix, let alone extremely detailed information about AIX and Dynix, is not useful to the analysis of whether portions of Linux are substantially similar to portions of Unix.

36. Consider also Mr. Sontag's indication (¶ 30) that "Because of changes made to source code over time, the current code version may 'look' different than the initial code version." He slides too quickly here past the possibility that, because of changes to source code over time, the current code version may in fact be different, i.e., no longer substantially similar. The changes made to correct bugs, improve features, add new features, or as a consequence of re-thinking the design of a section of the code, may over time simply produce code that is completely different from the original.

37. Note also that the claim of the utility of intermediate versions and change logs skips blithely past a central point: in order to find any places where Unix code might have been copied into AIX or Dynix, SCO will have to compare all of its Unix code against all of the AIX or Dynix code. How else will it find all the similarities? But it is worse than that: SCO will have to compare all of its Unix code against every version of the AIX or Dynix code; after all, Mr. Sontag has noted (¶ 48) that "IBM could have copied System V code into any number of the multiple versions of AIX and Dynix."

38. Here the basic contradiction in SCO's request becomes particularly clear. Mr. Sontag spends substantial space in his declaration suggesting that the task of comparing one version of Linux against one version of Unix is impossibly large. Given the IBM materials I understand SCO already has in hand—notably the many versions of Dynix and AIX that I understand IBM has produced—the task SCO proposes is many, many times larger than the one it claims is far too difficult. And yet SCO requests, among other things, "source code and log information for all interim and released versions of AIX, Dynix, ptx and Dynix/ptx from 1984 to the present," and "[a]ll design documents, white papers, and programming notes, created from 1984 to the present." (¶ 50.) If the original task of finding substantial similarity in one version is pragmatically impossible, what are we to make of a task many times larger, and one that is perhaps many, many times larger again than that? SCO seems in one breath to claim the task is too large and with the next claim that the task would become feasible if only it had a volume of information perhaps many, many times larger than what it already possesses.

39. It is estimated that the additional AIX and Dynix source code that SCO seeks exceeds 2 billion lines of code. Based upon the estimates Mr. Sontag used to arrive at his 25,000 man-years calculation, it would take SCO more than 14 million man-years to review just the additional AIX and Dynix code that SCO says it needs, putting aside how many more man-years it would require SCO to review the other materials it says it needs.3

III.2.2. No Additional Information From Others Is Needed

40. As voluminous as the list of materials SCO seeks from IBM is, it is dwarfed by the request for additional information from other parties (¶ 57):

  • "Determine what third parties IBM has partnered with to develop Linux and what work those groups have done . . . particularly as to the details of the partnering, such as which party makes what contribution, the motivation for the contribution, and the starting and ending code versions that resulted from the partnership. . . ."
  • "Take discovery on Linus Torvalds, the purported creator of Linux, about the contributors and contributions to Linux since its inception, and the maintenance of any records about the development history of Linux. Mr. Torvalds is expected to have detailed records of these contributors and their contributions, material that is not publicly available. Further, Mr. Torvalds can answer specific questions as to what each contributor intended, and where and how the contributor acquired or developed the derived code."
  • "Take discovery on the maintainers of the kernels... ."
  • "There are many contributors to the kernels, some of who [sic] have significant contributions to Linux code over the years. Some of these individuals, whose names are publicly available, should be deposed to find out their sources for their contributed code."
  • "Many corporations have made contributions to Linux, and SCO needs to take their discovery on certain of these companies to determine the sources of their contributions. Also, SCO needs to depose the programmers who work for these companies and made the contributions to determine the sources of those programmers' code contributions...."
  • "SCO has identified some, but not all, independent authors of various portions of the Linux code.... Those authors should know the sources of their code and should be able to provide information as to whether the code they contributed to Linux was obtained from SCO copyrighted code."
  • "Several private groups also made major contributions to Linux, so SCO should also be permitted adequate time to identify and take discovery from these entities."
  • "Many organizations exist whose purpose is to track and report on changes to Linux... SCO needs access to the more detailed information these organizations maintain. . . ."
  • "Licensees and former licensees of Unix source code to see if these entities, their employees, or former employees are contributing Unix code to Linux."

41. This list, too, is striking, for a number of reasons. First, while the information requested from IBM would make SCO's task many times larger than it is, the request for this third-party information would surely magnify SCO's task still more. Consider, for example, just the last item, requesting materials from "Licensees and former licensees of Unix source code to see if these entities, their employees, or former employees are contributing Unix code to Linux." (¶ 57.)

42. Second, Mr. Sontag provides vanishingly little rationale for this voluminous request, which is not surprising, as the requested information is irrelevant to the task at hand. Once again, the task at hand is finding substantial similarity between Unix and Linux as it is now. Gathering information regarding the entire development history of Linux, including from potentially hundreds or even thousands of individuals, would not merely require a considerable amount of time, it would be of little or no meaningful assistance. The notion, for example, that "Mr. Torvalds can answer specific questions as to what each contributor intended, and where and how the contributor acquired or developed the derived code," suggests a wholly unrealistic picture of any mortal and of the code development process. The task would be done far faster, and the time better spent, if SCO were simply to put even part of the effort imagined by Mr. Sontag to the task of comparing the Unix and Linux source code SCO already has.

43. Finally, the vast bulk of the information Mr. Sontag lists—and far more information than is necessary to determine substantial similarity - has long been accessible to SCO. Table 1 below lists a collection of web sites with archives of Linux code, mailing lists maintained by kernel authors (indexed by contributor), etc., that covers much of what has been requested and certainly more than SCO could possible need.

Table 1: List of Readily Available Sources of Information on Linux

V. SUMMARY

44. Mr. Sontag grossly exaggerates what is required to determine whether there is substantial similarity between Linux and SCO's allegedly copyrighted works. The materials necessary to the task have been available to SCO for years and tools capable of evaluating that material in a matter of months have also been available to SCO for years.

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


___[signature]___
Randall Davis
Date: 23 August 2004
Place: Weston, Massachusetts

VI. REFERENCES AND MATERIALS CONSIDERED


References

[1] Eric S. Raymond, Resource page for COMPARATOR 2.0.
http://www.catb.org/~esr/comparator/

[2] Dick Grune, The software and text similarity tester SIM.
http://www.cs.vu.nl/~dick/sim.html

Materials Considered

Computer Associates v. Altai, 982 F.2d 693 (2d Cir. 1992)

Gates Rubber, Inc., v. Bando American, Inc., 9 F.3d 823 (10th Cir. 1993)

Mitel, Inc. v. Iqtel, Inc. 124 F.3d 1366 (10th Cir. 1997)

References listed above

Web sites listed in Table 1 above

Declaration of Chris Sontag in Support of SCO's Opposition to IBM's Motion for Partial Summary Judgment, undated


1 In the on-line listing, each version number is a link to a file showing exactly what changes were made to go from one version to the next.

2 For example, Mr. Sontag claims that "SCO believes that much of its copyrighted code was copied from AIX and Dynix into Linux." (¶ 47.)

3 Mr. Sontag (¶ 14) states that comparing the 4 million lines of code in the Linux 2.4 kernel with the 3.4 million lines of code in SCO's Unix System V 4.2 MP kernel would require the comparison of 66,000 x 58,000 pages (assuming about 60 lines of code per page), and that a "initial" review of the code, assuming that each page comparison takes one minute, could take 25,000 man-years to complete. (66,000 x 58,000 equals 3,828,000,000 minutes, or 63,800,000 hours—SCO's calculation of 25,000 man-years thus implies a man-year of approximately 2,552 hours.) The approximately 2 billion lines of additional AIX and Dynix code would result in approximately 33,333,333 (again, using SCO's assumption of 60 lines of code per page) pages of code. SCO's suggested method of comparing code would thus require 66,000 x 33,333,333 = 2,199,999,978,000 minutes, or 36,666,666,300 hours, or 14,367,815 man-years to complete.


  


Randall Davis' Declaration - as text | 237 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
CORRECTIONS HERE
Authored by: caliboss on Friday, September 10 2004 @ 03:42 AM EDT
=-=-=-=-=-=-=-=-=-=-=-=

---
Grok the Law / Rock the World

[ Reply to This | # ]

OT HERE
Authored by: caliboss on Friday, September 10 2004 @ 03:45 AM EDT
-=-=-=-=-=-=-=-=-=-

---
Grok the Law / Rock the World

[ Reply to This | # ]

large scale obfuscation infeasible
Authored by: Anonymous on Friday, September 10 2004 @ 04:15 AM EDT
23. This is one reason why, while it is in principle possible to copy code and then purposely obscure its origin, that practice is generally carried out on programs at the scale of freshman homework assignments (where it is more easily detectable than freshmen think), not sections of multi-million line operating systems. Especially where large, complex programs are concerned, changes are that much more difficult to make, and purposeful obfuscation on a large scale is nearly impossible.
This is a very strong argument judging from my developer perspective. SCOX tries to imply that some large scale obfuscation took place which might appeal as a valid argument to someone not familar with programming within large systems.

The only reasonable possibility for large scale obfuscation would be to program a tool doing it. But this requires a lot of evil intention and still a lot of other developers and project members would notice. This would leave a company at great risk if employees later turn against the company etc.pp. From my talks to IBM developers and employees i find such large scale obfuscation and then contributing the stuff to GPLed Linux less likely then the internet imploding today.

Clingon

[ Reply to This | # ]

Somewhat verbose
Authored by: Anonymous on Friday, September 10 2004 @ 04:16 AM EDT
It really boils down to this. Either the source is 'substantially similar' (the
criteria for infringement) or it is not.

If it is substantially similar, SCO can show that right now by running a few
freely available tools that check specifically for substantial similarity on the
source already in their possesion.

If it is not substantially similar, they have no case.

That's basically what Dr Davis is saying, but he takes a long time to get there.
Then again, he is getting paid $550 an hour, so who can blame him?

[ Reply to This | # ]

Randall Davis' Declaration - as text
Authored by: jmc on Friday, September 10 2004 @ 05:18 AM EDT
I'm sorry to keep on about this point, but it never seems to get mentioned.

SCO seem to be saying: suppose there are L lines of code in a given version of
the Linux kernel, and there are U lines of code in the Unix one. Then you need
to compare L x U lines.

But this is wrong:

(a) because it is meaningless to compare blocks of code which do radically
different things - eg part of kernel scheduling in Linux with terminal drivers
in Unix, assembler interrupt handling in Unix with file systems in Linux.

(b) because there are numerous parts of Linux where things are supported which
SCO's Unix does not support - USB is an obvious example. Such things, and
anything in Unix which Linux doesn't support (not that I can think of anything)
should in my view be excluded.

That narrows down the areas of comparison hugely in my view, to be Order-N,
where N is a few hundred thousand, rather than Order-N-squared where N is
several million.

[ Reply to This | # ]

Randall Davis' Errors
Authored by: elderlycynic on Friday, September 10 2004 @ 05:27 AM EDT
Hmm. At a quick glance, I can spot two errors in that declaration,
but frankly they don't do more that reduce its force by a
few percent. One is almost pure nitpicking, and only the
other is a matter of consequence.

To establish my credentials (and identify me to Anyone In The
Know), I was one of the first few (probably two) people to write
a viable general-purpose file comparison program - and it was
not diff :-)

15. Mr. Sontag acknowledges that SCO has access to both Linux and
the allegedly copyrighted works. (19-23.) This is of course no
surprise, as Linux is publicly available to everyone, and at least
until recently, SCO was itself a distributor of Linux. As the
alleged copyright holder, SCO must have copies of the allegedly
copyrighted works.

Not so. A,T&T sold licences to use several of their copyright
programs (including the original System/360 C compiler) for over
two years after they had lost all copies of the source. Yes,
really :-)

23. This is one reason why, while it is in principle possible to
copy code and then purposely obscure its origin, that practice is
generally carried out on programs at the scale of freshman
homework assignments (where it is more easily detectable than
freshmen think), not sections of multi-million line operating
systems. Especially where large, complex programs are concerned,
changes are that much more difficult to make, and purposeful
obfuscation on a large scale is nearly impossible.

Now, THAT is complete nonsense, and he should have known
better. All that is needed is to compile the code and code
generate it into source. That is standard technology, and has
been for at least 45 years. Such an obfuscating compiler can
strip comments, rename identifiers and change data and control
structures to ones that are functionally equivalent but
syntactically and visually completely different.

One example of a source-to-source compiler that is used on
multi-million line commercial programs is NAG Fortran 95.
For reasons too technical for Groklaw, doing the same for the C
source of an operating system would be significantly harder,
but it is still feasible. He IS correct, as far as I know, in
saying that there are no industrial-strength, obfuscating C
compilers around, but it would be a trivial exercise to add
such a back end to gcc. Probably only a few man-years, and
not needing any unusual skills.


[ Reply to This | # ]

Randall Davis' Declaration - as text
Authored by: Anonymous on Friday, September 10 2004 @ 06:35 AM EDT
While I believe that the extremely qualified Professor’s declaration about
comparing the OS sources in question is accurate... I am not convinced by the
corollaries. For example, the idea that you can exchange words in literature to
disguise plagiarism but that this is not possible in software. To me this
argument doesn’t hold – for starters there are automated tools to re-factor the
names of variables types and functions. Pretty-print tools serve as a proof of
concept of myriad ways in which the syntax of source code can be modified
without affecting the behaviour of the code one iota. While it is obviously
possible to establish tools which would compare sources ignoring such syntactic
differences… this ignores the possibility of obfuscations arising from
algorithmic transforms. I believe that there are an infinite number of
algorithmic transforms which could be applied – either by intermingling new
redundant code which does not affect the behaviour of the original – or by
re-ordering calls where the order doesn’t affect overall behaviour. If you were
to supply me with a machine to compare source codes – I’m sure I could write a
program to transform source in order to deceive it. I don’t for one second want
to suggest that this diversion might be relevant to any SCO case – but it is an
academic amusement. The suggestion that the difficulty of comparing sources can
be ascertained without subjective evaluation of the code itself is, in my
opinion, dangerous. Conversely – I expect that in any practical context
establishing plagiarism in real code (i.e. code produced for a purpose other
than to prove a point about comparison itself) would be relatively
straightforward.

[ Reply to This | # ]

I think this is a weak point - please englighten me
Authored by: monoman on Friday, September 10 2004 @ 07:22 AM EDT
From the declaration:

33. As I understand the concept, and as is only logical, substantial similarity
must be a determination about two bodies of code as they are, not a question of
their heritage. Any given segment of Linux code either is or is not
substantially similar to a given body of Unix code; it is irrelevant to the
determination of similarity how the Linux code came to look the way it does. So
even if it is true that some code that came to be included in Linux originated
in AIX or Dynix, that is simply not important to the analysis of whether that
Linux code is in fact similar to any Unix code.

**

I understand what he's saying; however, I'm not sure it stands scrutiny. Let's
say I have copyright on code A, and then somebody grabs it and without my
permission, takes the source and starts playing with it. He modifies, improves,
changes, whatever my original code and comes up with code B, which no longer
resembles code A.

However, a violation of my copyright has occurred, hasn't it? I probably can't
prove it by looking at code B, and maybe I'll never be able to prove it in any
way, but my copyright has in fact been violated, I'd think.

[ Reply to This | # ]

a little trial obfuscation
Authored by: skip on Friday, September 10 2004 @ 08:13 AM EDT
I just had a go at obfuscating some code of mine.
Note, the original formatting from my code doesn't appear to be preserved,
sorry.

it went from this:
############
int parse_line ( char *input, char *word1, char *word2, char *word3) {
int a,pos;
a=pos= 0;
/* read the line till all words (max 3) have been read*/
while(1) {
while ((input[pos] !='') && (input[pos]!='
')&&(input[pos]!='n')) {
word1[a] = input[pos];
a++;
pos++;
}
if (input[pos] == '') { break;}
a=0;
pos++;
while ((input[pos] !='') && (input[pos]!='
')&&(input[pos]!='n')) {
word2[a] = input[pos];
a++;
pos++;
}
if (input[pos] == '') { break;}
a=0;
pos++;
while ((input[pos] !='') && (input[pos]!='
')&&(input[pos]!='n')) {
word3[a] = input[pos];
a++;
pos++;
}
if (input[pos] == '') {break;}
}
return 0;
}

##########

to this.....

############
int ReplacementFor_parse_line(char*ReplacementFor_input,char*
ReplacementFor_word1,char*ReplacementFor_word2,char*ReplacementFor_word3){int
ReplacementFor_a,ReplacementFor_pos;ReplacementFor_a=ReplacementFor_pos=0;while(

1){while((ReplacementFor_input[ReplacementFor_pos]!='')&&(ReplacementF
or_input
[ReplacementFor_pos]!=((char)(0xd62+1240-0x121a)))&&(ReplacementFor_inpu
t[
ReplacementFor_pos]!='n')){ReplacementFor_word1[ReplacementFor_a]=
ReplacementFor_input[ReplacementFor_pos];ReplacementFor_a++;ReplacementFor_pos++

;}if(ReplacementFor_input[ReplacementFor_pos]==''){break;}ReplacementFor_a=0;
ReplacementFor_pos++;while((ReplacementFor_input[ReplacementFor_pos]!='')&
&(
ReplacementFor_input[ReplacementFor_pos]!=((char)(0x180+4741-0x13e5)))&&
(
ReplacementFor_input[ReplacementFor_pos]!='n')){ReplacementFor_word2[
ReplacementFor_a]=ReplacementFor_input[ReplacementFor_pos];ReplacementFor_a++;
ReplacementFor_pos++;}if(ReplacementFor_input[ReplacementFor_pos]==''){break;}

ReplacementFor_a=0;ReplacementFor_pos++;while((ReplacementFor_input[
ReplacementFor_pos]!='')&&(ReplacementFor_input[ReplacementFor_pos]!=
((char)(0x1ad9+2310-0x23bf)))&&(ReplacementFor_input[ReplacementFor_pos]
!='n'))
{ReplacementFor_word3[ReplacementFor_a]=ReplacementFor_input[ReplacementFor_pos]

;ReplacementFor_a++;ReplacementFor_pos++;}if(ReplacementFor_input[
ReplacementFor_pos]==''){break;}}return 0;

##############

And this was with apparently minimal obfuscation..
How can ANYONE think that obfuscated code could be used in an open source
project succesfully?

personally, I'd dump it the moment it was submitted.

[ Reply to This | # ]

The Ones to Ask
Authored by: RealProgrammer on Friday, September 10 2004 @ 09:03 AM EDT

What bears repeating here is the relative trustworthiness of the witnesses each side has chosen.

While what the experts say and the facts they rely on to give their opinion are most important, courts naturally weigh reputation and bias in resolving opinion conflicts. Of course, you can't be an expert witness on a topic at all unless you qualify. That should be a layup in a case like this. For the sake of comparison, I'll assume they all qualify.

On one side there are the affidavits from two SCO Group executives, Gupta and Sontag. While doubtless these are capable people, they really don't have prior reputations in the industry. Further, their testimony bears an obvious bias over and above that of a typical hired expert.

On the other side are Brian Kernighan and Randall Davis. Brian Kernighan is the "K" of "K&R" -- that is, he wrote:

  • The C Programming Language with Dennis Ritchie ("K&R C")
  • Software Tools with P.J. Plauger
  • The AWK programming Language with Aho and Weinberger - yes, he's that "K", too.
  • Lots and lots of other stuff - see his Bell Labs page.

In short, he's who you might get if you could only pick one expert on UNIX software (perhaps even more than Dennis Ritchie or Ken Thompson, who have had a different focus than Brian). For comparison, TSG might have countered with Bill Joy (developer of BSD Unix and Java), except I don't think they'd have liked his answers.

Randall Davis is well known in the field. He's not just a run of the mill MIT professor, but the head of the CS&AI lab. He's also an expert on the relationship between computer software and intellectual property. To quote from his bio (in the pdf):

Dr. Davis has also been active in the area of intellectual property and software. In 1990 he served as expert to the Court in Computer Associates v. Altai, (775 F. Supp. 544 (E.D.N.Y. 1991); 982 F 2d 693) a case that produced the abstraction, filtration, comparison test for software copyright. (emphasis added)

TSG might have countered with someone like Lawrence Lessig, but I don't think they'd have liked his answers, either.

TSG has a couple of their executives; IBM has The Ones You Would Ask.

---
(I'm not a lawyer, but I know right from wrong)

[ Reply to This | # ]

Obfuscation feasible, plagarism infeasable.
Authored by: tz on Friday, September 10 2004 @ 10:41 AM EDT
There is a product called C-Shroud by a company that produces lint and
reformaters (a commercial product similar to gnu "indent").

You can use this utility to obfuscate code - it can recognize all the variable
names and turn them into random letter soup, remove comments, etc.

What cannot be easily done is to take code from A in style X and put it into B
in style Y, other than by rewriting it in such a manner that it would probably
not be a derivative work (Like taking a plot line written in high british
english, and rewriting it in 3rd grade american english changing all the proper
names and restructuring all paragraphs so no nontrivial word is in common).

It would be like doing one of those "buy a term-paper", but rewriting
it so it could not be matched via any automated tool. You might get suspicious
that the number of paragraphs matched and addressed similar subjects, but that
would require as much effort as writing it.

And in coding, I think "scenes a faire" would apply for any similarity
found, and it is improbably that very large sections could be lifted - but small
sections won't show anything.

[ Reply to This | # ]

re. obfuscation - text vs. machinery
Authored by: Anonymous on Friday, September 10 2004 @ 10:47 AM EDT
I think it would be helpful for a lot of non-techie people if we painted a few
mental pictures.

First of all, copyright law deals with text and artworks. Computer source code
isn't anywhere near text in its purpose. I know several people who have worked
on design projects for large off-shore oil rigs, and to obfuscate anything in
that design process and still hope to have a final working design would simply
be blind madness.

Point is, computer (source-) code isn't text - that's just how we represent it,
in order for us as mere human beings with a written language, to be able to work
with it, and communicate our ideas and intentions with it - think of it as
written music - or a description of a certain piece of machinery. A computer
program is a technical invention, encompassing instructions for a machine to
perform a certain set of tasks. Since the computer is an all-purpose machine, I
like to envision the program code as the actual machinery. In this respect it's
like an architectural or technical drawing, or even a stretch of gene-encoding
DNA (not all DNA codes for anything, don't you know? ;-)

Machine instructions, not text or IP as such. I don't know how much this will
enlighten the masses, or alter the current precedent, seeing as how DNA
sequences and microorganisms have been patented - current practice in the IP
domain isn't much to go by, sadly...

:-) *so PJ can identify me*

[ Reply to This | # ]

Who cares? SCO has no copyrights
Authored by: Anonymous on Friday, September 10 2004 @ 11:31 AM EDT

All this is irrelevant. SCO has no Unix copyrights. Novell does. End of
problem.

[ Reply to This | # ]

Randall Davis' Declaration - as text
Authored by: blacklight on Friday, September 10 2004 @ 11:51 AM EDT
"...and you can't just grab some Unix code and toss it in Linux and expect
it to work. The slightest change can bring the entire house of code falling
down, and the larger the program, and the more complex it is -- and Linux is
both large and complex -- the greater the likelihood of breaking things. In
short, he pretty much tells the court that Sontag is greatly mistaken at
best" PJ

... greatly mistaken at best, and showing his [Chris Sontag's] ignorance like
see-through underwear, too. So, these assertions about "non-literal
copying" comes from Chris Sontag, the guy who supervised 5000 Novell
developers? It goes to show that "supervising" is one thing, and
knowing anything about what one is supervising is another.

[ Reply to This | # ]

  • Did You Know... - Authored by: Anonymous on Friday, September 10 2004 @ 12:35 PM EDT
one bad thing?
Authored by: jig on Friday, September 10 2004 @ 12:33 PM EDT
the one thing that i don't like about this declaration is that it seems to open
the door a bit to arguments that pieces of code that don't look the same, but
still have the same functionality, can be considered similar.

this was in his description of sim, i think, where he describes a diff-tool that
can ignore variable names etc and look for functional similarities.

if sco starts coughing up code (finally), then they might be able to use IBM's
expert declaration to keep the ball rolling on having to decide if certain
functionally similar code is infringement or not.

i won't say that if we get down to deciding what is infringing based on
percentages of similar functionality that ibm has lost, but it certainly will be
a time win for SCO.

i guess that similar shouldn't really matter in copyright, it is either the same
or not. is it more of a patent claim to argue something is similar in method to
another?

[ Reply to This | # ]

  • one bad thing? - Authored by: Anonymous on Friday, September 10 2004 @ 01:10 PM EDT
  • Gates Rubber - Authored by: Anonymous on Friday, September 10 2004 @ 01:12 PM EDT
  • one bad thing? - Authored by: Anonymous on Friday, September 10 2004 @ 01:25 PM EDT
Randall Davis' Declaration - as text
Authored by: Dastardly on Friday, September 10 2004 @ 01:38 PM EDT
I was thinking this morning. Assuming there is no illegal copying of Unix code
to Linux, and SCO knows it. SCO's goal has to be to get this thing to a jury
trial, or at least make it last as long as possible. So, of course summary
judgement is bad for them.

Assuming the lawyers were decent wouldn't they have realized that summary
judgement motion would be coming related to the counterclaim. Wouldn't the
smart thing have been to show some code that was the same in Unix as Linux
regardless of origin i.e. from BSD. Couldn't that create the controversy of
fact to get them to jury trial on the counterclaim? Even if the community tears
apart the code to show it is legal, I was thinking that still might not be
enough to get summary judgment.

It is probably too late at this point to suddenly present code because that
should have been presented in response to the motions to compel. Therefore,
either there is no code whatsoever even code of common origin outside Unix, or
SCO lawyer's are incompetent and any code they may try to pull from their a%%
now will cause some kind of sanction.

[ Reply to This | # ]

Randall Davis' Declaration - as text
Authored by: pooky on Friday, September 10 2004 @ 01:53 PM EDT
It's a good argument made by an expert, and he finally says what I haven't seen
yet (although I'm sure someone wrote it somewhere in IBM's filings) that UNIX is
*NOT* AIX and Dynix, SCO can't hold copyrights in those OS's outside of any UNIX
code they contain, and this motion is about violation of SCO's copyrights. This
means UNIX, only UNIX, and nothing but UNIX.

SCO's going to have a problem escaping this fundamental fact, they do not and
cannot own copyrights in any AIX or Dynix code that is not directly derived from
UNIX, period. They keep trying to confuse the argument so as to avoid a summary
judgement ruling against them, likely because they know their argument is
flawed.

-pooky

---
If at First You Don't Succeed, Skydiving Isn't for You.

[ Reply to This | # ]

Look at Sega v. Accolade...
Authored by: Anonymous on Friday, September 10 2004 @ 02:11 PM EDT
IANAL (just an unregistered lurker), but I believe one of the ways that one can
shoot down the argument that "copyright was infringed at one point" is
to look at the reverse engineering that was performed in the Sega v. Accolade
case.

If my memory serves me right, Sega sued Accolade for copyright infringement when
Accolade reverse engineered the Sega Genesis game system to create its own games
without Sega's approval. Sega lost the lawsuit, as the judge not only ruled that
Accolade's reverse engineering is legal, but that intermediate copies of Sega's
copyrighted program code that was created during the reverse engineering process
is not a violation of copyright.

So here is an example where it is obvious (Accolade admitted) that code B is
obtained from code A, but no copyright was infringed getting from A => ....
=> B despite (substantial) copying in some of the internal versions.
Intermediate versions getting from A to B might (and probably does) contain A's
copyrighted code.

For example, during the reverse engineering process, a version A' might have
been created where Accolade replaced a single function of A with an original
test function to see if they really understood how that function of A worked.
All the other functions in A' would be identical to A, because in this
controlled experiment, only one function is being examined.

The situation would have probably turned out differently if Accolade actually
released code that partly contained Sega's code. (The "substantially
similar" argument would then apply.) But Accolade kept all of Sega's code
internal.

To me, the Sega case succinctly proves the assertion by the MIT professor:
Copyright infringement should be based on whether code B (in its current form)
is subsantially similar to code A. How one gets from A ==> B is irrelevant
from the criteria of being "substantially similar". IMHO, the heritage
of the code might come into play if one wants to show non-infringement: There is
some code C that belonged in the public-domain, we assert that we got B from C
and not from A, and an old version of B is similar to C. But as far as
demonstrating infringement, no, the history shouldn't matter.

SCO shouldn't be able to argue that AIX internal version 0.0002 [never released]
infringed on Unix version blah.

Thus, the Sega case should also IMHO shoot down SCO's argument for the need for
all of IBM's internal versions. All that counts are the versions that were
released (and which IBM has already provided).

Cheers!

[ Reply to This | # ]

even if your code obfuscator works as advertised it disproves your point.
Authored by: skidrash on Friday, September 10 2004 @ 02:39 PM EDT
how could that code be shoehorned into Linux?

Linux uses its own identifiers, its own versions of all the structs for process,
thread, memory allocations, EVERYTHING.

Any contributor who tried your trick would then have the immense job of making
his code conform to all the differences between Linux & UNIX.

Your code obfuscator would make it MORE DIFFICULT to put UNIX into Linux.

[ Reply to This | # ]

How do you obfuscate code?
Authored by: Anonymous on Friday, September 10 2004 @ 05:27 PM EDT
IANAL nor a C programmer and know very little about Linux and nothing about
Unix. Well those are my credentials.

It seems to me that to obfuscate the code in question you would have to:

1. Alter the Unix code so that it actually works in a Linux setting. Presumably
this requires some knowledge of C, Unix, and Linux. Test it well.

2. Re-write all the comments. Warning! correct any mistakes in the original
before re-wording. The new comments need to be written so that they look like
those written by a genuine programmer - this probably needs a genuine
programmer.

3. Replace variable names with likely sounding alternatives - again this might
need the services of a genuine programmer. Change the layout as permitted by the
syntax of C.

4. Unfortunately this source still compiles to exactly the same binary as you
had at the end of step 1. above. Try altering a few bits without breaking
anything (maybe some expressions could be rewritten to produce the same result
but compile to different binary, maybe some sections could be executed in a
different order without changing the overall result).

5. Release the code...back comes the first bug report...oops...what do you do
now?

BTW I forgot to say that you must shoot the entire development team. But
supposing one of them has sent a letter...In the event of my death...?

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