Monday, November 24, 2003

FSF Reprint Article on the SCO controversy


SCO: Without Fear and Without Research


Eben Moglen



Monday 24 November 2003





There's a traditional definition of a shyster: a lawyer who, when the law is against him, pounds on the facts; when the facts are against him, pounds on the law; and when both the facts and the law are against him, pounds on the table. The SCO Group's continuing attempts to increase its market value at the expense of free software developers, distributors and users through outlandish legal theories and unsubstantiated factual claims show that the old saying hasn't lost its relevance.

Just The Facts


SCO continues to claim in public statements about its lawsuit against IBM that it can show infringement of its copyrights in Unix Sys V source code by the free software operating system kernel called Linux. But on the one occasion when SCO has publicly shown what it claimed were examples of code from Linux taken from Unix Sys V, its demonstration backfired, showing instead SCO's cavalier attitude toward copyright law and its even greater sloppiness at factual research.

On August 18, 2003, SCO's CEO, Darl McBride, offered a slide presentation of supposed examples of infringing literal copying from Sys V to Linux at a public speech in Las Vegas. Within hours the free software and open source communities had analyzed SCO's supposed best evidence, and the results were not encouraging for those investors and others who hope SCO knows what it is talking about.[1]

In Las Vegas Mr. McBride offered two examples of code from the Linux program that were supposedly copied from Sys V. The first implements the "Berkeley Packet Filter" (BPF) firewall. Indeed, the Linux kernel program contains a BPF implementation, but it is the original work of Linux developer Jay Schulist. Nor did SCO ever hold an ownership interest in the original BPF implementation, which as the very name shows was originally part of BSD Unix, and which was copied, perfectly legally, into SCO's Sys V Unix from BSD. Because the BPF implementations in Sys V and Linux have a common intellectual ancestor and perform the same function, SCO's "pattern-matching" search of the two code bases turned up an apparent example of copying. But SCO didn't do enough research to realize that the work they were claiming was infringed wasn't their own (probably because they had "carelessly" removed the original copyright notice).

Mr. McBride's second example was only slightly less unconvincing. Mr McBride showed several dozen lines of memory allocation code from "Linux," which was identical to code from Sys V. Once again, however, it turned out that SCO had relied on "pattern-matching" in the source code without ascertaining the actual history and copyright status of the work as to which it claimed ownership and infringement. The C code shown in the slides was first incorporated in Unix Version 3, and was written in 1973; it descends from an earlier version published by Donald Knuth in his classic The Art of Computer Programming in 1968. AT&T claimed this code, among other portions of its Unix OS, as infringed by the University of California in the BSD litigation, and was denied a preliminary injunction on the ground that it could not show a likelihood of success on its copyright claim, because it had published the code without copyright notices and therefore, under pre-1976 US copyright law, had put the code in the public domain. In 2002, SCO's predecessor Caldera released this code again under a license that permitted free copying and redistribution. Silicon Graphics, Inc. (SGI) then used the code in the variant of the Linux program for "Trillium" 64-bit architecture computers it was planning to sell but never shipped. In incorporating the code, SGI violated the terms of Caldera's license by erroneously removing Caldera's (incorrect) copyright notice.

Thus SCO's second example was of supposedly impermissible copying of code that was in the public domain to begin with, and which SCO itself had released under a free software license after erroneously claiming copyright. SGI had complicated matters by improperly removing the inaccurate copyright notice. So how many PCs and Intel-architecture servers around the world contained this supposedly infringing code? Zero. No version of the Linux program for Intel architectures had ever contained it. No SGI hardware for which this code was written ever shipped. HP, which sells 64-bit Itanium servers, has removed the code from the IA-64 branch of the Linux code tree; it was technically redundant anyway. But SCO's research went no farther than discovering a supposed instance of "copying," without asking whether SCO had any rights in what had been copied, and certainly without providing the audience to whom it was speaking any indication that the "Linux" it was talking about was a variant for rare computers from which the supposedly-offending code had already been removed.

What the Las Vegas "examples" actually demonstrated was that SCO's factual claims were irresponsibly inflated when they weren't being kept artfully "secret." With the facts running against them even when the facts were of their own choosing, it was unsurprising that after August SCO turned to the law. But the law was not on their side either.


Making Up the Law


SCO's legal situation contains an inherent contradiction. SCO claims, in the letters it has sent to large corporate users of free software and in public statements demanding that that users of recent versions of the kernel take licenses, that the Linux program contains material over which SCO holds copyright. It also has brought trade secret claims against IBM, alleging that IBM contributed material covered by non-disclosure licenses or agreements to the Linux kernel. But it has distributed and continues to distribute Linux under GPL. It has therefore published its supposed trade secrets and copyrighted material, under a license that gives everyone permission to copy, modify, and redistribute. If the GPL means what it says, SCO loses its trade secret lawsuit against IBM, and cannot carry out its threats against users of the Linux kernel.

But if the GPL is not a valid and effective copyright permission, by what right is SCO distributing the copyrighted works of Linux's contributors, and the authors of all the other copyrighted software it currently purports to distribute under GPL? IBM's counterclaim against SCO raises that question with respect to IBM's contributions to the Linux kernel. Under GPL section 6, no redistributor of GPL'd code can add any terms to the license; SCO has demanded that parties using the Linux kernel buy an additional license from it, and conform to additional terms. Under GPL section 4, anyone who violates GPL automatically loses the right to distribute the work as to which it is violating. IBM therefore rightly claims that SCO has no permission to distribute the kernel, and is infringing not only its copyrights, but those of all kernel contributors. Unless SCO can show that the GPL is a valid form of permission, and that it has never violated that permission's terms, it loses the counterclaim, and should be answerable in damages not only to IBM but to all kernel contributors.

IBM's counterclaim painted SCO into a corner on the subject of the GPL. Not only the facts but also the law are now fundamentally against SCO's increasingly desperate position. SCO and its predecessor, Caldera, have benefited enormously from the protections of the GPL. Thanks to the GPL, SCO has been able, for example, to use the invaluable work of compiler designers and implementers around the world who have made GCC the premier cross-platform C compiler. Customer applications run on SCO's Sys V Unix because of GCC, to which SCO contributed modifications particular to its system, and for which it assigned copyright to the Free Software Foundation. Caldera and SCO could not have marketed a usable operating system product without the contributions of the free software community. SCO was happy to take the benefits, but it has unethically sought to avoid its responsibilities. The law does not permit SCO to have it both ways.

So now it has become time for SCO and its lawyers to pound the table. SCO's response to IBM's counterclaim has been a round of absurd attacks on the GPL, its users, and its author, the Free Software Foundation. The GPL, SCO's answer to IBM's counterclaim alleges, violates not just federal statutes but also the United States Constitution. How a private copyright holder can violate the US Constitution by giving others permission to copy, modify and redistribute its work SCO does not deign to say. Legal theories aren't secrets; if SCO's lawyers had anything to offer in support of this novel proposition, they would offer it. Not one case decided in the long history of US copyright affords support to this ridiculous conception of an unconstitutional copyright license. No lawyer of my reasonably broad acquaintance, no matter what his or her view of the GPL may be, takes this moonshine seriously. After failing on the facts, failing on the law, and raising no more than derisive laughter from pounding the table, even the proverbial shyster is out of luck. What will we see next from SCO, an attack on the umpire?

Footnotes
1 The most complete review of the SCO Las Vegas presentation was written by Bruce Perens, and is available at http://www.perens.com/SCO/SCOSlideShow.html.



--------------------------------------------------------------------------------

Copyright © Eben Moglen, 2003. Verbatim copying of this article is permitted in any medium, provided this notice is preserved.

Eben Moglen is professor of law at Columbia University Law School. He serves without fee as General Counsel of the Free Software Foundation.

Monday, November 10, 2003

Outsourcing's Hidden Cost: The Dell Example

I recently tried to purchase a new server from Dell server. I wanted a Dell 650. I was browsing the outlet store @ the time. So I opened another browser window. I went to Dell and began ordering. I got a phone call and then went back to ordering. I wasn't paying attention and completed the checkout at the Dell Outlet Store. The servers were nearly identical price. So I ended up with a 400 SC being shipped instead my 850. I did notice when I received the email confirmation. So I quickly called the Dell Outlet but they closed at 4:00 PM PST. So I called the sales line. They stated that they will not be able to help me as the order was placed with the outlet center. So after an hour of trying to fix it, I give up and order an 650. I call the outlet center the next morning (7:00 AM PST) and find out that the item has already shipped. I asked them to pull it off the truck but they state that's impossible - Why? Because this support center has been sent off shore to India and they are unable to stop it. When I pointed out that it certainly hasn't left the Dell facility, they said there is nothing they can do, they have their procedures. They are not even in the same country as the warehouse. I spent another hour and a half trying to correct the problem. Eventually I gave up and thought well maybe I can use the server since I suspect returning it will be an equal nightmare.

This highlights one of outsourcings hidden costs. Every company over time builds up informal information structures and communication structures. Usually this is in response to meeting customer needs. I have experienced this first hand before when I purchased from the outlet store. I was buying a system for my brother at the outlet store and needed more RAM. (BTW this was before the the customer service center was outsourced to India.) I had already placed the order and needed some changes. I called the customer service number, got a rep who was able to make the changes I need by emailing production and making the changes and billing my credit card seperately. Not the normal procedure but it got the job done. Companies every day have informal structures like this that sprout up like a spider web around the company. They serve to meet customer need and route around damaged processes.

Outsourcing kills these informal connections by severing them completely. By not having these informal connections through out the company, the outsourced division can only follow the rote script. Which in my case was followed to the letter. The script was followed politely, and courteously but it did not solve my problem. Instead I spent 2.5 hours dealing with the problem, still not getting it resolved and the few dollars I saved with Dell was completely wasted as I spent much more trying to correct the order. I have a few questions for Dell.


  1. Why can't I change or delete my order with Dell online like everything else I buy online?
  2. Since you have outsourced the entire customer service division for refurbished systems why do they keep Central Time hours? I spoke with over 20 reps at the center and every single one was Indian (Bangalore I think from the accent). Why not keep all business hours in the US? Isn't the business in California worth it?

Intuitively I know the answer to the first question. Dell is about shipping units, not customer service. By shipping the unit they book the revenue. It doesn't answer the second question though. It couldn't be that hard to add 4 hours to the time that customer service is available could it? Especially give than you are saving tremendously on a per hour basis. Aren't your customers worth it?