decoration decoration
Stories

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

Gear

Groklaw Gear

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


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

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

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
IBM's Greatest Hits - Ex. 33, SCO's Revised Supplemental Response to 1st and 2nd Set of Interrogatories - Updated
Wednesday, January 03 2007 @ 10:56 PM EST

I love discovery. Do you remember how I always told you that eventually we'd get to find out pretty much everything, sooner or later, even if we couldn't immediately see all the discovery going on? Here's a really fine example. We find out now what that fiasco about Intel was all about.

Here is Exhibit 33 [PDF], Plaintiff's Revised Supplemental Response to Defendant's First and Second Set of Interrogatories.
[ Update: A kind soul has split it into three parts, all PDFs: Part 1, Part 2, and Part 3.]

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:

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

MACHINES CORPORATION, a
Defendant.

______________________

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

trade secret information by transferring core portions of AIX and Dynix/ptx to Linux, as detailed below (the "Protected Materials").

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

minimal changes. As a result, in this particular instance, SCO is only identifying the file names, without additionally specifying the lines of code within each file.

TABLE A

DynixV v4.6.1 FilesLinux 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 #sLinux 2.4.1-01 files and line #s
kernel/os/kern_clock.c (Tab 10) 02028-2059arch/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-1497arch/i386/kernel/entry.S (Tab 16) 199-205
kernel/i386/trap.c (Tab 12) 1554-1563arch/i386/kernel/traps.c (Tab 17) 52-54, 244-247, 331-334, 542-545, 659-662, 718-721
kernel/i386/startup.c (Tab 13) 2054init/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

718-721. Tab 13 correlates Dynix/ptx code at line 2054 improperly copied into Linux, identitled in Tab 15 at lines 30-33, 609-616. These are instances of direct, line for line copying of Dynix/ptx code into the 2.4.1-01 version of Linux. Prior to this copying, Dynix/ptx had been held in confidence for SCO pursuant to the Sequent Software Agreement.

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 / SequenceDynixV file(s)Line #sLinux 2.6.0 file(s)Line #s
Register an RCU callbackkernel/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 structurekernel/sys/rclock.h (Tab 1) 217-228include/linux/rcupdate.h (Tab 20)66-72
RCU Callback listskernel/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 operatorskernel/sys/rclock.h (Tab 1) 300-312include/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 SubcomponentDynixV file(s)Line #sLinux 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

agreements and is prohibited from improper disclosure, has been improperly used in Linux far beyond its original use in Dynix/ptx.

TABLE E
RCU MethodDynixV file(s)| Line #sLinux 2.6.0 file(s) Line #s
RCU useAfter 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

--net/bridge/br_forward.c (Tab 52)77-97, 120, 147, 151
--net/bridge/br_if.c (Tab 53 ) 64, 72, 160, 269-270, 273
--net/irda/irlan/irlan_common.c (Tab 54)230, 275, 1083, 1113
--net/irda/irlan/irlan_client.c (Tab 55)172, 182
--net/ipv6/icmp.c (Tab 56)532, 534, 537
--net/ipv6/af_inet6.c (Tab 57) 173-174, 208, 271, 275, 279, 614, 640
--net/ipv6/ip6_input.c (Tab 58)155, 169, 197, 201
--net/802/psnap.c (Tab 59)36, 58, 71, 136, 151
--net/decnet/dn_route.c (Tab 60)149, 156, 1171, 1173, 1184, 1189, 1450, 1452, 1463, 1468, 1644, 1646, 1653, 1658, 1678, 1632, 1691, 1694, 1697, 1723
--drivers/net/wireless/strip.c (Tab 61)973, 983, 998, 1006, 2562
--drivers/net/wan/lapbether.c (Tab 62)70, 98, 118, 379, 395, 411, 431
--drivers/net/hamradio/bpqether.c (Tab 63)183, 225, 408, 437, 545, 560, 575, 595
--drivers/char/ipmi/ipmi_kcs_intf.c (Tab 64)1203
--arch/i386/oprofile/nmi_timer_int.c (Tab 65)41
--include/linux/dcache.h (Tab 66)96, 180
--include/linux/list.h (Tab 67)83-124, 152-167, 367-414, 462-477, 487, 499-508
--include/net/dst.h (Tab 68)77
--fs/dcache.c (Tab 69)81, 986, 993
1015, 1038,
1146, 1232,
1235
--kernel/module.c (Tab 70)1738
--ipc/util.c (Tab 71)197, 282,
289, 349,
354, 459,
461, 475,
478, 488,
497
--init/main.c (Tab 72)414

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-componentDynixV file(s)Line #sLinux 2.6.0 file(s)Line #s
RCU read protectkernel/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-2059include/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 initializationkernel/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

385-468, 659-752, 1314-1494 (Tab 2). These have been improperly copied into Linux 2.6.0 at lines 82-207 (Tab 21). The RCU subcomponent known as "RCU initialization" is found in Dynix/ptx at lines 414 (Tab 1) and lines 1222-1311 (Tab 2). These have been improperly copied into Linux 2.6.0 at lines 127 (Tab 20) and 201-240 (Tab 21).

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

(Emphasis added).

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

14

./kernel/os/vm_mem.cRevision 1.216, Revision 1.215, Revision 1.211, Revision 1.210,
Revision 1.209, Revision 1.206, Revision 1.196, Revision 1.195,
Revision 1.194, Revision 1.192
./kernel/os/vm_page.cRevision 1.126, Revision 1.125
./kernel/os/vm_page.cRevision 1.122
./kernel/os/vm_pageout.cRevision 1.100, Revision 1.97
./kernel/os/vm_proc.cRevision 1.118, Revision 1.117
./kernel/os/vm_sw.cRevision 1.140
./kernel/os/vm_subr.cRevision 1.88, Revision 1.86
./kernel/os/vm_swap.cRevision 1.151
./kernel/os/mmap_mfile.cRevision 1.148, Revision 1.147, Revision 1.145, Revision 1.142
./kernel/os/mmap_ifreg.cRevision 1.146, Revision 1.144, Revision 1.143, Revision 1.142,
Revision 1.140, Revision 1.138, Revision 1.136
./kernel/os/audit_subr.cReviewers: dmo, badari
./kernel/os/mmap_anon.cRevision 1.121, Revision 1.119, Revision 1.114, Revision 1.106
./kernel/os/vm_asops.cRevision 1.210, Revision 1.203, Revision 1.196
./kernel/os/vfs_dio.cRevision 1.86, Revision 1.85
./kernel/os/kern_perf.cRevision 1.63
./kernel/os/kern_daemon.cRevision 1.43
./kernel/os/kern_lwp.cRevision 1.95, Revision 1.92, Revision 1.88, Revision 1.85
./kernel/os/kern_lwpdir.cPR #254650, SCN sarahw163, reviewer : badari
./kernel/os/lwrwsema.cRevision 1.17
./kernel/os/region.cRevision 1.48, Revision 1.47, Revision 1.44, Revision 1.41, Revision
1.39
./kernel/os/region_mem.cRevision 1.57, Revision 1.56, Revision 1.53, Revision 1.51, Revision
1.49, Revision 1.48, Revision 1.45, Revision 1.44, Revision 1.42,
Revision 1.37, Revision 1.35, Revision 1.34, Revision 1.32
./kernel/os/region/misc.cRevision 1.19, Revision 1.18
./kernel/sys/region.hRevision 1.65, Revision 1.64, Revision 1.60, Revision 1.58, Revision
1.57
./kernel/sys/swap.hRevision 1.35
./kernel/sys/region_kstats.hRevision 1.8
./kernel/sys/mman.hRevision 1.111, Revision 1.108
./kernel/sys/aumacros.hPR 238431; SCN gerrit716; Reviewers : dmo, badari
./kernel/sys/ucontext.hPR 254872, SCN sarahw186, Reviewer badari
./kernel/sys/buf.hRevision 1.61
./kernel/sys/vm_extern.hRevision 1.121, Revision 1.120, Revision 1.117
./kernel/sys/cmap.hRevision 1.61, Revision 1.60, Revision 1.58, Revision 1.56, Revision
1.55
./kernel/sys/autetypes.hPR 251279; SCN timw369; Reviewer: badari
./kernel/sys/region_misc.hRevision 1.7
./kernel/sys/proc.hRevision 1.214

15

./kernel/sys/region_mem.hRevision 1.27, Revision 1.21, Revision 1.20, Revision 1.18
./kernel/vm/vmdki.cRevision 1.179
./kernel/vm/vm_ublock.cRevision 1.37
./kernel/sci/sci_archdep.creviewer - badari
./kernel/proc/migrate.cRevision 1.146, Revision 1.145, Rev ision 1.136
./kernel/scheduler/sched_core.cRevision 1.265
./kernel/scheduler/sched_loadbal.cRevision 1.3
./kernel/scheduler/sched_runq.cRevision 1.5
./shm/shm.cRevision 1.123
./ufs/ufs_inode.cRevision 1.117
./ufs/ufs_vnodeops.cPR #254506, SCN sarahw189, reviewer : badari

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

IBM. In summary, key components of UNIX high-performance systems appear (based on Badari's own comments) to have been contributed to Linux by a programmer who had worked on the same subsystem of Dynix/ptx 2 years earlier.

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 FileLine #sLinux 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-133include/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-166include/linux/jfs/ref/jfs_inode.h (Tab 76)414-421
usr/include/jfs/inode.h (Tab 74)172-180include/linux/jfs/ref/jfs_inode.h (Tab 76)37-48
usr/include/jfs/inode.h (Tab 74)199-205include/linux/jfs/ret/jfs_inode.h (Tab 76)52-59
usr/include/jfs/inode.h (Tab 74)62-66include/linux/jfs/ret/jfs_inode.h (Tab 76)286-290
usr/include/jfs/inode.h (Tab 74)72-76include/linux/jfs/ref/jfs_inode.h (Tab 76)295-302
usr/include/jfs/inode.h (Tab 74)83-158include/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
FilesLines
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

enterprise Linux. In addition, IBM's drop of JFS into Linux reference files contains references to the UNIX-based header files, not otherwise found in Linux prior to IBM's identified transfers, further indicating that the source of this technology was AIX.

These reference files are listed in Table I below.

TABLE I
AIX JFS Reference File in LinuxHeader 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 FileLine #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 #sAIX MERCED/9922A_43NIALine #s
include/linux/evms/evms_aix.h
(Tab 112)
157-263kernel/sys/IA64/bootrecord.h (Tab
113)
64-170
include/linux/evms/evms_aix.h
(Tab 112)
311-327usr/include/liblvm.h (Tab 114)234-250
include/linux/evms/evms_aix.h
(Tab 112)
329-349usr/include/liblvm.h (Tab 114)252-272,
289-307
include/linux/evms/evms_aix.h
(Tab 112)
352-400usr/include/liblvm.h (Tab 114)316-363
include/linux/evms/evms_aix.h
(Tab 112)
266-294usr/include/lvmrec.h (Tab 115)24-92
include/linux/evms/evms_aix.h
(Tab 112)
6-11usr/include/lvm.h (Tab 116)26-35
include/linux/evms/evms_aix.h
(Tab 112)
26kernel/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

public statements to categorize them usefully in the answers to these interrogatories. However, one particular performance study published by IBM in January 2003 (the "IBM Linux Enhancement Study") is illustrative of the large category of such public statements made by IBM. This performance study is attached as Tab 119, and is otherwise found at http: //www-106.ibm.com/developerworks/ linux/library/l-kperf/". The IBM Linux Enhancement Study contains the following statement by IBM:
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 componentDatabase queryVolanoMarkSPECweb99 Apache2 NetBenchNetperfLMBenchTioBench 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

Figure 1. Database query benchmark results

[chart]

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

wanted to view source code of AIX or Dynix/ptx, which included the files and lines of code identified above, to obtain a source code viewing license from AT&T and its successors, including SCO. SCO has not granted access to any person with respect to the Protected Materials identified above in response to interrogatory No. 1.

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 - German Authors
[redacted]

IBM - Australian Authors
[redacted]

IBM - Other
[redacted]

34

IBM - Austin office (JFS)
[redacted]

IBM - Corporation Copyrights (May be some repetition from above)

[redacted]

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

[redacted]

36

[redacted]

IBM Primary Technical Contacts in Project Monterey:
[redacted]

37

[redacted]

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

portion of such code or method in any product, such as AIX, in Linux, in open source, or in the public domain.

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

proprietary information including but not limited to the owners, licensors, licensees, assigners or assignees of those copyrights or patents.

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

1176110-1176111, 1177823-1177825, 1178164-1178197, 1178198-1178221, 1180107-1180108, 1180969-1180991, 1180994-1180999, 1184087-1184092, 1184093-1184105, 1184174-1184230, 1290038-1290040, 1184245-1184247, 1184287-1184296, 1187297-1187318, 1184319-1184345, 1184369-1184388, 1184389-1184395, 1184401-1184434, 1184515-1184525, 1184548-1184551, 1290047-1290049, 1184557-1184636, 1184637, 1184645, 1184648-1184653, 1290060-1290063, 1228015-1228048, 1228222-1228230, 1228250-1228256, 1228269-1228275, 1228322-1228374, 1228636, 1232498-1232521, 1232540-1232546, 1233450-1233455, 1233772-1233776, 1233779-1233789, 1233790-1233800, 1233804-1233823, 1233824-1233859, 1233860-1233872, 1233873-1233923, 1233928-1233946, 1234034-1234036, 1234037-1234038, 1234059-1234060, 1234062-1234063, 1234070, 1234077-1234078, 1234102-1234106, 1234117-1234120, 1234121-1234127, 1234260-1234264, 1234274-1234280, 1234804-1234826, 1234827-1234830, 1290677-1290681, 1235154-1235156, 1235160-1235161, 1235162-1235164, 1290709-1230749, 1238361-1238434, 1238456-1238492, 1238486-1238492, 1241409-1241411, 1241431-1241437, 1241438-1241443, 1241448-1241452, 1290778-1290804, 1290815-1290821, 1290822-1290829, 1290844-1290846, 1290861-1290878, 1290921-1290922, 1290923-1290924, 1290959-1290968, 1290983-1290985, 1290986-1290998, 1291025-1291039, 1291052-1291054, 1291056-1291060, 1291084-1291095, 1291096-1291102, 1291103-1291105, 1291106-1291109, 1291114-1291117, 1291118-1291119, 1291123, 1291124, 1291132-1291134, 1291157-1291158, 1276975-1277027, 1288112-1288150, 1233947-1233955, 1036311-1036320, 0978343-0978346, 0992712, 0992791-0992792, 0992824-0992827, 0995517-0995519, 0995600-0995605, 0983624-0983625, 0983644, 0983671-0983672, 0984244-0984272, 0985007-0985016, 0999577-0999586, 0985070-0985072, 1019097, 1019111, 1001269-1001272, 0986906, 0986930-0986932, 0985595, 0990276, 0990390-0990391, 1000706-

41

1000712, 0988180, 1031451-1031461, 1027607-1027610, 1027617-1027618, 1013237-1013245, 1024465, 1110924-1110934, 1110935-1111000, 1029445-1029456, 1030444-1030453, 1022138-1022142, 1127697-1127708, 1112467-1112477, 1122936-1122942, 1175259-1175265, 1175266-1175272, 1175278-1175279, 1175413-1175417, 1132248-1132257, 1142031-1142034, 1168854-1168855, 1168877-1168916, 1168918-1168957, 1168958-1168979, 1168985-1168989, 1168990-1168995, 1168837-1168853, 1168856-1168859, 1168861-1168869, 1168870-1168876, 1127709-1127711, 1161166-1161172, 1162391-1162399, 1233547-1233548, 1233568-1233577, 1234336-1234342, 1234345-1234360, 1234381-1234382, 1234390-1234397, 1296254-1296257, 1290769-1290772, 1289351-1289355, 1289301-1289309. As to subpart (b), there are two types of copyrights relating to the trade secret or confidential or proprietary information. The first group of copyrights relating to this information are SCO's copyrights, which are found at Bates numbers SCO 1292920 through SCO 1292941. The second group of copyrights relating to this information would be the copyrights, if any, of IBM (and Sequent). To the extent any such copyrights exist, SCO does not have possession of any such documents and cannot further respond to this question.

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

SCO, unfairly gained access to SCO's business relationships, and unfairly and knowingly diverted SCO's resources away from competition with IBM and toward the purposes of the partnership.

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

personnel at IBM who advocated IBM's adoption of Linux. SCO's executives involved in these events included Doug Michaels, Jim Wilt, Jeff Seabrook, and Jay Petersen.

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

IBM finally successfully induced AutoZone to cease using the SCO software and to use Linux with IBM's version of UNIX. AutoZone ultimately decided not to pay SCO the annual fee to continue to maintain the SCO products and, upon information and belief, with the encouragement of IBM, began the efforts required for conversion to Linux.

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

incorporating the SCO OpenServer shared libraries, it was interfering with SCO's agreement with AutoZone and otherwise inducing AutoZone to act wrongfully towards SCO. Upon information and belief, IBM's inducing and assisting AutoZone to breach its license agreement with SCO was an act that constitutes interference with contract. Upon information and belief, IBM profited by the interference by earning significant professional services fees in performing the switch from SCO OpenServer to Linux.

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

Agreement in that Sherwin Williams is improperly using the "shared libraries" (short cuts and methods which allow programs to interface with one another and the services of the operating system) contained in the Linux based OpenServer 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 Sherwin Williams were designed specifically to operate with OpenServer (UNIX based) shared libraries, but do not function with Linux shared libraries.

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

constitutes interference with SCO's contract with Sherwin Williams by IBM. Upon information and belief, IBM profited from the interference by earning significant professional services fees in performing the switch from SCO OpenServer to Linux.

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

with each of Intel, Computer Associates, and Oracle occurred during or shortly after the LinuxWorld 2003 conference. As a result of IBM's improper contact and improper attempts to destroy plaintiff's existing and prospective business relationships with Hewlett Packard, Oracle, Intel, and Computer Associates, each of those stated companies has slowed or ceased business activities with SCO.

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

computer can access this information, including in countries that the federal government prohibits dissemination of such information. IBM breached Section 6.03 by continuing to use the Software Products after the license was terminated on June 13, 2003, as well as failing to return or destroy all Software Products after that date. IBM also breached Section 7.06 by failing to maintain in confidence the Software Products, as that term is defined in the agreements. IBM also breached a subsequent agreement that IBM would not use System V or AIX in any open source operating system. IBM also breached §2.1 of Amendment X by using the Software Products for its contractors, including OSDL and other Linux development laboratories and Linux developers for other than Authorized Purposes. IBM also breached §6 of Amendment X by using the Software Product for an unauthorized use and distribution of Linux without paying the required additional royalty amounts. The breaches by IBM occurred during its various contributions to Linux and use of UNIX (including AIX and Dynix/ptx) software for external purposes and for the benefit of third parties in violation of the specific licensing restrictions set forth in the Software Agreement and Related Agreements. The dates of such breaches, as currently known to SCO, are set forth with specificity in response to Interrogatories Nos. 1-6 above, including the corresponding exhibits, and are expressly incorporated herein. Each and every use by IBM of UNIX-based software, including IBM's modifications and derivatives known as AIX and Dynix/ptx, and disclosure of that software to its development partners for use in Linux is a violation of IBM's contractual obligations to SCO under the Software Agreement, the Side Letter, and Amendment X.

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.

http://www.oss.sgi.com/projects/xfs/ faq.html#whatisxfs

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

linux-2.5.64/fs/xfs/linux/xfs_behavior.c
linux-2.5.64/fs/xfs/linux/xfs_vnode.h
linux-2.5.64/fs/xfs/linux/xfs_sysctl.c
linux-2.5.64/fs/xfs/xfs_attr_leaf.h
linux-2.5.64/fs/xfs/xfs_dir2_node.c
linux-2.5.64/fs/xfs/xfs_mount.h
linux-2.5.64/fs/xfs/support/mutex.h
linux-2.5.64/fs/xfs/support/atomic.h
linux-2.5.64/fs/xfs/support/mrlock.c
linux-2.5.64/fs/xfs/support/debug.c
linux-2.5.64/fs/xfs/support/sv.h
linux-2.5.64/fs/xfs/support/ktrace.c
linux-2.5.64/fs/xfs/support/move.h
linux-2.5.64/fs/xfs/support/kmem.c
linux-2.5.64/fs/xfs/support/ktrace.h
linux-2.5.64/fs/xfs/support/move.c
linux-2.5.64/fs/xfs/support/spin.h
linux-2.5.64/fs/xfs/support/mrlock.h
linux-2.5.64/fs/xfs/support/qsort.h
linux-2.5.64/fs/xfs/support/uuid.c
linux-2.5.64/fs/xfs/support/uuid.h
linux-2.5.64/fs/xfs/support/time.h
linux-2.5.64/fs/xfs/support/sema.h
linux-2.5.64/fs/xfs/support/debug.h
linux-2.5.64/fs/xfs/support/kmem.h
linux-2.5.64/fs/xfs/xfs_trans_inode.c
linux-2.5.64/fs/xfs/xfs_dir2_data.h
linux-2.5.64/fs/xfs/xfs_buf_item.c
linux-2.5.64/fs/xfs/xfs_inum.h
linux-2.5.64/fs/xfs/pagebuf/page_buf.c
linux-2.5.64/fs/xfs/pagebuf/page_buf_internal.h
linux-2.5.64/fs/xfs/pagebuf/page_buf_locking.c
linux-2.5.64/fs/xfs/pagebuf/page_buf_trace.h
linux-2.5.64/fs/xfs/pagebuf/page_buf.h
linux-2.5.64/fs/xfs/xfs_qm.c
linux-2.5.64/fs/xfs/xfs_dir2_block.c
linux-2.5.64/fs/xfs/xfs_dir2_leaf.h
linux-2.5.64/fs/xfs/xfs_trans_buf.c
linux-2.5.64/fs/xfs/xfs_itable.c
linux-2.5.64/fs/xfs/xfs_imap.h
linux-2.5.64/fs/xfs/xfs_dfrag.c
linux-2.5.64/fs/xfs/xfs_rw.h
linux-2.5.64/fs/xfs/xfs_log_priv.h

63

linux-2.5.64/fs/xfs/xfs_trans_item.c
linux-2.5.64/fs/xfs/xfs_macros.h
linux-2.5.64/fs/xfs/xfs_dquot_item.c
linux-2.5.64/fs/xfs/xfs_rtalloc.c
linux-2.5.64/fs/xfs/xfs_dir2_sf.h
linux-2.5.64/fs/xfs/xfs_trans_dquot.c
linux-2.5.64/fs/xfs/xfs_btree.h
linux-2.5.64/fs/xfs/xfs_ialloc.h
linux-2.5.64/fs/xfs/xfs_vfsops.c
linux-2.5.64/fs/xfs/xfs_attr.h
linux-2.5.64/fs/xfs/xfs.h
linux-2.5.64/fs/xfs/xfs_dir.c
linux-2.5.64/fs/xfs/xfs_fs.h
linux-2.5.64/fs/xfs/xfs_types.h
linux-2.5.64/fs/xfs/xfs_bmap.h
linux-2.5.64/fs/xfs/xfs_alloc.c
linux-2.5.64/fs/xfs/xfs_dir.h
linux-2.5.64/fs/xfs/xfs_log_recover.h
linux-2.5.64/fs/xfs/xfs_ialloc_btree.h
linux-2.5.64/fs/xfs/xfs_qm.h
linux-2.5.64/fs/xfs/xfs_dir_leaf.h
linux-2.5.64/fs/xfs/xfs_attr_sf.h
linux-2.5.64/fs/xfs/xfs_macros.c
linux-2.5.64/fs/xfs/xfs_fsops.h
linux-2.5.64/fs/xfs/xfs_ialloc_btree.c
linux-2.5.64/fs/xfs/xfs_mount.c
linux-2.5.64/fs/xfs/xfs_dir2_trace.h
linux-2.5.64/fs/xfs/xfs_alloc.h
linux-2.5.64/fs/xfs/xfs_acl.c
linux-2.5.64/fs/xfs/xfs_sb.h
linux-2.5.64/fs/xfs/xfs_acl.h
linux-2.5.64/fs/xfs/xfs_cap.c
linux-2.5.64/fs/xfs/xfs_trans_space.h
linux-2.5.64/fs/xfs/xfs_da_btree.h
linux-2.5.64/fs/xfs/xfs_dquot.c
linux-2.5.64/fs/xfs/xfs_trans.c
linux-2.5.64/fs/xfs/xfs_dir2_leaf.c
linux-2.5.64/fs/xfs/xfs_attr_leaf.c
linux-2.5.64/fs/xfs/xfs_trans_extfree.c
linux-2.5.64/fs/xfs/xfs_rename.c
linux-2.5.64/fs/xfs/xfs_extfree_item.h
linux-2.5.64/fs/xfs/xfs_bmap_btree.h
linux-2.5.64/fs/xfs/xfs_bmap_btree.c

64

linux-2.5.64/fs/xfs/xfs_1og_recover.c
linux-2.5.64/fs/xfs/xfs_mac.c
linux-2.5.64/fs/xfs/xfs_dfrag.h
linux-2.5.64/fs/xfs/xfs_alloc_btree.c
linux-2.5.64/fs/xfs/xfs_bit.c
linux-2.5.64/fs/xfs/xfs_ialloc.c
linux-2.5.64/fs/xfs/xfs_attr.c
linux-2.5.64/fs/xfs/xfs_cap.h
linux-2.5.64/fs/xfs/xfs_dir2_sf.c
linux-2.5.64/fs/xfs/xfs_dinode.h
linux-2.5.64/fs/xfs/xfs_qm_syscalls.c
linux-2.5.64/fs/xfs/xfs_dquot_item.h
linux-2.5.64/fs/xfs/xfs_clnt.h
linux-2.5.64/fs/xfs/xfs_dir_sf.h
linux-2.5.64/fs/xfs/xfs_attr_fetch.c
linux-2.5.64/fs/xfs/xfs_inode_item.c
linux-2.5.64/fs/xfs/xfs_rtalloc.h
linux-2.5.64/fs/xfs/Makefile
linux-2.5.64/fs/xfs/xfs_ag.h
linux-2.5.64/fs/xfs/xfs_error.h
linux-2.5.64/fs/xfs/xfs_buf_item.h
linux-2.5.64/fs/xfs/xfs_inode.h
linux-2.5.64/fs/xfs/xfs_trans.h
linux-2.5.64/fs/xfs/xfs_btree.c
linux-2.5.64/fs/xfs/xfs_iocore.c
linux-2.5.64/fs/xfs/xfs_dir2.h
linux-2.5.64/fs/xfs/xfs_da_btree.c
linux-2.5.64/fs/xfs/xfsidbg.c
linux-2.5.64/fs/xfs/xfs_extfree_item.c
linux-2.5.64/fs/xfs/xfs_dir2_trace.c
linux-2.5.64/fs/xfs/xfs_dqblk.h
linux-2.5.64/fs/xfs/xfs_arch.h
linux-2.5.64/fs/xfs/xfs_dir2_data.c
linux-2.5.64/fs/xfs/xfs_fsops.c
linux-2.5.64/fs/xfs/xfs_dir_leaf.c
linux-2.5.64/fs/xfs/xfs_inode_item.h
linux-2.5.64/fs/xfs/xfs_trans_priv.h
linux-2.5.64/fs/xfs/xfs_bit.h
linux-2.5.64/fs/xfs/xfs_bmap.c
linux-2.5.64/fs/xfs/xfs_error.c
linux-2.5.64/fs/xfs/xfs_alloc_btree.h
linux-2.5.64/fs/xfs/xfs_itable.h
linux-2.5.64/fs/xfs/xfs_dmapi.h

65

linux-2.5.64/fs/xfs/xfs_dir2_node.h
linux-2.5.64/fs/xfs/xfs_buf.h
linux-2.5.64/fs/xfs/xfs_inode.c
linux-2.5.64/fs/xfs/xfs_iget.c
linux-2.5.64/fs/xfs/xfs_dir2_block.h
linux-2.5.64/fs/xfs/xfs_rw.c
linux-2.5.64/fs/xfs/xfs_quota.h
linux-2.5.64/fs/xfs/xfs_trans_ail.c
linux-2.5.64/fs/xfs/xfs_dquot.h
linux-2.5.64/fs/xfs/xfs_utils.h
linux-2.5.64/fs/xfs/xfs_quota_priv.h
linux-2.5.64/fs/xfs/xfs_utils.c
linux-2.5.64/fs/xfs/xfs_log.c
linux-2.5.64/fs/xfs/xfs_vnodeops.c
linux-2.5.64/fs/xfs/xfs_mac.h
linux-2.5.64/fs/xfs/xfs_dir2.c
linux-2.5.64/fs/xfs/xfs_log.h
linux-2.5.64/include/linux/dqblk_xfs.h

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

Federal Express, Computer Associates, Intel, American Express, Merrill Lynch, Bear Stearns, CitiGroup, Wells Fargo, Raytheon, Honeywell, Bell South, SBC, GM, AT&T, Eli Lily, Baxter, Ford, McKesson, Merck, Union Pacific, CSX, Bristol Meyers, Exxon, Chevron, Amgen, Affiliated Computer Services, Becton Dickinson, Pfizer, Delphi, Computer Sciences, Unisys, Pitney Bowes, UPS, Sun and Texas Instruments (collectively, the "UNIX Source Code Licensees"). To the extent any of these the UNIX Source Cede Licensees have used access to UNIX-based source code or documentation to improve or enhance Linux, or to otherwise adapt UNIX to certain Linux functionality, such conduct would be a violation of SCO's contractual rights. Certain of the UNIX Source Code Licensees are presently affiliated with IBM in creation of enterprise versions of Linux in furtherance of the IBM-sponsored Data Center Linux Project, Carrier Grade Linux Project and the Linux Center of Competency for financial Linux. Those companies, some of which are listed above, include Oracle, Fujitsu, Computer Associates, Toshiba, Hitachi, NEC, Intel, Cisco, Motorola, Fujitsu, Toshiba, Alcatel, Mitsubishi, Dell, HP, Morgan Stanley and Merrill Lynch. SCO is in the process of evaluating all contributions by all UNIX Source Code Licensees, particularly work by UNIX Source Code Licensees in developing Data Center Linux, Carrier Grade Linux and Financial Linux (Linux Center of Competence) to determine the extent to which such violations, if any, have occurred.

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

or otherwise made available, when it was distributed or made available, to whom it was distributed or made available, and the terms under which it was distributed or made availalable (such as under the GPL or any other license).

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

it was distributed and to whom can be found in the invoices in Bates range 1186853 to 1227921. For the narrowing of the appropriate invoices they have been attached as Tab 121.
Respectfully submitted,
DATED this 15th day of January, 2004.
HATCH, JAMES & DODGE, P.C.
Brent O. Hatch
Mark F. James

BOIES, SCHILLER & FLEXNER LLP
[address, phone, fax]
Stephen N. Zack
Mark J. Heise
David K. Markarian
(admitted pro hac vice)

____[signature]____
Counsel for Plaintiff/Counterclaim Defendant

  


IBM's Greatest Hits - Ex. 33, SCO's Revised Supplemental Response to 1st and 2nd Set of Interrogatories - Updated | 56 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections here!
Authored by: Juggler9 on Wednesday, January 03 2007 @ 11:12 PM EST
So PJ can find them!

[ Reply to This | # ]

Off Topic
Authored by: Kilz on Wednesday, January 03 2007 @ 11:25 PM EST
For all those off topic subjects we all love.

[ Reply to This | # ]

Correct me if I'm wrong...
Authored by: brian on Wednesday, January 03 2007 @ 11:42 PM EST
This is the stuff they claim IBM was supposed to "keep
confidential for SCO" (translation; Trade Secrets that SCO
dropped but keeps trying to pull back in with "Methods &
Concepts"). I don't see any indication of any direct
copyright infringement in any of this. Am I missing
something? This stuff should be a dead fish by now.

B.

---
#ifndef IANAL
#define IANAL
#endif

[ Reply to This | # ]

We were right
Authored by: arch_dude on Thursday, January 04 2007 @ 12:03 AM EST
This appears to be the most explicit set of SCOG's allegations that we have seen
in the course of this entire excersize.

All of the explicit references are about RCU, JFS, and "methods and
concepts."

None of it makes any sense, of course.

My guess is that a groklawer with enough free time could match the file
references in this document against the references in list of 297
"final" "complaints."

Again, the plaintif trys very hard to conflate SCO (Santa cruz Operation) with
the plaintif SCO (the SCO Group.)

[ Reply to This | # ]

SCO's Revised Fishing Trip
Authored by: kawabago on Thursday, January 04 2007 @ 12:15 AM EST
Have you ever seen anyone try so hard to find someone else to blame for their
own failings?

[ Reply to This | # ]

Silly Question
Authored by: Anonymous on Thursday, January 04 2007 @ 12:48 AM EST
But, if TSCOG can be so specific here, why the blazes couldn't they put the
goods on the table when they were asked for?

Yeah, I know, silly question.

Tufty

[ Reply to This | # ]

It's a freaking LICENSING AGREEMENT
Authored by: darkonc on Thursday, January 04 2007 @ 12:56 AM EST
It's not like AZ had contracted with SCO for 20 years of support and then suddenly decided not to ... They had a license in which SCO graciously allowed them to use Unix for their work -- provided that they kept paying, year after year... and AZ finally decided to stop paying for 'protection'.

I think that this would be considered an 'at pleasure' engagement. SCO stopped pleasing AZ, so AZ stopped paying for licenses.

Now, the thing about getting them to use library hacks, ... that could have been something real -- presuming that AZ used more machines than they had licensed for, but making that sort of accusation totally without even a shred of proof, is the sort of thing that I really hope that IBM can recover (at least an award of) payment for frivolous and vexatious prosecution.

Actually getting paid, however, might be an entirely other fight ....

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

[ Reply to This | # ]

Code identification method: grep rcu
Authored by: whoever57 on Thursday, January 04 2007 @ 01:22 AM EST
Check how the line number match exactly with SCO's claimed lines "copied
from Dynix into Linux"


linux-2.6.0 # grep -n rcu !$
grep -n rcu net/core/netfilter.c
73: list_add_rcu(&reg->list, i->prev);
83: list_del_rcu(&reg->list);
357: list_for_each_continue_rcu(*i, head) {
517: rcu_read_lock();
548: rcu_read_unlock();
558: rcu_read_lock();
575: list_for_each_rcu(i, &nf_hooks[info->pf][info->hook]) {
612: rcu_read_unlock();



linux-2.6.0 # grep -n rcu net/core/dev.c
239: list_add_rcu(&pt->list, &ptype_all);
242: list_add_rcu(&pt->list, &ptype_base[hash]);
283: list_del_rcu(&pt->list);
995: rcu_read_lock();
996: list_for_each_entry_rcu(ptype, &ptype_all, list) {
1027: rcu_read_unlock();
1580: rcu_read_lock();
1581: list_for_each_entry_rcu(ptype, &ptype_all, list) {
1594: list_for_each_entry_rcu(ptype, &ptype_base[ntohs(type)&15],
list) {
1614: rcu_read_unlock();

[ Reply to This | # ]

TSCOG Appears to not understand big company methods.
Authored by: Anonymous on Thursday, January 04 2007 @ 05:06 AM EST
Having worked for various hi-tech companies over the last 30 years, I've frequently been involved in co-developments with IBM divisions, and the common theme every time was that you get to work with a division of IBM, not the whole company.

IBM has a future, and intends to make sure it continues to have a future, which of course means it follows all avenues that it thinks may be important. So while one division is working on Monterey, another is happily working with Intel in Linux futures. This isn't a "secret project" - it is simply a different division, and from my experience, it is common for the IBM divisions to have little knowledge of what other divisions are doing, and little influence on them as well.

The absurdity of the async I/O claims in this document are simply laughable. Async I/O as a technology is ancient - the fact that it got added to UNIX late on (comparatively) doesn't means it belongs to UNIX, or AIX or DYNIX. Anyone with an O/S background must know this, so were these claims written solely by lawyers?

[ Reply to This | # ]

Its hard to differentiate nonsense from meaningless
Authored by: Ian Al on Thursday, January 04 2007 @ 05:46 AM EST
IBM finally successfully induced AutoZone to cease using the SCO software and to use Linux with IBM's version of UNIX.
Putting aside whether the dead Monterey agreement between Santa Cruz and IBM prohibited the sale of other operating systems (It didn't. SCOG have no standing. Dale said 'for heaven's sake be quiet: we are not discussing Monterey) this sentence has no meaning. How does anyone use 'Linux with IBM's version of UNIX'?

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.
This is full of meaning, but is nonsense. Are they really suggesting that IBM and Sequent were not permitted to sell AIX and Dynix/ptx on the servers they sold and for use by others?

I see some of my old favourites, here.

'IBM agreed that they copied copyright UNIX code into Linux. ' IBM also agreed that it was IBM's copyright and it was materials found in IBM's AIX or Dynix/ptx, but not in Santa Cruz's UNIX.

'On information and belief they used UNIXWare libraries to migrate to Linux. How else could the migration have been so successful? $5B, please.'

Finally, SCOG list all the Copyright registrations that were in the Santa Cruz transfer of asset shedule that the dog ate, but forgot to mention which of them were violated by IBM and in which circumstances. Well, there is a lot of stuff, here. They can't be expected to include all of the detail. Or, can they?...

---
Regards
Ian Al

[ Reply to This | # ]

Reverse Abstraction Filtration Comparison
Authored by: rsteinmetz70112 on Thursday, January 04 2007 @ 10:21 AM EST
IBM seems here to have preformed a reverse abstraction-filtration-comparison
process. They have extracted all of the new or modified elements they have full
authorship of and removed any material by other authors and only then
contributed that code to Linux.

SCO is still depending on their viral contract theory, I hope Judge Kimball
rules directly on that point, much of SCO's case will evaporate. That will
likely cause the other pieces of the case to melt away in a second round of
motions.

---
Rsteinmetz - IANAL therefore my opinions are illegal.

"I could be wrong now, but I don't think so."
Randy Newman - The Title Theme from Monk

[ Reply to This | # ]

SCO -vs- Auto Zone is hilarious!
Authored by: Anonymous on Thursday, January 04 2007 @ 12:42 PM EST
Is that what it boils down to.

AutoZone stopped paying support, and continued to use the SCO software for a
short time until they were fully converted.

SCO sues AutoZone for breach of contract? Uh, guys they dropped the
contract!!

Where does it prevent them from continuing to use the software they purchased??
The contract is for *support*, not for using the software!!!

Methinks someone is drinking old fashioned CocaCola, with the Coca left in :)

[ Reply to This | # ]

Ok, TSG and BSF, repeat with me...
Authored by: Anonymous on Thursday, January 04 2007 @ 04:13 PM EST
Correlation does NOT imply causation.
Correlation does NOT imply causation.
Correlation does NOT imply causation.

...just because little bits of code are the same doesn't mean that Sequent
didn't copy from Linux nor that both didn't copy from somewhere else!

That's why IBM asked that last little question that you thought was too
burdomsome!!!

[ Reply to This | # ]

Why Did AutoZone Switch From OpenServer to Linux?
Authored by: sk43 on Thursday, January 04 2007 @ 07:19 PM EST
From the answer to Interrogatory 8, interference with contracts,
In the second quarter of 2001, IBM was actively advising AutoZone's internal software group about converting to Linux. In the second quarter of 2001, despite the AutoZone Openserver License Agreement with SCO ...IBM finally successfully induced AutoZone to cease using the SCO software and to use Linux ...

We can be sure that AZ's conversion surely had nothing to do with this article from Mar 11, 1998:

New OpenServer 5.x.x releases this year presage the code going into maintenance mode thereafter as the company picks up as much OpenServer-to-UnixWare 7.0 converts as it can with a bunch of migration tools plus second-half 1998 UnixWare 7.0 releases specifically designed for small-to-medium sized business and replicated sites.

Or this article from Aug, 2001 quoting Ransom Love :

The operating system is in maintenance mode now ...

or this Jan 9, 2002 article :

SCO's OpenServer has been in maintenance mode for some years ...

or surely SCO would have mentioned it in their interrogatory reply. Right?

[ Reply to This | # ]

Intel et al
Authored by: The Mad Hatter r on Thursday, January 04 2007 @ 10:35 PM EST


I think PJ is right - BSF messed up on purpose so they wouldn't have to worry
about what Intel would say in the court room.

Look at the replies - they've accused a lot of people of working with IBM to
torpedo TSCOG. And have no proof to back it up.

Pardon me - but this sounds like an interesting and protracted method of
corporate suicide.


---
Wayne

http://urbanterrorist.blogspot.com/

[ Reply to This | # ]

Making secret plans with Intel during 1999
Authored by: Anonymous on Friday, January 05 2007 @ 09:23 AM EST
This must be the most absurd claim possible. There can't be any excuse for a
statement like this before a court as a swearing of "information and
belief" by an honest lawyer even if the client is being dishonest. The lack
of any diligence at all would be inexcusable.

There was certainly no secret about IBM's joining with the then ongoing effort
to port Linux and the GNU environment and toolchain to the IA-64 architecture;
it was clearly and explicitly announced publicly in August of 1999:

http://news.com.com/2100-1001-229622.html

"IBM has joined the effort to make sure that Linux will be ready to run
Intel's next-generation microprocessor.

The computing giant has signed onto the Trillian initiative to "port"
Linux to Intel's first 64-bit chip, code-named Merced, joining Intel, VA Linux
Systems, SGI, Hewlett-Packard, and Cygnus Solutions, according to sources. The
move indicates IBM's increasing seriousness toward the upstart operating
system.

The first versions of Linux for IA-64 will be released to the open source
community in the first quarter of 2000, said Intel's Sean Maloney, senior vice
president for sales and marketing, in a keynote address here today at the
LinuxWorld conference. Intel will help the effort by making several Merced
prototype servers available over the Internet to the open source community at
large, instead of just the Trillian partners.

The four major commercial Linux sellers--Red Hat, Caldera, SuSE, and
Turbolinux--and VA each will get a prototype Merced machine, Maloney said.
"We'll make the systems available...so people can actually do development
across the Net," he said. "

Caldera /dba "the SCO Group" had no reason to be unaware of that fact
any more than they had reason to be unaware of every and all of the activities
they complain of in their quest for $Billions.

http://news.com.com/Linux-on-Itanium+effort+gets+more+backing/2100-1001_3-234199
.html

"Published: December 9, 1999, 3:30 PM PST

.......

Caldera Systems confirmed its participation in the Trillian project.

"We've already allocated resources. We're excited to be on this
project," said Caldera Systems' Benoy Tamang. "It's necessary in order
for us to maintain our own momentum and keep up with the new archtitecture. We
believe strongly that the Merced [the code name for Itanium] version of Linux
will be just critical."

Intel versions of Caldera Systems software account for more than 90 percent of
revenues, Tamang said. Intel declined to comment on the new partners."

Even pretending that Caldera is in actuality the Santa Cruz Operation doesn't
provide a reasonable basis of claim for relief that any court can grant, since
SCO had been fully aware of Intel and IBM's actions and made clear statement of
its lack of concern:

http://www.vnunet.com/vnunet/news/2107749/sco-forum-trillian-project-threat-mont
erey-claims-sco-president

"SCO Forum: Trillian Project no threat to Monterey, claims SCO president

by Cath Everett in Santa Cruz
, vnunet.com 19 Aug 1999

The Trillian Project to port Linux to Intel’s IA-64 architecture does not pose a
threat to the Santa Cruz Operation (SCO) or Project Monterey, according to Doug
Michels, SCO’s president and chief executive.

And the fact that IBM has signed up to the new Linux initiative and will deploy
both the Trillian and Monterey operating systems (OSs) on its hardware does not
show it is wavering in its commitment either, he claimed.

........

He added: “IBM is not looking at Trillian as an alternative to Monterey. The
real interest in Linux is coming from all the software companies that sell
databases and transaction based tools because they are frustrated that Microsoft
moreorless gives these things away as part of the Back Office bundle. So they
say ‘if you give us a free OS, we’ll make money from it’.”

But Trillian is not intended to make Linux an enterprise class OS and there are
no real efforts elsewhere to do so either, he claimed.

“Linux may be there sooner than 10 years, but I don’t see any efforts there yet.
Trillian is not that type of project and I don’t see them adding enterprise
class services or performance management capabilities. Noone is doing it. SGI
has made some noises and people are talking about it, but it’s not coming this
week, next year or before Merced ships,” he said."

Although it doesn't show a lot of savvy on the part of the Santa Cruz Operation
(whose product was and is OpenServer, a third-rate base UNIX flavor without
significant capabilities and no future for at least the previous five years
before that statement), that doesn't rise to the level of allowing another
incompetent group of losers (the current proprietorship of Caldera / Caldera
Systems Inc / Caldera International / the SCO Group) to recover $Billions from
the people of the United States (and its the public that will pay) by publicly
funded enforcement of the taxation of IBM by our federal courts on the basis of
inane nonsense.



[ Reply to This | # ]

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

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