Poor Mr. Rochkind has a number of problems, as far as I can see. The first difficulty Mr. Rochkind finds himself in is that while he thinks he is disagreeing with IBM's expert, Randall Davis, regarding the need for specific lines of code when identifying methods and concepts, in reality he is contradicting the court, which ordered SCO to provides specific lines of code. So he is arguing to the court that SCO should be allowed to deliberately ignore the court's orders, based on his opinion that it isn't necessary to comply. That's a problem. It's a compound problem, because SCO's lawyers wrote this up for him, and they know what her orders said.

The second problem he -- and SCO -- has is, what law is it that IBM is supposed to have violated? We've arrived at a new theory of the case, methods and concepts, but is SCO charging methods and concepts under contract law, or do they have a theory under copyright law, as hinted by Darl McBride and Chris Sontag in their musings on Harry Potter and Vanilla Ice? For IBM to be able to respond, they do need to know. If it's under copyright law, what would or wouldn't be covered would differ than if it is contract law. There is no fair use, for example, under contract law.

Another problem is that IBM has already told the court that it doesn't know how to defend itself from such vague material. No court in the world will tell IBM to fend for itself and just do the best it can, because an expert says they should be able to figure it out for themselves. The lack of specificity is a serious weakness. If, as he says, you can find a method and concept in pretty much all versions of Linux, SCO's list should have enumerated them. After all, even if the method and concept belongs to SCO and we find it in Linux, they haven't shown that IBM put it there, have they, without specifics. Then they need to specify what part of a method and concept they claim ownership of. Are they saying they "own" entire ideas on how to approach a computer problem? If they are, how much of those same ideas show up in DOS, for example? Such a claim is as big as the sky and would disrupt the entire software industry, and judges tend to avoid disrupting entire industries.

SCO's expert may say lines aren't needed, but IBM says it needs lines and versions in order to figure out how to respond. With specificity, IBM has the opportunity to trace it out and presumably prove ownership of the method and concept itself. Two unrelated people on two separate desert islands can invent the same method and concept, after all. So where is the tracing that would show that IBM has done a single thing wrong? I think it's a given that SCO will, at best, be ordered to be more specific and provide what was required by the court's orders and in response to IBM's expressed inability to know what SCO is talking about. It's a matter of simple fairness. Does anyone know what SCO is talking about? Don't you find it odd, after three years of this goop that you -- and IBM -- still don't know? These are the kinds of games that give lawyers a bad name, and rightly so. It looks to me like SCO decided to try to get all the way through discovery without ever revealing to IBM what its theory of the case really was. I can't tell you the depths of disgust that I feel if that was the plan. It'd be like a boxer deliberately hitting his opponent below the belt, having the poor guy drop to the ground, and then declare himself the champion of the world on the basis of a knockout. Champions of the world do not deliberately hit opponents below the belt. There are rules about that.

Also, one comes away from this declaration, particularly reading paragraph 10, with the distinct feeling that SCO is asking the court for billions in damages because some computer programmers sat around and chatted in email about different ways to do X or Y. That is preposterous. If you divide $5 billion by a couple of hundred "misuses" -- even if you credit every stupid item on SCO's list as being real -- that is a stupefyingly ridiculous calculation. No jury in the world will give SCO money at that scale.

The most remarkable thing he says, to me, is that this really is all SCO has. IBM accused SCO of holding out and refusing to reveal what they have. But their own expert tells the court that this really is all there is:

16. IBM alleges in its reply brief that "it is beyond reasonable debate that SCO acted willfully in not specifying its claims" (at 10) and that "SCO has declined, as a practical matter, to tell IBM what is in dispute" (at 9).

17. I am familiar with the technical evidence. I played the largest, although not an exclusive, role in assembling it, so I am in the best position to know that IBM's allegation is false. For each of the 294 Items, I did everything I could to ensure that everything we had was disclosed and that it was organized in the most accessible possible manner.

How extraordinary. They sued IBM and cost them millions in legal fees because of a paltry few items of questionable merit in the category of "infringed" code out of millions of lines of code in Linux and a handful of vague methods and concepts, which, from what we see so far, adds up to some guys who worked on Dynix talking about how to solve problems, not anything IBM as a company ever did in any official capacity. It's simply mind-boggling.

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

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)
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 OF MARC ROCHKIND Case No. 2:03CV0294DAK Honorable Dale A. Kimball Magistrate Judge Brooke C. Wells FILED IN REDACTED FORM [ORIGINAL FILED UNDER SEAL]

1. I have devoted my professional career to computer science, a field in which over the past 39 years, I have developed software, written textbooks, and taught. My speciality is in the area of UNIX operating systems.

2. I received a Bachelor's Degree in Mechanical Engineering from the University of Maryland in 1970, a Masters of Science in Mechanical Engineering from Rutgers in 1972, and a Masters of Science in Computer Science from Rutgers in 1976. I have taught computer science courses at the University of Colorado. Exhibit A contains details of my professional background and publications.

3. I consider myself to have expertise in computer science generally, and specifically on application and system programming, programming languages, software development processes, software design, database systems, graphical user interfaces, and internet applications.

4. I have personal experience in the development of the UNIX operating system. From 1970 to 1982, I worked on UNIX development at AT&T Bell Laboratories. My work involved design and development of the UNIX operating system and of applications running on the UNIX operating system.

5. I wrote Advanced UNIX Programming, published in 1985, which was the first textbook to explain in detail how to use UNIX system calls to write applications. I updated Advanced UNIX Programming in 2004 to include newer features of UNIX and to include material on Linux and FreeBSD. These books are considered standard references on UNIX operating systems.

6. I was retained by counsel to SCO in May 2005, to analyze the technical evidence in this case, to help prepare the preliminary October and December 2005 Disclosure of Material

2

Misused by IBM (the "December Submission") and to serve as a consultant and expert witness. I have since been asked to review the declaration recently submitted by Professor Randall Davis, and this declaration is submitted as a result of that review.

7. I strongly disagree with Professor Davis's assertion (at paragraph 11) that SCO has failed to identify with specificity 198 challenged items in the December Submission. SCO's Submission identifies the technology in issue with specificity, both with respect to disclosures of code and with respect to disclosures of methods and concepts. It provides ample identification to define each technology in question and from which IBM can formulate a defense, if such defense is available.

8. Of the 294 Items in the December Submission, about a third are cases of misused code, and about two-thirds are cases of misused methods and concepts. With respect to disclosures of code, the December Submission provides specific identification of the code that was wrongfully disclosed by IBM, including in many cases providing charts showing precisely where the code had been disclosed. These disclosures of code are, with a few exceptions, not the subject of IBM's motion or Professor Davis's declaration.¹

9. The remaining two-thirds of the material identified in the December Submission are methods and concepts. These are specifically identified in the December Submission not only by

¹ IBM notes that SCO "appears not to have even used [CMVC] to prepare its Final Disclosures." That is incorrect. I used CMVC extensively.

REDACTED

3

summarizing the method or concept implicated, but also, in almost all cases, by identifying the actual written communication that constitutes the disclosure. In other words, the method and concept is fully described in the December Submission and the related materials, which are referenced as sources for each of the enumerated items. In most cases the December Submission also identifies the IBM individuals involved in making the disclosure.

10. Contrary to disclosures of source code, disclosures of methods and concepts neither require an accompanying disclosure of source code, nor is the method and concept defined or identified by source code. Many textbooks on computer programming discuss methods and concepts without providing accompanying source code for actual systems. I strongly disagree with the premise of Professor Davis that version, file, and line of source code must be provided to identify a method and concept, and to prepare a defense to an allegation of misuse. Where IBM disclosed methods and concepts from the Dynix and Dynix/ptx operating systems without providing source code in the disclosures, for example, it is often not possible and certainly not necessary to cite to specific source code in identifying the disclosure. The reason is simple: the material that was improperly disclosed to Linux was the method or concept itself, not particular lines of source code from Dynix/ptx.

11. Moreover, for many of the challenged items in the December Submission, there is code imbedded in the disclosure email or other document, or found at a referenced URL (internet website) address. In addition, some of the methods and concepts relate to other disclosures that do implicate code.

REDACTED

4

12. I have prepared and attach as Exhibit B a summary chart of the 198 challenged disclosures. This chart first shows where the actual disclosure, such as an email from an IBM engineer to a Linux programmer discussing the protected material, has been provided. (See column A.) In these cases, to use Professor Davis's analogy, the proverbial needle itself is identified, verbatim, in the December Submission. The chart also identifies those disclosures as to which there is accompanying source code for the item contained in either the text of the disclosure, a document or URL address referenced in the disclosure, or in related code that is the subject of a separate disclosed item. (See column B.) In those cases, the origin of the method and concept in protected material (often Dynix/ptx) is supported by such source code. In yet other cases, the disclosure does not reference specific code, but contains in the face of the communication an admission or other statement that directly links the method and concept as coming from protected material such as System V, or a derivative such as AIX or Dynix/ptx. (See column C.) Finally, the chart indicates in Column D those disclosures for which file locations in Linux are provided relating to the challenged method and concept.²

13. Even the one example cited by Professor Davis in his Declaration, Item 146, does not support his point that it "provides no meaningful information about what IBM is alleged to have done wrong."

REDACTED

² IBM criticizes the lack of versions in these references. However, the files referenced can be found, in most cases, in any version of Linux issued after the disclosure.

5

REDACTED

6

16. IBM alleges in its reply brief that "it is beyond reasonable debate that SCO acted willfully in not specifying its claims" (at 10) and that "SCO has declined, as a practical matter, to tell IBM what is in dispute" (at 9).

17. I am familiar with the technical evidence. I played the largest, although not an exclusive, role in assembling it, so I am in the best position to know that IBM's allegation is false. For each of the 294 Items, I did everything I could to ensure that everything we had was disclosed and that it was organized in the most accessible possible manner. Counsel to SCO made it very clear that that was what they wanted me to do. I made sure that every Tab containing a publicly available email included the complete URL and I also made sure that not only would versions, lines, and files be cited where available, as they were in the October Interim Submission, but that the code itself would be shown and that the misused lines would be highlighted and indicated with red lines drawn between the columns. As I explain above, code copying is properly described one way (version, file, and line), and a different approach is used for methods and concepts.

18. I note that there were some candidate Items that, in my opinion, did not meet my professional standards for completeness, clarity, and specificity. I told SCO's counsel that these should be rejected, and in all cases they took my advice.

19. In short, the 198 Items challenged in IBM's reply brief are as complete as possible, and constitute a specific identification of the misappropriated technology at issue.

20. I will timely submit my expert report, which will offer fully explored opinions about IBM's disclosures formed during the work I have done over the last year.

7

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

(signature)

Marc Rochkind

Date: 9-April-2006
Place: Boulder, CO

8

CERTIFICATE OF SERVICE

Plaintiff, The SCO Group, Inc., hereby certifies that a true and correct copy of the foregoing Declaration of Marc Rochkind was served by mail on Defendant International Business Machines Corporation on the 10th day of April, 2006, by U.S. Mail to:

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

Donald J. Rosenberg, Esq.
[address]

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

(signature)

9

EXHIBIT A

Marc Rochkind

Marc Rochkind received a BS in Mechanical Engineering from the University of Maryland in 1970, an MS in Mechanical Engineering from Rutgers in 1972, and an MS in Computer Science from Rutgers in 1976.

>From 1970 to 1982 he worked at AT&T Bell Laboratories as a Member of Technical Staff and Technical Supervisor. Starting in 1972 he began working on development of the UNIX system. He contributed to the architecture and implementation of the Programmer's Workbench version of UNIX (PWB), several UNIX commands, a table-driven data-validation system that served as a model for the "awk" programming language, and the Source Code Control System (SCCS).

His paper on SCCS, delivered at the first IEEE Software Engineering conference, won an award from IEEE a decade later as the most significant from the first conference. SCCS has formed a basis for RCS, CVS, SourceSafe, PVCS, and other version control systems.

In 1982 Mr. Rochkind started one of the early software companies to take advantage of the emergence of the IBM PC as the dominant personal computer. In 1988 he invented XVT, the first developer tool to allow programmers to write portable, but native, graphical user interfaces for Windows, Macintosh OS, OS/2, X/Motif, OpenLook, and character displays. Methods and concepts from XVT have influenced contemporary user-interface systems such as Java AWT and KDE Qt.

Mr. Rochkind's publications include a 1985 textbook, Advanced UNIX Programming (Prentice-Hall), which explained how to program UNIX applications at the system-call level. In 1998 he authored Advanced C Programming for Displays, also published by Prentice-Hall. He rewrote Advanced UNIX Programming in 2004 to bring it up to date and to specifically cover Linux and FreeBSD. In the 2004 Linux Journal 2004 Readers' Choice Awards, Advanced UNIX Programming won third place for "Most Indispensable Linux Book."

Mr. Rochkind has delivered numerous technical papers on UNIX, software development, and graphical user interfaces, and has taught professional seminars on UNIX and computer science at the University of Colorado.

In addition to his work as a consultant and author, Mr. Rochkind continues to develop computer software. He has designed and implemented applications for UNIX, Windows, Macintosh OS X, and Linux servers, including a high-capacity web-based grading and report-card application for a large school district, applications for digital photography, and database utilities.

10

Marc Rochkind's UNIX-Related Publications

Rochkind, M.J., "The Source Code Control System," IEEE Transactions on Software Engineering, Vol. SE-1, Number 4, pp. 364-370, Dec., 1975.

Rochkind, M.J., "A Table-Driven Data Validator," Proc. of COMPCON FALL 1980, IEEE Catalog No. 80CH1598-2C.

Bergeron, R.F. and Rochkind, M.J., "Software Tools and Components," Bell System Technical Journal, 61(6), July-Aug., 1982.

Rochkind, M.J., "Structure of a Database File System for the UNIX Operating System," Bell System Technical Journal, 61(9), Nov., 1982.

Rochkind, M.J., "Evolution of UNIX Within Bell Laboratories," UNIX Symposium, Sydney, Australia, May 1-3, 1984.

Rochkind, M.J., Advanced UNIX Programming, Prentice-Hall, 1985.

Rochkind, M.J., "Pick, Coherent, and THEOS," BYTE Inside the IBM PCs, 10(11), Fall, 1985.

Rochkind, M.J., Advanced C Programming for Displays, Prentice-Hall, 1988.

Rochkind, M.J., "XVT: A Virtual Toolkit for Portability Between Window Systems," Proceedings of the Winter 1989 USENIX Conference, Jan. 30-Feb. 3, 1989, San Diego, CA, USA, pp. 151-163.

Rochkind, M.J., "A Unified Programming Interface for Character-Based and Graphical Window Systems," Proceedings of the Summer 1989 USENIX Conference, June 12-16, 1989, Baltimore, MD, USA, pp. 109-117.

Rochkind, M.J., "An extensible virtual toolkit (XVT) for portable GUI applications," IEEE Compcon Spring '92 Thirty-Seventh IEEE Computer Society International Conference, Digest of Papers, 24-28, San Francisco, CA, USA, Feb., 1992.

Farrand, A.B., Rochkind, M., Chauvet, J.-M., Tognazzini, B., and Smith, D.C., "Common Elements in Today's Graphical User Interfaces: The Good, the Bad, and the Ugly, Proceedings of ACM INTERCHI'93 Conference on Human Factors in Computing Systems, Amsterdam, The Netherlands, pp. 470-473.

Rochkind, M.J., "Has UNIX Programming Changed in 20 Years?," informit.com, Addison Wesley Professional, May 28, 2004.

Rochkind, M.J., Advanced UNIX Programming, 2nd Ed., Addison-Wesley, 2004.

11

EXHIBIT B

12

13

14

15