SCO's file list on page 4-6 of their non-response is as follows. A number of themes show up repeatedly in these files. Many files were selected simply because the term "IBM" appears somewhere inside them, for example mentions of IBM's creation of the IBM PC hardware platform twenty years ago. SCO claims to own code whose only purpose is to run IBM hardware or hardware unique to a company other than SCO or its predecessor. SCO claims to "own" techniques that have been used throughout the industry for years before Linux, or even Unix, existed. SCO claims to own IP that's actually the property of Intel, and was contributed to Linux directly by Intel.

SCO's entire list appears to have been generated by a text search; this reviewer can't see how some files (especially many of the smaller "header" files) could have been identified in any other fashion. In several instances, SCO is effectively claiming to own a lack of support for things, by indicating files that only mention the technologies they dispute in comments noting that something isn't implemented yet, or won't work for certain uses.

arch/i386/kernel/i8259.c
arch/i386/kernel/timers/timer_tsc.c
arch/i386/mach-default/topology.c
arch/i386/mach-pc9800/topology.c
arch/i386/mm/discontig.c
arch/ia64/kernel/perfmon.c
arch/ppc64/kernel/htab.c
arch/ppc64/kernel/ioctl32.c
arch/ppc64/kernel/iseries_irq.c
arch/ppc64/kernel/iseries_setup.c
arch/ppc64/kernel/ppc_ksyms.c
arch/ppc64/kernel/prom.c
arch/ppc64/kernel/pseries_htab.c
arch/ppc64/kernel/setup.c
arch/ppc64/kernel/signal32.c
arch/ppc64/kernel/smp.c
arch/ppc64/kernel/sys_ppc32.c
arch/ppc64/kernel/time.c
arch/ppc64/kernel/xics.c
arch/ppc64/mm/init.c
arch/ppc64/mm/numa.c
arch/ppc/platforms/4xx/oak_setup.c
arch/ppc/platforms/4xx/sycamore.c
arch/ppc/platforms/4xx/walnut.c
arch/ppc/platforms/ev64260_setup.c
arch/ppc/platforms/pmac_pic.c
arch/ppc/platforms/sandpoint_setup.c
arch/ppc/syslib/prom_init.c
arch/s390/kernel/compat_linux.c
arch/s390/kernel/compat_signal.c
arch/x86_64/kernel/e820.c
arch/x86_64/kernel/traps.c
fs/cifs/cifssmb.c
fs/compat.c
fs/jfs/acl.c
fs/jfs/endian24.h
fs/jfs/file.c
fs/jfs/inode.c
fs/jfs/jfs_acl.h
fs/jfs/jfs_btree.h
fs/jfs/jfs_debug.c
fs/jfs/jfs_debug.h
fs/jfs/jfs_defragfs.h
fs/jfs/jfs_dinode.h
fs/jfs/jfs_dmap.c
fs/jfs/jfs_dmap.h
fs/jfs/jfs_dtree.c
fs/jfs/jfs_extent.c
fs/jfs/jfs_extent.h
fs/jfs/jfs_filsys.h
fs/jfs/jfs_imap.c
fs/jfs/jfs_incore.h
fs/jfs/jfs_inode.c
fs/jfs/jfs_lock.h
fs/jfs/jfs_logmgr.c
fs/jfs/jfs_metapage.c
fs/jfs/jfs_metapage.h
fs/jfs/jfs_mount.c
fs/jfs/jfs_superblock.h
fs/jfs/jfs_txnmgr.c
fs/jfs/jfs_txnmgr.h
fs/jfs/jfs_types.h
fs/jfs/jfs_umount.c
fs/jfs/jfs_unicode.c
fs/jfs/jfs_unicode.h
fs/jfs/jfs_uniupr.c
fs/jfs/jfs_xattr.h
fs/jfs/jfs_xtree.c
fs/jfs/jfs_xtree.h
fs/jfs/namei.c
fs/jfs/resize.c
fs/jfs/super.c
fs/jfs/xattr.c
include/asm-i386/mach-numaq/mach_mpparse.h
include/asm-i386/mach-summit/mach_mpparse.h
include/asm-i386/mmzone.h
include/asm-i386/mpspec.h
include/asm-ppc64/mmu.h
include/asm-ppc64/mmzone.h
include/asm-ppc64/paca.h
include/asm-ppc64/ppcdebug.h
include/asm-s390/thread_info.h
include/linux/ibmtr.h
include/linux/rcupdate.h
ipc/util.h
kernel/compat.c
kernel/pid.c
kernel/rcupdate.c
arch/i386/kernel/dmi_scan.c
arch/i386/kernel/mca.c
arch/i386/kernel/setup.c
arch/i386/kernel/traps.c
arch/s390/kernel/process.c
arch/s390/kernel/ptrace.c
arch/s390/kernel/setup.c
arch/s390/kernel/signal.c
arch/s390/kernel/smp.c
arch/s390/kernel/sys_s390.c
arch/s390/kernel/time.c
arch/s390/kernel/traps.c
arch/s390/lib/delay.c
arch/s390/mm/fault.c
arch/s390/mm/init.c
fs/namei.c
include/asm-s390/atomic.h
include/asm-s390/bitops.h
include/asm-s390/lowcore.h
include/asm-s390/sigp.h
include/asm-s390/smp.h
ipc/util.c
kernel/module.c

Some of these files were present in the (uncontested) 2.2 kernel.

SCO has publicly acknowledged that the 2.2 kernel line was free of their IP. According to the file dates on www.kernel.org, the last version of the 2.2 linux kernel issued, before the release of 2.3.0, was 2.2.15. SCO does not currently seem to be claiming that any version of 2.2 infringes upon its IP, (or, for that matter, the "unstable" 2.3 series used to develop the "stable" 2.4), but to be extremely conservative I'm using an older version.

The following files from SCO's list were present in the 2.2.15 kernel, and thus versions of these files predate SCO's alleged infringement. Given the existence of known non-contested versions, it is inexcusable for SCO to fail to identify what specific code segments of what specific versions of these files it objects to.

arch/i386/kernel/mca.c
arch/i386/kernel/setup.c
arch/i386/kernel/traps.c
arch/s390/kernel/process.c
arch/s390/kernel/ptrace.c
arch/s390/kernel/setup.c
arch/s390/kernel/signal.c
arch/s390/kernel/smp.c
arch/s390/kernel/sys_s390.c
arch/s390/kernel/time.c
arch/s390/kernel/traps.c
arch/s390/lib/delay.c
arch/s390/mm/fault.c
arch/s390/mm/init.c
fs/namei.c
include/asm-s390/atomic.h
include/asm-s390/bitops.h
include/asm-s390/lowcore.h
include/asm-s390/sigp.h
include/asm-s390/smp.h
ipc/util.c
kernel/module.c

Some files are specific to hardware IBM designed and manufactured.

SCO is literally claiming that IBM, a company that manufactures and designs its own hardware platforms, cannot program those hardware platforms without support from SCO, a company that has never designed or manufactured any hardware. The following files are specific to IBM hardware:

arch/ppc64/kernel/htab.c
arch/ppc64/kernel/ioctl32.c
arch/ppc64/kernel/iseries_irq.c
arch/ppc64/kernel/iseries_setup.c
arch/ppc64/kernel/ppc_ksyms.c
arch/ppc64/kernel/prom.c
arch/ppc64/kernel/pseries_htab.c
arch/ppc64/kernel/setup.c
arch/ppc64/kernel/signal32.c
arch/ppc64/kernel/smp.c
arch/ppc64/kernel/sys_ppc32.c
arch/ppc64/kernel/time.c
arch/ppc64/kernel/xics.c
arch/ppc64/mm/init.c
arch/ppc64/mm/numa.c
arch/ppc/platforms/4xx/oak_setup.c
arch/ppc/platforms/4xx/sycamore.c
arch/ppc/platforms/4xx/walnut.c
arch/ppc/platforms/ev64260_setup.c
arch/ppc/platforms/pmac_pic.c
arch/ppc/platforms/sandpoint_setup.c
arch/ppc/syslib/prom_init.c
include/asm-ppc64/mmu.h
include/asm-ppc64/mmzone.h
include/asm-ppc64/paca.h
include/asm-ppc64/ppcdebug.h
include/asm-s390/thread_info.h

IBM designs and manufactures its own microprocessors, based on technologies like RISC which were invented at IBM. IBM's POWER line (Performance Optimized With Enhanced Risc) was one of the first commercial RISC implementations, and was a precursor to the Power PC systems that IBM designed in partnership with Apple and Motorola. (Power PC processors are at the heart of modern Macintosh systems, as well as being used extensively in IBM's own products.)

More recently, IBM has extended the Power PC design to 64 bits. Now that Motorola has exited the microprocessor business (to focus on cell phones and other electronic devices), IBM is Apple's primary supplier for the Power PC processors in Macintosh systems. (IBM is to Apple what Intel is to Dell.)

IBM also produces S390 mainframe systems, which are a backwards-compatable successor to the older S360 mainframes, which in turn trace their lineage back many decades. Modern S390 systems can still run software written for IBM's "VM" systems from the 1960's, which predate the invention of UNIX.

SCO is not even a "white box" manufacturer assembling third party components into finished systems. SCO has emphasized its history of selling software exclusively for hardware designed by Intel. SCO's expertise with non-Intel hardware is nonexistent.

By including files in its list which are specific to three different hardware platforms designed and manufactured by IBM, SCO is literally claiming that IBM cannot program hardware that IBM itself designed, without assistance from SCO.

SCO claims to own IBM's Journaling FileSystem (JFS).

fs/jfs/acl.c
fs/jfs/endian24.h
fs/jfs/file.c
fs/jfs/inode.c
fs/jfs/jfs_acl.h
fs/jfs/jfs_btree.h
fs/jfs/jfs_debug.c
fs/jfs/jfs_debug.h
fs/jfs/jfs_defragfs.h
fs/jfs/jfs_dinode.h
fs/jfs/jfs_dmap.c
fs/jfs/jfs_dmap.h
fs/jfs/jfs_dtree.c
fs/jfs/jfs_extent.c
fs/jfs/jfs_extent.h
fs/jfs/jfs_filsys.h
fs/jfs/jfs_imap.c
fs/jfs/jfs_incore.h
fs/jfs/jfs_inode.c
fs/jfs/jfs_lock.h
fs/jfs/jfs_logmgr.c
fs/jfs/jfs_metapage.c
fs/jfs/jfs_metapage.h
fs/jfs/jfs_mount.c
fs/jfs/jfs_superblock.h
fs/jfs/jfs_txnmgr.c
fs/jfs/jfs_txnmgr.h
fs/jfs/jfs_types.h
fs/jfs/jfs_umount.c
fs/jfs/jfs_unicode.c
fs/jfs/jfs_unicode.h
fs/jfs/jfs_uniupr.c
fs/jfs/jfs_xattr.h
fs/jfs/jfs_xtree.c
fs/jfs/jfs_xtree.h
fs/jfs/namei.c
fs/jfs/resize.c
fs/jfs/super.c
fs/jfs/xattr.c

SCO is claiming to own IBM's JFS filesystem. The version of JFS that IBM contributed to Linux came from IBM's OS/2 operating system. This was not only IBM's public explanation for the source of the code at the time it was contributed, but it is extensively supported by examination of the code itself.

Searching all the files in the fs/jfs directory of Linux 2.5.69 for the string "AIX" produces exactly one result: jfs_filesys.h, line 33, which defines a constant by which a JFS filesystem originating on AIX may be identified (presumably on the off chance this code is ever used to access a JFS filesystem coming from an AIX system). This AIX constant is never actually used in the rest of the JFS code. (Its definition is more or less documentation as to why that value was skipped.) This definition is the only mention of AIX in the entire fs/jfs directory. Meanwhile, the corresponding OS/2 constant (defined on line 36) is used elsewhere in the code approximately a dozen times to identify OS/2 filesystems and maintain compatibility with them. But that constant is by no means the only mention of OS/2 in the code.

Searching the fs/jfs files for the string "OS/2" or "OS2" produces over 60 hits, many of which illustrate the code's OS/2 roots. The comment in jfs_dinode.h (lines 80-82) explains "We would probably be better off redesigning the entire structure from scratch, but we don't want to break commonality with OS/2's JFS at this time." A comment in jfs_dmap.c (lines 619-622) says "We try to avoid having more than one open file growing in an allocation group, as this will lead to fragmentation. This differs from the old OS/2 method of trying to keep empty ags around for large allocations." jfs_dtree.c line 3077 defines a "Legacy filesystem" as either one originating from OS/2 or else from the Linux version JFS versions 0.3.6 and earlier (which had an identical on-disk format). Comments in the diRead and diWrite functions of jfs_imap.c (lines 387 and 658) mark some OS/2 compatability code to do with the layout of inodes. The comment on lines 444-445 of jfs_mount.c shows where the Linux JFS code blanks some bookkeeping fields that Linux doesn't care about, so OS/2 knows to recalculate them if the same JFS filesystem is later used under OS/2. The file jfs_superblock.h lines 92-93 note that a field "must be 11 bytes to conform with the OS/2 BootSector requirements". Line 372 of namei.c notes another piece of code inserted solely for compatability with OS/2.

Entire pieces of JFS infrastructure SCO cites illustrate the difference between the AIX and OS/2 implementations of JFS. The file xattr.c is dedicated to support for OS/2 extended attributes, which is something the AIX version of JFS simply does not have. AIX does not have support for extended attributes in any of its filesystems, whereas OS/2 requires such support in all its filesystems. The string "AIX" does not appear once in this file, while the strings OS/2 or OS2 appear over thirty times.

(Extended attributes are a desktop concept, primarily used to attach display information such as icon positioning to files. The Macintosh "resource fork" is the most prominent example. Windows NT uses the system registry for this purpose, although NTFS does support extended attributes. Traditional unix systems do not support extended attributes; Unix desktop applications store their display information in normal files with an ".rc" extension, or ask another program (the X11 server) to remember display information for them.)

The corresponding header file, jfs_xattr.h, explicitly states (line 25), "I am maintaining compatibility with OS/2 where possible." No mention is made of AIX in this file either.

It's interesting to note that SCO claims to have found infringement in the file jfs_acl.h, which contains nothing but function declarations (no algorithms or data structures, just "glue" letting one file know how to use parts of another), and jfs_extent.h (five function declarations, and one macro definition).

Similarly, the file endian24.h contains a half-dozen macro definitions that swap the order of bytes so that processors which naturally deal with bytes in a different order (Intel and Power PC, for example) can use each other's on-disk data formats. Byte swapping is a trival computer science procedure that a high school student can be expected to figure out how to do from first principles. Apple gives a good description of byte swapping (with diagrams) on its website.

Being able to control byte order is a fundamental part of doing device independent I/O. Some machines such as Macintoshes are "big endian" (with the big end, or most significant byte, stored first), and other machines such as Intel's x86 processors are "little endian", storing the bytes in reverse order. Techniques for converting between these representations so these machines can communicate with each other predates the invention of Unix.

Dealing with endianness issues is a common homework assignment for programming students. A few random Google results:

http://www.stedwards.edu/science/cassandra/courses/cosc3331/hw-spring2003/hw02.html
http://ccrma-www.stanford.edu/CCRMA/Courses/422/homework/hw4/endian/
http://www.cs.uwm.edu/classes/cs654/handouts/homework9.html
http://www.cs.utexas.edu/users/chris/cs310/f2003/hmwkFAQ/hw4FAQ.html
http://ece-www.colorado.edu/~ecen4593/Homework/Homework11.html

Older versions of Linux did byte order converstions back before kernel 1.0. The internet RFC standards documents (such as RFC 1071, section 2b) often mention the need to do byte swapping in passing, assuming that the reader will already know how. Conversions routines between little-endian and big-endian numbers are commonly collected into a header file called "endian.h" in many projects. A quick google search finds http://www.digitalcinemaarts.com/dev/file_out/docs/endian_8h.html documenting one such routine (this documentation has byte-swapping sample code), a byte-swapping header from the University of Utah at http://www.csafe.utah.edu/Information/Documentation/UCF/Endian_8h-source.html and a bsd header file implementing byte-swapping at http://www.openmash.org/lxr/source/misc/bsd-endian.h.

I could go on ad nauseam. It is _inexcusable_ of SCO to try to claim ownership of something this obvious. It predates _UNIX_.

SCO's list names all but five of the files in the fs/jfs directory. It may be more interesting to examine why the files jfs_dtree.h, jfs_imap.h, jfs_inode.h, jfs_logmgr.h, and symlink.c were not mentioned.

arch/i386/kernel/i8259.c

This programs the Intel 8259A programmable Interrupt controller, a chip present in the original IBM AT twenty years ago and still present in some modern systems because it's cheap, generic, and standardized. More modern systems use an Advanced Programmable Interrupt Controller (APIC) instead. (See the comments around line 80.) Note: an APIC is required to route interrupts in an SMP system. The 8259A is an ancient chip which does not have the concept of routing interrupts to more than one CPU.

The basic functionality of this file derived from arch/i386/kernel/irq.c in linux kernel 2.2.15. This includes the functions disable_8259A_irq, enable_8259A_irq, i8259A_irq_pending, mask_and_ack_8259A, math_error_irq, init_ISA_irqs. The function make_8259A_irq is identical.

The 2.5.68 function init_IRQ is smaller than the 2.2.15 init_IRQ, in part because some functionality was split out into separate functions. For example, the 2.5.68 function setup_timer implements functionality that could previously be found in 2.2.15's init_IRQ starting at line 1123. Similarly, the function "init_8259A" replaced the old "enable_8259A_irq". Other new functions include i8259A_irq_real, i8259A_resume (for power management), timer_resume, and some data structures for the linux "device fs" which SCO does not have.

Simple identification of the file is by no means enough to pinpoint a "part of which include information (including methods) that IBM was required to maintain as confidential or proprietary pursuant to contract with SCO and/or which constitute trade secrets misused by IBM", which SCO claims it found within Linux (at the top of page 3).

Why any of the contents of this file would be considered a trade secret by anyone is still an open question. The i8259A is a twenty year old interrupt controller chip that was designed and manufactured by Intel, sold retail to all comers, and has been extensively documented by Intel. (The Massachusets Institute of Technology has a copy of the 8259A datasheet in PDF format at http://www.mit.edu/afs/sipb.mit.edu/contrib/doc/specs/ic/misc/8259A_PIC_Datasheet.pdf). SCO is claiming the knowledge of how to use Intel's public documentation as SCO's trade secret.

arch/i386/kernel/timers/timer_tsc.c

This file is devoted to controlling the step counter, which is a timing function built into modern "Pentium" style processors. The information on how to interact with this piece of hardware comes from the hardware manufacturer, Intel. It is possible that code segments supplied directly by Intel were incorporated verbatim into SCO's UnixWare, but that doesn't mean SCO can tell Intel not to give those code segments to others.

The 2.5.68 version of this file starts with a comment:

/*
 * This code largely moved from arch/i386/kernel/time.c.
 * See comments there for proper credits.
 */

And this can easily be seen by comparing with the appropriate file from 2.2.15. For example, the 2.5.68 function calibrate_tsc contains only two lines (199 and 207) which did not appear verbatim in the 2.2.15 time.c file (which can be found at line 550 in time.c). Those two new lines represent sections of code in the old file that were moved into separate functions for the sake of clarity and to avoid redundancy.

Similarly, the 2.5.68 function init_tsc (starting at line 305) shares large portions with the 2.2.15 function time_init (starting at 609). (Match old line 621 and new line 300, continue for 26 lines discounting indentation. Match old line 650 with new line 333, continue for eight lines. The only difference between the asm statement at old 669 and the asm statement at new 346 was the conversion from hertz to megahertz -- I.E. the clock frequency increased.)

This file contains significant quantities of material that SCO claims not to be objecting to. They have not identified the specific material to which they are objecting. If SCO would like to object to something more specific, it should at the very least identify the starting and ending lines of each range of code it objects to. Much of the text in this file is clearly original to the Linux developers, and unchanged from older versions of Linux SCO has recommended users revert to as a remedy against its claims.

Doing some of SCO's work for it, a google search for "IBM Linux tsc" produces the following two pages from IBM's Linux patch archive:

http://www-124.ibm.com/linux/patches/?patch_id=438
http://www-124.ibm.com/linux/patches/?patch_id=694

The second patch is a self-described "minor cleanup", which does things like remove some unused code.

The first is indeed a NUMA patch, but all it does is disable the TSC on Numa systems, to work around a bug. (With the TSC disabled, these systems fall back to the older but less accurate 8259 Programmable Interrupt Timer.) Considering the patch was for linux 2.4.9, this bug has probably been fixed since. Here's the help entry from the patch, explaining the new option it adds:

+CONFIG_X86_TSC_DISABLE
+  This option is used for getting Linux to run on a NUMA multi-node
+  boxes, laptops and other systems suffering from unsynced TSCs or
+  TSC drift, which can cause gettimeofday to return non-monotonic values.
+  Choosing this option will turn off the CONFIG_X86_TSC optimization.
+  Which allows you to then specify "badtsc" as a boot option to force all
+  cpus to use the PIT for gettimeofday.
+
+  Note: This does not disable access to the unsynced TSCs from userspace,
+  thus applications using the rdtsc instruction for timing may have
+  issues. To disable userspace access, instead of "badtsc" use the "notsc"
+  boot option.
+

Once again, SCO seems to be claiming to own the LACK of support for something. In this case, TSC didn't work on NUMA, so IBM conditionally disabled it.

fs/cifs/cifssmb.c

The name "cifssmb" is an acronym for "Common Internet File System" / "Server Message Block", which are names for Microsoft's network filesystem used to export Windows shared directories.

This is not a technology SCO owns. CIFS/SMB was designed by Microsoft, as an extension of IBM's earlier "NetBIOS/NetBUI" technology used under DOS. It is not a traditional Unix technology.

The piece of Linux software most commonly associated with SMB networking is the "Samba" package from www.samba.org. Samba is a piece of GPL-licensed application software which allows a non-Windows server to share its files through the network with Windows clients. Linux is free to incorporate code from Samba, because the two programs are distributed under the same license. (There is also explicit cooperation between the Samba and Linux kernel projects, with some developers contributing to both projects.)

Despite SCO's condemnation of the GPL as an "IP-destroying" license, SCO continues to ship the Samba suite with its proprietary Unix operating systems. Without the open source GPL-licensed Samba technology, neither SCO UnixWare nor SCO OpenUnix could act as a file server for Windows clients. (Note that SCO has been explicitly questioned about its continued distribution of Samba, and has found no problem with it as of November 2003. SCO's complaints about the GPL seem to only occur when the license is applied to Linux, not when it is applied to other software SCO still wishes to benefit from.)

The cifssmb.c file in Linux implements an SMB "client" filesystem, which allows a Linux workstation to use files on an SMB server out on the network, such as a Windows server or a Linux or Unix system running Samba. (The client code in cifssmb.c does not allow the Linux system to act as a CIFS/SMB server; that's Samba's job.)

SCO would appear to lack any in-house SMB server technology -- despite their professed distaste for the license, they still ship Samba because they need it. Therefore, if SCO's own operating systems are capable of acting as a client for SMB shares, it is quite likely that they are using code from one of these two GPL-licensed sources (Samba or Linux). (Note that they appear to have an older technology for mounting Windows shares called "visionfs", introduced in 1996. See http://www.profprog.com/vfsintro.pdf for details. This was part of a larger Unix compatability product called SCO Vision2k, http://www.tarantella.com/products/vision/evaluate/docs/user/v2kcdins.pdf now discontinued. In 1996, SCO was already under heavy attack from Windows.)

SCO is attributing to IBM code developed by others (such as AMD and partner SuSE).

SCO's mindless text search came up with the files arch/x86_64/kernel/e820.c and arch/x86_64/kernel/traps.c, which they obviously never bothered to read, and do not seem to understand.

The x86-64 architecture is AMD's new 64-bit processor (marketed as Opteron). AMD first publicly released specifications and a simulator to the Linux development Community at LinuxWorld Expo in the summer of 2000. (See http://www.fool.com/portfolios/rulemaker/2000/rulemaker000818.htm .) For the past few years, AMD has paid Linux vendor SuSE to develop and optimize x86-64 versions of Linux. Suse's August 2000 press release on its partnership with AMD is available at http://www.suse.de/en/company/press/press_releases/archive00/AMD.html

Once again, SCO is complaining that the company that designs and manufactures a piece of hardware is contributing support for that hardware directly to Linux, and somehow it's IBM's fault.

Although both of these files contain the word "IBM", in neither cases does it indicate participation by the company IBM. This fact would have been obvious if SCO had bothered to read the files its text search turned up.

The file e820.c is another file that looks at the BIOS ROM to discover information about the hardware Linux is running on, in this case looking for the layout of memory. The comment block from lines 434-439 mentions a model of laptop manufactured by IBM:

 * We check to see that the memory map contains at least 2 elements
 * before we'll use it, because the detection code in setup.S may
 * not be perfect and most every PC known to man has two memory
 * regions: one from 0 to 640k, and one from 1mb up.  (The IBM
 * thinkpad 560x, for example, does not cooperate with the memory
 * detection code.)

This is the only mention of IBM in the file: a laptop manufactured by IBM is one example of a system which will not work with this code). SCO either never actually looked at this file, or else they didn't understand it. I'm not sure which would be worse.

The other file identified in this directory, arch/x86_64/kernel/traps.c, describes itself (in the comment on line 14) as code that "handles hardware traps and faults", which are actions that interrupt a running program. This file contains copyright notices from Linus Torvalds, and employees of SuSE and VA Linux, but not from IBM. The only mention of IBM in this file is in the comment on lines 770-771:

 * Careful.. There are problems with IBM-designed IRQ13 behaviour.
 * Don't touch unless you *really* know how it works.

The "IBM-designed" here refers to the interrupt handling in the original IBM PC and IBM AT from the early 1980's, from which all modern PC systems are descended. This comment is not implying any participation by IBM more recent than twenty years ago.

SCO is claiming the unique ability to program hardware it didn't design.

The file arch/ia64/kernel/perfmon.c starts with the following comment:

 * This file implements the perfmon subsystem which is used
 * to program the IA-64 Performance Monitoring Unit (PMU).
 *
 * Originaly Written by Ganesh Venkitachalam, IBM Corp.
 * Copyright (C) 1999 Ganesh Venkitachalam 
 *
 * Modifications by Stephane Eranian, Hewlett-Packard Co.
 * Modifications by David Mosberger-Tang, Hewlett-Packard Co.
 *
 * Copyright (C) 1999-2003  Hewlett Packard Co
 *               Stephane Eranian 
 *               David Mosberger-Tang 

Let's go through in order. The purpose of the file is to use a piece of hardware, the Performance Monitoring Unit of the IA-64. The IA-64 processor was designed by Hewlett Packard, in partnership with Intel. Although this file was started by an IBM engineer in 1999, it has since been modified by two different Hewlett Packard engineers.

The Performance Monitoring Unit is a publicly documented part of the IA-64 hardware design, which SCO did not invent, manufacture, or indeed contribute to in any way. SCO is not a hardware company. SCO has never posessed any information about the IA-64 hardware that IBM could not have more easily gotten from the hardware's actual designers (HP and Intel), and engineers from the company that designed the hardware (HP) have taken over maintenance of this file since IBM lost interest in IA-64 platform (see http://www.computerworld.com/softwaretopics/os/linux/story/0,10801,78460,00.html )due to the total failure of IA-64 to gain any market momentum in the five years since its introduction (see http://www.theinquirer.net/?article=7983 ).

For more information on this, see the history and wealth of links in Appendix D of The Halloween 9 document, The Itanic Disaster.

SCO is once again continuing its trend of claiming to own Intel's intellectual property, in this case claiming IP which is jointly owned by Hewlett Packard. There is no hardware design owned by SCO.

SCO is claiming to own the concept of NUMA

Non-Uniform Memory Access (NUMA) is a way of building larger multi-processor systems than SMP (Symmetrical Multi-Processing) allows.

Processors operating at 1 gigahertz update one billion times per second, meaning that each cycle lasts one nanosecond, in which time light travels 11 centimeters. Therefore, signals that must make a round trip of more than 11 centimeters physically cannot be tightly coupled to a gigahertz processor, due to the speed of light and the laws of physics. This is a significant limitation on the scalability of SMP systems: the components must be placed very close together or the travel time for signals becomes significant at high clock speeds.

When a system becomes physically larger than SMP can handle, the speed of light's effect on the travel time of signals to and from memory becomes signifcant. Efficiently programming such a large "non-uniform memory access" system involves teaching the operating system that some memory is closer to a given processor (and can be accessed without a significant delay), and that other memory is farther away (requiring many cycles of travel time to fetch data from). Programs running on a given processor should have their data stored in fast local memory (physically near that processor), and try to minimize any access to more distant memory, to avoid the associated delay.

Programming a NUMA system complicates memory allocation decisions, because each processor (or group of processors) has a different view of the system's memory. Some memory is fast and local, some memory is distant and slow. This is different from SMP systems, where all memory lives at an equal distance from every processor, and memory allocation decisions are a simple question of finding available space without having to weigh how much any section of memory costs to access.

A lot of research has been done into how to efficiently program NUMA systems, and the important thing to realise about this is that NUMA is type of hardware. The problems involved with programming it are dictated by the nature of the hardware, and the laws of physics. Solving those problems is a fairly straightforward research problem for hardware and software engineers who have access to this hardware: test how a given program performs on the hardware, find bottlenecks, theorize, implement a solution, and repeat.

Sequent has been working with NUMA hardware for twenty years, and IBM had some in-house expertise with the speed of light's limiting effect on signal propogation before purchasing Sequent. Many other hardware companies, including SGI (which bought Cray) and HP (which, through its acquisition of Compaq, now owns what is left of Digital Equipment Corporation), have experience with NUMA systems. All of these companies have contributed their expertise to Linux.

SCO however, is not a hardware manufacturer. What expertise it once had lay in programming cheap low-end PC systems, hardly unique today. SCO has never designed, manufactured, or shipped NUMA hardware, and the current SCO/Caldera entity has no experience whatsoever with NUMA systems. SCO's entire understanding of NUMA seems to be limited to the belief that it's a bigger kind of SMP.

Some of the files SCO is objecting to are straightforward infrastructure, implementing obvious techniques. For example, the file arch/i386/mm/discontig.c (written by Patricia Gaughen with additional code by Martin J. Bligh) implements support for "discontiguous memory". This is support for "holes" in the system's memory, so that all the various memory chips in the system do not have to be installed at consecutive addresses. This is useful on NUMA systems (hence both IBM and SCO's interest), but less generic implementations of the technique have been available on Linux for many years. The ability to skip chunks of address space that don't have usable memory installed in them is useful on some normal PC systems that simply do not have all their memory installed in a single large chunk. For example, the gap between 640k and 1 megabyte is often skipped due to way modern PC hardware was designed around the limitations of old DOS systems, and the Windows systems that evolved from them. This gap used to be handled in an ad-hoc way (see the 2.2.15 file arch/i386/mm/ioremap.c), but the discontiguous memory infrastructure provides a more general mechanism to support this kind of memory hole.

Another concern addressed by this infrastructure is support for "bad RAM" (in which some memory locations do not reliably store information, but the majority of the chip works fine). Earlier approaches to address this problem were proposed years ago, for an example see the July 2000 patch submission at "http://www.ussg.iu.edu/hypermail/linux/kernel/0006.0/0180.html". With the discontiguous memory patch, the system can simply be instructed not to use the bad locations, by adding a hole. It is a more generic solution to a range of problems.

The discontiguous memory patch is original development by IBM employees, and duplicates functionality offered to the linux kernel by independent developers years ago. Archaeologically, Patricia Gaughen's first public submission of the material (which was part of the Linux Scalability Effort on Sourceforge at the time) seems to be in this posting: http://lwn.net/2002/0502/a/discontigmem.php3

SCO's failure to understand NUMA is evident in their file selection. The file include/asm-i386/mach-numaq/mach_mpparse.h is one of four files in the mach-numaq directory, all of which deal with supporting IBM's NUMA-Q architecture. This particular file is only 42 lines long, and the only thing that stands out about it is lines 30-31:

        if (strncmp(oem, "IBM NUMA", 8))
                printk("Warning!  May not be a NUMA-Q system!\n");

I.E. continuing SCO's penchant for claiming to own the lack of support for things, the code snippet flagged by their text search detects systems that may accidentally have been misidentified as an IBM NUMA-Q system, but aren't really. The other three files in this directory are also specific to IBM's NUMA-Q architecture, and if SCO had the foggiest idea what they actually did it would probably either claim all of them, or none at all.

Similarly, the file include/asm-i386/mach-summit/mach_mpparse.h supports the "summit" architecture, another IBM NUMA system. All three files in this directory exist to support IBM's summit hardware. The unique thing about mach_mpparse.h is that it contains the string "IBM", and the other two do not. If SCO understood the relationship between these files, it would identify all of them, or none of them.

Another file that was apparently singled out due to an explicit IBM copyright notice is include/asm-i386/mmzone.h. This file supports both Summit and NUMA-Q, and according to line 2 was written by Patricia Gaughen of IBM in March 2002. This is recent, independent development, which took place after SCO was purchased by Caldera. Comments like the one by Martin Bligh beginning on line 88 (providing a more generic, alternate implementation for one of the macros and explaining the rationale for using the more specific, faster version) show a deep understanding of the techniques on the part of IBM. They document how they could have done it another way. If this file was ruled to infringe upon someone else's IP, they could clearly write a new (and different) version from scratch without reference to the original. Therefore, why would they need to reference anyone else's IP to write the first one? (Even assuming someone else was capable of writing a version of this file, to support IBM-specific hardware?)

Another file apparently singled out due to the letters "IBM" appearing it it is include/asm-i386/mpspec.h. Line 64 contains a comment that a certain is "/* Used by IBM NUMA-Q to describe node locality */". The file itself is not specific to any IBM product, it is in fact an implementation of an Intel specification, as described by the comment beginning on line 4:

/*
 * Structure definitions for SMP machines following the
 * Intel Multiprocessing Specification 1.1 and 1.4.
 */

Another theme is SCO's tendency to lay claim to Intel's intellectual property. This file is yet another example. Some of IBM's systems, which use Intel processors, understandably conform to Intel's well-documented public specifications. Perhaps SCO's systems also conform to Intel's specifications, but that doesn't mean SCO owns the standard Intel published.

The pair of files arch/i386/mach-default/topology.c and arch/i386/mach-pc9800/topology.c show SCO's continuing failure to understand what the code they're complaining about does. Yes, an IBM copyright notice exists on both files. So what do the files do?

The comment on line 2 of (both copies of) topology.c explains that the file's purpose is to "Populate driverfs with topology information". This means that it figures out how the various processors in the system are connected together, and makes that information available to running programs though a file-like interface. Patrick Mochel's "driverfs" (now renamed "sysfs") is a collection of special files that are synthesized by the operating system to contain information about the running system. Patrick Mochel is not an IBM employee, and this is an original design of his which is not a part of traditional Unix systems.

The file topology.c contains a single function, topology_init, which fills a file in driverfs/sysfs with information about how many processors are in the system and how they are connected together. The file arch/i386/mach-default/topology.c contains two versions of this function, one for NUMA systems (lines 34-54), and a slightly simpler version for non-NUMA systems (lines 55-66).

The file arch/i386/mach-pc9800/topology.c was derived from the mach-default version, as described by the comment added on line 26:

 * Modify for PC-9800 by Osamu Tomita 

This second version is specific to the Japanese PC-9800 hardware, and the ONLY functional difference is that the NUMA code from lines 34-54 has been deleted. The file is otherwise identical, except for changes to the comment at the top.

This second version does not contain any NUMA support. The entire difference between the files is that the second one has had the NUMA support removed, by someone in Japan. The IBM copyright notices at the top are blindly duplicated boilerplate, a fact which would have been obvious if SCO had paid the slightest bit of attention to the contents of the files they were complaining about. Once again, SCO is claiming to own a lack of support for something.

SCO is claiming to own "glue" code.

Some code just doesn't have any significant IP in it. For example, at the top of the file fs/compat.c is a comment describing its contents:

 *  Kernel compatibililty routines for e.g. 32 bit syscall support
 *  on 64 bit kernels.

This is a series of "wrapper" functions. The actual algorithms live in other files, this file just allows them to be called from a different context and translates the results. (In this case, to call some 32-bit functions from a 64-bit context.)

The reason SCO's text search found this file is probably due to the comment on lines 193-194:

/* Never free them really. This avoids SMP races. With a Read-Copy-Update
   enabled kernel we could just use the RCU infrastructure for this. */

The comment notes that the code is lazy and avoids doing something because it's not worth the effort to make it work properly on SMP. (Instead of allocating and freeing certain structures, it re-uses them.) It also notes that in future this might be a good place to use the RCU infrastructure, but they haven't gotten around to it yet.

SCO is once again claiming to own not doing something.

Similarly, the file kernel/compat.c contains more "wrapper" functions for calling existing 32-bit functions from a 64-bit context. The comment that presumably caused SCO's text search to trigger begins on line 155:

        /*
         *      In the SMP world we might just be unlucky and have one of
         *      the times increment as we use it. Since the value is an
         *      atomically safe type this is just fine. Conceptually its
         *      as if the syscall took an instant longer to occur.
         */

SCO selected both of these files because the copyright notice at the top says "Copyright (C) 2002-2003 Stephen Rothwell, IBM Corporation". (In the case of fs/compat.c, there are several other copyright notices, including notices from Red Hat and SuSE.) Perhaps Stephen Rothwell would like to testify that this file was his own original work, and that he never saw the AIX code. SCO is showing a pervasive assumption that IBM is incapable of doing original development work. (SCO is also assuming that the portions it is objecting to were written by IBM, rather than one of the other contributors to the files.)

More IBM Hardware SCO needs to help IBM program

The file include/linux/ibmtr.h describes itself (on line 4) as "Definitions for an IBM Token Ring card". Token Ring is IBM's proprietary networking hardware, which has been rendered obsolete by ethernet. This networking hardware was designed, manufactured, and deployed by IBM. The fact IBM is also capable of programming it without outside help should be obvious to anyone with enough functioning neurons to remain upright.

Is SCO claiming to own anything about Token Ring (which was also covered by a number of IBM patents, which may have expired due to the age of the technology)? IBM designed token ring, IBM manufactured token ring, IBM wrote token ring drivers for a number of other operating systems including DOS, OS/2, several versions of Windows, and VM and AS/400 "big iron" systems. IBM does not need any external help to write a device driver for hardware it invented and manufactured, and SCO would have no expertise in this area to contribute whatsoever.

What, exactly, is SCO claiming about this file? Probably, its text search for the string "SMP" triggered on an entirely unnecessary comment in line 219, which notes that a lock is (obviously) "SMP Protection".

Some files are wholly implementations of IBM patents

Two of the files are patented by IBM. The file kernel/rcupdate.c, and the corresponding header file include/linux/rcupdate.h, implement IBM's patented "Read, Copy, Update" technology (RCU). RCU is a fairly simple technique allowing multi-processor systems to update data structures safely without the use of performance-limiting locking techniques, by performing ordinary read, copy, and update operations in a carefully controlled order. The file rcupdate.c is an infrastructure file, whose sole purpose is to implement helper functions making it easier to use the patented RCU technique.

The Linux Kernel developers originally rejected the inclusion of rcupdate.c due to the existence of IBM's RCU patent, until IBM granted them an explicit patent license. This exchange was recorded in the Linux-Kernel mailing list archives in 2001:

In the first message, Linux kernel developer Andrea Arcangeli from SuSE rejects IBM's submission of RCU to Linux because the technology is covered by US Patent #5442758, as pointed out by Alan Cox of Red Hat.

http://www.cs.helsinki.fi/linux/linux-kernel/2001-36/0393.html

Note that similar patents pertaining to Read-Copy-Update are 5,727,209 (assigned to Sequent) and 6,219,690 (assigned to IBM). The 5,442,758 patent is simply the earliest (August 15, 1995). All of these patents may be found in the uspto database at http://patft.uspto.gov/netahtml/search-bool.html

The second message is from IBM employee Dipankar Sarma stating that IBM owns this patent, having purchased the inventor Sequent, and that IBM legal has reviewed it and approved its release under the GPL.

http://www.cs.helsinki.fi/linux/linux-kernel/2001-36/0394.html

The third message is confirmation from Andrea Arcangeli that copies of an IBM patent grant letter have been received by both Linus Torvalds and by himself.

http://www.cs.helsinki.fi/linux/linux-kernel/2001-36/0505.html

This exchange was public, involving one of SCO's partners in the United Linux Consortium, which SCO (as Caldera) was a founding member of. SCO had no objection to inclusion of technology openly discussed on the main Linux development list (when SCO still listed core business as Linux Development in Securities and Exchange Comission filings of the period), and had no objection to the filing of the RCU patent years earlier, publicly documenting the technology and awarding exclusive rights over it to a company other than SCO.

Note that SCO is not able to use RCU in its own proprietary Unix products without violating IBM's patent. SCO does not own the RCU technology, nor is it licensed to use the patent except through the GPL patent grant mentioned above. Therefore, SCO cannot use RCU in its proprietary Unix products, only in its GPL-licensed Linux products, which it suspended the sale of after filing suit against IBM. Since SCO does not, under any legal theory put forth so far, have the right to use this technology in any product it currently ships or has announced plans to resume shipment of, it is effectively arguing that a competitor's patented technology should be kept off the market entirely.

According to Bill Claybrook, one of the analysts SCO showed its case to, the RCU code was not even originally developed on a System V Unix base, but on a BSD Unix base. The following quote is from http://mozillaquest.com/Linux03/ScoSource-20-CodeReview_Story03.html

DYNIX developed at Sequent years ago was derived from BSD 4.1 with patches from 4.2 and new code by Sequent. DYNIX/ptx, also developed at Sequent was really BSD code with System V wrappers. So the code was really still BSD code, the kernel code that is. It appears then that the NUMA kernel code was developed on the BSD code.

Some files interact with the system BIOS, using code provided by the hardware vendors.

The purpose of the file arch/i386/kernel/dmi_scan.c is to query a system ROM to identify and configure that specific computer's hardware when Linux runs on it. To do so, it uses code snippets provided by the manufacturers of the various hardware (who also wrote the ROM routines being queried). For example, see the comment on lines 205-208 of dmi_scan.c:

/*
 * Reboot options and system auto-detection code provided by
 * Dell Computer Corporation so their systems "just work". :-)
 */

When computers are first powered on, a ROM chip called the Basic Input/Output System (BIOS) provides the initial program responsible for loading and executing the first part of the operating system. Later, the operating system can query the BIOS to identify and configure some of the hardware that is installed in the system.

The BIOS in a system is supplied by the hardware vendor. IBM puts its own BIOS in Thinkpads, DELL provides a BIOS for Inspirons, HP/Compaq provides a BIOS for Presarios, etc. Although these BIOS chips are often based on licensed code (from companies like Phoenix or AMI that specialize in writing BIOS code, or open source groups like the Linux BIOS Project), each BIOS must be customized by the hardware vendor, tailored to the specific hardware it is installed in.

SCO does not write BIOS code, because SCO does not manufacture hardware. This is a great disadvantage to SCO, and previous SCO exectuives have noticed that their persistent failure to achieve any significant market penetration can be attributed to the fact that the vast majority of operating system sales are bundled with a hardware purchase. [link on bundling]

The comment on lines 331-334 reads:

/*
 * The Intel AL440LX mainboard will hang randomly if the local APIC
 * timer is running and the APM BIOS hasn't been disabled.
 */

A similar comment starts at line 432:

/*
 * The Intel 440GX hall of shame.
 *
 * On many (all we have checked) of these boxes the $PIRQ table is wrong.
 * The MP1.4 table is right however and so SMP kernels tend to work.
 */

The comment beginning on line 349 reads:

/*
 * Don't access SMBus on IBM systems which get corrupted eeproms
 */

And this is from lines 362-356:

/*
 * Work around broken HP Pavilion Notebooks which assign USB to
 * IRQ 9 even though it is actually wired to IRQ 11
 */

Lines 391 and 392 mention a workaround for more Dell systems:

 *      Phoenix A04  08/24/2000 is known bad (Dell Inspiron 5000e)
 *      Phoenix A07  09/29/2000 is known good (Dell Inspiron 5000)

This comment begins on line 402:

/*
 * Check for a Sony Vaio system
 *
 * On a Sony system we want to enable the use of the sonypi
 * driver for Sony-specific goodies like the camera and jogdial.
 * We also want to avoid using certain functions of the PnP BIOS.
 */

Toshiba shows up on line 453:

/*
 * Toshiba keyboard likes to repeat keys when they are not repeated.
 */

And again at line 463:

/*
 * Toshiba fails to preserve interrupts over S1
 */

These are not the only vendors' hardware this file deals with. Many comments indicate quirks in vendor-indendent features, such as lines 491-494:

/*
 * Some Bioses enable the PS/2 mouse (touchpad) at resume, even if it was
 * disabled before the suspend. Linux used to get terribly confused by that.
 */

Or the comment beginning on line 292:

/*
 * Some machines, usually laptops, can't handle an enabled local APIC.
 * The symptoms include hangs or reboots when suspending or resuming,
 * attaching or detaching the power cord, or entering BIOS setup screens
 * through magic key sequences.
 */

The comment on lines 312-316 reads:

/*
 * The Microstar 6163-2 (a.k.a Pro) mainboard will hang shortly after
 * resumes, and also at what appears to be asynchronous APM events,
 * if the local APIC is enabled.
 */

In addition, the dmi_blacklist structure (beginning on line 536) is a long enumeration of specific systems with features that need to be disabled for Linux to work properly on them. This list contains systems from IBM, Dell, Compaq, ASUSTeK, TriGem, Fujitsu, Intel, Sharp, Sony, Higraded, Microstar, HP, and others.

By indicating a file devoted to identifying hardware that needs to be partially disabled to work with Linux, SCO continues its trend of claiming ownership of a LACK of support for things. Attempting to lay claim to the absence of something is not a position that makes logical sense. It seems fairly clear that SCO does not understand what the code they're talking about actually _does_, and in many cases didn't even read the plain English comments contained in the files they identified.

Random files that simply have an IBM copyright notice.

The file kernel/pid.c is devoted to dynamically allocating resources for newly created processes, and recycling those resources when processes exit. This file was created as part of Ingo Molnar's scalability work, which also led to the new "O(1) scheduler". (The O(1) notation indicates that the new scheduler can find the next task for the system to run in a constant amount of time, no matter how many tasks there are in the system.)

In the 2.2 kernel, the analog of this functionality lived in the file kernel/fork.c. (See "get_pid" on line 188 in version 2.2.14.) Note that this older file also contains SMP support and the string "SMP" (for example, in the comment beginning on page 96), and would probably have triggered SCO's text search if it was a new development. It was not as scable as the new version, but it already scaled to more than one processor.

The new pid.c file in 2.5.69 is related to Ingo Molnar's scalability work, which also included the O(1) scheduler and many related improvements in process creation ("fork") and process exit handling. Ingo Molnar was an employee of Red Hat when he did this work, as evidenced by the copyright notice on line 5 of pid.c:

 * (C) 2002 Ingo Molnar, Red Hat

Although Ingo was the driving force behind this scalability work (as documented on the linux-kernel mailing list), the resulting code was extensively tested by IBM, and this testing resulted in the identification of some bottlenecks. The identification of William Irwin's IBM copyright notice on top of Ingo's work is by no means surprising: IBM has very large systems with which to test and benchmark the kind of performance improvement Ingo authored. But Ingo remains the primary author of this file, with IBM in a supporting role.

More text searching for the string "RCU".

The file ipc/util.h describes itself thusly on line 5:

* ipc helper functions (c) 1999 Manfred Spraul 

(The acronym "IPC" stands for inter-process communication.)

Note that Manfred Spraul was not an IBM employee, but he is one of the non-IBM developers deploying RCU technology throughout the Linux kernel, now that IBM has granted the Linux developers a license to use the RCU patent. (For a recent example, see his 12/20/2003 posting titled "[RFC,PATCH] use rcu for fasync_lock".)

The fact that SCO's text search found the string "rcu" in files in the Linux kernel (as their text search apparently found in lines 44-48 of util.h) does not prove that IBM put it there. RCU is a simple, well-documented technique (Paul McKinney's excellent archive of RCU documentation, as well as the history of RCU in Linux, can be found at http://www.rdrop.com/users/paulmck/rclock/). Now that IBM's patent has been removed as an impediment to deploying it, the Linux kernel developers are implementing it on their own.

In fact, such documentation of RCU (so that one skilled in the art could reproduce the invention) is both a requirement and a goal of the patent process. If SCO was going to object to the filing of Sequent's patent years ago, it had ample opportunity to do so. (Whether or not it had any grounds or standing is another matter, now moot.) The fact that SCO's management at the time was not as profoundly delusional as SCO's current management doesn't change the fact that SCO allowed the patent to be filed for and granted, that the technology is widely documented with no vestige of trade secret status, and that a valid patent on it exists which does not belong to SCO and does belong to IBM.