Of course, we have already done so in the past, but because SCO has new management, we'd like to offer help by showing exactly where on Groklaw they can find materials regarding each item.

So, let's start with item number one on their list for this article, the 1999 Robert Swartz memo [PDF].

Here's what they say about it:

A Memorandum from Robert Swartz to Steve Sabbath and Doug Michels dated Oct 4, 1999 reporting a character by character comparison between UnixWare 7, UnixWare 3.2, UnixWare 4.0, and UnixWare 4.2 and Red Hat Linux 5.2.

The report states, in part, "First, many portions of Linux were clearly written with access to a copy of Unix sources. This of course would be a violation of the License agreements under which Unix is distributed. Second there is some code where Linux is line for line identical to Unix. This is not entire programs but fragments of code and programs from various areas of the operating system. Thirdly there are also portions of the programs which appear to have been rewritten, perhaps only for the purposes of obfuscating that the code is essentially the same."

If you go to this Groklaw article, you will find the rebuttal to it, and I'll add some new points here now. The memo points out similarities between Linux and UnixWare code, but it also pointedly stated that Swartz had not traced ownership of the code but would leave it to Mike Davidson to do that, since code in BSD Lite, he wrote, for just one example, would be perfectly legal to use in Linux:

Additionally we investigated the settlement of The Regents of the University of California and BSDI. It is my understanding that anything in BSD Lite tape which was distributed by the University of California, is free of any legal encumbrances from SCO. Further any code which is necessary to meet the POSIX standard is also free of encumbrances.

Date: Tue, 13 Aug 2002 13:26:51 -0700
From: Michael Davidson
Organization: Caldera International
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: en
To: Reg Broughton
Subject: Re: Patents and IP Investigation

The actual investigation itself was done by an outside consultant (Bob Swartz) hired by SCO. I worked with him and reviewed his findings.

My recollection is that Bob produced an initial proposal for the project which outlined the methodology to be used, and he *may* have also provided a final report, but I don't have copies of either.

The project was a result of SCO's executive management refusing to believe that it was possible for Linux and much of the GNU software to have come into existance without *someone* *somewhere* having copied pieces of proprietary UNIX source code to which SCO owned the copyright. The hope was that we would find a "smoking gun" somwhere in code that was being used by Red Hat and/or the other Linux companies that would give us some leverage. (There was, at one stage, the idea that we would sell licenses to corporate customers who were using Linux as a kind of "insurance policy" in case it turned out that they were using code which infringed our copyright).

Note that the scope of the project was limited to looking for evidence of copyright infringement (we didn't consider patents because SCO didn't own the rights to any patents, and more general IP issues were just too vague - besides SCO was *sure* that it was going to find evidence of copyright violations which are comparatively straightforward to prove once you have found them)

An outside consultant was brought in because I had already voiced the opinion (based on very detailed knowledge of our own source code and a reasonably broad exposure to Linux and other open source projects) that it was a waste of time and that we were not going to find anything.

Bob worked on the project for (I think) 4 to 6 months during which time he looked at the Linux kernel, and a large number of libraries and utilities and compared them with several different vesrions of AT&T UNIX source code. (Most of this work was automated using tools which were designed to to fuzzy matching and ignore trivial differences in formatting and spelling)

At the end, we had found absolutely *nothing*. ie no evidence of any copyright infringement whatsoever.

There is, indeed, a lot of code that is common between UNIX and Linux (all of the X Windows system, for example) but invariably it turned out that the common code was something that both we (SCO) and the Linux community had obtained (legitimately) from some third party.

md

From: Reg Broughton
Sent: Tuesday, August 13, 2002 10:05 PM
To: Darl McBride
Subject: Fwd: Re: Patents and IP Investigation

DARL

we can probably track down Bob Swartz if you want to dig further. Based on our last conversation, this summary of the code investigation probably closes that discussion.

This of course does not invalidate any of your statements on Caldera owning the central IP, and being the core provider of key technology and IP over the years into the UNIX and Linux communities.

Groklaw published the formerly confidential settlement terms in 2004, and Swartz was correct that anyone could use BSD Lite code. Notice the language in this section:

c. USL agrees that it shall take no action against any person who utilizes any methods and concepts in the Restricted Files which as of this date have become available to the general public by acts not attributable to the University, its employees or students. Nothing in this provision shall limit USL's rights against a third party arising out of a breach of any license agreement with USL or AT&T.

d. The University agrees that to the extent 4.4 BSD(Lite) contains any material contained in the UNIX Derived Files, the files in which such matter is contained will include, in text form, the USL Copyright Notice and list of restrictions on use and distribution of the software required by section 2.e of this Settlement Agreement.

e. Without waiving any of its proprietary rights therein, USL agrees that UNIX Derived Files listed in Exhibit B, or any material therein, may be freely distributed by the University and may be freely reproduced and redistributed by others without payment of any royalties or fees and without execution of any license agreement with USL and/or the University, provided such files or portions thereof include, in text form, a USL Copyright Notice and the same list of restrictions on use and redistribution of the software presently contained in the Net2 version of the file. Attached as Exhibit F is a copy of said notice which has been agreed upon by the parties.

Groklaw Takes A Closer Look at the ABI Files, by Frank Sorenson et al

Signal.h -- Part 2 of Warren Toomey's look at the ABI Files

The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society

SCO's Former VP Said The ABI Files Could Be Used in Linux Freely

I highlighted the wording about methods and concepts because SCO on its legal page also mentions that copyright covers methods. But in this case, it doesn't affect any Linux end users not in a contractual relationship with SCO, because of the wording in the BSDi settlement agreement. But even if it did, we've answered all that long ago. For example, here and here. And SCO has admitted there are no trade secrets in UNIX. They said it in open court. But even if they had not said it, take a look at the Unix Methods and Concepts database Groklaw prepared. We can do this stuff in our sleep. It's all out there. You look very foolish if you try to claim methods and concepts, frankly, even if the court in the IBM case would let you, and it already ruled it won't. Even if it let you, you'd still lose. Read the IBM contracts.

You'll find Exhibit F on the same page as our published copy of the settlement. Essentially, it required a copyright notice and no use of USL's name as if they endorsed your stuff. Provided you abided by those requirements, here's what you could do:

Copyright © 1982, 1986, 1988
The Regents of the University of California
All Rights Reserved.

© UNIX System Laboratories, Inc. All or some portions of this file are derived from material licensed to the University of California by American Telephone and Telegraph Co. or UNIX System Laboratories, Inc. and are reproduced herein with the permission of UNIX System Laboratories, Inc.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

I would point out that the settlement terms applied to the two parties that signed it, since it was never court-ratified. It was a private agreement, binding on no one else, but of course copyright notices are binding on the world. And there were no restrictions on who could use the code.

Let me remind you of what Darl McBride was claiming:

The UNIX ABIs were never intended or authorized for unrestricted use or distribution under the GPL in Linux. As the copyright holder, SCO has never granted such permission.

Compare what SCO claimed about that BSDi settlement before we published it, and try to make it match. When you can't, ask yourself, why did they say what they did? And why do they persist?

BSD was and is free to use that code, and so is everybody else, since BSD Lite's copyright notice did not restrict use only to BSD. Those threats were empty ones, and beneath contempt.

But let's get back to that Swartz memo. First, notice the date. It's 1999. Do you remember when SCO claims that IBM first became involved in Linux? Notice their Second Amended Complaint specifically mentions the date 2000. So whatever Swartz thought he found, IBM wasn't involved, according to SCO's own narrative. Notice also, please, as SCO tells the story their way, which kernels were allegedly affected by IBM's involvement in Linux:

79. As a result, a very significant amount of UNIX protected code and materials are currently found in Linux 2.4.x, Linux 2.5.x and Linux 2.6.x releases in violation of SCO’s contractual rights and copyrights.

iBCS is the Intel Binary Compatibility Specification, an ABI developed by vendors of x86-based Unix vendors to allow binary compatibility between their respective implementations. With the death of most proprietary x86 Unix variants and the adoption of the Linux ABI as the de facto standard x86 ABI, it has now faded to the background. For example, the Linux kernel implementation of the iBCS standard has seen no new deveopment since 1998, and is incompatible with 2.4 and 2.6 kernels.

By the way, would you like to see some improvements made to the Linux ABI specifically with regard to SCO code? Let's go back to 2002, shall we? And look who is making those improvements -- Christoph Hellwig of Caldera. Well, knock me over with a feather:

2002-01-03 Christoph Hellwig

linux-abi-2.4.17.0

• rework/cleanup lcall7 syscall handling
• make sure x.out sections aren't loaded into illegal areas
• fix SVR4 mmap() to always assume post-SunOS4 behaviour

2001-11-24 Christoph Hellwig

linux-abi-2.4.15.0

• simplify wyse socket handling, use native syscalls directly where possibles else use normal calling conventions
• fix compilation for non-i386 machines (Olaf Hering)
• fix alignment checks in binfmt_xout (based on patch by Joerg Ahrens)
• rewrite abi_brk: fix (theoretical) races, check for page alignment
• don't try to take a non-existant lock in xnx_nap, cleanup xnx_nap. fix value reported by sysi86(SI86MEM).

2001-11-18 Christoph Hellwig

linux-abi 2.4.14.0

• small binfmt_xout bugfixes (Joerg Ahrens)
• move isc into it's own personality
• make all personalities independant of abi-ibcs
• merge socket handling into abi-wyse

2001-10-22 Christoph Hellwig

linux-abi 2.4.12.0

• big mmap rewrite
  | correctly check for flags in svr4_mmap
  | use svr4_mmap for the UnixWare personality as well
  | OpenServer has it's own implementation now as it supports rather different flags than SVR4 & derivates
• * more header cleanups - all helper routines are now in abi/util/*.h

2001-10-04 Christoph Hellwig

linux-abi 2.4.10.0

• add MODULE_DESCRIPTION/MODULE_AUTHOR/MODULE_LICENSE tags
• don't use alternate prefix for directories (David Mosberger)
• fix non-modular buil
• cleanup stat handling
  | use Alexander Viro's kstat concept
  | all emulations now have their own xstat implementations
  | fixed overflows
• add full-fledged types.h headers for all peronalities

2001-08-06 Christoph Hellwig

linux-abi 2.4.9.0

• fix missing solaris socket exports
• move Xenix support from ibcs to sco module, make unconditional
• UnixWare LFS fixes
• make the actual code work on the Alan Cox tree

2001-08-06 Christoph Hellwig

linux-abi 2.4.7.0

• some final polishing for segmented 286 x.out binaries (Joerg Ahrens)
• fix SPX handling (again)
• fix setpgrp and cleanup procids while we're at it
• update SCO syscall table to match OSR506a

2001-07-19 Christoph Hellwig

linux-abi 2.4.6.1

• rewritten /dev/socksys handling
• fix more non-x86 breakage (Olaf Hering)
• port solaris native sockets from sparc64
• add sysctl support for runtime-tweaking
• add cxenix to the ibcs sysent table for Xenix/386 (J�rgen G�nther)
• (re)add support for segmented x.out binaries (Joerg Ahrens)
  | I probably broke it while rebasing against -CURRENT
• reject IRIX binaries on mips32 (David Woodhouse)

2001-07-09 Christoph Hellwig

linux-abi 2.4.6.0

• svr4/signal.c typo fix
• make cxenix debug printk's less verbose (Christian Lademann)
• misc small bugfixes (Christian Lademann)
• compile fixes for !CONFIG_ABI on non-x86 architectures

2001-06-18 Christoph Hellwig

linux-abi 2.4.5.1

• rewrite of abi_sigsuspend() to make it work as expected
• fix cxenix syscall table
• actually initialize socksys

2001-06-09 Christoph Hellwig

linux-abi 2.4.5.0

• rewrite of kernel exec_domain support
• make faking of SCO utsname information configurable
• get rid of SYS() and sysfunc_p (Arjan van de Ven)
• fix socket families (Stephan Springl)
• fix SCO signal mapping (Stephan Springl)
• fix SCO (and Wyse) error mapping
• continued source tree restructuring

2001-04-31 Christoph Hellwig

linux-abi 2.4.4.0

• disable tracing by default
• rewrite of the SYSV IPC code
• add support for SCO OpenServer 5 ELF binaries
• fix an error in binfmt_coff that does not clear the return value
• provide generic template macros for stat and friends
• start of source tree reorganization

2001-03-30 Christoph Hellwig

linux-abi 2.4.3.0

• fix shared library support for COFF
• x.out is now supported (again)
• redo setting of personality based on ELF headers
• get rid of CONFIG_ABI_TRACE (and a lot of nasty ifdefs)
• added documentation, mostly from iBCS

I was paid by Caldera for working on Linux-ABI

• ended with the big Caldera layoffs in 4/2002

Incidentally, Everything2 explains why companies wanted to be compatible with Linux-ABI, so much so that in time it took over from iBCS as the standard:

So, since the iBCS standard predates the creation of the Linux kernel, why hasn't it become the standard ABI for x86-based Unix systems? The first reason has to do with the age-old bane of the proprietary Unix market: incompatible extensions. Sure, everyone involved sat down and hammered out a standard that they then all implemented, but then they each solved problems with or added capabilities to their ABIs without consultation with each other or changing the published standard. Thus, iBCS became a family of subtly different ABIs, each of whose quirks needed to be addressed in any implementation which offered true compatibility. The issue of shared libraries was probably also a factor, with the base Linux libraries being freely redistributable unlike some of their competitors's. But the final blow was probably that, by the end of the 1990s, most x86 Unix machines were running Linux or a BSD variant. Then, these were the systems to be compatible with, not the systems that had to be compatible. Since BSD had implemented a Linux compatibility system, this left the Linux ABI as the de facto standard for x86 Unix.

And if you are still confused, here's an article about using iBCS, an article in Linux Journal from 1994 that explains that iBCS is a standard:

The term iBCS2 simply stands for the “Intel Binary Compatibility Specification 2”, and is the name of a standards document for binary compatibility between different systems running Unix on Intel 386, 486, and “greater” CPU's. Some parts of iBCS2 overlap with POSIX, and since Linux is POSIX compliant it means that there are portions of the emulation which are trivial. Unfortunately, there are also places where Linux and iBCS2 are quite different, so iBCS2 emulation is by no means trivial....

iBCS2 emulation under Linux is a relatively new feature that offers you the ability to take an application that was designed to run under a system such as SCO Unix or SVR4 and run it directly on your machine running Linux. This feature is most useful for commercial applications for which the source code is not publicly available, and therefore would be impossible to simply port to Linux

IBM doesn't just have defenses; it has counterclaims. Even if SCO could win 5 cents at trial, what do you think the counterclaims might be worth? Here's a glimpse:

121. SCO has made material false representations regarding AIX, Dynix and IBM's Linux-related products and services, which affect a customer's decision whether to purchase these products and services. Specifically, SCO has publicly misrepresented the legitimacy of these products and services by falsely representing that IBM no longer has the right, authority and license to use, produce and distribute these products and by misrepresenting SCO's own rights in and to Unix, AIX, Dynix and Linux.

122. SCO has published its false statements in a series of widely-distributed press releases, press interviews and other streams of commerce, as part of its bad faith campaign to discredit IBM's products and services in the marketplace, to increase the perceived value of SCO's limited rights to UNIX and to promote SCO's own UNIX operating systems, UnixWare and Open Server.

123. These statements are likely to cause confusion and mistake and have in fact caused confusion and mistake as to the characteristics of IBM's goods, products and/or services.

124. As a direct result of SCO's false representations, all of which are in violation of 15 U.S.C. § 1125, IBM has suffered damages in an amount to be determined at trial. IBM is also entitled to damages and attorneys' fees pursuant to 15 U.S.C. § 1117(a).

What SCO needs to think about now, in my view, is: what is there on that list that it can prove is infringing, to counter the damages it is going to have to pay IBM? Surely not header files, for all the reasons listed in that 2005 Groklaw article. For one thing, there's no code in header files. Or go to our search engine, and search for ABI or Errno.h or header files.

Another issue I'd worry about if I were SCO's new management. SCO swore up and down that they had no plans to sue anybody until after they set up stock plans for the executives. The plans were established in March of 2003. From the above email's date, would you say that is true? If not, what does it mean for the company, would you guess? Here's a page where you can find how much the executives made from the upswing in value of the SCO stock after SCO began issuing its wild claims, the Lanham Act-encumbered statements, if I may call them that.

And of course, Eben Moglen, the world's expert on the GPL noted this way back in 2004:

Many of the large, sophisticated enterprises who are the targets of SCO’s efforts responded to their claims last summer by taking copies of the Linux program, under GPL, from SCO’s own FTP server, where the code remained publicly available. They therefore have an auditable license from SCO to use, copy, modify and redistribute the code about which SCO continues to threaten legal action. For such enterprises, which now can also get a copy of the same program, under the same license, from Novell, any action by SCO to bring a copyright infringement claim would be particularly foolish.

2. Even once the litigation is resolved, and regardless of who prevails, customers will still have the right to use the Linux code in question without purchasing a license from either SCO Group or Novell. Moglen points out that both SCO Group and Novell (who recently purchased SuSE Linux, a distributor of Linux) have distributed the Linux code under the GPL. Since the GPL allows licensees to use, modify, copy and distribute the Linux code freely, the results of the litigation will have no affect on those rights, and customers will have no obligation to purchase another license from either SCO Group or Novell to ensure those rights.

SCO under its old management paid no attention to the warnings. Many of us watched SCO march over the cliff into bankruptcy, led on by its legal advisors, who as far as we can tell never did understand the GPL and still don't, and they marched forward like Napoleon's army through the snows toward Moscow, against all reason. And they are still urging SCO's new management to trudge onward through the frigid wilderness. But what can you possibly win in the end? I'm talking as to a friend.

I mean no disrespect, but the simple truth is, Boies Schiller has not been known as a specialist in IP litigation. Moglen is known as an expert in copyright law as applied to software. That's just simply factual. Smoke and mirrors might work in the media, but in the courts you need proof. Where is it? After half a decade, where is it?

So, where is the big payday going to come from? No. Really. What SCO's new management needs to ask is this: are we being given good legal advice in this instance?