decoration decoration
Stories

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

Groklaw Gear

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


Contact PJ

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


User Functions

Username:

Password:

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

No Legal Advice

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

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Exhibit 1 to IBM's Report on SCO's Compliance
Tuesday, February 17 2004 @ 03:40 PM EST

Here, at last, is Exhibit 1, attached to IBM's Report on Compliance, SCO's supplemental responses, or more precisely, PLAINTIFF'S REVISED SUPPLEMENTAL RESPONSE TO DEFENDANT'S FIRST AND SECOND SET OF INTERROGATORIES.

Remember, this is the submission that IBM gave to the judge, telling her at the hearing that while they were appreciative to have more information, they still didn't have complete responses.

I have removed email addresses. The original is available here.

I wish to thank all who helped to transcribe, particularly Rand McNatt and Thomas Frayne. We have proofread it but it is so detailed, you may note other OCR errors. If so, kindly email me so I can fix them.

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

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
New York corporation,

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.

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 [sic] 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 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 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 Files Linux 2.4.1-01 files
kernel/sys/rclock.h (Tab 1)
kernel/os/rclock.c (Tab 2)
include/linux/rclock.h (Tab 5)
kernel/rclock.c (Tab 6)
kemel/sys/kma_defer.h (Tab 3)
kernel/os/kma_defer.c (Tab 4)
include/linux/kmemdef.h (Tab 7)
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).

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




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

In Table B, Tab 10 correlates Dynix/ptx code at lines 2028-2059 directly with copies of the same Dynix/ptx code improperly copied into Linux, identified 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 lines 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, 718-721. Tab 13 correlates Dynix/ptx code at line 2054 improperly copied into Linux, identified in Tab 18 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 / Sequence DynixV file(s) Line #s Linux 2.6.0 file(s) Line #s
Register an RCU callback kernel/sys/rclock.h (Tab 1) 412 include/Iinux/rcupdate.h (Tab 20) 131-132
kernel/os/rclock.c (Tab 2) 503-613 kernel/rcupdate.c (Tab 21 ) 58-80
RCU Callback control structure kernel/sys/rclock.h (Tab 1) 217-228 include/linux/rcupdate.h (Tab 20) 66-72
RCU Callback lists kernel/sys/rclock.h (Tab 1) 238-241 include/linux/rcupdate.h (Tab 20) 87-108
kernel/i386/plocal.h (Tab 19) 1517-1537
RCU Comparison operators kernel/sys/rclock.h (Tab 1) 300-312 include/linux/rcupdate.h (Tab 20) 75-85

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

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


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

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 agreements and is prohibited from improper disclosure, has been improperly used in Linux far beyond its original use in Dynix/ptx.

TABLE E
RCU Method DynixV file(s) Line #s Linux 2.6.0 file(s) Line #s
RCU use After IBM's initial improper contribution of RCU specifically identified above, RCU became widespread In the Linux kernel.

These files use RCU functions and macros - and if they are used, then the RCU functionality is used, too. The number of lines and number of files, although substantial, is less significant than the impact of the changes, which is dramatic for networking, device drivers, lists, and directory access.
net/core/netfilter.c (Tab 41) 73,83,357,516-517, 548, 558, 575, 612
net/core/dev.c (Tab 42) 239, 242, 238, 995-996, 1027, 1580-1581, 1594,1614, 2893
net/ipv4/ip_input.c (Tab 43) 220, 241, 266
net/ipv4/af_inet.c (Tab 44) 340-341, 375, 430, 1012, 1040
net/ipv4/icmp.c (Tab 45) 707-712
net/ipv4/route.c (Tab 46) 227, 231, 240, 243, 246, 282, 440, 446, 1004, 1008, 1026, 1037, 1076, 1257, 1260, 1296, 1852, 1854, 1867, 1873, 2219, 2221, 2235, 2241, 2451, 2454, 2462, 2467
net/bridge/br_device.c (Tab 47 ) 79, 81
net/bridge/br_ioctl.c (Tab 48) 78, 97, 159, 161, 179
net/bridge/br_stp.c (Tab 49) 43
net/bridge/br_private.h (Tab 50) 77
net/bridge/br_input.c (Tab 51) 59, 61, 106, 117, 135, 142, 151,156
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_net6.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,1682, 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
kemel/module.c (Tab 70 ) 1738
ipc/util.c (Tab71) 197, 282, 289, 349, 354, 459, 461, 475, 478, 488, 497
init/main.c (Tab 72) 414
The next table, Table F, shows additional misuse by IBM of the RCU structures and sequences embodied in Dynix/ptx.








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

kernel/os/rclock.o (Tab 2) 1222-1311 kernel/rcupdate.c (Tab 21) 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 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.e:

/*
* fs/direct-io.c
*
* Copyright (C) 2002, Linus Torvalds.
*
* O_DIRECT
*
* 04Jul2002 akpm@zip.com.au
* Initial version
* HSep2002 janetinc@us.ibm.com
* added readv/writev support.
* 29Oct2002 akpm@zip.com.au
* rewrote bio_add_pageQ 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).

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/prx transfer of AIO technology to Linux, SCO needs to obtain the full production of source code from IBM. However, from examining v4.6.1 of Dynix/ptx, it is apparent that Badari Pulavarty was an experienced Dynix kernel programmer, based on the numerous revisions to Dynix with which he is credited, including the following:


Dynix v4.6.1 file Revisions credited to Badari
./io/tlbtest/tlbtest rc.c Revision 1.28
./io/tlbtest/tlbtest toutc Revision 1.18
./io/ff/ff fc.c Revision 1.111, Revision 1.110
./kernel/debug/dinfo ,c Revision 1.75
./kernel/i386/mc_vmmac.h Revision 1.53
./kernel/i386/plocal.h Revision 1.144, Revision 1.143
./kernel/i386/vm boot.c Revision 1.199
./kernel/i386/vmpt machdep.c Revision 1.180, Revision 1.101
./kernel/i386_space/param_space.c Revision 1.207
./kernel/os/heap kmem.c Revision 1.128
./kernel/os/init main.c Revision 1.216
./kernel/OS/kern fork.c Revision 1.253, Revision 1.250, Revision 1.245, Revision 1.238
./kernel/OS/kern exec.c Revision 1.200, Revision 1.198, Revision 1.197, Revision 1.196
./kernel/OS/kern sig.c PRs 254728, 254503, SCN sarahwl86, Reviewer: Badari
./kernel/os/mmap ifchr.c Revision 1.55
./kernel/os/kern_posix . c Revision 1.43
./kernel/os/sys_process.c Revision 1.267
./kernel/os/vm sched.c Revision 1.145, Revision 1 .143, Revision 1 .130, Revision 1.122
./kernel/os/vm sched.c Revision 1.121
./kcmel/os/sys_vm.c Revision 1.57
./kernel/os/vfs bio.c Revision 1.108, Revision 1.106, Revision [???]
./kemel/os/kern clock.c Revision 1.168, Revision 1.165
./kerne!/os/vm_swap.c Revision 1.163, Revision 1.156, Revision 1.153
./kernel/os/vm drum.c Revision 1.141, Revision 1.138
./kernel/os/vm_mem.c Revision 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
./kemel/os/vm page.c Revision 1.126, Revision 1.125
./kernel/os/vm_page.c Revision 1.122
./kernel/os/vm_pageout.c Revision 1.100, Revision 1.97
./kernel/os/vm_proc.c Revision 1.118, Revision 1.117
./kernel/os/vm_sw.c Revision 1.140
./kernel/os/vm_subr.c Revision 1.88, Revision 1.86
./kernel/os/vm_swp.c Revision 1.151
./kernel/os/mmap mfile.c Revision 1.148, Revision 1.147, Revision 1.145, Revision 1.142
./kernel/os/mmap_ifreg.c Revision 1.146, Revision 1.144, Revision 1.143, Revision 1.142, Revision 1.140, Revision 1.138, Revision 1.136
./kernel/os/audit_subr.c Reviewers: drao, badari
./kernel/os/mraap_anon.c Revision .121, Revision 1.119, Revision 1.114, Revision 1.106
./kernel/os/vm_asops.c Revision .210, Revision 1.203, Revision 1.196
./kemel/os/vfs dio.c Revision .86, Revision 1.85
./kernel/os/kern perf.c Revision .63
./kernel/os/kern daemon.c Revision 43
./kernel/os/kern Iwp.c Revision .95, Revision 1 .92, Revision 1 .88, Revision 1.85
./kernel/os/kern hvpdir.c PR #254650, SCN sarahw!63, reviewer : badari
./kemel/os/lwrwsema.c Revision 1.17
./kernel/os/region.c Revision 1.48, Revision 1.47, Revision 1.44, Revision 1.41, Revision 1.39
./kernel/os/region_mem.c Revision 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.c Revision 1.19, Revision 1.18
./kernel/sys/region.h Revision 1.65, Revision 1.64, Revision 1.60, Revision 1.58, Revision 1.57
./kernel/sys/swap .h Revision 1.35
./kernel/sys/region_kstats.h Revision 1.8
./kernel/sys/mman.h Revision 1.111, Revision 1.108
./kernel/sys/aumacros.h PR 238431; SCN gerrit716; Reviewers: dmo, badari
./kernel/sys/ucontext.h PR 254872, SCN sarahw!86, Reviewer badari
./kernel/sys/buf.h Revision 1.61
./kernel/sys/vm extern.h Revision 1.121, Revision 1.120, Revision 1.117
./kernel/sys/crnap.h Revision 1.61, Revision 1 .60, Revision 1.58, Revision 1.56, Revision 1.55
./kernel/sys/autetypes.h PR 25 1279; SCN timw369; Reviewer: badari
./kernel/sys/region misc.h Revision 1.7
./kernel/sys/proc.h Revision 1.2 14
./kernel/sys/region_mem.h Revision 1 .27, Revision 1 .2 1 , Revision 1 .20, Revision 1.18
./kernel/vm/vmdki.c Revision 1.179
./kemel/vm/vm_ublock.c Revision 1.37
./kernel/sci/sci_archdep. c reviewer - badari
./kernel/proc/migrate.c Revision 1.146, Revision 1.145, Revision 1.136
./kernel/scheduler/sched core.c Revision 1.265
./kernel/scheduler/sched_loadbal.c Revision 1.3
./kemel/scheduler/sched_runq.c Revision 1.5
./shm/shm.c Revision 1.123
./ufs/ufs_inode.c Revision 1.117
./ufs/nfs vnodeops.c PR #254506, SCN sarahwl 89, 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 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 (janetinc@us.ibm.com). 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 of 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.

Thus far, SCO has received no production whatsoever from IBM of AIX software. Notwithstanding this fact, SCO has identified copying by IBM of files of AIX into Linux. One instance of copying of AIX into Linux involves improper contribution by IBM to Linux 2.4 of the AIX Journaling File System ("JFS"). The contribution of JFS was done in a series of "drops" of AIX code identified as "reference files" inside Linux. The first such drop occurred on or about February 2000, with multiple additions and significant follow-up work by IBM since that time to adapt AIX/JFS for enterprise use inside Linux. These drops of reference files do not necessarily become part of the source code in the Linux kernel, but rather are public displays of the Protected Materials so that anyone has access to them and can use them to construct a similar file in Linux.

The first drop contains (a) partially functioning port, or transfer, of JFS from AIX to Linux;

(b) a set of reference directories (named ref/) which contain the AIX reference version of AIX/JFS;

(c) AIX/JFS-related utility files used to maintain and upkeep AIX/JFS; and

(d) a set of directories (named directory ref_utils/) which contain the AIX reference version of utilities. Copies of AIX/JFS files into Linux are shown in Table G, below. Table G compares a 1999 version of AIX currently in SCO's possession. Nevertheless, even this old version of AIX shows the following similarities, demonstrating copying of code, structures and sequences.




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


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 83-158 (Tab 74) have been copied improperly to Linux at lines 322-411 (Tab 76). These transfers of AIX/JFS to Linux are in violation of the Related Agreements, and are an improper use of AIX for adaptation to a general operating system in violation of the Related Agreements.

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

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





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 "AlXisms," 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 "AlXisms", 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/jfsjJw.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 UNLX7AIX 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 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 Linux Header file used
Include/linux/jfs/ref/jfs_dasdlim.h (Tab 82)
Include/linux/jfs/ref/jfs_dinode.h(Tab 83)
Include/linux/jfs/ref/jfs_lock.h (Tab 84) "mmph.h"
include/linux/jfs/ref/jfs_superblock.h (Tab 85)
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) "mmph.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(Tab92)
fs/jfs/ref/jfs_inode.c (Tab 93) "mmph.h"
fs/jfs/ref/jfs_link.c (Tab 94)
fs/jfs/ref7jfs_logmgr.c (Tab 95) "mmph.h"
fs/jfs/ref/jfs_mknod.c (Tab 96)
fs/jfs/ref/jfs_readdir.c (Tab 97) "mmph.h"
fs/jfs/ref/jfs_readlink.c (Tab 98)
fs/jfs/ref/jfs_statfs.c (Tab 99)
fs/jfs/ref/jfs_symlink.c (Tab 100)
fs/jfs/ref/jfs_txnmgr.c(Tab 101) "mmph.h"
fs/jfs/ref/selector.c (Tab 102)


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

TABLE J
Linux 2.2.12 File Line #s
include/linux/jfs/jfs_ctmap.h (Tab 104) 31-36,291-329,158-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-219, 240-311, 559-2566, 3586-3659, 3764-4589
jfs/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_raount.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-282, 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.

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 id=25076&packageid=17436. The first code drop of AIX/EVMS by IBM was vO.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.1, which occurred on 12/20/2003. The following table, Table K, identifies the AIX/EVMS "patches" of source code improperly transferred by IBM to the Linux 2.4 version.



TABLE K
EVMS 1.0.0 patches to Linux 2.4.x Line #s AIX MERCED/9922A_43NIA Line #s
include/linux/evms/evms aix.h (Tab 112) 157-263 kernel/sys/IA64/bootrecord.h (Tab113) 64-170
include/linux/evms/evms aix.h (Tab 112) 311-327 usr/include/liblvm.h (Tab 114) 234-250
include/linux/evms/evms aix.h (Tab 112) 329-349 usr/include/liblvm.h (Tab 114) 252-272, 289-307
include/linux/evms/evms aix.h (Tab 112) 352-400 usr/include/liblvm.h (Tab 114) 316-363
include/linux/evms/evms aix.h (Tab 112) 266-294 usr/include/lvmrec.h Tab 115) 24-92
include/linux/evms/evms aix.h (Tab 112) 6-11 usr/include/lvm.h (Tab 116) 26-35
include/linux/evms/evms aix.h (Tab 112) 26 kerneysys/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
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 ATX 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 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.




TABLE L
Linux kernel iperformance benchmarks
Linux kernel component Database query Volano Mark SPECweb99 Apache2 NetBench Netperf LMBench TioBench lOZone
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

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:

Figure 1. Database query benchmark results

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 performence of the Linux kernel can be improved significantly. We are proud to tribute to this goal by working within the open source community to quantify

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.

INTERROGATORY NO. 2:

For each alleged trade secret of any confidential or proprietary information identified in response to interrogatory 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 (c) 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 information 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 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 information 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.

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]

IBM - German Authors

[redacted]

IBM - Australian Authors

[redacted]

IBM - Other

[redacted]

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]

IBM Primary Technical Contacts in Project Monterey:

[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 Interrogatory 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 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 identifies these individuals in discovery, SCO is unable to identify further individuals involved in the public dissemination of the material identified in Interrogatory No. 1.

INTERROGATORY NO. 5:

For each alleged trade secret and any confidential or proprietary information identified in response to Interrogatory 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 proprietary information including but not limited to the owners, licensors, licensees, assignors or assignees of those copyrights or patents.

SUPPLEMENTAL RESPONSE TO INTERROGATORY NO. 5:

Subject to and without waiving its objections, Plaintiff supplements its response 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-1017585, 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, 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- 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.

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 IFF (64bit Itanium)

SCO Linux Server 4.0, Powered by UnitedLinux

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

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

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 December 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 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 engineering 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 Rajiv Samant, John Kelly, Ross Mauri, Tilak Agerwala, William Sandve, Miles Barel, William Freeman, Michael Day, Gerry Hackett and Helene Armitage. 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 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 plaintiff'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 # 1V736, 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 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, upon information and belief, 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 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 Williams 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 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 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 # 1V743 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.

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 Linux World 2003 convention held in New York during or about January 2003. During this event, Darl McBride, 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 companies to cut off business ties with SCO. On information and belief, such contact by Ms. Smith with each of Intel, Computer Associates, and Oracle occurred during or shortly after the Linux World 2003 conference. As a result of IBM's improper contact and improper attempts to destroy plaintiffs 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 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?UOand examples under which IBM is not entitled to make such disclosures. Paragraph 3.7 of Amendment X provides as follows:

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.

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
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/include/asm-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/ioctl.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
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-sparc/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, specifically, in public statements and when contributing these files of code to Linux, SGI has proclaimed credit for these contributions from IRIX:

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/proiects/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/linux/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
Iinux-2.5.64/fs/xfs/iinux/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
Hnux-2.5.64/fs/xfs/linux/xfs_ioctI.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
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/xfsMs_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
Iinux-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
iinux-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
Iinux-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
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
iinux-2.5.64/fs/xfs/xfs_trans_dquot.c
Iinux-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
linux-2.5.64/fs/xfs/xfs_log_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
1 inux-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/f s/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
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
Iinux-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 offending 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, 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 Code 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 [sic], Toshiba [sic], 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 identified 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 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 available (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 [sic] 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 plaintiff 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 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.

DATED this 15th day of January, 2004.

Respectfully submitted,

___________[signed]_____________________________
Counsel for Plaintiff/Counterclaim Defendant

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)


  


Exhibit 1 to IBM's Report on SCO's Compliance | 242 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Stupid Question, I'm Sure
Authored by: penfold on Sunday, February 15 2004 @ 04:27 AM EST
I see a lot of references in the document to the linux 2.6 kernel. I am sure
it's a pure technicality, but is SCo allowed to point to 2.6 code?

None of the complaints I have reviewed have implicated, nor even mentioned, the
2.6 kernel... Granted, it wasn't released when the suit was filed, but after 3
months after it was released, you would think it would have warranted a press
release that the "new, just released kernel" also "infringed on
SCO IP".

However technical, isn't providing evidence from a source not previously
implicated a little wrong? Afterall, for 10 months IBM has supposedly been
looking at the vaguely indentified versions in the complaint and responses, but
now they have to come up with arguments from the newest code that they didn't
necessarily have to be concerned with before this was filed...

In my mind, after establishing that this code was improperly introduced to
linux, then they can argue what was done with it and where things went from
there.

But first and foremost is that the code shouldn't have been in linux in the
first place. And for the sake of argument, if SCO wins, then we can worry about
what Linux did with it. (We will not even get into why UNIX did NOT do it first,
or if they were even going to do it at all.)

---
Blood from a turnip? That's easy! Try getting SCOX to produce evidence!

[ Reply to This | # ]

Exhibit 1 to IBM's Report on SCO's Compliance - Proofreaders Please
Authored by: Nick_UK on Sunday, February 15 2004 @ 05:17 AM EST

Ummm. This is going to be a mare to sort out. Now, too much to look at, by a quick investigation. From above, one of the files (chosen due to only mentioning it has a few lines copied):

	kernel/i386/locore.s
	(Tab
11)
	1487-1497
	arch/i386/kernel/entry.S
	(Tab 16)
	199-205

entry.S is assembly code.
Now, the lines in question, 199-205 from Linux:
  
ret_from_exception:
         preempt_stop
  
ret_from_intr:
	GET_THREAD_INFO(%ebp)
	movl EFLAGS(%esp), %eax  # mix EFLAGS and
CS
	movb CS(%esp), %al
	testl $(VM_MASK | 3), %eax

Now this thread, with a patch (from Luca Barbieri ldb.ods.org) that actually changes some of that, and the reply to the patch has Linus quesioning it (and the code logic - what registers to use) etc.

http://www .ussg.iu.edu/hypermail/linux/kernel/0301.1/0527.html
          
preempt_stop
    ret_from_intr:
   - GET_THREAD_INFO(%ebx)
   +
GET_THREAD_INFO(%ebp)
            movl EFLAGS(%esp), %eax # mix EFLAGS and CS
  
         movb CS(%esp), %al
            testl $(VM_MASK | 3), %eax

That doesn't look like copying to mean, as the code was changed on existing code that was supposedly copied 'lock stock and barrel!!

Nick

[ Reply to This | # ]

HTML version
Authored by: rakaz on Sunday, February 15 2004 @ 12:07 PM EST
Fully fixed HTML version with all tables is send to PJ.

[ Reply to This | # ]

Exhibit 1 to IBM's Report on SCO's Compliance - Proofreaders Please
Authored by: ErichTheWebGuy on Sunday, February 15 2004 @ 01:43 PM EST
I am doing tables K and L

---
Striving daily to be RFC-2550 compliant

[ Reply to This | # ]

I have proofed up to Table F
Authored by: PJ on Tuesday, February 17 2004 @ 02:20 AM EST
I have finished proofing up to Table F. I found a number of typos. I also
did the final list. Everything in between still needs to be compared with
the PDF.

[ Reply to This | # ]

Exhibit 1 to IBM's Report on SCO's Compliance - Proofreaders Please
Authored by: coolmos on Tuesday, February 17 2004 @ 09:46 AM EST
Page 31 to 50 (Interrogatory No.2 to Interrogatory No.7) are proofread and sent
to PJ.

[ Reply to This | # ]

OT: Judge's Order
Authored by: Anonymous on Tuesday, February 17 2004 @ 06:56 PM EST
Maybe I have missed something here, but wasn't the judge supposed to issue a
ruling on SCO's non-compliance by the end of last week?

[ Reply to This | # ]

Exhibit 1 to IBM's Report on SCO's Compliance
Authored by: Anonymous on Tuesday, February 17 2004 @ 07:21 PM EST
They (SCO) seem to be hinging at least part of the argument on something agreed
to in project Monterey...?

[ Reply to This | # ]

Exhibit 1 to IBM's Report on SCO's Compliance
Authored by: staypuft on Tuesday, February 17 2004 @ 07:25 PM EST
PJ, great stuff, I donated last week.
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.
I don't see how SCO can even claim this with a straight face. SCO's UnixWare does not contain any of the "copied" code.

Martin

[ Reply to This | # ]

Some things dont change
Authored by: Anonymous on Tuesday, February 17 2004 @ 07:27 PM EST
Quote from "SUPPLEMENTAL RESPONSE TO INTERROGATORY NO. 8:"
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.
In other words they dont know, but since it worked thay must have copied from us.

[ Reply to This | # ]

No claims of System 5 to Linux copying. Not one.
Authored by: rjamestaylor on Tuesday, February 17 2004 @ 07:31 PM EST
SCO is boldly asserting its fanatical definition of derivative works
(apparently, if it touched UNIX it's ours) throughout this document and makes no
attempt to show System 5 to Linux copying by IBM or Sequent. Unless the first
paragraph holds in court, the rest of the copyright / contribution to Linux
argument goes out the window. (Of course, if Novell prevails against SCO w/r/t
the copyright suit, it doesn't matter anyway.)

Not so clear to me are the unfair competition claims as that involves a business
relationship between SCO (not Caldera, btw) and IBM not unauthorized transfer of
code. Is it legal to change strategies and switch partners? If the first
partner is a failing business on its way out is it illegal to saddle up with a
competitor to partner 1? Seems like whining and sour grapes rather than an
actionable claim, but then again I don't think people should get money for
spilling coffee on themselves, so what do I know about these things?

---
SCO delenda est! Salt their fields!

[ Reply to This | # ]

Liar, liar
Authored by: rand on Tuesday, February 17 2004 @ 07:42 PM EST
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.

Technically true, but conveniently leaves out the many version of 2.4 that were distributed with OpenLinux:

Additional Key Features
Linux 2.4 Kernel – The new Linux 2.4 kernel is a key component of the OpenLinux Workstation product.

Linux 2.4 Kernel – The new Linux 2.4 kernel is a key component of the OpenLinux Server product.

And in true SCOG fasion, I don't think they know these datasheets are still on their server.

---
The Wright brothers were not the first to fly an aircraft...they were the first to LAND an aircraft. (IANAL and whatever)

[ Reply to This | # ]

Exhibit 1 to IBM's Report on SCO's Compliance
Authored by: Anonymous on Tuesday, February 17 2004 @ 07:45 PM EST
Interrogatory #12 asks for all code in Linux that SCO claims it has rights to,
not just IBM code but from everyone else.

SCO has been claiming publically that this is over a million lines, but from
what I understand they have identified only about 3700 lines. If that is the
case, and they can't come up with anything more, then SCO was lying about what
was found in the code comparison last year by three teams of experts, and for
that reason alone it loses on IBM's Lanthan Act et al charges.

Also, if SCO comes up with only 3700 lines, then it basically loses its case
against IBM. That is so even if SCO persuades the judge that it has rights over
all that code.

The reason is that SCO claims IBM owes it billions of dollars because it was
ready to become king of the x86 unix server market, worth billions a year,
until, SCO alleges, IBM made it possible for Linux to become an enterprise os by
giving it an enormous amount of SCO code, and this act destroyed SCO's market.

If IBM gave only 3700 lines to Linux, then it played no significant in helping
Linux become an enterprise os, and so IBM at most owes SCO a few million
dollars.

SCO is simply dead unless it is able to come up with a few hundred thousand more
lines of code, and very soon.




[ Reply to This | # ]

An analysis
Authored by: Anonymous on Tuesday, February 17 2004 @ 07:50 PM EST
For much of the document, SCO appeared to do little more than highlight IBM's
contributions to Linux. They seemed to argue that IBM transferred ideas or
programming concepts into Linux rather then cite any specific meaty line by line
code examples. SCO lists a lot of Linux code however they don't seem to be able
to list specifically what parts of their code were lifted. A good analogy would
be 2 authors writing different books on the same subject. It seemed as if SCO
was claiming ownership of the ideas as if they wished they owned the patents to
them. When asked what portions of Linux they own, SCO refused stating the
request was "overly broad and unduly burdensome". SCO also danced
around the issue that they themselves distributed to code in question under the
GPL by claiming ignorance. Once I heard a joke about someone who claimed
ownership of the Brooklyn bridge and tried to sell it. How is SCO claiming
ownership of Linux and trying to sell it any different from that situation?

[ Reply to This | # ]

12 & 13 still not relevant?!
Authored by: xtifr on Tuesday, February 17 2004 @ 08:15 PM EST

I've noticed that filings from IBM always start by listing SCOG as "plaintiff / counterclaim defendant" and IBM as "defendant / counterclaim plaintiff", while filings from SCOG always omit the "counterclaim" bits. Between that and the fact that SCOG claims that interrogatories 12 & 13 are not relevant to the case (when it's absolutely clear that they're relevant to IBM's counterclaims) I'm starting to wonder if maybe SCOG hasn't just forgotten that there's a countersuit. I mean, when you think you're in line to get <quote voice="carl sagan">"bill-yuns and bill-yuns"</quote> of dollars, it's easy to get excited and overlook these little details, right? :)

[ Reply to This | # ]

Can SCO utilize information
Authored by: Anonymous on Tuesday, February 17 2004 @ 08:18 PM EST
for current events that thwy could noth ahve nknow at teh time tehy filed suit?
IE on #8 they where notified this month about Target's switch from Openserver,
so it wasn't on the radar screen 6 months ago. It seems to me that Target
dropped SCO because of the lawsuit and general SCO instabilities, never mind the
flaky SCO server software.

[ Reply to This | # ]

But for IBM's transfer...
Authored by: Anonymous on Tuesday, February 17 2004 @ 08:25 PM EST

``But for IBM's transfer of AIX technology to Linux, Linux developers would have had to learn from the beginning, through trial ind error, how to create an advanced filing system for enterprise application.''[emphasis mine]

Um, is SCO letting out how they develop code? Through trial and error? :-)

I'm overlooking the wishful thinking on SCO's part about JFS coming from AIX (when it actually came from OS/2).

So... Linux would never have gotten a journaled file-system without IBM's help? That'd be news to Hans Reiser. And to the bunch of people involved in getting ext3 incorporated into the kernel.

--
SCO, spelled j-u-s-t-p-l-a-i-n-n-u-t-s (They're all silent)

[ Reply to This | # ]

What does this say?
Authored by: maco on Tuesday, February 17 2004 @ 08:28 PM EST
  1. outright lies:
    • linux nowhere without IBM
    • SCO ownership of "derived" code
  2. header files
  3. insignificant code snippets
  4. am I missing something?
Must be hoping the judge is awful stupid.

[ Reply to This | # ]

Exhibit 1 to IBM's Report on SCO's Compliance
Authored by: Anonymous on Tuesday, February 17 2004 @ 08:38 PM EST
Forgive me if I am wrong, but isn't IBM allowed to copy its own code into Linux?
Shouldn't SCO be showing how the unix code == dynix code == linux code?

[ Reply to This | # ]

Dig out those downloads from ftp.sco.com
Authored by: snorpus on Tuesday, February 17 2004 @ 08:56 PM EST
From SUPPLEMENTAL RESPONSE TO INTERROGATORY 13:

Insofar as this interrogatory seeks information as to whether plaintiff 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. (emphasis added)

So... either the versions of linux distributed from the SCOG servers didn't contain the code they question, or SCOG management didn't exercise their fiduciary responsibilities in supervising the actions of their subordinates.

Didn't a couple of heads at the NYTimes lose their jobs because a reporter, several managerial levels below them, essentially made up his stories without really being there? Can SCOG management legitimately claim that GPL'd linux was being distributed without their knowledge from the SCOG servers?

OT: NAV just sent me an update for the Bagle/Bagel virus. As always, never open an unexpected attachment... but you knew that.

---
73/88 de KQ3T

[ Reply to This | # ]

Bates numbers???
Authored by: Anonymous on Tuesday, February 17 2004 @ 08:59 PM EST
What are these? I presume they're index numbers of some kind.

In any event, I took a closer look at that list. SCO claims that their own
copyrights are referenced under Bates numbers 1292920 through 1292941, but the
long list immediately above that doesn't contain those numbers at all! Am I
misreading this, or is SCO actually claiming that nothing here involves their
(SCO) copyrights at all?

[ Reply to This | # ]

SCO's Blender
Authored by: RedBarchetta on Tuesday, February 17 2004 @ 09:23 PM EST

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.


Of course they'd object to this interrogatory.

They wouldn't want the judge to know that they themselves contributed to Linux, now would they? That just might put a monkey-wrench in SCO's legal blender! DOH!

[ Reply to This | # ]

TYPO
Authored by: Nivuahc on Tuesday, February 17 2004 @ 09:23 PM EST
All the way at the beginning of the document,
SUPPLEMENTAL RESPONSE TO INTERROGATORY NO. 1:

....trade secret information by transferring core portions of ADC and Dynix/ptx to Linux, as detailed below...

Should be

trade secret information by transferring core portions of AIX and Dynix/ptx to Linux, as detailed below

---
SCO-Logic: If you lie about something long enough, people will eventually believe it. And if they don't believe it, you aren't yelling loud enough.

[ Reply to This | # ]

  • TYPO - Authored by: PJ on Thursday, February 19 2004 @ 02:53 AM EST
Odd Graph
Authored by: Anonymous on Tuesday, February 17 2004 @ 09:30 PM EST
Looks like a couple of regressions - check out the last two dates, as well as
two early ones.

[ Reply to This | # ]

And the Other Unix Licenses
Authored by: ansible on Tuesday, February 17 2004 @ 09:41 PM EST

I was particularly fascinated that they chose to mention that they are reviewing the contributions made to Linux by all the other Unix licensees.

Reads like a list of people they are planning to sue next. I wonder if the other licensees are going to band together to pre-emptively challenge fiaSCO.

[ Reply to This | # ]

Exhibit 1 to IBM's Report on SCO's Compliance
Authored by: Ted Powell on Tuesday, February 17 2004 @ 11:17 PM EST
Brent 0. Hatch (5715)
Mark F. James (5295)
HATCH, JAMES & DODGE, P.C.

Hatch's middle initial appears here (approx line ten) as a zero (0) instead of
the letter "O".

---
Truth is not determined by majority vote.

[ Reply to This | # ]

Exhibit 1 to IBM's Report on SCO's Compliance
Authored by: Anonymous on Tuesday, February 17 2004 @ 11:55 PM EST
isn't the fundamental issue that the judge asked sco to provide proof for the
exact line numbers in System V and linux? not dynix and linux?

they have provided information, but the entirely wrong information. proving
that ibm contributed these things is like calling the kettle black - ibm has
never denied doing so, unlike sco...

[ Reply to This | # ]

One More Time -- Contract Dispute, not Copyrights.
Authored by: LionKuntz on Wednesday, February 18 2004 @ 12:07 AM EST
One more time...

This is presently a CONTRACT DISPUTE, not a copyright dispute. Copyrights are
argued in FEDERAL COURT; this is a Utah State court.

A judge, with no especial technical expertice, is asked to evaluate a flood of
data presented by SCOG, as to completeness of disclosure. This is NOT THE TRIAL
-- this is PRE-TRIAL DISCOVERY (different rules and standards of strictness).


In public statements out-of-court, and statements in court pleadings, SCOG
claims that their CONTRACT was breached.

Was it, or wasn't it -- this is FACT, to be determined in TRIAL, not something
to be determined PRE-TRIAL.

The "information" from NOVELL, from AT&T, from SCOG's release of
documents, may be decided out-of-court by armchair jurists, but the law requires
it to be settled inside a courtroom by the rules of evidence in a trial.


A motion to dismiss might be entered and succeed only IF there is some
extra-ordinary evidence OTHER THAN WHAT HAS BEEN SHOWN TO DATE ON GROKLAW.NET.


AS OF TODAY, FEBRUARY 17, 2004, the main case SCOG v IBM has no copyright
infringement element. All out-of-court discussions by SCOG and/or armchair
jurists about copyrights is peripheral to the matter in contest in court.


SCOG's arguments are their "copyrighted" code was used as a platform
for development of extended functionality to AIX/DYNIX, and BY CONTRACT SCOG has
rights to suppression of distribution to extensions to "their"
contract.


UNLESS IBM's legal team (and volunteers in the open community) can turn up clear
evidence that SCOG's code was publically released without copyrights long ago,
THEN the case must proceed onwards to trial next year.

ONLY PROOF of the invalidity of SCOG's copyright claims can shorten the process
-- nothing else other than SCOG's voluntary withdrawal of the lawsuit can
shorten the process. QUESTIONS "OF FACT" MUST BE DECIDED BY TRIER OF
FACT, AS REQUIRED BY LAW. The "Trier of Fact" is the trial with
evidence and witnesses of both sides.


ALL hope for shorter process is doomed to failure, because deep-pockets
Microsoft has endless dollars to throw at this. They have given $8.3 already,
which is equal to what has been spent so far, and nobody knows for certain who
is behind the $50m of Canadian money from another country. One must assume there
is no shortage of funds for SCOG to keep the controversy alive.


The short path to resolution is to invalidate SCOG's claim to valid copyrights
by turning up eyewitnesses who go on record that UNIX was distributed without
proper copyrights affixed, and without a rigorous confidentiality compliance
program between 1968 and 1972.



IF SCOG has claims on a "Public Domain Collection Copyright", rather
than claims on "Original Creative Work Copyright", THEN there can be
no DERIVATIVE RIGHTS possible, AND THEN the CONTRACT DISPUTE based on
DERIVATIVES is terminated -- SCOG has no standing to sue. Case Dismissed.



IBM is evidently pursuing this avenue by demanding all source codes going all
the way back in their discovery actions against SCOG. Hundreds of people can
spend hundreds of hours transcribing filing after filing. If you want your
energy to be fruitful and productive you will ignore all the paper blizzard and
concentrate on finding those eyewitnesses.

They surely exist. Strong clues are in the UNIX histories online.

Probably, the seal on the USL v UC Berkeley case revolve around "trade
secrets" involving how much of UNIX escaped into Public Domain in the early
period.

Besides Berkeley, many universities and many hundreds (if not many thousands) of
students were exposed to UNCOPYRIGHTED distributed source code.

All that early UNIX code was distributed and exposed without strict
confidentiality INVALIDATING COPYRIGHT PROTECTION at a time in history where
AUTOMATIC COPYRIGHT PROTECTION UPON CREATION DID NOT YET EXIST.



SCOG cannot retroactively apply today's copyright laws onto that old code, just
as AT&T could not legally do it.


WE HAVE SEEN EYEWITNESS STATEMENTS THAT COPYRIGHTS WERE ADDED VERY LATE INTO
WIDESPREAD DISTRIBUTION OF EARLY UNIX. These copyrights are only for NEW code
added from that date and DO NOT PROTECT OLD CODE BEFORE THAT DATE.



If you want to make this case go away, find those eyewitnesses. Find plenty of
them willing to swear on oath affadivits before notary publics. Once confirmed,
AT&T's copyrights apply only to "verbaitum" copies, never to
derivative works. All successors to AT&T own "collections of public
domain with a scattering of original contributions". Almost all the header
files will be old and public domain.


SCOG has defined the game in such a way that they win, everbody else loses.
Don't play their game by their rules.

The RULES that apply was the law as it was in 1968 to 1972 when UNIX was young.
Those rules define who wins and who loses. Force the game to require using those
rules and SCOG loses.

[ Reply to This | # ]

Moving the goalposts
Authored by: Anonymous on Wednesday, February 18 2004 @ 12:11 AM EST

Two things:

One, I think I have another case of SCO's public statements failing to match up with their legal claims. I think SCO once claimed that versions of the 2.4 kernel prior to 2.4.18 or 2.4.19 were not infringing. I remember this, because I spent some time poking around SCO's public ftp directories soon after the lawsuit broke looking for Linux source code. I'm going to have to dive back into my old Slashdot posts, but I think I posted a link to some 2.4.13 source, and someone else or myself pointed out that SCO was not claiming that version as infringing at that point. This filing clearly makes reference to 2.4.1 code and 2.2.12 code, among others.

SCO's lobbed out so much BS in public by now, I'm starting to wonder if they're really smooth operators trying to trip up critics into debating throwaway public statements that are meant to distract from their (still bloody weak) court case.

Nah. Too much credit, calling them "smooth operators".

On that note, I reach my second point--the copyright infringement shenanigans.

We're likely not going to find any code that can be considered part of System V Unix on a pure copied-code basis. The basis of SCO's suit relies on a viral interpretation of the SysV licence, that any code developed as a derivative of the SysV codebase belongs to the SysV owner, which SCO claims is themselves.[0] Therefore, IBM's simple contribution of code even derived from the Sequent code can be considered by SCO to be infringing, even though SCO never wrote the code or, likely, never even looked at it until after going to court.[1] IBM's amendment to the AT&T licence seems to give IBM carte blanche to use derived code all they wish. This whole thing, at its core, seems to come down to whether the Sequent code and technologies came under the IBM SysV amendment upon purchase of the company. I say "technologies", because many of the code sections SCO claims are evidence of "copying" don't seem to match up in terms of line amounts. I eagerly await the table scans--I need a laugh.

In short, eyes on the prize.

[0] And Novell challenges this. Hell, Novell seems to have specifically told SCO they cannot chase down violations based on the Sequent codebase, told SCO to back down, and SCO is ignoring their partner in the SysV licence agreement. The AT&T $ echo article seems to indicate that the Death Star never intended for the derivatives clause to be used in this fashion (way back in 1985!), and while AT&T is no longer the owner of SysV, Novell may very well be, they know the licence, they have their interpretation of "derivative works", and there's still a conflict with SCO regarding ownership of SysV that SCO seems strangely quiet regarding.

[1] Which may explain the AIX/dynix fishing expeditions. Still, the version of JFS used in Linux is reportedly derived from the OS/2 implementation, which was developed separately from the AIX implementation, and I'm waiting for legal confirmation from IBM on this (ie, they mention this in a court filing). SCO seems to be claiming that the very act of providing any code to Linux that implements a technology found in IBM's UNIX offering, even if the code is developed in a cleanroom situation instead of outright code copying, is a violation of the SysV agreement.[2] In other words, IBM cannot port Unix-based technologies to Linux, which IIRC was exactly what the IBM/SCO Monterrey project was about. As I type this, I wonder if this is coming back to petty revenge over IBM backing out of Monterrey.

[2] And people complain that the GPL is viral...

[ Reply to This | # ]

Project Monterey
Authored by: flowctrl on Wednesday, February 18 2004 @ 12:54 AM EST
SCO's account of Project Monterey, a strategic alliance between itself, IBM and
Intel, paints a rather sinister picture of Big Blue (INTERROGATORY NO. 7). I
don't know how much, if any, of it is true, but if it is, could SCO have a case
against IBM for unfair business practices or breach of contract, code-copying
issues aside?

[ Reply to This | # ]

Interesting point...
Authored by: Anonymous on Wednesday, February 18 2004 @ 01:10 AM EST
...made in the following posts to slashdot:
post 1
post 2
I've not seen this previously discussed on groklaw (though I admit to not having read all posts). Does anyone know if there is anything to these ideas?

[ Reply to This | # ]

Exhibit 1 to IBM's Report on SCO's Compliance
Authored by: Anonymous on Wednesday, February 18 2004 @ 01:29 AM EST
Examining the SCO claims, I see they now claim rights to
XFS from SGI as well. So when do the SGI court proceedings
start?

This is rediculous. Under the basis of SCO's claims they
would have "rights" to any application written by a company
that at one time licensed a copy of UNIX from AT&T where
the application accessed low level UNIX kernel code.

This would mean SCO has "rights" to the entire Veritas
product suite, because that is every bit as low level as
XFS and JFS, and I'm sure Veritas at one time probably
purchased a license to port and test their product on SVR4.

When you get down to it, the Oracle database handles raw
volumes, does that mean SCO has "rights" to Oracle as well?
I'm sure Oracle has at some point purchased a license then
ported and tested their product for use with SVR4. I am
sure the same would apply to IBM's DB2 and other UNIX
applications from almost any vendor.

I'm sure the news these SCO "rights" would come as a shock
to the folks at both Veritas, Oracle and various UNIX
application vendors.

If some vendor was to port the ext3 filesystem to Solaris, HP-UX, Irix, AIX or
Dynix, would that mean SCO could then claim "rights" to the ext3
filesystem?

The perl scripting language uses kernel calls every bit as low level as JFS and
XFS. Does this mean SCO can now claim
"rights" to perl. This would come as a shock to virtually
every web master on the planet and even include Microsoft.

The whole concept of SCO's claimed "rights" is stupid
beyond all reason. SCO should know their concept of
"derived rights" is stupid and totally without basis.

Maybe it is SCO that should be sued for "Slander of Title".
They are knowingly and deliberately slandering the title of
Linux impacting the copyright of thousands of individual
contributers without first having reasonably verified proof
of any legal or valid claim to Linux. Unlike SCO's slander
claim against Novell, I'm sure some specific Linux lost
sale could be proven as well as the other three elements
needed for a successful Slander of Title claim.

PRH

[ Reply to This | # ]

Exhibit 1 to IBM's Report on SCO's Compliance
Authored by: roman_mir on Wednesday, February 18 2004 @ 03:01 AM EST
Darl is daring to call GPL viral and at the same time asserts that anything that
looks like Unix code written by IBM after that SystemV contract belongs to SCO.

Conclusion: Darl is a turd. Don't touch it, it's excrement.

[ Reply to This | # ]

EVMS !!!
Authored by: alan.hughes on Wednesday, February 18 2004 @ 03:03 AM EST
I think SCO dropped the ball on this one!

EVMS is not, and never has been an integral part of the Linux kernel. Linux EVMS version 1 was developed by an IBM-lead team, that is a matter of record and cannot be disputed. However EVMS 1.x was always released as a set of patches to the kernel that was not widely adopted by the Linux distros, largely because Linux already had a volume management system - LVM developed by another company (name escapes me at the moment).

The EVMS patches where submitted to Linus for official inclusion into the kernel, however he rejected them on the basis that they did not provide any benefits over the existing LVM system. The EVMS team was disappointed but, to their credit, took the hit on the chin and started the development of EVMS 2, a set of user space tools designed to support the management of LVM (and software RAID as well).

I hope IBM's legal beagles read this because it would be really nice to point out a major flaw (what another one) in SCO's arguments.

[ Reply to This | # ]

  • LVM - Authored by: Anonymous on Wednesday, February 18 2004 @ 06:47 AM EST
    • LVM - Authored by: alan.hughes on Wednesday, February 18 2004 @ 07:05 AM EST
  • EVMS !!! - Authored by: Anonymous on Saturday, September 04 2004 @ 01:11 PM EDT
SCO considered harmful.
Authored by: TimDaly on Wednesday, February 18 2004 @ 05:01 AM EST
SCO claims that:
 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.
but IBM had prior technology and understanding of the scatter/gather I/O technique from its IBM/360/370 VM operating system. Thus IBM developed (and may have patented) the technology independent of, and prior to, SCO's acquiring the technology. This technology exists somewhere in the late 60s, early 70s. It exists in the VM codebase. Thus scatter/gather is not a "Dynix" technique. This renders void SCO's claim that IBM could not have given scatter/gather I/O to Linux without Unix.

[ Reply to This | # ]

I don't know but it happened this way.
Authored by: TimDaly on Wednesday, February 18 2004 @ 05:20 AM EST
 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.
I'm sorry, your honor, I wasn't there but it is clear that everybody conspired against us then went out for a beer. Once we are allowed to fish thru their expense account records we'll be able to show that beer was consumed on that day. From that we can infer that they conspired against us and should be liable for megamillions. You know what THEY say: "Linux, free as in beer", right? Can you make the argument in a legal document that you don't know and could not know that things happened but you claim they did? I can see the potential to get rich quick if this argument succeeds.

[ Reply to This | # ]

SCO is ripping IBM's heart out...
Authored by: Anonymous on Wednesday, February 18 2004 @ 05:28 AM EST
and all IBM can do is watch and retaliate with some cheap remarks while still
having to START producing its FIRST AIX version ???

Hats off to SCO.

Whoever still thinks that everything is going just fine for IBM/Linux needs to
pull his head out the sand. Now.

Frankly, I'm astonished.
Things really start to look very ugly.

[ Reply to This | # ]

Exhibit 1 to IBM's Report on SCO's Compliance - Am I missing something?
Authored by: Anonymous on Wednesday, February 18 2004 @ 05:33 AM EST
In this document, SCO responds to requests from IBM to identify "all
persons", etc. to whome information was disclosed by just listing
individuals at IBM (and Sequent).
It seems to me that they are not being fully responsive. I think this is
important because under the terms of the license, the licensee's duty of
confidentiality ends if the information becomes public through the actions of
others.
It doesn't seem to me that SCO's responses provide all of the information they
are required to disclose...

Have I missed something? or is this not important...?

[ Reply to This | # ]

Exhibit 1 to IBM's Report on SCO's Compliance
Authored by: Anonymous on Wednesday, February 18 2004 @ 05:54 AM EST
Just out of interest, I downloaded a copy of the 2.4.1 kernel, unpacked the
tarball and had a look at one of the disputed files at random - this case
timer.c. Assuming that I'm looking at the right line numbers (25-28), these are
quite simply just variable declarations (eg: "long time_reftime"). So
SCO is seriously thinking that generic variable declarations like these that
could appear in virtually any code are their intellectual property? This is like
saying that Linux infringes SCOs copyright because the word "begin"
occurs in various subroutines in both SCO and Linux source code.

I'm not one to get quite so inflamed about such stuff, but I honestly hope the
judge grinds these SCO cretins under her heel into the oily, slimy gloop that
they obviously evolved from.

[ Reply to This | # ]

Contempt for the Judge
Authored by: TimDaly on Wednesday, February 18 2004 @ 05:56 AM EST
 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.
So, B-trees are SCO's magic trade secret? Well, look at Folk, M and Zoellick, B. "File Structures", 2nd ed. (1992) Addison-Wesley Publishing Company ISBN 0-201-55713-4 Ch 8 "B-Trees and Other Tree-structured File Organizations" to see the algorithms (with pictures) of file management with B-trees. Actual C code exists starting on page 389.
Or see "Knuth, D. "Art of Computer Programming" Vol 3 "Sorting and Searching" (1973) Addison-Wesley for a discussion of B-trees.
Or even more to the point, IBM has INNOVATED in this area with VSAM. See IBM GC26-3799 "Virtual Storage Access Method" which is a technique for accessing a file with both sequential and B-tree accesses. VSAM was in MVS, IBM's mainframe operating system, somewhere in the early 70s and maybe before that (possibly in MVT or MFT).
So SCO claims that without Unix it would not be possible to write B-tree based code or journaled file systems? (Hans Reiser would be amazed). IBM knew this area long before Darl could read. I may know nothing about law but I know technical nonsense when I see it. If this were judged on the technical merit, (my area of expertise), rather than legal merit I'd have sentenced SCO to chroot-jail for contempt of the court's intelligence. As a professor of computer science I'd fail anyone who wrote such crap. Unfortunately the judges can't be expected to know when they are being "baffled with bullshit" on such technical subjects.

[ Reply to This | # ]

Does the origin of RCU matter?
Authored by: Anonymous on Wednesday, February 18 2004 @ 07:09 AM EST
I find it odd that TSG focus their effort on RCU.

To my understanding, Sequent were somewhat careful to present it as an academic work using a dynix implementation only as a proof-of-concept/demonstration.

Not only is it patented (5,442,758) but, as noted in discussion (google cache) on LWN, the paper references earlier works in the area.

Therefore, assuming the worst, that (1) TSG can prove it owns the dynix implementation of RCU and (2) a requirement is placed that it be stripped from Linux, there is nothing to prevent a trivial reimplementation from the details in said patent and papers.

My conclusion is that TSG cannot harm Linux through RCU (and really, they must know this), so this will stop with the existing contract dispute with IBM. Everything else is hot air.

Now, as far as the contract dispute is concerned (assuming the worst, that TSG in fact do have a claim to code written by Sequent/IBM)

  • is it sufficient for them to show that common code exists between dynix and linux, or need they prove also that there is no alternative method by which this code arrived in linux (i.e. it is not a natural implementation from patent and/or paper, albeit by persons who may have also written the code for dynix) ?
  • alternatively is it sufficient defence for IBM to show that an alternative method exists?
That is, does the origin of RCU constitute a legal point and on whom is the burden of proof?

[ Reply to This | # ]

RE: Exhibit 1 to IBM's Report on SCO's Compliance
Authored by: Anonymous on Wednesday, February 18 2004 @ 09:44 AM EST
I have two problems with this:
1) This is another case of "all your codes belong to us" mentality.
Dynix code is Sequents property (now IBMs property), not a part of SysV UNIX.
2) I'm pretty sure we've seen this errno.h debacle before - it's a part of the
C standard library for goodness sake!

I really hope nobody gets panicked by this rubbish.

[ Reply to This | # ]

Exhibit 1 to IBM's Report on SCO's Compliance
Authored by: Anonymous on Wednesday, February 18 2004 @ 09:47 AM EST
The URL between tables J and K should
be:
http://www.sourceforge.net/project/showfiles.php?group
id=25076&packageid=17436

Looks like the OCR tool choked on it. Thanks for
transcribing this document.

[ Reply to This | # ]

Supplemental No. 8: AutoZone claims are false
Authored by: jbgreer on Wednesday, February 18 2004 @ 10:00 AM EST

I don't know whether to be pleased or angry at SCO's assertion that IBM must have assisted AutoZone's transition to Linux due to the "precision and efficiency with which the migration occurred". You see, I was a Sr. Technical Advisor at AutoZone, where I was an employee for over 10 years. During my tenure, I participated and led in the design, development and maintenance of many of AutoZone's store systems. More importantly, I initiated AutoZone's transition to Linux and I directed the port of their existing store software base to Linux. I personally ported all of AutoZone's internal software libraries for use under Linux. I personally developed the rules by which other AutoZone developers should make changes to their code to support both Linux and SCO's OpenServer product. I believe at one point I had as many as 35 AutoZone developers performing porting work for me, much of which was trivial, given that our code did not generally rely on SCO specific features and that the more technologically sophisticated portions of our code tended to reside in our libraries. The developers were also responsible for testing their individual applications under both SCO and Linux; I supplemented this activity by performing builds of the entire AutoZone store software base on my desktop, which I had converted to Linux.

As to the claim that SCO's shared libraries were a necessary part of the port: false. No SCO libraries were involved in the porting activity.

As to the claim that IBM induced us to transition to Linux: false. It was, in fact, SCO's activities that 'greased the skids' and allowed the business case for using Linux to be made more easily. That is a story long in the telling; perhaps I'll share it another day.

One should remember the Linux business environment that existed at the time the AutoZone transition began. Several vendors - the original Caldera Linux distribution company, Red Hat, and Linuxcare - were offering support for enterprise installations of Linux. In fact, Bryan Sparks, then CEO of Caldera, flew to Memphis and met with me during my evaluation of the various distribution and support offerings. I also met and talked briefly with Dave Sifry of Linuxcare during the 1999 Linux Expo. AutoZone settled on Red Hat chiefly because of my familiarity with their distribution and the ease with which AutoZone could negotiate a support agreement with them.

I must add that SCO was eventually made aware of AutoZone's transition to Linux. They responded by offering to assist AutoZone in the porting activity. By the time of their offer, AutoZone had already completed the initial porting activity and had already installed a Linux-based version of their store system in several stores.

Finally, I'll add that I was for a time a member of SCO's Customer Advisory Board. As such, I believe I have some useful insights as to why SCO lost AutoZone's and several other large accounts' business.

Regards, Jim Greer

[ Reply to This | # ]

Deritive Works Belongs to Owners' Says AT&T
Authored by: Anonymous on Wednesday, February 18 2004 @ 10:09 AM EST

AT&T said in 1985 that any deritive works of Unix are the owners'. PJ already knows about this, and I think she is going to put it in the timeline too. But this info is important so spread the word since SCO is bound by AT&T's promises.

1.) Quote from "AT&T Trips Up SCO" by Frank Hayes (http://www.computerworld.com/printthis/2004/0,4814,90205,00.html)

It was a copy of "$ echo," a newsletter published by AT&T in 1985 for its Unix licensees. In it, AT&T clarified what that derivative-works clause in the Unix license meant. (Apparently, there was confusion about it even then.)

AT&T said it wanted "to assure licensees that AT&T will claim no ownership in the software that they developed -- only the portion of the software developed by AT&T."


2.) Article from Slashdot "Novell Quotes AT&T on Derivative Works" (http://slashdot.org/article.pl?sid=04/02/10/2328203)

Novell has released their latest correspondance with [SCO] ordering them to stop the lawsuit by noon tomorrow, and clarify what the SVRX licensing agreements with AT&T meant regarding derivative works. The letter quotes AT&T from the April '85 issue of $echo as stating that they 'claim no ownership interest in any portion of such a modification or derivative work.' So much for the ladder rung analogy." And reader highwaytohell links to today's CRN article in which Eben Moglen suggests that the SCO/Linux lawsuit cannot move ahead "until SCO resolves its dispute with Novell. And regardless of which company prevails in court, he said, customers won't have to pay any company for a license fee since both claimants--SCO and Novell--have distributed the Linux code under the GPL. Once again, SCO have no comment.

[ Reply to This | # ]

Not Brent Zero Hatch.
Authored by: phuff on Wednesday, February 18 2004 @ 10:44 AM EST
Looks like the OCR did Brent Zero Hatch. It should be O, I assume.
-Paul

[ Reply to This | # ]

UNIX Confidential ?
Authored by: lightsail on Wednesday, February 18 2004 @ 10:49 AM EST
One element of the TSG arguments is that UNIX is requird by license to be held
in confidence, not shared publicly. That dastardly IBM shared a derivative work.


BUT, TSG shared 32V publicly, which maybe a violation of contidentiality, doing
damage to those who have maintained confidentiality of 32V Unix. DOes IBM have a
32V license also?

IBM could play TSG and claim that TSG released UNIX publicly and that
confidentaility has been hopelessly compromised by TSG. The old UNIX is UNIX
let's forget versions etc play.

Does the release of ancient Unix by TSG infringe the Novell copyrights if Novell
still owns these copyrights?

[ Reply to This | # ]

The Third Battlefield
Authored by: John Goodwin on Wednesday, February 18 2004 @ 02:18 PM EST
There are three ways to view this sort of thing.

1. From an ideal, philosophical perspective of right and wrong, who should win?

2. From a realistic perspective of how will this affect business. What will the
players actually do. Who, aside from theory, will in fact win what legal
battles, which ones, will anyone care, if so what will *they* do?

3. From a defensive perspective for Free Software--in a dangerous world filled
with Software Patents, bogus lawsuits, and bizarrely motivated governments all
over the world, what should *we* do?

It is the third one that concerns me. Not whether the claims should ever have
been made, nor what the outcome in a few years will be, but what the best course
is for Free Software. Clearly, there are going to be these sorts of
attacks--like Software Patents, the DMCA, the RIAA offensive and so on.

So how does one deal with this sort of thing in general. Here's some shared
code and someone walks up and says "that's mine"--maybe its pretty
glittering code, maybe they are nuts it doesn't matter. It will happen. Now
what? The GPL is great and gives various defenses, the last resort of which is

But what happens if this sort of thing rises above nuisance value--the odd SCO
suit--and because endemic, like SPAM. I like the analogy of an interstate
highway. Lots of "free travel" without (many) restrictions--until
every town puts up a toll booth, every 2 miles. It *is* possible to kill
freedom, if the bandits get out of control.

Obviously, the main deterent to this sort of thing right now is the high cost of
going to court. Only a *determined* and *rich* enemy of Free Software can use
this tactic. The backers of this suit (covert and overt) are both. Maybe the
best defense for Free Software will turn out to be ecological--evolving beyond
the "monoculture desktop" and "monoculture server" as a
paradigm. It is clear we cannot stand still however. We need tactics and
philosophies to meet this challenge.

IP Terrorism worries me, as a phenomenon. It doesn't "spell the end of
Free Software as we know it", but it does mean we have a challenge that we
have to meet--beyond the courtroom and boardroom, there is a third battlefield.
Geeks need to be sharpening their swords. We can evolve faster than they can
sue us, or even perceive our paradigms--but our depending on a corporate
champion to fight our battles will not work to preserve our freedom, nor will
bringing down corporate foes suffice. Both these things will happen, on their
own timescales, but the real battle will be long over before then.

No answers here. Just questions. We need to start talking.

[ Reply to This | # ]

Okay, looks better for SCO; now show us Exhibit A
Authored by: Anonymous on Wednesday, February 18 2004 @ 02:55 PM EST
This disclosure restores my faith in SCO ;-). More specifically, thanks to this
I now believe that they truly believe what they're saying, and they're not
merely playing for time. Or at any rate I can't prove malice.

These disclosures very nicely carry out SCO's untenable (but firmly held) theory
that every part of a derivative work is a derivative work, regardless of
ownership or authorship. This theory makes the rest of SCO's case make sense.

Of course, this theory is incorrect and untenable, but it's up to the court to
show that. I suspect that this case WILL go to court, and not be dismissed.

But that doesn't matter to us (because SCO will lose this case, and because
IBM's contract violations don't affect us). What DOES matter to us is what SCO
will do in the meantime -- we need to know what SCO is claiming that's copied
directly from UnixWare! That information appears to be contained in Exhibit A.
Is there any way we can get a hold of it, or get someone who's seen it to tell
us something about it?

-Billy

[ Reply to This | # ]

We Are SCO!
Authored by: Anonymous on Wednesday, February 18 2004 @ 03:05 PM EST
We are SCO! All your #defines are belong to us!

[ Reply to This | # ]

Looking at the RCU stuff
Authored by: jmaurer on Wednesday, February 18 2004 @ 04:36 PM EST
I've had a look at the RCU (read-copy-update) stuff. (I do not have access to Dynix.) If you want to follow up on that, please note that SCO's Dynix/Linux comparison tables talk about Linux 2.4.1-01, which is actually a patc h from IBM on top of Linux 2.4.1 that implements the RCU stuff. Sequent's patent 5,442,758 from 1995 is available at the USPTO.

There are two issues here: First, SCO claims that IBM violated SCO's intellectual property by publishing (in this case) the read-copy-update code taken mostly from Dynix. Second, SCO claims that the distributed official Linux kernels still have that Dynix code. The first issue is just a quarrel between SCO and IBM, and need not concern anybody else. The second issue concerns everybody, because SCO claims that the official kernel is contaminated by illegal code.

Of course, IBM's original read-copy-update code did not go into the official kernels without serious modifications. That may make a case that this is no longer derived work as defined by copyright law.

Table A
As an example, here's a central structure from IBM's rclock.h. This structure is used to register callbacks with the RCU framework, i.e. functions that are to be called at some later time. (The botched formatting is due to the Groklaw comment software.)

struct rc_callback {
       rc_callback_t *next;
      
rc_callback_func_t callback;
       void            *arg1;
       void          
 *arg2;
       char            flags;   /* flags, see below. 
*/
};
Here's the structure with the same purpose from Linux 2.6.2:
struct rcu_head {
        struct list_head list;
        void
(*func)(void *obj);
        void *arg;
};
That structure is at least on first sight different from IBM's patch. The detailed differences are: The name was changed from rc_callback to rcu_head, standard Linux list handling was used instead of do-it-yourself linear lists. The function to be invoked gets one argument only. The type of the function pointer is spelt explicitly, not hidden behind a typedef.

The kmemdef.h and kmemdef.c files I can't find at all in Linux 2.6.2.

Table B
Linux 2.6.2 does not have the changes to arch/i386/kernel/apic.c, kernel/timer.c, arch/i386/kernel/entry.S, arch/i386/kernel/traps.c. It does have a change to init/main.c which is similar in spirit to the change in IBM's patch.

Table C
This table gets more interesting, because it actually has references to Linux 2.6.0.

include/linux/rcupdate.h: Lines 131-132 is one (!) function declaration (out of several):

extern void FASTCALL(call_rcu(struct rcu_head *head, 
  
                       void (*func)(void *arg), void *arg));
Table A claims that Dynix' kernel/sys/rclock.h referred here and the rclock.h in IBM's patch is copied fully and verbatim. So I was expecting to find something similar in IBM's patch. However, I can't find even a rough equivalent in IBM's patch, except probably rc_callback_wrapper().

kernel/rcupdate.c: Contains the implementation of the call_rcu() function. About half of the lines is a comment. The semantics of the other half map to rc_alloc_callback() and rc_callback(), but the actual code is as different as is conceivable while still maintaining "register a callback" semantics.

kernel/rcupdate.h: Lines 75-85 contain some comparison inline functions named rcu_batch_xxx() for potentially-wrapping counters. Again under the assumption that rclock.h in IBM's patch is a verbatim copy from Dynix as per table A, I find RC_GEN_xx macros that perform this task. Again, this is as different as is conceivable under the circumstances.

I'm getting tired, so do the rest of table C yourself. One of the conclusions to draw from this comparison: Obviously, IBM's patch is not equal to RCU in 2.6.0 (see above), thus assuming Dynix is equal to IBM's patch, it follows that RCU in 2.6.0 is not equal to Dynix. So SCO's claims towards 2.6.0 are at least questionable on text comparison grounds only, not even considering their funny "legal theory".

Table D
These are mostly one-liners for memory barriers. This is needed for synchronizing the memory accesses of multiple processors and is in no way specific to RCU. Of note is include/asm-i386/system.h, the lines referenced point to a large comment and one #define that makes a memory access synchronization function a no-op. The comment is completely different from a comment for a remotely similar function in rclock.h of IBM's patch. However, the comment in Linux' system.h refers to a memory_barrier() function that does not exist in Linux, so I suspect that (part of) that comment were taken from somewhere else.

Table E
That table contains a bunch of places where Linux uses the RCU mechanism. Nothing spectacular here.

My conclusion: The RCU implementation in current Linux 2.6.0 is sufficiently different from IBM's patch (which is allegedly mostly identical to Dynix) that there remains virtually no verbatim Dynix code in Linux 2.6.0. (Regarding JFS or XFS, only a small fraction of Linux installations use this, so damages that SCO may claim cannot be high.)

Jens Maurer

[ Reply to This | # ]

What's missing?
Authored by: DMF on Wednesday, February 18 2004 @ 05:05 PM EST
Maybe I'm being naive here, but there seems to be an awful shortage of specifics
in this document. Okay, the code snippets give them something to argue about,
but the meat of that argument has to be derived from other primary data
presented at discovery.
But there is next to NO primary data in this document. A bunch of arguement
and excuses, yes, but very little data. In a couple of places they've basically
said, "Since we can't supply *all* the data you want, we'll supply none
it."
<sigh>

[ Reply to This | # ]

If I were an IBM lawyer...
Authored by: Anonymous on Wednesday, February 18 2004 @ 07:57 PM EST
If I were an IBM lawyer, I would steadfastly pressure SCOG to identify with
specificity all occurrences of AT&T source files being copied into Linux
distributions. Ignore IBM’s own source files.

Why? This would defeat SCOG’s plan with a truth any jury could comprehend.

All of SCOG's public behavior both inside and out of court has been a
diversion. I would not label it a smokescreen; it is far more complex, like the

shell game with a pea or Three Card Monte, and intended to divert you from
taking the optimum action. I doubt that SCOG intentionally says anything
useful in public or in court, but IBM can force the truth from SCOG.

Simply do what is best for the business of software and march forward
ignoring Daryl’s antagonistic posing.

Prove for the legal record that:
1) SCOG knows there is NO AT&T source code in Linux.
2) the secret, private deal among USL, BSDi, and Novell has been obviated by
subsequent events like the free licensing of V32 and all earlier versions by
Cadera. It is no longer necessary.
3) SCOG has been deliberately misrepresenting API files, freely distributed
and updated since the mid-1980s, as part of the hardware ABI.
4) SCOG has no trademark in UNIX, trade secrets in AT&T UNIX, or patents in

AT&T UNIX. None.
5) SCOG has very limited copyrights in AT&T System III because AT&T
previously gave up many copyrights, Novell retains all remaining System V
copyrights, and Caldera permanently, freely licensed V32 and earlier versions.
So, little remains.
6) SCOG has no contractual rights, based on the UNIX licenses, to
independently developed software like file systems or virtual memory
management systems. UNIX licensees are free to go it alone.
7) No single organization could own all the intellectual property rights
existent in any of UNIX’s many versions.

Daryl is going down, so look beyond his reign of terror. Look forward to
Microsoft and the traditional UNIX cabal who are guarding their turf. They
won their turf in hard fought battles but now must change in order to
compete. Change is incompatible with protecting turf.

The open software community is thriving because more and more people
notice their predictable, repeatable project successes. Also, more people trust

that these projects truly respect intellectual property rights because of their

open procedures. Educators, students, engineers, scientists, system admins,
network admins, CIOs, CEOs, and more choose OSS because it is right for
them.

The SCOG is part of history. Continue taking the right legal actions to pave
the road ahead from cooperation to commerce in a global information
society. No group would long prosper that deemed it prudent to hoard its IP
in isolation. The relentless pressure of competition combined with
dynamically changing technology favors sharing over hoarding, doesn’t it?

[ Reply to This | # ]

OCR typo "urnmount" should be "unmount"
Authored by: Anonymous on Wednesday, February 18 2004 @ 09:15 PM EST
fs/jfs/jfs_urnount.c should probably be unmount.c Looks like the OCR software
barfed on that

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