SCO's longer list was probably generated by some form of text search, not by human inspection. A brief set of Linux text search commands can recreate this list by searching for all files containing the words "smp", "numa", and "rcu" in eight directories of the 2.5.69 Linux kernel source, plus the entire contents of the fs/jfs directory. Here is a brief unix script that does exactly this:
#!/bin/sh # to be run in the linux-2.5.69 kernel tree ( find * -name '*.[ch]' | egrep -v '^(drivers|sound)|(arch/|include/asm-)(sparc|alpha|parisc)' | xargs egrep -iwl '(smp|numa|rcu)' ls fs/jfs/*.[ch] ) | sort -u
When this script is run against the 2.5.69 linux kernel source, it identifies all of the files in SCO's list, with only four extra files (arch/um/drivers/harddog_kern.c, arch/um/drivers/harddog_user.c, arch/um/drivers/mconsole_kern.c, and include/asm-h8300/smplock.h) that SCO did not include in their list. The "code analysis" that SCO has done can very nearly be replicated with a nine line unix shell script.
The most obvious example of the "text search" nature of this list is the file include/asm-m68k/spinlock.h, which SCO identified as potentially infringing. This file is reproduced here in its entirety, with line numbers:
1) #ifndef __M68K_SPINLOCK_H 2) #define __M68K_SPINLOCK_H 3) 4) #error "m68k doesn't do SMP yet" 5) 6) #endif
There are only four lines of actual text in this file, three of which (the first, second, and sixth) implement a standard technique to prevent the file from being included twice in a given compilation, which is used by most "header" type files.
(Footnote: this technique is called "header file guarding". SCO cannot be claiming to own this technique, it's common to all "header" files, including the ones shipped (in human readable plain-text form) with SCO's own C compiler, and similar compilers from Microsoft, Sun, etc. The 2.2 kernel, which SCO admits is not infringing, uses this technique, as do thousands of other header files in Linux which SCO did not identify as potentially infringing. Header guarding is an industry standard, literally textbook application of the C programming language's preprocessor facility. See http://users.bestweb.net/~ctips/tip007.html or http://www.cs.umbc.edu/courses/undergraduate/201/fall98/lectures/lec17/guard.sht ml or http://userpages.umbc.edu/~dhood2/courses/cmsc201/fall2002/notes/disc12/03.shtml for more information.)
The remaining non-blank line (line four) issues an error message and stops the compiler from proceeding. This file is only included in the linux kernel when an imposible configuration is requested, and its purpose is to abort the build process with an error message if that happens. As the message says, the Motorola 68000 version of the Linux kernel does not support Symmetrical Multi-Processor operation. (It is an obsolete hardware platform for which little or no interesting SMP hardware exists.)
Technically, SCO is claiming to own a _lack_ of support for SMP for the m68k platform. The only distinguishing feature of this file is that the error message contains the word "SMP". The file does not contain code to implement any potentially secret techniques. In fact it does not contain any "code" at all, in that there are no statements in this file that would result in the generation of executable output.
What SCO is claiming to own in this case is the string of letters "SMP". This would have been clearly obvious to any minimally competent programmer reading it, therefore it is very unlikely that SCO selected this file as the result of a human reading it. It was identified by a text search for the string "SMP".
Note that this file is not unique: SCO identified several other virtually identical files in their list of potential infringers, including include/asm-h8300/spinlock.h, include/asm-sh/spinlock.h, and include/asm-arm/spinlock.h. Each of these files is six lines long, and equivalent to the m68k version except for the name of the platform. The 10-line file include/asm-arm/smp.h is substantially similar as well, differing only in the circumstances under which the error message indicating a lack of SMP support is triggered to stop the compiler from producing an impossible configuration of Linux.
Many of the other files identified in this list contain no "methods" at all, let alone potentially infringing ones. SCO listed files which contain no algorithms or data structures. They're pure "glue", directives that link together algorithms and data structures defined elsewhere without defining any of their own.
One small example is the 14-line file include/asm-v850/percpu.h. This includes three lines of header file guarding, a six line comment, two "include" statements (pointing the compiler to other files it should read), and three blank lines. That's it. There is no "meat" in this file. No algorithms, no data structures. Unless SCO is claiming to own the comment?
Here is include/asm-v850/percpu.h in its entirety. Note that the word SCO was searching for (smp) only occurs in the comment.
#ifndef __V850_PERCPU_H__ #define __V850_PERCPU_H__ #include <asm-generic/percpu.h> /* This is a stupid hack to satisfy some grotty implicit include-file dependency; basically, <linux/smp.h> uses BUG_ON, which calls BUG, but doesn't include the necessary headers to define it. In the twisted festering mess of includes this must all be resolved somehow on other platforms, but I haven't the faintest idea how, and don't care; here will do, even though doesn't actually make any sense. */ #include <asm/page.h> #endif /* __V850_PERCPU_H__ */
Another algorithm-free file SCO objects to is include/linux/vermagic.h, 23 lines which assemble a brief block of text identifying the kernel version. This file consists almost entirely of configuration tests and macro definitions, ending with the assembly of several smaller strings of letters into one big block of text. The most complicated thing it does is ask the compiler what version it is, so that information can be included in the version string. (So that when a program asks the linux kernel what version it is, it can find out if it was compiled with "gcc 2.95", "gcc 3.2.2", or something else. This can be important when trying to track down obscure bugs.) It triggered SCO's text search because whether or not the kernel is compiled for SMP is part of the version information.
Another 23 lines of fluff is include/asm-i386/mach-visws/entry_arch.h. This file has a couple of comments, a couple of configuration tests, and six uses of a macro called BUILD_INTERRUPT. It might be interesting to know what BUILD_INTERRUPT does, but that's not defined in this file, so even if it did something interesting this would still be the wrong file to look at.
23 more lines SCO obviously never looked at is fs/jfs/jfs_inode.h, which consists primarily of the Free Software Foundation's boilerplate copyright notice, which the FSF recommends for use with the GPL (although this practice is discouraged in instances such as this, when the copyright notice is larger than the rest of the file). The rest of the file is six lines: three lines of header file guarding, two blank lines, and a function declaration. Function declarations indicate that a function exists elsewhere in the program, and how to interact with it, but the actual function (and any algorithms it implements or data structures it uses) is defined elsewhere.
The function declaration line in jfs_inode.h is:
extern struct inode *ialloc(struct inode *, umode_t);
It would be interesting to see SCO explain how they believe that line belongs to them.
Several much longer files are also pure glue, such as the file arch/s390/kernel/s390_ksyms.c (87 lines).
This file exists to export symbols, so they can be found and used by other parts of the kernel (such as dynamically loadable modules). What this means is that this is another type of housekeeping file that does not produce executable computer code, but merely links together other pieces of code defined elsewhere.
In addition to EXPORT_SYMBOL statements, this file has some function prototypes (which again define calling conventions for functions that are defined elsewhere), and some #include statements referencing headers that live elsewhere. It also has some comments, and one #ifdef/#endif pair that allows portions of the file to be excluded by the configurator. The rest of the lines are blank.
Despite this file's greater length, it contains no algorithms or even data structures. It produces no executable statements. This file is pure glue.
The same kind of linker directives can be found in arch/i386/kernel/i386_ksyms.c (213 lines), this time for the i386 platform (I.E. standard intel chips, including Pentiums). Although this one is somewhat longer, we've verified that it contains no actual executable code, or even data structure definitions.
SCO included a number of other ksyms files:
arch/ia64/kernel/ia64_ksyms.c arch/ppc64/kernel/ppc_ksyms.c arch/ppc/kernel/ppc_ksyms.c arch/sh/kernel/sh_ksyms.c arch/um/kernel/ksyms.c arch/x86_64/kernel/x8664_ksyms.c
Eric or I could hand-verify they're all nothing but plumbing, if you like.
SCO included a number of ACPI files:
arch/i386/kernel/acpi/boot.c arch/i386/kernel/acpi/sleep.c arch/ia64/kernel/acpi.c arch/x86_64/kernel/acpi/boot.c arch/x86_64/kernel/acpi.c include/asm-ia64/acpi.h
ACPI is Intel's Advanced Configuration and Power Interface, which can be used to slow down a CPU to conserve power, query the battery status on a laptop, tell when a laptop lid is open or closed, and is also used for hardware detection.
This is a standard that Intel designed and published, and the ACPI code in Linux was written and contributed directly by Intel. These files contain prominent Intel copyright notices right at the top, and the contact information for Intel developers if anyone has questions about them. IBM clearly has nothing to do with these files, and these files clearly do not infringe upon any of SCO's intellectual property, since SCO did not invent or implement ACPI, and Intel did both and publicly contributed the results to Linux, and has assigned full-time paid development staff to support, debug, and enhance the Linux ACPI code it has already contributed.
Intel's own page on ACPI is at http://www.intel.com/technology/iapc/acpi/downloads.htm, which refers to the intel-sponsored sourceforge project at http://acpi.sourceforge.net as the place to get the most recent ACPI code for linux.
The current ACPI maintainer is Len Brown of Intel, who took over from Andrew Grover (also of Intel) on September 17, 2003. (See http://groups.google.com/groups?selm=wOBl.2rh.7%40gated-at.bofh.it for the handoff message.) As Andrew Grover said during the handoff:
Len will be responsible for pulling ACPI CA updates into the Linux release, and the rest of Linux-specific code in general.
Len Brown's job, as an Intel employee, is to maintain ACPI support for Linux. On november 18th, Len Brown submitted the most recent update of ACPI to Marcelo Tosatti, the 2.4 kernel maintainer. (See http://groups.google.com/groups?selm=TlgW.7OW.19%40gated-at.bofh.it for the public notification on the Linux-kernel mailing list.)
SCO has also included a number of subdirectories devoted to platform-specific support of computer architectures IBM does not sell, support, or otherwise have any interest in. If SCO had run its list by any remotely technically competent individual, it would have noticed that the MIPS platform is a product of mips technologies (which makes the processor) and SGI (the largest producer of machines using the MIPS processor). Even if SCO didn't bother to open the files and read the copyright notices at the top, the fact that several of the files have the initials "sgi" in their names should have been a bit of a clue:
arch/mips64/kernel/proc.c arch/mips64/kernel/ptrace.c arch/mips64/kernel/signal32.c arch/mips64/kernel/signal.c arch/mips64/kernel/smp.c arch/mips64/kernel/syscall.c arch/mips64/kernel/traps.c arch/mips64/kernel/unaligned.c arch/mips64/math-emu/cp1emu.c arch/mips64/mips-boards/generic/printf.c arch/mips64/mm/fault.c arch/mips64/mm/umap.c arch/mips64/sgi-ip22/ip22-int.c arch/mips64/sgi-ip27/ip27-init.c arch/mips64/sgi-ip27/ip27-irq.c arch/mips64/sgi-ip27/ip27-klnuma.c arch/mips64/sgi-ip27/ip27-memory.c arch/mips64/sgi-ip27/ip27-nmi.c arch/mips64/sgi-ip27/ip27-reset.c arch/mips64/sgi-ip27/ip27-setup.c arch/mips/kernel/ipc.c arch/mips/kernel/irixioctl.c arch/mips/kernel/irixsig.c arch/mips/kernel/irq.c arch/mips/kernel/old-irq.c arch/mips/kernel/ptrace.c arch/mips/kernel/signal.c arch/mips/kernel/smp.c arch/mips/kernel/syscall.c arch/mips/kernel/sysirix.c arch/mips/kernel/sysmips.c arch/mips/kernel/time.c arch/mips/kernel/traps.c arch/mips/kernel/unaligned.c arch/mips/math-emu/cp1emu.c arch/mips/mips-boards/generic/printf.c arch/mips/mm/fault.c arch/mips/mm/umap.c arch/mips/sgi/kernel/indy_int.c arch/mips/sni/io.c include/asm-mips64/hardirq.h include/asm-mips64/mmzone.h include/asm-mips64/processor.h include/asm-mips64/semaphore-helper.h include/asm-mips64/sgiarcs.h include/asm-mips64/sn/sn0/arch.h include/asm-mips64/sn/types.h include/asm-mips64/spinlock.h include/asm-mips64/timex.h include/asm-mips/atomic.h include/asm-mips/bitops.h include/asm-mips/hardirq.h include/asm-mips/semaphore.h include/asm-mips/semaphore-helper.h include/asm-mips/sgiarcs.h include/asm-mips/spinlock.h include/asm-mips/system.h include/asm-mips/timex.h
Even if those files did contain confidential SCO information (which SCO has yet to identify), they are specific to non-IBM hardware platforms.
Similarly, the ARM processor (used in embedded devices such as Cisco's Linksys routers and Sharp's Zaurus PDA) is not an IBM product. ARM is the product of a United Kingdom firm, which licensed the design to Intel in 1998. Its main feature is low power consumption.
The ARM support files in Linux have prominent contact information for Russell King of the ARM Linux project (Google produced an "about Russell King" page at http://www.arm.linux.org.uk/personal/aboutme.html), which could easily have allowed SCO to remove the following files from its list if they'd made minimal inquiries:
arch/arm/kernel/irq.c arch/arm/kernel/ptrace.c arch/arm/kernel/signal.c arch/arm/kernel/time.c arch/arm/mach-arc/small_page.c arch/arm/mach-integrator/cpu.c arch/arm/mm/init.c include/asm-arm/arch-clps711x/memory.h include/asm-arm/arch-sa1100/memory.h include/asm-arm/atomic.h include/asm-arm/smp.h include/asm-arm/spinlock.h include/asm-arm/system.h include/asm-arm/thread_info.h
Similarly, the following files from the "cris" architecture made SCO's list:
arch/cris/kernel/irq.c arch/cris/kernel/process.c arch/cris/kernel/ptrace.c arch/cris/kernel/setup.c arch/cris/kernel/signal.c arch/cris/kernel/sys_cris.c arch/cris/mm/init.c include/asm-cris/delay.h include/asm-cris/hardirq.h include/asm-cris/pgtable.h include/asm-cris/semaphore-helper.h include/asm-cris/smp_lock.h include/asm-cris/timex.h
In linux kernel 2.5.68, the first of those files (arch/cris/kernel/irq.c) contains the following copyright notice in lines 5-7:
* Copyright (c) 2000,2001 Axis Communications AB * * Authors: Bjorn Wesen (bjornw@axis.com)
While we're here, note that this file apparently triggered SCO's search and was included in the list due to the comment on line 15:
* Notice Linux/CRIS: these routines do not care about SMP
Again, SCO is claiming to own a
Bjorn's email address is at axis.com. Checking out www.axis.com reveals that axis is an "embedded" systems vendor manufacturing video cameras that can be connected to the internet, network file and print servers, and wireless access points (see http://www.axis.com/products/index.htm). According to http://www.axis.com/corporate/index.htm they were founded in 1984, and are located in Sweden. And elsewhere on the site we learn that they design and sell their own processors (http://developer.axis.com/products/mcm/) and that they ported Linux to those processors themselves (http://developer.axis.com/products/etrax100lx/etrax_history.html).
SCO did not do the most basic investigation of publicly available information to determine who was responsible for these files. They want IBM to do this work for them, possibly because they are not technically capable of even this simple querying of public information.