Here is Exhibit 33 [PDF], Plaintiff's Revised Supplemental Response to Defendant's First and Second Set of Interrogatories. It's huge, another exhibit in IBM's list of 597 exhibits in support of its summary judgment motions. We have fredex to thank for this, because he did the OCR and did a lot of the HTML for me too.

We get a window into SCO's brain here, and it's early in the discovery process, so we find out what SCO suspected prior to getting all the discovery it asked for and got. And while most of what they allege here went up in a poof of discovery smoke, what stands out to me is that they actually accused IBM of conspiring with Intel to secretly ruin SCO's business, accusing IBM of this:

Making secret plans with Intel during 1999 to support Linux without notifying SCO of such plans, even though Intel, SCO and IBM were all partners in Project Monterey, and even though IBM should have known that joint IBM/Intel support for Linux was calculated to undermine the purpose of Project Monterey.

So, now we know why SCO wanted to depose someone from Intel. But if it really believed this allegation, why did it mess up on the subpoena? I can't help but wonder if they got scared instead of just goofing up, although it certainly looked like a simple goof. But Intel was furious, if you recall, about the story SCO told the court about the subpoena, calling SCO out for telling things that were not so. It was such a strong reaction, I remember I wrote that the moral of the story was Do.Not.Mess.With.Intel.For Real. Intel prevailed, if you remember the hearing, in getting the subpoena tossed overboard, and its attorney made clear it wasn't taking sides in the dispute but it found deeply offensive that Intel was falsely accused, and so SCO lost its chance to do discovery. Imagine what Intel might do if SCO accused them in court of conspiracy in a tortious interference claim?

You will see a number of other interesting details, such as the situation with AutoZone -- you'll understand at last why poor AutoZone got dragged into this -- and all the other accusations SCO threw on the table to try to demonstrate interference. I've never seen a case like this one, where so many allegations melted into a puddle of nothingness.

If you look on the chart of the exhibits, you'll find this exhibit is used in support of five summary judgment motions:

• IBM's Redacted Memorandum in Support of its Motion for Summary Judgment on SCO's Contract Claims (SCO's First, Second, Third and Fourth Causes of Action): ¶¶158, 159, 165, 167, 168, 186;
• IBM's Memorandum in Support of its Motion for Summary Judgment on SCO's Unfair Competition Claim (SCO's Sixth Cause of Action): ¶¶10, 11, 12, 13;
• IBM's Memorandum in Support of its Motion for Summary Judgment on SCO's Interference Claims (SCO's Seventh, Eighth and Ninth Causes of Action): ¶8;
• IBM's Memorandum in Support of its Motion for Summary Judgment on its Eighth Counterclaim for Copyright Infringement [PDF]: ¶¶40, 47;
• IBM's Memorandum in Support of its Motion for Summary Judgment on its Claim for Declaratory Judgment of Non-Infringement (Linux activities) (IBM's Tenth Counterclaim) [PDF; Part B [PDF]: ¶¶137, 149, 153, 192

This was a bear to do, so if you have major corrections or know a way to make it prettier, please send it to me in an email, plain text, so I can copy and paste. I'm a little bit sick of working on it. I redacted some names of the IBM "accused", because it's too ridiculous, and there's no reason to smear people's good names. SCO might not think of that, but I do. And in a couple of cases, I couldn't figure out how to do the table without fudging on the pagination a bit. Just letting you know.

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

Brent O. Hatch (5715)
Mark F. James (5295)
HATCH, JAMES & DODGE, P.C.
[address, phone, fax]

Stephen N. Zack
Mark J. Heise
BOIES, SCHILLER & FLEXNER LLP
[address, phone, fax]

Attorneys for Plaintiff The SCO Group, Inc.

________________________

IN THE UNITED STATES DISTRICT COURT
DISTRICT OF UTAH

THE SCO GROUP, INC.
a Delaware corporation,

Plaintiff,

vs.

INTERNATIONAL BUSINESS

______________________

PLAINTIFF'S REVISED SUPPLEMENTAL
RESPONSE TO DEFENDANT'S
FIRST AND SECOND SET OF
INTERROGATORIES

Honorable Dale A. Kimball

Magistrate Judge Brooke C. Wells

______________________________

Pursuant to Rule 33 of the Federal Rules of Civil Procedure, and this Court's order dated December 12, 2003, Plaintiff, The SCO Group, Inc. ("SCO"), hereby files this Revised Supplemental Response to Interrogatories No. 1 through 9, 12 and 13.

GENERAL OBJECTIONS

SCO hereby incorporates by reference all of its General Objections set out in Plaintiff's Responses to Defendant's First and Second Set of Interrogatories and First Request for the Production of Documents (the "Plaintiff's Responses"). All of SCO's original General Objections are incorporated into the following Specific Objections and Responses as if fully set forth therein. Pursuant to the Federal Rules of Civil Procedure, SCO's revised and supplemental responses to IBM's Interrogatories are made to the best of SCO's present knowledge, information and belief. In particular, these current responses are based on the evidence SCO has discovered independently and based on information contained in IBM's limited production to date. Upon receiving complete discovery from IBM, including all versions of AIX and Dynix/ptx, there undoubtedly will be further evidence of IBM's contractual breaches and other violations of law. Accordingly, SCO reserves the right to further supplement or amend its answers as discovery or further investigation may reveal.

2

SPECIFIC OBJECTIONS AND SUPPLEMENTAL RESPONSES TO INTERROGATORIES

INTERROGATORY NO. 1:
Please identify, with specificity (by product, file and line of code, where appropriate) all of the alleged trade secrets and any confidential or proprietary information that plaintiff alleges or contends IBM misappropriated or misused, including but not limited to as alleged in ¶ 105 of the Complaint.

SUPPLEMENTAL RESPONSE TO INTERROGATORY NO. 1:
Subject to and without waiving its objections, Plaintiff supplements its response to this Interrogatory No. 1 and states pursuant to their respective Software Agreements, Sublicensing Agreements and related agreements ("Related Agreements"), which are attached to the Amended Complaint, IBM and Sequent had certain contractual obligations and restrictions on their use of the UNIX System V code that they licensed from AT&T, SCO's predecessor. These restrictions, which are more fully stated in the forgoing agreements, also restricted IBM and Sequent's use of the modifications they made to UNIX System V and derivative works of UNIX System V. IBM's version of UNIX is known as AIX and Sequent's version of UNIX is known as Dynix/ptx. Based on the forgoing agreements, IBM and Sequent agreed to restrictions on AIX and Dynix/ptx, including that AIX and Dynix/ptx would be used solely for internal business purposes, that they would not allow the use of AIX or Dynix/ptx for or by others, and that they would not transfer any part of Dynix/ptx to parties who do not have a UNIX System V source code agreement with SCO. IBM and Sequent also agreed that they would maintain all of AIX and Dynix/ptx in confidence. IBM breached the terms of the agreements and thereby misused or misappropriated the confidential or proprietary or

3

Thus far, SCO has received limited production from IBM of some versions of Dynix/ptx for comparison. Based on the limited software produced by IBM, SCO has identified direct copying by IBM of entire files of Dynix/ptx source code as a patch to Linux 2.4.1-01. The first misuse of the Protected Materials identified below is in Read Copy Update ("RCU"). RCU is a mechanism that can significantly improve the performance and scalability of multi-processor systems by allowing simultaneous access to data without the need for expensive and time consuming locking protocols. Dynix/ptx/RCU structures and sequences were originally offered as a patch to the Linux 2.4 kernel by IBM, with rather limited functionality inside Linux 2.4. However, in the development of Linux version 2.6, the deployment of Dynix/ptx/RCU structures and sequences has spread into new uses inside Linux, including networking, device drivers, list management, and directory access. This demonstrates how improper contribution of a few hundred lines of change from Dynix/ptx has had a massive impact on Linux kernel efficiency, particularly relating to multi-processor functionality and processor memory synchronization.

For detailed comparison, compare the files of code contained in Table A below. The original code in Dynix/ptx in Tab 1 is set against the files of code identified in Linux in Tab 5. Compare files contained in Dynix/ptx Tab 2 against the files contained in Linux in Tab 6. Also compare files contained in Tab 3 in Dynix/ptx against files contained in Linux in Tab 7. Compare files contained in Tab 4 in Dynix/ptx against files contained in Tab 8 in Linux. Virtually the entire files identified in the above tabs that originated in Dynix/ptx were published as a patch to Linux 2.4.1-01, with only

4

TABLE A

DynixV v4.6.1 Files	Linux 2.4.1-01 files
kernel/sys/rclock.h (Tab 1)	include/linux/rclock.h (Tab 5)
kernel/os/rclock.c (Tab 2)	kernel/rclock.c (Tab 6)
kernel/sys/kma_defer.h (Tab 3)	include/linux/kmemdef.h (Tab 7)
kernel/os/kma_defer.c (Tab 4)	kernel/kmemdef.c (Tab 8)

As stated, the entire files specified above show direct line-by-line copying of the files with the same name in Dynix, with slight changes made to reflect some variations between the two operating systems. By comparing the tabs correlating each file in Dynix against the corresponding patch for Linux, the direct copying is apparent to the layperson's eye. That the code in Linux comes from Dynix/ptx is further confirmed by the commentary in the Linux patch that expressly states that it is "[b]ased on a Dynix/ptx implementation by Paul McKenney..." Mr. Mckenney was formerly an engineer at Sequent, and is now employed at IBM following IBM's acquisition of Sequent. After the first initial improper contribution of RCU by IBM, RCU persists as a functionality available in Linux, is maintained by IBM (and thereafter others) and became more widespread in the Linux kernel (as shown in Tab 9).

5

Lines of code from Dynix/ptx files, but less than the entire file, were also copied line-for-line from DynixV v4.6.1 to Linux 2.4.1-01. Table B maps the line-for-line copied code from specified lines in DynixV v4.6.1 to Linux 2.4.1-01, with the file name and file line number in each code base identified appropriately. By comparing the tabs that correlate with each file in Dynix/ptx against the corresponding file in Linux, the direct copying is again apparent to the untrained eye.

TABLE B

DynixV v4.6.1 Files and line #s	Linux 2.4.1-01 files and line #s
kernel/os/kern_clock.c (Tab 10) 02028-2059	arch/i386/kernel/apic.c (Tab 14) 25-28, 662-664, 676-684
kernel/os/kern_clock.c (Tab 10) 2028-2059	kernel/timer.c (Tab 15) 26-29, 631-683, 688-697
kernel/i386/locore.s (Tab 11) 1487-1497	arch/i386/kernel/entry.S (Tab 16) 199-205
kernel/i386/trap.c (Tab 12) 1554-1563	arch/i386/kernel/traps.c (Tab 17) 52-54, 244-247, 331-334, 542-545, 659-662, 718-721
kernel/i386/startup.c (Tab 13) 2054	init/main.c (Tab 18) 30-33, 609-616

In Table B, Tab 10 correlates Dynix/ptx code at lines 2028-2059 directly with copies of the same Dynix/ptx code improperly copied into Linux, identitied in Tab 14 at lines 25-28, 662-664, 676-684. Tab 10 also correlates the same Dynix/ptx code found at lines 2028 -2059 with copies of the same Dynix/ptx code improperly copied into Linux, identified in Tab 15 at lines 26-29, 681-683, 688-697. Tab 11 correlates Dynix/ptx code at 1ines 1487-1497 directly with copies of the same Dynix/ptx code improperly copied into Linux, identified in Tab 16 at lines 199-205. Tab 12 correlates Dynix/ptx code at lines 1554-1563 directly with copies of the same Dynix/ptx code improperly copied into Linux, identified in Tab 17, lines 52-54, 244-247, 331-334, 542-545, 659-662,

6

The next table, Table C, shows an example of UNIX-based code structures and sequences in Dynix/ptx/RCU that have been improperly copied into the newest version of Linux, 2.6.0.

TABLE C

Structure / Sequence	DynixV file(s)	Line #s	Linux 2.6.0 file(s)	Line #s
Register an RCU callback	kernel/sys/rclock.h (Tab 1) kernel/os/rclock.c (Tab 2)	412 503-613	include/linux/rcupdate.h (Tab 20) kernel/rcupdate.c (Tab 21)	131-132 58-80
RCU Callback control structure	kernel/sys/rclock.h (Tab 1)	217-228	include/linux/rcupdate.h (Tab 20)	66-72
RCU Callback lists	kernel/sys/rclock.h (Tab 1) kernel/i386/plocal.h (Tab 19)	238-241 1517-1537	include/linux/rcupdate.h (Tab 20)	87-108
RCU Comparison operators	kernel/sys/rclock.h (Tab 1)	300-312	include/linux/rcupdate.h (Tab 20)	75-85

The sequence that performs "Register an RCU callback" in DynixV v4.6.1 at line 412, (Tab 1) correlates to the same sequence improperly copied into, and used in Linux 2.6.0 at line 131-132 (Tab 20). The structure "RCU callback control" performed in Dynix/ptx at line 127-228 (Tab 2) was improperly copied into Linux 2.6.0 at lines 66-72 (Tab 21). The sequence "RCU callback lists" performed in Dynix/ptx at line 238-241 (Tab 1) and lines 1517-1537 (Tab 19) was improperly copied into Linux 2.6.0 at lines 87-108 (Tab 20). The structure "RCU comparison operators" found in Dynix/ptx at line 300-312 (Tab 1) was improperly copied into Linux 2.6.0 at lines 75-85 (Tab 20). Again, these are structures and sequences that materially advance the enterprise performance of Linux, and are based on the Protected Materials that Sequent had agreed to not disclose.

7

The next table, Table D shows how IBM has released valuable proprietary methods related to RCU functionality found in Dynix/ptx that have now been adapted across the newest release of Linux, version 2.6.0 in a multitude of different ways. A sub-component of RCU is "force cache write for memory consistency" found in Dynix/ptx at lines 331-358.

TABLE D

RCU Subcomponent	DynixV file(s)	Line #s	Linux 2.6.0 file(s)	Line #s
Force Cache write for memory consistency	kernel/sys/rclock.h (Tab 1)	331-358	include/asm-alpha/system.h (Tab 22)	152-153, 159, 164
-	-	-	include/asm-arm/system.h (Tab 23)	104, 228,235
-	-	-	include/asm-arm26/system.h (Tab 24)	197
-	-	-	include/asm-cris/system.h (Tab 25)	19,27,32
-	-	-	include/asm-h8300/system.h (Tab 26)	97, 102
-	-	-	include/asm-i386/system.h (Tab 27)	368-420,434, 440
-	-	-	include/asm-ia64/system.h (Tab 28)	83,89,94
-	-	-	include/asm-m68k/system.h (Tab 29)	80, 87
-	-	-	include/asm-m68knommu/system.h (Tab 30)	105, 110
-	-	-	include/asm-mips/system.h (Tab 31)	145-197,256, 261
-	-	-	include/asm-parisc/system.h (Tab 32)	134-135
-	-	-	include/asm-ppc/system.h (Tab 33)	24-25, 34, 43, 48
-	-	-	include/asm-ppc64/system.h (Tab 34)	28-29, 38, 47, 52
-	-	-	include/asm-s390/system.h (Tab 35)	255 259
-	-	-	include/asm-sh/system.h (Tab 36)	80, 86, 91
-	-	-	include/asm-sparc/system.h (Tab 37)	281, 287
-	-	-	include/asm-sparc64/system.h (Tab 38)	86, 96, 101
-	-	-	include/asm-v850/system.h (Tab 39)	70, 78
-	-	-	include/asm-x86_64/system.h (Tab 40)	283, 288, 305

8

Thus, Dynix/ptx lines 331-358 maps in structure and sequence to Linux 2.6.0 files shown in Table D. These include lines of the Linux 2.6.0 kernel as follows: lines 152-153, 159, 164 (Tab 22); lines 104, 228, 235 (Tab 23); line 197 (Tab 24); lines 19, 27, 32 (Tab 25); lines 97-102 (Tab 26); lines 368-420, 434, 440 (Tab 27); lines 83, 89, 94 (Tab 28); lines 80, 87 (Tab 29); lines 105, 110 (Tab 30); lines 145-197, 256, 261 (Tab 31); lines 134-135 (Tab 32); lines 24-25, 34, 43, 48 (Tab 33); 28-29, 38, 47, 52 (Tab 34); lines 255, 259 (Tab 35); lines 80, 86, 91 (Tab 36); lines 281, 287 (Tab 37); lines 86, 96, 101 (Tab 38); lines 70, 78 (Tab 39); lines 283, 288, 305 (Tab 40). This is a good demonstration of how the Protected Materials that were subject to the restrictions in the Software Agreements, Sublicensing Agreements and Related Agreements have rapidly spread throughout Linux by the open source development community, and underscores why IBM's improper contributions to Linux are so devastating to the value of proprietary UNIX technology. IBM is literally giving Protected Materials to the open source development community so that Linux can be made suitable for enterprise use. But for IBM's wrongful actions in this regard, Linux would lag far behind SCO's UnixWare in functionality and acceptability for enterprise use on Intel processors.

As is demonstrated above, and in the following examples as well, IBM's Linux plan has been to release large blocks of proprietary source code and methods to open source, and to invite the entire open source development community to access that code and those methods in their latest design efforts for Linux. IBM has provided the valuable UNIX proprietary code and methods, and the Protected Materials, to the open source development community. Open source developers have then accessed the Protected Materials at will to design new creations in Linux based on the Protected Materials. Another example of this problem is shown in the next table, Table E. Table E demonstrates how use of the RCU method, which is subject to the restrictions of the Sequent

9

TABLE E

RCU Method	DynixV file(s)| Line #s	Linux 2.6.0 file(s)	Line #s
RCU use	After IBM's initial improper contribution of RCU specifically identified above RCU became widespread in the Linux kernel These files use RCU functions and macros - and if they are used, then the RCU functionality is used, too. The number of lines and number of files, although substantial, is less significant than the impact of the changes, which is dramatic for networking, device drivers, lists, and directory access.	net/core/netfilter.c (Tab 41)	73, 83, 357, 516-517,548, 558, 575,612
-	-	net/core/dev.c (Tab 42)	239, 242, 238, 995-996, 1027, 1580-1581,1594, 1614, 2893
-	-	net/ipv4/ip_input.c (Tab 43)	220, 241, 266
-	-	net/ipv4/af_inet.c (Tab 44)	340-341, 375, 430, 1012, 1040
-	-	net/ipv4/icmp.c Tab 45)	707-712
-	-	net/ipv4/route.c (Tab 46)	227, 231, 240, 243, 246, 282, 440, 446, 1004, 1008, 1026,1037,1076, 1257, 1260, 1296, 1852, 1854, 1867, 1873, 2219, 2221, 2235, 2241, 2451, 2454, 2462, 2467
-	-	net/bridge/br_device.c (Tab 47)	79, 81
-	-	net/bridge/br_ioctl.c (Tab 48)	78, 97, 159, 161, 179
-	-	net/bridge/br_stp.c (Tab 49)	43
-	-	net/bridge/br_private.h (Tab 50)	77
-	-	net/bridge/br_input.c (Tab 51)	59, 61, 106, 117, 135, 142, 151,156

10

11

The next table, Table F, shows additional misuse by IBM of the RCU struc tures and sequences embodied in Dynix/ptx.

TABLE F

RCU sub-component	DynixV file(s)	Line #s	Linux 2.6.0 file(s)	Line #s
RCU read protect	kernel/sys/rclock.h (Tab 1) kernel/os/rclock.c (Tab 2) kernel/os/rclock.c (Tab 2) kernel/os/rclock.c (Tab 2)	373-387 1758-1825 503-613	include/linux/rcupdate.h (Tab 20) kernel/rcupdate.c (Tab 21)	124-125 58-80
Existence of valid callbacks, call "checker"	kernel/os/kern_clock.c (Tab 10)	2028-2059	include/linux/rcupdate.h (Tab 20) kernel/sched.c (Tab 73)	112-122 1364-1365
RCU "checker" (actually processes callbacks)	kernel/sys/rclock.h (Tab 1) kernel/os/rclock.c (Tab 2)	411, 415 385-468, 659-752, 1314-1494	include/linux/rcupdate.h (Tab 20) kernel/rcupdate.h (Tab 21)	128 82-207
RCU initialization	kernel/sys/rclock.h (Tab 1) kernel/os/rclock.c (Tab 2)	414 1222-1311	include/linux/rcupdate.h (Tab 20) kernel/os/rclock.c (Tab 2)	127 201-240

The RCU subcomponent identified as "RCU read protect" is found in Dynix/ptx at lines 373-387 (Tab 1) and lines 1758-1825 (Tab 2). These have been improperly copied into Linux 2.6.0 at lines 124-125 (Tab 20). The RCU subcomponent identified as "Existence of valid callbacks, call checker" is found in Dynix/ptx at lines 2028-2059 (Tab 10). These have been improperly copied into Linux 2.6.0 at lines 112-133 (Tab 20) and 1364-1365 (Tab 73). The RCU subcomponent known as "RCU checker (actually processes callbacks)" is found in Dynix/ptx at lines 411, 415 (Tab 1); lines

12

An additional core technology transferred improperly by IBM to Linux from Dynix/ptx and AIX is in asynchronous input/output ("AIO") and scatter/gather I/O. Input/output ("I/O") is the way operating systems communicate with files and peripheral devices attached to the computer (such as a standard printer or a network interface). Asynchronous and scatter/gather I/O are specialized methods for I/O that have recently been included into Linux and, as discussed in detail below, are believed to have originated in Dynix/ptx and/or AIX and therefore are part of the Protected Materials.

The Linux "patches" implementing AIO were provided by Badari Pulavarty, formerly a Sequent employee, now an IBM employee. Improper transfer of AIO Protected Materials to Linux is illustrated below in this comment from Linux 2.6.0, in the file fs/direct-io.c:

/*
* fs/direct-io.c
*
* Copyright (C) 2002, Linus Torvalds.
*
* O_DIRECT
*
* 04Jul2002 akpm@zip.com.au
* Initial version
* 11Sep2002 janetinc@us.ibm.com
* added readv/writev support.
* 29Oct2002 akpm@zip.com.au
* rewrote bio_add_page() support.
* 30Oct2002 pbadari@us.ibm.com
* added support for non-aligned IO.
*06Nov2002 pbadari@us.ibm.com
* added asynchronous IO support.
* 21Jul2003 nathans@sgi.com
* added IO completion notifier.
*/

13

In October and November of 2002, Badari Pulavarty, formerly a Sequent employee, now an IBM employee, added changes that allow for asynchronous I/O and non-aligned I/O to Linux. In order to completely trace the Dynix/ptx transfer of AIO technology to Linux, SCO needs to obtain the full production of source code from IBM. However, from examining v4.6.1 of Dynix/ptx, it is apparent that Badari Pulavarty was an experienced Dynix kernel programmer, based on the numerous revisions to Dynix with which he is credited, including the following:

Dynix v4.6.1 file	Revisions credited to Badari
./io/tlbtest/tlbtest_rc.c	Revision 1.28
./io/tlbtest/tlbtest_tout.c	Revision 1.18
./io/ff/ff_fc.c	Revision 1.111, Revision 1.110
./kernel/debug/dinfo.c	Revision 1.75
./kernel/i386/mc_vmmac.h	Revision 1.53
./kernel/i386/plocal.h	Revision 1.144, Revision 1.143
./kernel/i386/vm_boot.c	Revision 1.199
./kernel/i386/vmpt_machdep.c	Revision 1.180, Revision 1.101
./kernel/i386_space/param_space.c	Revision 1.207
./kernel/os/heap_kmem.c	Revision 1.128
./kernel/os/init_main.c	Revision 1.216
./kernel/os/kern_fork.c	Revision 1.253, Revision 1.250, Revision 1.245, Revision 1.238
./kernel/os/kern_exec.c	Revision 1.200, Revision 1.198, Revision 1.197, Revision 1.196
./kernel/os/kern_sig.c	PRs 254728, 254503, SCN sarahw186, Reviewer: badari
./kernel/os/mmap_ifchr.c	Revision 1.55
./kernel/os/kern_posix.c	Revision 1.43
./kernel/os/sys/process.c	Revision 1.267
./kernel/os/vm_sched.c	Revision 1.145, Revision 1.143, Revision 1.130, Revision 1.122
./kernel/os/vm_sched.c	Revision 1.121
./kernel/os/sys_vm.c	Revision 1.57
./kernel/os/vfs_bio.c	Revision 1.108, Revision 1.106, Revision [unreadable]
./kernel/os/kern_clock.c	Revision 1.168, Revision 1.165
./kernel/os/vm_swap.c	Revision 1.163, Revision 1.156, Revision 1.153
./kernel/os/vm_drum.c	Revision 1.141, Revision 1.138

14

15

The scope and type of changes indicate that Badari is a programmer who is intimately familiar with the UNIX kernel, and has considerable experience with the Dynix kernel. More specifically, in Dynix/ptx v4.6.1 a file named kernel/os/vfs_dio.c has the following comments attributed to Badari:

* Revision 1.86 1999/06/16 23:17:48 badari
* Revision 1.85 1999/05/03 23:41:53 badari

These comments are specific to fixing aspects of the asynchronous I/O implementation. More significantly, the file vfs_dio.c in Dynix implements the "direct I/O" subsystem, which is coupled to implementation of asychronous I/O and scatter/gather. The file kernel/os/vfs_dio.c in Dynix/ptx ("Virtual File System/Direct I/O") has direct relation to the file fs/direct_io.c in Linux 2.6.0. Based on the forgoing, SCO has reason to believe that through Badari's contributions to Linux, IBM improperly transferred Protected Materials to Linux. Badari Pulavarti certainly was in a position to contribute expertise (and apparently implementation) to the Linux kernel that most likely was gained while working on Dynix/ptx. This belief is based, in part, on the observation that most of Badari's contributions to Dynix are 1999/2000 while his contributions to Linux are dated 2002. Further comments in newsgroups and Linux patches support our belief. To definitively trace the Dynix/ptx transfer of AIO technology to Linux, SCO needs to obtain the full production of source code from

16

Further, improper transfer of scatter/gather I/O Protected Materials to Linux is illustrated in the same comments in the same Linux 2.6.0 file (fs/direct_io.c). The scatter/gather mechanism "readv" and "writev" was contributed by Janet Morgan from IBM (email). Ms. Morgan has been identified by IBM as someone who has or had access to AIX source code. Through Janet Morgan's contributions to readv/writev in Linux, IBM improperly transferred Protected Materials to Linux. Further comments in newsgroup discussions support our belief. In order to completely trace the AIX transfer of scatter/gather technology to Linux, SCO needs to obtain the full production of source code from IBM. In summary, another key component of UNIX high-performance systems appears (based on Ms. Morgan's own comments) to have been contributed to Linux by a programmer who had access to the same subsystem of AIX.

IBM has also improperly contributed other core technologies found in IBM's own derivative work of UNIX known as AIX to Linux in violation of the IBM Related Agreements. As noted earlier, IBM agreed in the Software Agreement that it would use AIX solely for internal business purposes, that it would not allow the use of AIX for or by others, and that it would not transfer any part of AIX to parties who do not have a UNIX System V source code agreement with SCO. IBM also agreed that it would maintain all of AIX in confidence, and that it would not adapt or allow its contactors to adapt AIX for purposes of a creation af a new general operating system by a non-IBM entity. IBM breached its promises to SCO in the Software Agreement, Sublicensing Agreement and Related Agreements by transferring core portions of AIX to Linux.

17

Thus far, SCO has received no production whatsoever from IBM of AIX software. Notwithstanding this fact, SCO has identified copying by IBM of files of AIX into Linux. One instance of copying of AIX into Linux involves improper contribution by IBM to Linux 2.4 of the AIX Journaling File System ("JFS"). The contribution of JFS was done in a series of "drops" of AIX code identified as "reference files" inside Linux. The first such drop occurred on or about February 2000, with multiple additions and significant follow-up work by IBM since that time to adapt AIX/JFS for enterprise use inside Linux. These drops of reference files do not necessarily become part of the source code in the Linux kernel, but rather are public displays of the Protected Materials so that anyone has access to them and can use them to construct a similar file in Linux. The first drop contains (a) partially functioning port, or transfer, of JFS from AIX to Linux; (b) a set of reference directories (named ref/) which contain the AIX reference version of AIX/JFS; (c) AIX/JFS-related utility files used to maintain and upkeep AIX/JFS; and (d) a set of directories (named directory ref_utils/) which contain the AIX reference version of utilities. Copies of AIX/JFS files into Linux are shown in Table G, below. Table G compares a 1999 version of AIX currently in SCO's possession. Nevertheless, even this old version of AIX shows the following similarities, demonstrating copying of code, structures and sequences.

TABLE G

AIX 9922A_43NIA File	Line #s	Linux 2.2.12 ref/ File	Line #s
usr/include/jfs/inode.h (Tab 74)	16-37	include/linux/jfs/ref/jfs_inode.h (Tab 76)	84-95, 126-138
kernel/sys/vnode.h (Tab 75)	109-133	include/linux/jfs/ref/jfs_inode.h (Tab 76)	96-122
usr/include/jfs/inode.h (Tab 74)	39-40	include/linux/jfs/ref/jfs_inode.h (Tab 76)	189-90
usr/include/jfs/inode.h (Tab 74)	161-166	include/linux/jfs/ref/jfs_inode.h (Tab 76)	414-421
usr/include/jfs/inode.h (Tab 74)	172-180	include/linux/jfs/ref/jfs_inode.h (Tab 76)	37-48
usr/include/jfs/inode.h (Tab 74)	199-205	include/linux/jfs/ret/jfs_inode.h (Tab 76)	52-59
usr/include/jfs/inode.h (Tab 74)	62-66	include/linux/jfs/ret/jfs_inode.h (Tab 76)	286-290
usr/include/jfs/inode.h (Tab 74)	72-76	include/linux/jfs/ref/jfs_inode.h (Tab 76)	295-302
usr/include/jfs/inode.h (Tab 74)	83-158	include/linux/jfs/ref/jfs_inode.h (Tab 76)	322-411

18

Protected Materials from AIX appear in AIX 9922A_43NIA (hereafter referred to only as "AIX") at lines 16-37 (Tab 74) and have been improperly copied into Linux version 2.2.12 at lines 84-95, 126-138 (Tab 75). Protected Materials from AIX at lines 109-133 (Tab 75) have been improperly copied into Linux at lines 96-122 (Tab 76). Protected Materials from AIX at lines 39-40 (Tab 74) have been improperly copied into Linux at lines 189-90 (Tab 76). Protected Materials from AIX at lines 161-166 (Tab 74) have been improperly copied into Linux at lines 414-421 (Tab 76). Protected Materials from AIX at lines 172-180 (Tab 74) have been improperly copied to Linux at lines 37-48 (Tab 76). Protected Materials from AIX at lines 199-205 (Tab 74) have been improperly copied to Linux at lines 52-59 (Tab 76). Protected Materials from AIX at lines 62-66 (Tab 74) have been improperly copied to Linux at lines 286-290 (Tab 76). Protected Materials from AIX at lines 72-76 (Tab 74) have been improperly copied to Linux at lines 295-302 (Tab 76). Protected Materials from AIX at lines 53-158 (Tab 74) have been copied improperly to Linux at lines 322-411 (Tab 76). These transfers of AIX/JFS to Linux are in violation of the Related Agreements, and are an improper use of AIX for adaptation to a general operating system in violation of the Related Agreements.

In addition, there are source code files of Protected Materials in JFS called "aixisms.h" which demonstrate the AIX core nature of JFS. Linux files referencing AIX (by name in the commentary) in the JFS drops identified in the AIX files and lines include those listed in Table H.

TABLE H

Files	Lines
include/linux/jfs/ref/jfs_aixisms.h (Tab 77)	26-27, 32, 62, 193, 227, 248
include/linux/jfs/ref/jfs_dirent.h (Tab 78)	55
include/linux/jfs/ref/jfs_inode.h (Tab 76)	76-77, 81, 95, 97
include/linux/jfs/ref/jfs_os2.h (Tab 79)	33-34
fs/jfs/ref/jfs_dio.c (Tab 80)	333
fs/jfs/ref/jfs_logmgr.c (Tab 81)	3134

19

These files were improperly transferred by IBM to Linux as part of IBM's effort to transfer JFS capabilities from AIX to Linux. The files that include "AIXisms," improperly transferred by IBM, are included in Linux at lines 26-27, 32, 62, 193, 227, 248 (Tab 77); line 55 (Tab 78); lines 76-77, 81, 95, 97 (Tab 75); line 33-34 (Tab 79); line 333 (Tab 80) and line 3134 (Tab 81). At this time, there is clear proof of IBM's use of AIX in contributing JFS to Linux in violation of its contractual obligations. The purpose of making these files available in Linux was to assist the open source development community to use AIX/JFS to improve or perfect a Journaling File System for Linux. By including the "AIXisms", developers are able to see the original source code, see how JFS worked in AIX, modify Linux code based on IBM's significant experience with JFS in AIX in enterprise applications, and thereby gain the benefit of IBM's nearly 20 years of UNIX programming in adapting AIX/JFS for Linux. In Tab 80, for example, in the file marked fs/jfs/ref/jfs_dio.c (Tab 80) in the table above, the entry in Linux, written by IBM, says "[o]n AIX we were able to do this in dioIODone() function." This represents a clear violation of IBM's obligations to not transfer AIX to contractors for adaptation for a general operating system.

IBM's decision to release AIX/JFS source code into reference files in Linux illustrates the early pattern of IBM's Linux development plan. Under that plan, IBM initially placed AIX/JFS into files that (mostly) did not actually operate within Linux at the time of the source code drop. Rather, the AIX/JFS files were simply placed in a separate, non-compiling, file that allowed open source programmers to see and use UNIX/AIX development methods and code to improve Linux. JFS then, became another source of UNIX protected technology transferred by IBM to assist in the growth of

20

These reference files are listed in Table I below.

TABLE I

AIX JFS Reference File in Linux	Header file used
Include/linux/jfs/ref/jfs_dasdlim.h (Tab 82)	net32/netcons.h net32/neterr.h net32/dasd.h
Include/linux/jfs/ref/jfs_dinode.h (Tab 83)	sys/types.h sys/mode.h sys/time.h sys/lock_def.h
Include/linux/jfs/ref/jfs_lock.h (Tab 84)	"mmph.h"
include/linux/jfs/ref/jfs_superblock.h (Tab 85)	sys/time.h
fs/jfs/ref/jfs_bufmgr.c (Tab 86)	"mmph.h"
fs/jfs/ref/jfs_cachemgr.c (Tab 87)	"mmph.h"
fs/jfs/ref/jfs_dio.c (Tab 88)	"mmph.h"
fs/jfs/ref/jfs_dnlc.c (Tab 89)	"mmh.h"
fs/jfs/ref/jfs_dtree.c (Tab 90)	"mmph.h"
fs/jfs/ref/jfs_ifs.c (Tab 91)	"mmph.h"
fs/jfs/ref/jfs_initl.c (Tab 92)	devcmd.h
fs/jfs/ref/jfs_inode.c (Tab 93)	"mmph.h"
fs/jfs/ref/jfs_link.c (Tab 94)	sys/vnode.h sys/errno.h
fs/jfs/ref/jfs_logmgr.c (Tab 95)	"mmph.h"
fs/jfs/ref/jfs_mknod.c (Tab 96)	sys/vfs.h sys/cred.h sys/errno.h
fs/jfs/ref/jfs_readdir.c (Tab 97)	"mmph.h"
fs/jfs/ref/jfs_readlink.c (Tab 98)	sys/file.h sys/errno.h
fs/jfs/ref/jfs_statfs.c (Tab 99)	sys/vfs.h sys/statfs.h
fs/jfs/ref/jfs_symlink.c (Tab 100)	sys/vfs.h sys/uio.h sys/file.h sys/cred.h sys/errno.h
fs/jfs/ref/jfs_txnmgr.c (Tab 101)	"mmph.h"
fs/jfs/ref/selector.c (Tab 102)	seldesc.h

21

The use of these header files provides exact sequences and direct code for use by Linux programmers to copy into Linux when building a new journaling file system for Linux, which in this case is clearly derived from, and based on, AIX/JFS. On information and belief, much of the C source code contained in the files referenced by the above header files was also transferred improperly by IBM to Linux. Without the later versions of AIX it is not possible to definitively make this statement, but SCO expects to confirm this fact upon receipt of outstanding discovery requests from IBM, including recent versions of AIX. In numerous files in the Linux JFS directory (that is, the directory of files that actually compiles into Linux, as opposed to the reference files which will not compile under Linux), there are indications that the AIX source code has now been used by the open source development community as a template for creation of the new journaling file system for Linux improperly based on AIX/JFS. In addition to code similarities, there are also compiler directives that serve as comments. For example, the code in the Linux file entitled "fs/jfs/jfs_umount.c" at lines 35-55 (Tab 110) states as follows:

35 #include
36 #include
37 #include
38 #include
39 #include
40 #include

42 #ifdef_STILL_TO_PORT
43 #include "jfs_types.h"
44 #include "jfs_filsys.h"

22

45 #include "jfs_lock.h"
46 #include "jfs_inode.h"
47 #include "jfs_bufmgr.h"
48 #include "jfs_superblock.h"
49 #include "jfs_imap.h"
50 #include "jfs_dmap.h"
51 #include "jfs_dnlc.h"
52 #include "jfs_proto.h"
53 #include "jfs_dasdlim.h"
54 #include "jfs_debug.h"
55 #endif /* _STILL_TO_PORT */

Lines 35-40 above use the header files specified and now actually compile and run Linux code based on AIX/JFS. However, the next line, line 42, includes a compiler directive that also serves as comments that instruct the programmer as follows:

"If the symbol _STILL_TO_PORT is defined, then use the header
files until you see #endif /*_STILL_TO_PORT */ (on line 55).

This comment tells the programmer how to work around AIX reference files that still will not compile in Linux, while allowing the ones that now function with Linux to compile, and thereby operate as the new Linux filing system based on AIX/JFS. This is the equivalent of telling a programmer that "work here is yet to be done", while at the same time providing a partially working system. The commentary is not limited to inclusion of header files, but also includes actual code. Wherever these comments are present, the non-ported code is identical to that in the AIX reference files, and the ported code bears striking similarities to the original. Other places in Linux where this partial-port commentary exists are set forth in Table J.

23

TABLE J

Linux 2.2.12 File	Line #s
include/linux/jfs/jfs_dmap.h (Tab 104)	31-36, 291-329, 153-165
include/linux/jfs/jfs_lock.h (Tab 105)	32-34, 44-73, 198-336
fs/jfs/jfs_dmap.c (Tab 106)	39-52, 130-172, 323-4494
fs/jfs/jfs_dtree.c (Tab 107)	111-124, 177-21 9, 240-311, 559-2566, 3586-3659, 3764-4589
fs/jfs/jfs_imap.c (Tab 108)	60-76, 78-123, 129-150, 202-216, 273- 282, 293-323, 596-607, 631-739, 765- 2550, 2593-2983
fs/jfs/jfs_mount.c (Tab 109)	70-78, 80-86, 124-143, 168-200, 208- 212, 215-280, 306-360, 371-437, 467- 484, 496-498, 503-513, 515-520, 527- 550, 552-566, 724-732, 808-839
fs/jfs/jfs_umount.c (Tab 110)	42-55, 79-86, 91-148, 155-157, 162-236, 243-272
fs/jfs/jfs_xtree.c (Tab 111)	33-41, 125-167, 980-4110

As identified in Table J, commentary in Linux JFS files that refer to AIX are found in Linux at lines 31-36, 291-329, 158-165 (Tab 104); lines 32-34, 44-73, 198-336 (Tab 105); lines 39-52, 130-172, 323-4494 (Tab 106); lines 111-124, 177-219, 240-311, 559-2566, 3586-3659, 3764-4589 (Tab 107); lines 60-76, 78-123, 129-150, 202-216, 273-232, 293-323, 596-607, 631-739, 765-2550, 2593-2983 (Tab 108); lines 70-78, 80-86, 124-143, 168-200, 208-212, 215-280, 306-360, 371-437, 467-484, 496-498, 503-513, 515-520, 527-550, 552-566, 724-732, 808-839 (Tab 109); lines 42-55, 79-86, 91-148, 155-157, 162-236, 243-272 (Tab 110); lines 33-41, 125-167, and 980-4110 (Tab 111). The significance of this information is that it shows how information first improperly "dropped" into Linux by IBM in non-functional form has been used by Linux developers to implement AIX/JFS in Linux. But for IBM's transfer of AIX technology to Linux, Linux developers would have had to learn from the beginning, through trial and error, how to create an advanced filing system for enterprise application. With IBM's improper transfer of Protected Materials, it became far easier for the open source development community to help create a functional file system for enterprise use.

24

IBM has also improperly transferred a UNIX/AIX-based enterprise volume management system ("AIX/EVMS") to Linux, which also constitutes Protected Materials. Again, this was done by IBM to transfer enterprise-class capabilities from AIX to Linux, and was a violation of IBM's Related Agreements and promise not to adapt AIX as a general operating system for a non-IBM company. The purpose of AIX/EVMS is to allow the management of disk storage in terms of logical 'volumes' in a large enterprise environment. Tools with this level of sophistication and performance were entirely unavailable and unknown to the open source development community prior to IBM's improper transfer to Linux. The actual transfer "patch" by IBM can be found at http://www.sourceforge.net/project/ showfiles.php?group_id3D25076&package_id3D17436. The first code drop of AIX/EVMS by IBM was v0.0.1, which occurred on 03/21/2001. The first major release of AIX/EVMS by Linux was vl.0.0, in Linux 2.4, which occurred on 03/27/2003. The latest Linux release version of AIX/EVMS is v2.2.l, which occurred on 12/20/2003. The following table, Table K, identifies the AIX/EVMS "patches" of source code improperly transferred by IBM to the Linux 2.4 version.

TABLE K

EVMS 1.0.0 patches to Linux 2.4.x	Line #s	AIX MERCED/9922A_43NIA	Line #s
include/linux/evms/evms_aix.h (Tab 112)	157-263	kernel/sys/IA64/bootrecord.h (Tab 113)	64-170
include/linux/evms/evms_aix.h (Tab 112)	311-327	usr/include/liblvm.h (Tab 114)	234-250
include/linux/evms/evms_aix.h (Tab 112)	329-349	usr/include/liblvm.h (Tab 114)	252-272, 289-307
include/linux/evms/evms_aix.h (Tab 112)	352-400	usr/include/liblvm.h (Tab 114)	316-363
include/linux/evms/evms_aix.h (Tab 112)	266-294	usr/include/lvmrec.h (Tab 115)	24-92
include/linux/evms/evms_aix.h (Tab 112)	6-11	usr/include/lvm.h (Tab 116)	26-35
include/linux/evms/evms_aix.h (Tab 112)	26	kernel/sys/hd_psn.h (Tab 117)	32
include/linux/evms/evms_aix.h (Tab 112)	13, 300- 309	kernel/sys/vgsa.h (Tab 118)	37, 56-73

25

These AIX/EVMS files are header files originating in UNIX/AIX. The AIX/EVMS Protected Materials found in Linux 2.4 kernel at lines 157-263 (Tab 112) is traced directly back to, and is a copy of, AIX 9922A_43NIA version at lines 64-170 (Tab 113). Lines 311-327 (Tab 112) from Linux are copies of AIX at lines 234-250 (Tab 114). Lines 329-349 (Tab 112) from Linux are copies of AIX lines 252-272, 289-307 (Tab 114). Lines 352-400 (Tab 112) from Linux are copies of AIX lines 316-363 (Tab 114). Lines 266-294 (Tab 112) from Linux are copies of lines 24-92 from AIX (Tab 117). Lines 6-11 (Tab 112) from Linux are copies of lines 26-35 of AIX (Tab 116). Line 26 (Tab 112) of Linux is a copy of line 32 of AIX (Tab 117). Lines 13, 300-309 (Tab 112) of Linux are copies of lines 37, 56-73 of AIX (Tab 118). As with the violations above, these transfers of Protected Materials by IBM constitute improper use of AIX for and by others, improper transfers of AIX to others, and improper adaptation of AIX as a general operating system for a non-IBM company under the restrictions of the Related Agreements. In disregard of the Related Agreements, IBM has transferred this key enterprise technology From UNIX/AIX to Linux.

SCO also has reasonable cause to believe that IBM is, and has since about 2001, continuously used UNIX Technology, including Protected Materials embodied in AIX and Dynix/ptx, in ways that are not directly traceable to specific transfer of source code to Linux, but nevertheless deploy methods, sequences and structures from UNIX-based Protected Materials. IBM has made numerous statements about the many ways in which it is improving the performance of Linux--far too many

26

In order for Linux to be enterprise-ready and commercially viable in the SMP market, its SMP scalability, disk and network I/O performance, scheduler, and virtual memory manager must be improved relative to commercial UNIX systems.

The Linux Scalability Effort (LSE) (see Resources for a link) is an open source project that addresses these Linux kernel issues for enterprise class machines, with 8-way scalability and beyond.

The IBM Linux Technology Center's (LTC) Linux Performance Team (see Resources for a link) actively participates in the LSE effort. In addition, their objective is to make Linux better by improving Linux kernel performance with special emphasis on SMP scalability. (Emphasis added).

As specified in this quotation, IBM is placing "special emphasis" on SMP (i.e., Symmetrical Multi-Processing) scalability. The IBM Linux Enhancement Study continues by identifying a table that identifies the areas in which IBM is dedicating resources and funds to improve Linux performance and functionality in enterprise applications. The IBM Table is set out below as Table L.

27

TABLE L
Linux kernel performance benchmarks

Linux kernel component	Database query	VolanoMark	SPECweb99 Apache2	NetBench	Netperf	LMBench	TioBench IOZone
Scheduler	-	X	X	X	-	-	-
Disk I/O	X	-	-	-	-	-	X
Block I/O	X	-	-	-	-	-	-
Raw, Direct & Async I/O	X	-	-	-	-	-	-
Filesystem (ext2 & journaling)	-	-	X	X	-	X	X
TCP/IP	-	X	X	X	X	X	-
Ethernet driver	-	X	X	X	X	-	-
Signals	-	X	-	-	-	X	-
Pipes	-	-	-	-	-	X	-
Sendfile	-	-	X	X	-	-	-
pThreads	-	X	X	-	X	-	-
Virtual memory	-	-	X	X	-	X	-
SMP scalability	X	X	X	X	X	-	X

Again, Table L identifies specifically that IBM has achieved SMP scalability in every single area identified in the performance benchmark testing. The IBM Linux Enhancement Study continues by charting performance improvements IBM has made to Linux performance, thus far, specified as follows:

28

This chart states that IBM has achieved on Linux a 5x improvement in throughput on an 8-way 700 MhZ Pentium III Intel Processor with 2MB L2 Cache, 8 GB Ram, running on an IBM SerRAID on RedHat 7.1 Linux Kernel 2.4.6/2.4.16/2.4.17. IBM concludes the IBM Linux Enhancement Study with the following summary statement:

Linux has enjoyed great popularity, specifically with low-end and midrange systems. In fact, Linux is well regarded as a stable, highly-reliable operating system to use for Web servers for these machines. However, high-end, enterprise level systems have access to gigabytes, petabytes, and exabytes of data. These systems require a different set of applications and solutions with high memory and bandwidth requirements, in addition to larger numbers of processors (see Resources for the developerWorks article, "Open source in the biosciences", which discusses this type of application).

This type of system application introduces a unique set of issues that may be orders of magnitude more complex than those present in smaller installations. In order for Linux to be competitive for the enterprise market, its performance and scalability must improve.

Our experience thus far indicates that the performance of the Linux kernel can be improved significantly. We are proud to contribute to this goal by working within the open source community to quantify,

29

Linux kernel performance, and to develop patches to address degradation issues to make Linux better, and to make it enterprise ready. (Emphasis added).

As admitted by IBM, it is actively working with the open source community to improve Linux performance in large-systems for enterprise use, particularly through advanced use of SMP sequences and structures. In addition to the numerous improper contributions detailed above, based on information and belief, IBM is improperly using methods, sequences and structures from UNIX that are included in the Protected Materials in order to make such improvements. However, performance improvements such as SMP are not readily visible from evaluation of the Linux code base alone. Plaintiff needs complete discovery from IBM to fully identify all of the ways in which IBM is contributing methods, sequences, structures and code to Linux SMP and other performance enhancements, and to fully identify the degree to which IBM is improperly using Protected Materials in making such enhancements.

Upon receipt of complete discovery from IBM, particularly all versions of AIX and Dynix/ptx, SCO will be able to further identify with greater particularity the specific ways in which the referenced files and others were created by IBM and its agents, contractors and partners, the methods used in creating such files, and their improper contribution to Linux. SCO therefore may provide additional supplements to this interrogatory answer as discovery progresses.

30

INTERROGATORY NO. 2:
For each alleged trade secret of any confidential or proprietary information identified in response to interrogatoty No. 1, please identify: (a) all persons who have or have had rights to the alleged trade secret or confidential or proprietary information; (b) the nature and source of the rights; and (a) all efforts by any person to maintain the secrecy or confidentiality of the alleged trade secrets and any confidential or proprietary information.

SUPPLEMENTAL RESPONSE TO INTERROGATORY NO. 2:
Subject to and without waiving its objections, Plaintiff supplements its response to this Interrogatory No.2 and states that persons who have or have had rights to the information that IBM was required to maintain as confidential or proprietary and/or constitutes trade secrets, as contained in the files and lines of code identified in response to Interrogatory 1 above, include IBM and Sequent and their respective employees, contractors and agents and some customers. In addition, SCO, and its predecessors in interest including The Santa Cruz Operation, Novell, UNIX Systems Laboratories and AT&T, required that such informatian be maintained in confidence pursuant to the Software Agreements and Sublicensing Agreements with IBM and Sequent attached to the Amended Complaint, together with Related Agreements. For many years, IBM (and Sequent) complied with the terms and conditions of the foregoing agreements, such as maintaining the confidentiality of UNIX System V and the derivative works and modifications thereto. In fact, besides having their own license agreements with their customers, which required confidentiality of the code identified above and otherwise restricted use of such code, Sequent and IBM also would require customers who

31

The latest efforts by any person to maintain the secrecy or confidentiality of the information identified above occurred when SCO learned that IBM was breaching the terms of its above referenced agreements by giving its modifications and derivatives of System V to Linux. Specifically, SCO first attempted to negotiate with IBM to prevent IBM's improper disclosure of the Protected Materials. Thereafter, SCO filed suit against IBM and then terminated IBM's (and Sequent's) licenses and sublicenses.

INTERROGATORY NO. 3:
For each alleged trade secret and any confidential or proprietary information identified in response to Interrogatory No. 1, please identify all persons to whom the alleged trade secret or confidential or proprietary information is known or has been disclosed and describe, in detail, the circumstances under which it became known or was disclosed, including but not limited to: (a) the date on which the alleged trade secret or confidential or proprietary informatian was disclosed or became known to such persons; (b) the specific terms on which the information was disclosed or became known, such as pursuant to a confidentiality agreement; (c) all documents or agreements relating to the disclosure; and (d) all places or locations where the alleged trade secret or confidential or proprietary information may be found or accessed.

32

SUPPLEMENTAL RESPONSE TO INTERROGATORY NO. 3:
Subject to and without waiving its objections, Plaintiff supplements its response to this Interrogatory No. 3 and states that because IBM posted the Protected Materials publicly, including in the Linux 2.4 kernel and above, it is impossible to identify all persons to whom the Protected Materials have been disclosed.

Despite IBM's failure to provide the necessary discovery, SCO is currently aware of the following persons at IBM in which part of the confidential or proprietary and/or trade secret information was known or had been disclosed:

IBM - US Authors>

[redacted]

33

IBM - Australian Authors
[redacted]

IBM - Other
[redacted]

34

The following persons likely have knowledge, although their names do not appear in the Linux code base. Upon receipt of discovery from IBM, SCO will be better able to definitively state whether these individuals have the requisite knowledge:

[redacted]

35

36

IBM Primary Technical Contacts in Project Monterey:
[redacted]

37

As further response to subpart (a), where available, the information in response to Interrogatory 1, particularly the tabbed exhibits, identify the dates when such information was publicly disclosed. As to subparts (b) and (c), IBM may have entered into agreements with others to make such contributions. SCO, however, does not have the agreements, if any, IBM entered into to disclose such materials to Linux. As to subpart (d), the Tables and tabbed exhibits in response to Interrogatary No. 1 identify where such information may be accessed or located.

INTERROGATORY NO. 4:
For each alleged trade secret and any confidential or proprietary information identified in response to Interrogatory No.1, please describe, in detail, each instance in which plaintiff alleges or contends that IBM misappropriated or misused the alleged trade secret or confidential or proprietary information, including but not limited to: (a) the date of the alleged misuse or misappropriation; (b) all persons involved in any way in the alleged misuse or misappropriation; (c) the specific manner in which IBM is alleged to have engaged in misuse or misappropriation; and (d) with respect to any code or method plaintiff alleges or contends that IBM misappropriated or misused, the location of each

38

SUPPLEMENTAL RESPONSE TO INTERROGATORY NO. 4
Subject to and without waiving its objections, Plaintiff supplements its response to this Interrogatory No. 4 and states that IBM misappropriated and misused the trade secrets and/or confidential and proprietary information of Plaintiff each time it made contributions to Linux, including contributions to Linus Torvalds and/or the Open Source Development Laboratory ("OSDL"), including the Protected Materials identified in response to Interrogatory No. 1, in violation of the Software and Sublicensing Agreements attached to the Amended Complaint. As to subpart (a), the dates of contributions, if known, are identified in the Tables and tabbed exhibits in Interrogatory No. 1. As to subpart (b), to the extent the identity of persons involved in the misuse or misappropriation is publicly known, those individuals are identified in the tabbed exhibits in response to Interrogatory No. 1. Others at IBM who may have been involved in the public dissemination of the Protected Materials identified in response to Interrogatory No. 1 are also identified in response to Interrogatory No. 3 above. Until IBM identities these individuals in discovery, SCO is unable to identify further individuals involved in the public dissemination of the material identified in Interrogatory No. 120

INTERROGATORY NO. 5:
For each alleged trade secret and any confidential or proprietary information identified in response to Interrogatary No.1, please identify: (a) all agreements relating to the alleged trade secret or confidential or proprietary information including but not limited to the parties to and the terms of the agreements; and (b) all copyrights and patents relating to the alleged trade secret or confidential or

39

SUPPLEMENTAL RESPONSE TO INTERROGATORY NO. 5
Subject to and without waiving its objections, Plaintiff supplements its re sponse to subpart (a) by referencing all of the agreements with IBM and Sequent attached to the Amended Complaint and Related Agreements. The numerous Related Agreements between SCO (or its predecessors) and IBM and Sequent are found at the following Bates numbers: 9085045, 0986966, 0988096-0988097, 0990372-0990373, 0996962, 0997870, 1000091-1000092, 1000191, 1000197-1000201, 1000202-1000203, 1000204-1000214, 1000222-1000223, 1003707, 1006113-1006120, 1014916-1015030, 1017409, 1017421, 1017436-1017437, 1017444-1017526, 1017548-1017558, 1017559-1017562, 1017563, 1017573-1017576, 1017581-1017535, 1017586-1017588, 1017600-1017607, 1017608-1017610, 1017611-1017612, 10227495, 1022500, 1022506-1022507, 1026515, 1026516-1026517, 1112278, 1127016-1127021, 1021961-1021966, 1009625-1009633, 1153282-1153286, 1153287-1153288, 1003293-1003299, 1122744-1122745, 0981279, 1014788, 0976801-0976802, 0976880-0976881, 0977352-0977353, 0977524-0977526, 0977836, 0977948-0977949, 0978147, 0978202-0978206, 0978258-0978292, 0978348, 0978350, 1288870-1288875, 1169925-1169928, 1174979-1174981, 1169925-1169928, 1174966-1174978, 1174979-1174981, 1289249-1289251, 1174983-1174986, 1174989-1174990, 1175000-1175001, 11754002, 1175007-1175011, 1175017-1175021, 1175022-1175024, 1175025-1175030, 1175031-1175034, 1175040-1175051, 1175052-1175071, 1289255, 1175072-1175084, 1175136-1175141, 1175142-1175146, 1175147-1175152, 1175153-1175155, 1175212-1175243, 1175244-1175251, 1175252-1175254, 1289294-1289300, 1175255-1175258, 1175280-1175283, 1175287-1175309, 1175310, 1289313-1289342, 1175349-1175378,

40

41

INTERROGATORY NO. 6:
For each line of source or object code and each method identified in response to Interrogatory No. 1, please identify: (a) the origin of the code or method, including when, where and by whom the code or method was created; and (b) all products in which, in whole or in part, the code or method is included or on which, in whole or in part, the code or method is based.

42

SUPPLEMENTAL RESPONSE TO INTERROGATORY NO. 6:
Subject to and without waiving its objections, Plaintiff supplements its response to this Interrogatory No. 6 and states that the origin of the code and/or method identified in response to Interrogatory No. 1 above is at two levels. At the original level, the origin of the code or method, or that on which it is based, is UNIX System V code licensed by IBM and Sequent, i.e., System V Release 3.2 and System V Release 4.0, as AIX and Dynix/ptx are modifications or derivatives of UNIX System V. At the modification or derivative level, the origin of this code is from AIX or Dynix/ptx as set forth in the Tables and tabbed exhibits in response to Interrogatory No. 1. Because that work was done by IBM and Sequent and because SCO has not received complete discovery from IBM on the creation of this code, SCO cannot provide any further detail as to who at IBM or Sequent created the code or method or precisely when they did so. To the extent the contributions by IBM identified in response to Interrogatory No. 1 publicly identify who at IBM made the contribution to Linux, it appears in the tabbed exhibits in response to Interrogatory No. 1. The code or method identified in response to Interrogatory No. 1 is included in any product that contains the Linux kernel 2.4 and above, which is sold or distributed by hundreds of entities around the world thereby making it impossible to identify all products in which this code is included. As to SCO, the products that it discontinued distributing that include the information identified in response to Interrogatory No. 1 likewise are those that contain the Linux kernel 2.4 and above. These products are as follows:

SCO Linux Server 4.0, Powered by UnitedLinux IPF (64bit Itanium)
SCO Linux Server 4.0, Powered by UnitedLinux

43

INTERROGATORY NO. 7:
Please describe, in detail, each instance in which plaintiff alleges that IBM engaged in unfair competition, including but not limited to: (a) the dates on which IBM allegedly engaged in any unfair competition; (b) all persons involved in the alleged unfair competition; and (c) the specific manner in which IBM is alleged to have engaged in unfair competition including but not limited to as alleged in ¶118 of the Complaint.

SUPPLEMENTAL RESPONSE TO INTERROGATORY NO. 7:
See answer to interrogatary 8 below. In addition, IBM's unfair competition arose from the relationship it established with SCO as a result of the joint effort between SCO and IBM known as "Project Monterey." Part of the focus of Project Monterey was to jointly develop an operating system based on SCO's UnixWare for 64-bit Intel processors. Beyond the scope of the formal contract to create the new operating system for 64-bit Intel processors, IBM made numerous representations to SCO. These representations by IBM executives to SCO executives, made during or about Q4 of 1998 that IBM would do the following as part of a broad partnership relationship with SCO:

 (a) Port its family of enterprise applications to SCO's existing 32-bit version of UnixWare, including Lotus/Domino, Tivoli, WebSphere and DB2;

 (b) Publish its own price list for SCO's existing 32-bit version of UnixWare, and market 32-bit UnixWare within its own customer base;

 (c) Market SCO's existing 32-bit version of Unixware within IBM's ISV channels, encourage IBM's ISV partners to port their applications to UnixWare, and invite

44

SCO marketing representatives on joint marketing calls to IBM's ISV partners for these purposes;

 (d) Expand IBM's family of products so that SCO's existing 32-bit version of UnixWare and AIX would jointly operate in a combined environment for RISC and Intel proccssors.

In return, IBM asked SCO for access to SCO's OEM channels and ISV partner relationships so that IBM could start promoting the joint IBM/SCO products through SCO's OEM channels. At this point in time, IBM had had little or no UNIX-based independent experience with the companies that were SCO's OEMs. SCO, on the other hand, had had years of successful experience, and deep UNIX-based business relationships with its 15,000 OEM channel partners.

A Project Monterey Fact Sheet designed jointly by SCO and IBM in October 1998 spoke of the new enhanced relationship, as represented by IBM and relied on by SCO, in part, as follows:

On October 26th, 1998 SCO announced that it has reached a strategic, long-term business agreement with IBM Corporation. SCO and IBM in collaboration with Intel and other key partners, will aggressively accelerate worldwide growth of Intel processor-based UNIX servers for the enterprise, and will deliver a seamless family of UNIX products for today's IA-32 systems and future IA-64 systems.

Under the new agreement, IBM is applying substantial resources to promote and sell SCO's UnixWare operating system word wide, and feed the demand for 32-bit systems in the enterprise. IBM has committed to make UnixWare 7 its strategic 32-bit UNIX operating system for the high volume enterprise market, and will offer it as a member of its new UNIX product family. (Emphasis added.)

A working draft of the Project Monterey Fact Sheet is attached as Exhibit 120. The detailed plan discussed between SCO and IBM for porting IBM's enterprise applications identified above to UnixWare in a document entitled "Solution Stacks for Project Monterey" attached as Exhibit 103.

45

SCO reasonably relied on IBM's representations identified above, based on the circumstances. As a result of the formal agreement between SCO and IBM and the numerous representations made by IBM that were calculated to be relied on by SCO, IBM had a fiduciary obligation to SCO that required IBM to be forthright and truthful in all affairs related to the partnership relationship.

Based on the agreed strategic relationship to promote 32-bit UnixWare and to develop new products as a family of products with IBM and AIX, SCO ceased its own independent efforts to aggressively market UnixWare for broad enterprise applications, even though the demand for UnixWare product (UNIX on Intel) was substantial at the time. The general time frame for the above representations was Q4, 1998.

Following the events specified above, SCO worked aggressively to make the joint relationship actually came about. SCO diverted resources for independent development and marketing of UnixWare 7 in order to create the new IBM and SCO relationship. SCO also introduced IBM products to its entire ISV network, and encouraged its ISV network to develop stronger relationships with IBM in UNIX-on-Intel environment. SCO also encouraged its largest OEM partners, including those identified above, to begin a working relationship with IBM for development of UnixWare on Intel. Prior to that time, SCO's OEM partners had been largely competitors of IBM in UNIX. Therefore, SCO's encouragement of OEM partners to work with IBM was a significant benefit to IBM. SCO continued in this vein, attempting to advance the joint goals of IBM and SCO as represented by IBM and as set forth above, from Q4 1998 through and including most of the entire year of 1999. IBM, on the other hand, unfairly took advantage of its partnership relationship with

46

IBM did not port its applications to UnixWare. IBM did not introduce its ISV partners to SCO. IBM did not promote or market UnixWare. IBM did not provide working documents to combine UnixWare with the AIX family of products, as had been earlier represented. The general excuse used by IBM executives during this period of time for its failure to perform was to the effect that IBM always acted slowly in doing things. Therefore, SCO kept promoting IBM and encouraging SCO ISV partners and OEM partners to develop relationships with IBM, while IBM did nothing in return. Because of the fiduciary relationship that existed between the parties under Project Montcrey formal agreements, IBM had a fiduciary obligation to deal fairly with SCO, to inform SCO of changes in its business plans that might effect UnixWare, and to be forthright and clear in all such matters so that SCO would be able to rely properly on earlier representations that IBM had made, or understand that it needed to go in its own direction rather than rely on IBM.

IBM failed in its fiduciary obligation to deal fairly with SCO in its intentions with respect to UnixWare and its plans to form a family of UNIX architectural products tied to IBM's own AIX. In fact, while leading SCO to believe that UnixWare would join the "IBM family of products," it was secretly planning to undermine UnixWare and SCO, and replace UnixWare with Linux. During a substantial part of 1999 IBM was secretly developing plans to cease its planned strategic relationship with SCO, as outlined above, and to begin supporting Linux. On information and belief, this planning was also done with Intel, who was a partner with SCO and IBM in Project Monterey. Neither IBM nor Intel, during 1999, informed SCO of their true plans to support Linux instead of UnixWare. At the end of December 1999, IBM announced publicly its plans to support Linux.

47

Because IBM had been developing its plan to replace its UnixWare support with Linux support, and because it knew that SCO had dedicated its entire enterprise resources to the IBM/UnixWare joint relationship, IBM had a fiduciary obligation to inform SCO of its Linux-related plans long before its Linux public announcement of Decembcr 1999. IBM's acts that rise to unfair competition cognizable at law included unfair conduct described above, which occurred during the time period specified, and involving the persons specified above. Specifically, IBM's conduct which is properly characterized as unfair competition is:

 (a) Failure to timely disclose to SCO the secret IBM plan to support Linux in place of UnixWare, even though IBM knew that SCO's entire resources were dedicated to a long-term strategic plan with IBM based on IBM's representations that it was supporting UnixWare;

 (b) Intentionally diverting SCO's resources away from UnixWare competition against IBM with other potential industry partners so that IBM could gain the lead time needed to develop Linux before UnixWare took hold in the market among enterprise customers;

 (c) Making secret plans with Intel during 1999 to support Linux without notifying SCO of such plans, even though Intel, SCO and IBM were all partners in Project Monterey, and even though IBM should have known that joint IBM/Intel support for Linux was calculated to undermine the purpose of Project Monterey;

 (d) Unfairly inducing SCO to promote IBM within SCO's ISV partnerships and OEM channels, with knowledge that SCO's promotion of IBM was

48

solely based on its expectation that IBM would perform under Project Monterey, and with knowledge that IBM had no intention of performing under Project Monterey;

 (e) Unfairly co-opting SCO's business relationships with its ISV partners and OEM partners under false pretenses;

 (f) Unfairly inducing SCO to dedicate its entire enigineering and marketing resources to promote Project Monterey as the enterprise class UNIX product for Intel processors, in order to prevent SCO from independently marketing the value of its Unixware 7 for enterprise use at a time when IBM had no intention to support Unixware and that it intended to replace UnixWare with Linux;

 (g) Using products, methods and know-how jointly developed by SCO and IBM in Project Monterey to develop and market AIX5L for Linux.

IBM executives involved in the representations specified above included include [redacted]. The persons at IBM involved in unfair competition are directly unknown to SCO, inasmuch as activity of this sort is typically done behind closed doors. The allegations set forth above regarding IBM's development of Linux during 1999 are based on IBM's later public statements regarding its involvement with Linux. SCO needs to take discovery of IBM to identify the exact extent of its Linux activities during 1999, and the persons involved therein. SCO, however, believes that such persons will include the authors of the 10-page Linux report sought by SCO in discovery, identified above, and all other senior management

49

INTERROGATORY NO. 8:
Please identify all agreements with which plaintiff alleges IBM interfered and describe, in detail, each instance in which plaintiff alleges or contends that IBM interfered with those agreements, including but not limited to: (a) the date of the alleged interference; (b) all persons involved in the alleged interference; (c) the specific manner in which IBM is alleged to have interfered with the agreement; (d) the specific actions, if any, that IBM induced or encouraged plaintif's customers or licensees to take; (e) the specific action, if any, that plaintiff's customer or licensee took as a result of the actions allegedly induced or encouraged by IBM; and (f) the specific trade secret or confidential or proprietary information, if any, involved in the alleged interference.

SUPPLEMENTAL RESPONSE TO INTERROGATORY NO. 8:
IBM interfered with SCO's software licensing agreement with AutoZone for the SCO OpenServer software operating system, Contract #IV736, effective January 24, 2001 (the AutoZone Openserver License Agreement). Under the AutoZone Openserver License Agreement, AutoZone utilized the SCO software as the foundation from which to conduct all store operations including inventory tracking, point of sale transactions, back office server activities, event monitoring and to enable corporate updates to be transmitted to all retail locations.

In mid-2000, upon information and belief, IBM approached AutoZone in an effort to induce AutoZone to breach its agreement with SCO. In the second quarter of 2001, IBM was activeiy advising AutoZone's internal soiware group about converting to Linux. In the second quarter of 2001, despite the AutoZone Openserver License Agreement with SCO, upon information and belief,

50

Upon information and belief, AutoZone's new Linux based software implemented by IBM featured SCO's shared libraries which had been stripped out of SCO's UNIX based OpenServer by IBM and embedded inside AutoZone's Linux implementation in order to continue to allow the continued operation of AutoZone's legacy applications. The basis for SCO's belief is the precision and efficiency with which the migration to Linux occurred, which suggests the use of shared libraries to run legacy applications on Linux. Among other things, this was a breach of the AutoZone OpenServer License Agreement for use of SCO software beyond the scope of the license.

Upon information and belief, AutoZone is currently in breach of the AutoZone OpenServer License Agreement in that AutoZone is improperly using "shared libraries" (short cuts and methods which allow programs to interface with one another and the services of the operating system) contained in the OpenServer (UNIX based) operating system to enable "legacy applications" to function on Linux. Legacy applications are those versions of software applications that have a lengthy and proven track record of high level function and reliability. The legacy applications utilized by AutoZone were designed specifically to operate with OpenServer (UNIX based) shared libraries, but do not function with Linux shared libraries.

IBM was aware of the AutoZone OpenServer License Agreement. IBM knew that the SCO OpenServer shared libraries were proprietary to SCO. Therefore, IBM knew, or should have known, that by assisting AutoZone to implement Linux to support legacy applications by improperly

51

SCO does not presently know the specific dates on which the interference occurred, how it occurred or which IBM or AutoZone employees were involved because SCO was not present when IBM sold Linux-related services to AutoZone, when IBM assisted AutoZone in the design of the new Linux system deploying legacy applications that depended on SCO OpenServer shared libraries in order to function, or when IBM performed the professional services to assist AutoZone to improperly deploy OpenServer shared libraries inside its IBM-provided Linux implementation. More specific information, such as which IBM and AutoZone employees were involved, is in the possession of IBM and/or AutoZone and will require additional discovery from at least IBM and AutoZone.

Upon information and belief, IBM interfered with SCO's software licensing agreement with Sherwin Williams for the SCO OpenServer software operating system in existence since at least 1995, (the Sherwin Wiliiams OpenServer License Agreement). Sherwin Williams utilized the SCO software as the key component to operate all of their retail store locations for over 10 years. The software enabled Sherwin Williams to operate its point of sale system and back office server. Upon information and belief, in 2001 and 2002 IBM began working with Sherwin Williams in order to induce Sherwin Williams to breach its agreement with SCO. As a result, upon information and belief, Sherwin Williams is currently in breach of the Sherwin Williams OpenServer License

52

Upon information and belief, IBM induced Sherwin Williams to abandon its use of SCO's OpenServer UNIX product in favor of Linux in the summer of 2001. Upon information and belief, Sherwin Williams' new Linux based software implemented by IBM featured SCO's shared libraries which had been stripped out of SCO's UNIX based OpenServer and embedded inside Sherwin Williams' Linux implementation in order to continue to allow the continued operation of Sherwin Williams' legacy applications. SCO's belief is based upon the precision and efficiency with Sherwin Williams accomplished the migration, which suggests the use of shared libraries to run legacy applications on Linux. However, IBM and Sherwin Williams were not entitled to strip out SCO's shared libraries for use inside their Linux implementation in order to continue operating legacy applications. This was a breach of the Sherwin Williams OpenServer License Agreement for use of SCO software beyond the scope of the license. Upon information and belief, IBM induced Sherwin Williams to use the SCO OpenServer shared libraries beyond the scope of the Sherwin Williams Openserver License Agreement, and by assisting Sherwin Williams to implement Linux to support legacy applications by improperly incorporating the SCO OpenServer shared libraries. The act of inducing and assisting Sherwin Williams to breach its license agreement with SCO was an act that

53

SCO does not presently know the specific dates on which the interference occurred, the identities of those involved, nor how the interference occurred because SCO was not present when IBM sold Sherwin Williams Linux-related services, or when IBM assisted Sherwin Williams in the design of the new Linux system deploying legacy applications that depended on SCO OpenServer shared libraries in order to function, or when IBM performed the professional services to assist Sherwin Williams to improperly deploy OpenServer shared libraries inside its IBM-provided Linux implementation. More specific information, such as which IBM and Sherwin Williams employees were involved, is in the possession of IBM and/or Sherwin Williams and will require additional discovery from at least IBM and Sherwin Williams.

IBM interfered with SCO's software licensing agreement with Target for the SCO OpenServer software operating system Contract # IV743 dated March 2001 (the Target OpenServer License Agreement). Target utilized the SCO software in order to operate store pharmacies.

Within the last month, SCO has been informed that Target has decided to abandon its use of SCO's OpenServer UNIX product. Upon information and belief, Target's decision was induced by IBM. SCO contends that the act of inducing and assisting Target to breach its license agreement with SCO was an act that constitutes interference with contract by IBM. IBM stands to profit from the interference by earning significant professional services fees in performing the switch from SCO OpenServer to Linux.

54

More specific information, such as which IBM and Target employees were involved, is in the possession of IBM and/or Target and will require additional discovery from at least IBM and Target.

Insofar as IBM has been involved in the sale and deployment of Linux-related products and services to any other customers of SCO for the use and deployment of SCO OpenServer shared libraries inside a Linux implementation, that conduct is also interference with SCO's licensing agreements with such parties and there may in fact be additional SCO customers that have been interfered with other than AutoZone, Sherwin Williams and Target.

IBM has also improperly interfered with SCO's business relationships and prospective economic relationships. The facts known to Plaintiff giving rise to the conduct of such interference started during the LinuxWorld 2003 convention held in New York during or about January 2003. During this event, Darl MeBride, SCO's CEO, informed Karen Smith of IBM that SCO intended to offer a software license to Linux users to allow for legal and authorized use of SCO's UNIX OpenServer shared libraries in a Linux implementation. Karen Smith responded by saying that "IBM was not pleased with SCO's plan to offer licenses for OpenServer shared library use in Linux", and that "the licensing plan would kill Linux." Ms. Smith also said that as a result of SCO's licensing plan for SCO OpenServer shared libraries, "IBM was going to cut off all of its business ties with SCO, and would have other IBM business partners do the same." Ms. Smith contacted Mr. Becker of Hewlett Packard during or shortly after the LinuxWorld 2003 convention and stated that IBM was cutting off all business ties with SCO and wanted Hewlett Packard to do the same. On information and belief, Ms. Smith also contacted representatives from Intel, Computer Associates, and Oracle for the same purpose and with the same general statement that IBM wanted each of those respective cempanies to cut off business ties with SCO. On information and belief, such contact by Ms. Smith

55

INTERROGATORY NO. 9
Please identify all agreements that plaintiff alleges or contends that IBM has breached, including the specific provisions or portions of those agreements that plaintiff alleges or contends that IBM breached, and describe, in detail, each instance in which plaintiff alleges or contends that IBM breached those agreements, including but not limited to (a) the date of the alleged breach; (b) all persons involved in the alleged breach; and (c) the specific manner in which IBM is alleged to have breached the agreement.

SUPPLEMENTAL RESPONSE TO INTERROGATORY NO. 9:
Subject to and without waiving its objections, at this time, SCO supplements its answer to Interrogatory No. 9 and states that, as detailed in the Amended Complaint, among the provisions of the Software and Sublicensing Agreements that IBM breached are Sections 2.01, 2.05, 4.01, 6.03 and 7.06, of the Software Agreement. Section 2.01 was breached by IBM's failure to treat modifications and derivative works as part of the original Software Product by contributing such items to open source. Likewise, IBM breached Section 2.05 by allowing use for others and by others as a result of contributing the Protected Materials to open source. Section 4.01 prohibits export of the Software Products, which IBM breached by contributing the Software Product, including methods, modifications and derivative works to open source. As a result, persons anywhere in the world with a

56

Indeed, Amendment X, §3.7, provides examples under which IBM is entitled to disclose UNIX and AIX source code to its development partners--and examples under which IBM is not entitled to make such disclosures. Paragraph 3.7 of Amendment X provides as follows:

57

The following illustrations are intended to clarify and illustrate the relief provided in Subsection 2.1 of this Amendment [relating to disclosure of source code to contractors].

Company A, sublicensee of the Sublicensed Product [AIX] is a general computing system manufacturing firm. IBM may distribute Source Copies to Company A for Authorized Purposes.

However, IBM may not distribute Source Copies to Company A for purposes of making modifications to adapt the Sublicensed Products [AIX] as a general operating system for Company A's general computer hardware system.

As is made perfectly clear in ¶ 3.7 of Amendment X, IBM may not use any Sublicensed Product from SCO, including AIX, for the purposes of making modifications to adapt AIX as a competing general operating system. IBM's breaches of contract under the Software Agreement, the Side Letter, Amendment X, and related agreements confirm one undisputable fact: IBM is using UNIX, AIX, and Dynix/ptx to improve Linux, and is thereby adapting UNIX, AIX, and Dynix/ptx for use in a competing operating system in violation of its obligations to SCO.

INTERROGATORY NO. 12
Please identify, with specificity (by file and line of code), (a) all source code and other material in Linux (including but not limited to the Linux kernel, any Linux operating system and any Linux distribution) to which plaintiff has rights; and (b) the nature of plaintiff's rights, including but not limited to whether and how the code or other material derives from UNIX.

58

SUPPLEMENTAL RESPONSE TO INTERROGATORY NO 12:
SCO objects to this question as overly broad and unduly burdensome, and on the basis that it seeks information neither relevant nor calculated to reasonably lead to the discovery of admissible evidence insofar as it requests the identity of source code and other material in Linux contributed to Linux by parties other than IBM or Sequent. Subject to and without waiving these objections, as it pertains to SCO's rights involving IBM's contributions to Linux, SCO has set forth that information in response to Interrogatories Nos. 1 and 9 and the corresponding exhibits. As to others who have violated the terms of their Software and Sublicensing Agreements, that information is contained in Exhibits A through C. Specifically, in Exhibit A, it details the line-for-line copying of UNIX System V code that improperly appears in Linux. Similarly, in Exhibit B, SCO identifies the application binary interfaces ("ABIs") that SCO has rights to that are improperly in Linux. Specifically, in 1992, Unix Systems Laboratories (USL), SCO's predecessor in interest, sued Berkeley Software Design, Inc. (BSD) for, among other things, copyright infringement. One of the bases of that action was BSD's copying and distributing some USL UNIX System V files without proper permission or attribution. The confidential Settlement Agreement that ended the Unix Systems Laboratories, Inc. v. Berkeley Software Design, Inc., litigation required BSD to change the copyright information in certain of these files, including the nine files listed in Exhibit B. To SCO's knowledge, BSD complied with the terms of the Agreement, and gave USL the proper attribution, as also set forth in Exhibit B. At a later time, persons as yet unknown copied these files into Linux, erasing the USL copyright attribution in the process. The files in Linux that improperly use the ABIs are as follows:

linux-2.4.21/include/asm-alpha/errno.h

59

linux-2.4.21/include/asm-arm/errno.h
linux-2.4.21/include/asm-cris/errno.h
linux-2.4.21/include/asm-i386/ errno.h
linux-2.4.21/include/asm-ia64/errno.h
linux-2.4.21/include/asm-m68k/errno.h
linux-2.4.21/include/asm-mips/errno.h
linux-2.4.21/include/asm-mips64/errno.h
linux-2.4.21/include/asm-parisc/errno.h
linux-2.4.21/include/asm-ppc/errno.h
linux-2.4.21/include/asm-ppc64/errno.h
linux-2.4.21/include/asm-s390/errno.h
linux-2.4.21/include/asm-s390x/errno.h
linux-2.4.21/include/asm-sh/errno.h
linux-2.4.21/include/asm-sparc/errno.h
linux-2.4.21/include/asm-sparc64/errno.h
linux-2.4.21/include/asm-x86_64/errno.h
linux-2.4.21/include/asm-alpha/signal.h
linux-2.4.21/include/asm-arm/signal.h
linux-2.4.21/include/asm-cris/signal.h
linux-2.4.21/include/asm-i386/signal.h
linux-2.4.21/include/asm-ia64/signal.h
linux-2.4.21/include/asm-m68k/signal.h
linux-2.4.21/include/asm-mips/signal.h
linux-2.4.21/include/asm-mips64/signal.h
linux-2.4.21/include/asm-parisc/signal.h
linux-2.4.21/include/asm-ppc/signal.h
linux-2.4.21/include/asm-ppc64/signal.h
linux-2.4.21/include/asm-s390/signal.h
linux-2.4.21/include/asm-s390x/signal.h
linux-2.4.21/include/asm-sh/signal.h
linux-2.4.21/include/asm-sparc/signal.h
linux-2.4.21/includelasm-sparc64/signal.h
linux-2.4.21/include/asm-x86_64/signal.h
linux-2.4.21/include/linux/stat.h
linux-2.4.21/include/linux/ctype.h
linux-2.4.21/lib/ctype.c
linux-2.4.21/include/asm-alpha/ioctl.h
linux-2.4.21/include/asm-alpha/ioctls.h
linux-2.4.21/include/asm-arm/ioctl.h
linux-2.4.21/include/asm-cris/ioct1.h
linux-2.4.21/include/asm-i386/ioctl.h
linux-2.4.21/include/asm-ia64/ioctl.h
linux-2.4.21/include/asm-m68k/ioctl.h

60

linux-2.4.21/include/asm-mips/ioctl.h
linux-2.4.21/include/asm-mips64/ioctl.h
linux-2.4.21/include/asm-mips64/ioctls.h
linux-2.4.21/include/asm-parisc/ioctl.h
linux-2.4.21/include/asm-ppc/ioctl.h
linux-2.4.21/include/asm-ppc/ioctls.h
linux-2.4.21/include/asm-ppc64/ioctl.h
linux-2.4.21/include/asm-ppc64/ioctls.h
linux-2.4.21/include/asm-s390/ioctl.h
linux-2.4.21/include/asm-s390x/ioctl.h
linux-2.4.21/include/asm-sh/ioctl.h
linux-2.4.21/include/asm-sh/ioctls.h
linux-2.4.21/include/asm-sparc/ioctl.h
linux-2.4.21/include/asm-spare/ioctls.h
linux-2.4.21/include/asm-sparc64/ioctl.h
linux-2.4.21/include/asm-sparc64/ioctls.h
linux-2.4.21/include/asm-x86_64/ioctl.h
linux-2.4.21/include/linux/ipc.h
linux-2.4.21/include/linux/acct.h

In Exhibit C, SCO sets forth additional code in Linux in which SCO claims a right. Specifically, Exhibit C shows that Silicon Graphics, Inc. ("SGI") violated its UNIX Software Agreement with SCO by transferring direct lines of UNIX to Linux from its version of UNIX known as "IRIX." IRIX is a derivative work of, and modification based on, System V that contains substantial parts of System V code. In addition to SGI's transfer of direct lines of code from UNIX System V to Linux, as set forth in Exhibit A attached hereto, SGI has improperly transferred the UNIX filing system it developed as part of IRIX to Linux, thereby improperly giving the Linux open source developers access to an advanced journaling file system for streaming media for use in enterprise applications of Linux. On information and belief, most or all of the code contained in all of the files of the IRIX/XFS filing system have been improperly transferred to Linux. Specificaily, in public statements and when contributing these files of code to Linux, SGI has proclaimed credit for these contributions from IRIX:

61

Q: What is XFS?

A: XFS is a journalling filesystem developed by SGI and used in SGI's IRIX operating system. It is now also available under GPL for linux. It is extremely scalable, using btrees extensively to support large and/or sparse files, and extremely large directories. The journalling capability means no more waiting for fsck's or worrying about meta-data corruption.

These files are listed below, with the corresponding source code to each file attached hereto and incorporated herein by reference as Exhibit C. The IRIX/XFS files improperly contributed to Linux are identified in Linux 2.5.64 version as follows:

linux-2.5.64/fs/xfs/linux/xfs_lrw.c
linux-2.5.64/fs/xfs/linux/xfs_sysctl.h
linux-2.5.64/fs/xfs/linux/xfs_linux.h
linux-2.5.64/fs/xfs/linux/xfs_vfs.h
linux-2.5.64/fs/xfs/linux/xfs_fs_subr.c
linux-2.5.64/fs/xfs/linus/xfs_lrw.h
linux-2.5.64/fs/xfs/linux/xfs_super.h
linux-2.5.64/fs/xfs/linux/xfs_stats.h
linux-2.5.64/fs/xfs/linux/xfs_iops.c
linux-2.5.64/fs/xfs/linux/xfs_vnode.c
linux-2.5.64/fs/xfs/linux/xfs_globals.h
linux-2.5.64/fs/xfs/linux/xfs_cred.h
linux-2.5.64/fs/xfs/linux/xfs_iomap.c
linux-2.5.64/fs/xfs/linux/xfs_file.c
linux-2.5.64/fs/xfs/linux/xfs_iops.h
linux-2.5.64/fs/xfs/linux/xfs_behavior.h
linux-2.5.64/fs/xfs/linux/xfs_globals.c
linux-2.5.64/fs/xfs/linux/xfs_fs_subr.h
linux-2.5.64/fs/xfs/linux/xfs_ioctl.c
linux-2.5.64/fs/xfs/linux/xfs_aops.c
linux-2.5.64/fs/xfs/linux/xfs_super.c
linux-2.5.64/fs/xfs/linux/xfs_stats.c
linux-2.5.64/fs/xfs/linux/xfs_version.h

62

63

64

65

As stated above, the source code that is contained in each identified file is attached hereto and incorporated herein by reference as Exhibit C. SCO has not had access to versions of IRIX to compare and identify the exact location where the amending files and lines of code are found inside IRIX. However, the material portions of the files identified above are publicly identified by SGI as having come from IRIX. The transfer of this portion of IRIX to Linux is a violation of its contractual obligations to SCO under the SCO/SGI Software Agreement.

In addition, there are many companies that have Software Agreements with SCO that are substantially similar to the IBM Software Agreement and the Sequent Software Agreement. For example, 41 of the Fortune 100 have a Software Agreement with SCO that contains substantially the same requirements as set forth in the IBM Software Agreement and Sequent Software Agreement. These companies are: Bank of America, Oracle, Cisco, Morgan Stanley, Motorola, Goldman Sachs,

66

INTERROGATORY NO. 13

For each line of code and other material identitied in response to Interrogatory No. 12, please state whether (a) IBM has infringed plaintiff's rights, and for any rights IBM is alleged to have infringed, describe in detail how IBM is alleged to have infringed plaintiff's rights; and (b) whether plaintiff has ever distributed the code or other material or otherwise made it available to the public, as part of a Linux distribution or otherwise, and, if so, the circumstances under which it was distributed

67

SUPPLEMENTAL RESPONSE TO INTERROGATORY 13:

SCO objects to this question on the basis that it is overly broad and unduly burdensome and seeks information neither relevant nor reasonably calculated to lead to the discovery of admissible evidence insofar as it requests the identity of source code and other material in Linux contributed to Linux by parties other than IBM or Sequent. Subject to and without waiving these objections, as it pertains to SCO's rights involving IBM's contributions, SCO incorporates it answers to its revised and supplemental answers to Interrogatory Nos. 1 through 6 and 9 above and the corresponding exhibits.

Insofar as this interrogatory seeks information as to whether plaintif has ever distributed the code in question or otherwise made it available to the public, SCO has never authorized, approved or knowingly released any part of the subject code that contains or may contain its confidential and proprietary information and/or trade secrets for inclusion in any Linux kernel or as part of any Linux distribution. However, as noted above in response to Interrogatory No. 6, the Protected Materials that IBM improperly contributed to Linux from AIX and Dynix/ptx are found in any product that contains the Linux 2.4 kernel or above. SCO sold or distributed the 2.4 kernel and above for a brief period of time in SCO Linux Server 4.0, Powered by UnitedLinux. The sale or distribution of this product was under the GPL without knowledge of the violations identified above. After gaining knowledge of the violations discussed above, SCO ceased distribution of the code in question. The particulars of when

68

PJ's articles are licensed under a Creative Commons License