A reader points out that SCO's legal page [http://www.sco.com/company/
legal/update/] seems to be changing. Since that likely indicates what they are planning going forward and what cards they imagine they are holding, we at Groklaw thought it
would be useful to answer them, item by item.
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.
Swartz mentioned that it would take someone else to trace the ownership of the code that Swartz found that was similar, to find out if it was legally used or not. Mike
Davidson later did in fact do the tracing out of each item on Swartz's list, and in 2002 he reported to Reg Broughton at Caldera, now calling itself the SCO Group, what he had found: that there was no illegal code in what Swartz had referenced in his memo. None. Here's the email [PDF], once again:
Date: Tue, 13 Aug 2002 13:26:51 -0700
This report was sent, as you see, to Reg Broughton, who then sent it on to Darl McBride, writing:
From: Michael Davidson
Organization: Caldera International
X-Mailer: Mozilla 4.6 [en] (Win98; I)
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.
From: Reg Broughton August 13, 2002 would be right after Darl joined the company, and history shows he didn't accept Davidson's sensible report or Broughton's logical conclusion. He simply had to go forward, and given that he had seen this report, it frames his public claims about Linux and copyright infringement in what some might view as Lanham Act territory. In fact, IBM did, in its Second Amended Counterclaims, and so did Red Hat. Here's the Red Hat Complaint [PDF].
Sent: Tuesday, August 13, 2002 10:05 PM
To: Darl McBride
Subject: Fwd: Re: Patents and IP Investigation
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. Exhibit B includes on the list errno.h, one of the files SCO has claimed are infringed. But there you can see with your own eyes how proposterous that claim is. If you can't, here are some more details on why it is frivolous in my view:
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
Notice any restrictions on operating systems? Me neither.
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. However, if you take a look at the copyright notices on BSD Lite, which you can find here in an article we ran in 2004, before we had obtained the BSDi settlement agreement, you will find, just as in Exhibit F, that there are no such restrictions on the code. You will also find the results of a code comparison done by a Groklaw member in 2003, comparing Linux kernel 2.6 with BSD Lite, and there were no matches at all in the ABI area. BSDi copyright notices were not stripped off of Linux ABI files, by the way. Groklaw checked. But guess who did strip off copyright notices? Caldera did from its OpenLinux. We at Groklaw checked that too.
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. So whatever SCO imagines IBM did, it has absolutely nothing to do with the Swartz memo. But let's address the ABI/API issue, also found on SCO's website. Compare the allegations with this informational page on Everything2, about IBCS:
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. Incompatible with the 2.4 and 2.6 kernels. So evidently, once again, SCO is wrong on the tech. No surprise there, to those of us geeks who have been following this case from the beginning.
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 See? It was Caldera itself that developed Linux-ABI, its own employee Christoph Hellwig. SCO should ask its experts what that means, if it isn't clear. Hint: Compare this page with the list of SCO's claims to infringement.
And if the experts say he was doing it as an individual and not with company authorization, they are wrong. Here's a slide from a talk Hellwig gave in 2002 at the UKUUG Linux Developers Conference on Linux-ABI, where he says flat out he was paid by Caldera to work on Linux ABI:
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
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
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
- 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
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
- fix missing solaris socket exports
- move Xenix support from ibcs to sco module,
- UnixWare LFS fixes
- make the actual code work on the Alan Cox tree
2001-08-06 Christoph Hellwig
- 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
- 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
- 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
2001-06-09 Christoph Hellwig
- rewrite of abi_sigsuspend() to make it work as expected
- fix cxenix syscall table
- actually initialize socksys
- 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
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
- 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 He said that in 2002, not recently, and prior to anyone suing anyone. So, what does that mean? That everything in that list above was paid for by Caldera, now calling itself the SCO Group. They should definitely sue themselves and leave the rest of us alone. It's ridiculous to keep presenting this ABI claim, when it has been so thoroughly rebutted. I believe the word, more accurately, would be frivolous. Ridiculously frivolous. There.
- 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. If you want to know more about ABIs and
COFF and ELF and such, Groklaw has plenty of information collected for you, so there is literally no excuse to persist with these allegations, I think, particularly now that we know SCO's new management, like SCO's old management, reads Groklaw.
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.... So while SCO is apparently claiming some tweaks to iBCS were proprietary, the evidence here indicates that no one wanted to use their proprietary tweaks, and they didn't need to, because Linux-ABI, maintained by Caldera itself, quickly became the standard.
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. That isn't even going in to how much SCO will owe for copyright infringement of IBM's GPL'd code in Linux, which SCO continued to distribute long after it claimed to have stopped. We at Groklaw, among many others around the world, downloaded it or screenshot the availability of it without any warning notice on SCO's sites. SCO admits continued distribution to customers, so get out your abacus and start doing the math. Don't forget punitives.
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. As for going after us little people, first, we have nothing, so you are wasting your money, and second, we have a license already, the GPL, just like the big boys and just because we are little people doesn't make us too stupid to download at the same time that the big boys did. Here's how the press release about Moglen's paper put it:
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. You may think it matters if SCO can somehow fool a jury into deciding it owns the copyrights. But it doesn't matter to us end users at all. SCO is trying to change the terms of a deal midstream, and that is not appropriate.
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?