FAQ: SCO and Linux

Necessary and important disclaimers: I am not a lawyer, and none of the following constitutes legal advice.  At most it contains one layman's understanding of the law.  In particular, the legal issues are addressed in the context of the laws of the United States.  The rules may differ in other countries.  If you want legal advice, ask a lawyer for it.

I make no pretense of concealing my own biases, but the material presented here is intended to be factual and accurate, though often simplified in the interest of brevity.  Despite my best efforts, it is likely that some errors of fact or of law have crept into this document.  I invite correction of any such errors. Nevertheless the responsibility for the contents of this document is mine alone.

What is SCO doing about Linux?

Four things, mainly:

These actions have outraged the open source community, and perplexed many others in the IT industry. SCO faces a counter suit from IBM and other lawsuits from Red Hat and others.

What is intellectual property?

As the term is generally used, there are four kinds of intellectual property: patents, trademarks, copyrights, and trade secrets.  These four kinds of intellectual property are distinct, and different legal rules apply to them.  Hence the term "intellectual property" has no very well defined meaning in law.  It is best to avoid using the term at all, unless you want to mislead people by blurring important distinctions.

What kinds of intellectual property does SCO claim in Linux?

SCO owns no relevant patents, nor does it claim to.  The Open Group owns the trademarks for "UNIX" and "UnixWare".

The complaint filed by SCO makes only a passing reference to alleged copyright infringement, and that reference does not attribute any infringement to IBM specifically. Indeed, SCO has stated that the filing against IBM is about breach of contract, not about copyrights.

What's left is trade secrets -- information that one or more parties are under contract not to disclose.

Do SCO's versions of UNIX contain trade secrets?

Trade secrecy is like virginity: once lost, it can never be restored.  If someone has disclosed a trade secret, even if the disclosure was illegal and improper, the information is no longer a trade secret.  Only the one who improperly disclosed it is liable for damages.  Others may use the information freely, except of course as that usage may be otherwise restricted by copyright law or other considerations.

It would be difficult for SCO to claim any trade secrets in the UNIX code base that it inherited from AT&T.  Versions of this source code have circulated widely for years, much of it in book form.  Caldera itself has published one version of the source code under a BSD-style license.  The principles and architecture of the AT&T-derived UNIX kernel are described in books and taught in University classes.

It is possible for SCO to claim trade secret status for additions and modifications to UNIX that were made after receiving the ancestral source code.  Such changes could have been made by SCO or by its predecessors in interest.

Kevin McBride, one of SCO's lawyers, has even admitted in court that "there is no trade secret in Unix system files."

Has IBM disclosed any of SCO's trade secrets?

SCO says it has, and IBM says it hasn't.  Until SCO identifies the trade secrets that IBM has allegedly disclosed, it is impossible for an outsider to evaluate SCO's claims.

Likewise it is impossible to evaluate other claims of breach of contract without knowing about the contract.

IBM secured a perpetual and irrevocable UNIX license from AT&T.  Later SCO took AT&T's place as successor in interest.  These contracts are on the public record, but other contracts between the parties may not be - such as the agreements surrounding the ill-fated Project Monterey.

This FAQ will not dwell on the lawsuits between SCO and IBM. IBM can take care of itself.

Does SCO own UNIX?

No. SCO has often claimed to own UNIX, both in their lawsuit and in public statements.  However this claim is demonstrably false.

The trademarks for "UNIX" and "UnixWare" belong to the Open Group.  Legally, UNIX is whatever the Open Group says it is.  In practice, the Open Group is a standards body.  It permits the UNIX trademark to be applied to any operating system that has been shown to comply with the applicable standards, regardless of where the source code came from.  By this definition, a version of UNIX may be genetically unrelated to the original AT&T UNIX.

SCO owns two particular implementations of UNIX, namely OpenServer and SCO UnixWare.

Does SCO own the copyrights to the UNIX source code?

SCO may own copyrights to some of the ancestral UNIX code, as successor in interest to AT&T.  However, the extent of those rights is unclear.

According to a 1993 court ruling, UNIX System Laboratories (a spinoff from AT&T) had "failed to demonstrate a likelihood that it can successfully defend its copyright in 32V."  The terms of the eventual settlement, though not publicly disclosed, were widely viewed as a crashing defeat for USL.

The 1993 ruling would of course not apply to any code written subsequently.  Modifications to code that was covered by the 1993 ruling are a gray area, and would have to be considered on a case by case basis.

According to Ransom Love, a co-founder of Caldera (now SCO), much of the code in UNIX is copyrighted by other companies.  If so, SCO cannot claim ownership of all the UNIX copyrights.

Furthermore, Novell has also claimed copyrights on much of the same UNIX code.  These conflicting claims have yet to be resolved in court.

But didn't SCO just register its copyrights?  Doesn't that establish ownership?

Registering a copyright only records a claim of ownership.  It does not prove that the claim is valid.

Anyone who pays a $30 fee and fills out the paperwork can register a copyright on anything, including someone else's creation.  Such a registration is a formality, a procedural prerequisite for a copyright infringement suit.  A registered copyright may be declared invalid if someone demonstrates that the copyright holder is not entitled to it.

Does Linux infringe on SCO's copyrights?

The most that can be said with confidence is that there is no demonstrated infringement.

Let me repeat that: there is no demonstrated infringement.

Why don't you just say that there is no infringement, period?  It looks suspicious to hedge like that.

Saying that there is no infringement is like saying that there are no unicorns: I can't prove it.  No matter how hard I look, maybe there's a unicorn that I missed somewhere.

On the other hand, if you claim that there are unicorns, then the burden is on you to show me one.  If you point to a goat and a cow as examples of unicorns, your credibility will suffer.  If you then claim that you can't show me any unicorns because they're secret, but that I owe you $699 for every unicorn on my property, don't be surprised if I refer your invoice to the nearest Attorney General.

But SCO already showed two examples of infringing code.  Even a non-programmer could tell that the Linux code was almost identical to the SCO code.  You can't explain that by coincidence.

Yes, it was similar, and not by coincidence.  However, similarity does not establish provenance.  From merely comparing the code you can't tell whether the Linux code was derived from the SCO code, or the SCO code from the Linux code, or both from a common ancestor.

To establish provenance you have to trace the history of the code -- who contributed it in the first place, who contributed each modification, and when.  For Linux this history is in the public record.  Anyone who knows how to look it up can do so.  For SCO's code, and for proprietary code in general, that history is not publicly available.

What about the first example -- the memory allocation code?  Even the variable names are the same.

This code goes back to at least 1973, and was originally written by either Dennis Ritchie or Ken Thompson when they were both at AT&T.  Versions of this code appear in various versions of UNIX, including BSD and the AT&T flavors.  One version appears in The C Programming Language by Kernighan and Ritchie, a widely used textbook.

Because the differences among these versions are very minor, it's difficult to determine from the code alone exactly which was derived from which.  Several people in the open source community analyzed the possibilities and came to somewhat different conclusions.  However, it is clear that the Linux version is only trivially different from a version that was released as open source under a BSD-style license by Caldera (now SCO) in 2002.

This code was present in Linux only briefly, and applied only to some SGI hardware that never found more than a handful of customers.  It was removed for technical reasons even before SCO publicly identified it as an alleged infringement.

What about the second example?

In the second example, what SCO claims as its own code comes from the Berkeley Packet Filter (BPF), and does not belong to SCO at all.  Under the BSD license either SCO or Linux may use this code, though the attribution must be preserved.  The fact that SCO claims the code as its own suggests that at least one of the following is true:

The Linux version is not derived from the BSD code.  It is a clean room implementation written by Jay Schulist, based on a protocol specification.  It looks similar to the BSD code because each version implements the same specification in the most obvious way.  It would have been unnatural to implement it in any other way.

SCO originally labeled the Linux version as obfuscated, meaning that the Linux developer had deliberately tried to disguise the origins of the code.  Later, SCO backpedaled, insisting that the code samples were shown only to demonstrate SCO's ability to detect obfuscation.  You can judge for yourself what this episode demonstrates about SCO.

Didn't SCO later identify a number of other infringing files?

In a court filing, SCO provided a list of 591 files of Linux source code, saying that "information IBM should have kept confidential was or may have been improperly used or incorporated" in those files (emphasis added).  That's like saying to a detective, "The murderer's name may be somewhere in this list," and then handing him a copy of the Manhattan telephone directory. 

Despite SCO's claims to have performed advanced code analysis, these files appear to have been identified by a few primitive text searches, looking for such key words as SMP and RCU.  In some cases these key words occur only in comments or error messages.  Whoever came up with this list of files clearly didn't pay much attention to their contents.

The same filing listed 115 other source files that allegedly contain infringing code.  However the filing didn't specify which lines supposedly infringed, nor did it say much about the nature of the infringement.  Some of the files apply only to architectures that SCO's own products do not support.

Finding that SCO had been too vague about its claims, the judge gave SCO 30 days to come back with something specific enough to be useful.  At this writing, SCO's response is not yet available, and will probably be protected under an order of confidentiality.

In a threatening letter to Unix licensees, SCO listed 65 files as infringing.  Almost all of these files were simple header files specifying values for various error codes and the like.  Their contents are broadly specified by various industry standards. 

If you're a C programmer, you know how preposterous it is for SCO to claim ownership of standard header files like errno.h and signal.h. If you're not -- well, it's as if a cookbook publisher demanded that you pay him royalties every time you prepare any dish that involves flour, butter, or eggs.

If there is infringing code in Linux, who is liable for damages?

If there is an infringement, whoever contributed the infringing code would be liable.  In practice, however, senior Linux developers are very careful about copyrights.  There are cases on record where contributions have been refused solely because of doubt about their copyright or patent status.

A Linux distributor might be liable if it had failed to show due diligence.

Would an end user be liable for damages?

In general, an end user is not liable for damages under copyright law.

If Stephen King wrote a novel,  and Paramount Studios turned it into a movie without his permission, King could sue Paramount.  He could not sue the movie theaters, unless they had somehow colluded with the studio in the infringement.  He certainly could not sue the people in the audience, even if it were economically feasible to do so.

Strictly speaking, if an end user made multiple copies of a CD containing an infringing copy of Linux, or installed such a Linux on multiple computers from a single CD, he might be liable for unauthorized copying.  As long as the copying was done in good faith, however, it is not likely that any judge or jury would hold him liable for more than nominal damages, if any.

Furthermore, in the unlikely event that SCO collects damages from IBM for the alleged trade secret violations, SCO cannot also collect damages from end users for the same infringement.

If end users are not liable, then how can SCO threaten to sue them?

Beats me.

Isn't it possible that someone slipped some SCO code into Linux, and the rest of the Linux team didn't realize it?

Of course it's possible.  There's no way anyone -- either Linux developers or proprietary developers -- can be completely sure that a piece of code wasn't copied from somewhere else, especially if the original was proprietary code, not available for comparison.

However, there's little incentive for anyone to misappropriate code into an Open Source project such as Linux.  Since all the code is in the open, infringements cannot be concealed.  Anyone caught misappropriating code, especially for such a high-profile project as Linux, would instantly become a pariah, apart from any civil or criminal liability.  Such ostracism would be no small penalty in the open source community, where an individual's primary reward for contributions is not money, but bragging rights.

The same is not true of proprietary code.  If SCO were to misappropriate Linux code into its own products, the infringement would almost certainly go undetected, unless it were disclosed by an insider or through discovery proceedings.

Indeed, precisely such an infringement has been alleged by a former SCO employee, in the case of the Linux Kernel Personality.  These allegations are currently unverifiable because SCO's proprietary code is not publicly available for inspection.

Still, suppose there is infringing code in Linux. Can SCO claim damages?

For trade secrets, no one is liable for damages except the people who improperly disclosed them.  If you didn't promise to keep a secret, you aren't obliged to keep it.

To pursue a claim of copyright infringment, SCO would have to establish a valid copyright claim -- not a simple task for the AT&T code, due to the 1993 ruling, and due to Novell's competing claim for the same copyrights.

Furthermore, the plaintiff in a copyright infringement case must make a good faith effort to mitigate the damages, where possible, by letting the defendant remove the infringing material.  SCO has steadfastly refused to do so.  It refuses to identify the allegedly infringing code, or even to provide any evidence of infringement, other than the two examples discussed earlier -- both of which were immediately shown to be spurious.

But if SCO identified the infringing code, the Linux people would just replace it.

Yes, they would, assuming of course that they agreed that it infringed.  The question is, why does SCO want to prevent them from doing so?

Replacing infringing code would in no way remove the evidence of infringement.  The developmental history of Linux is a matter of public record, available from many sources around the globe.  The Linux community could not expunge it even if they wanted to.

In fact, one of the spurious claims of infringement (the memory allocator) was based on code that had already been removed from the most current version of Linux.

There are at least two possible reasons why SCO refuses to identify the alleged infringements:

Why would SCO want infringing code to remain in Linux?  Perhaps to extend and preserve the damages that they think they can claim; or perhaps to preserve a basis for demanding that end users buy additional licenses.  In any case, SCO's refusal to mitigate the alleged damages will severely undermine any copyright infringement suit that it may bring to bear.

The most authoritative clue comes from Darl McBride himself:

Our belief is that SCO has great opportunity in the future to let Linux keep going, not to put it on its back but for us to get a transaction fee every time it's sold. That's really our goal.

Do I need a license from SCO to run Linux?

You should ask your lawyer.  If you ask me, I say: No.

The GNU General Public License (GPL) gives you all the permission you need to run Linux, as long as you remain in compliance with its provisions.  You may also redistribute it, modify it, and redistribute it with your modifications, provided that any redistribution is under the GPL as well.  Consult the text of the GPL itself for the full details.

Buying a license from SCO -- or even accepting one for free -- would be an acknowledgement that you need SCO's permission to run Linux.  Such a license would grant you no rights that you don't already have.  In fact it would forfeit some of the rights you do have, and grant SCO some rights that it does not otherwise have.

How would SCO's license interact with the GPL, for the same software?

They are completely incompatible.  SCO's license explicitly denies you rights that the GPL explicitly grants you.

Under SCO's license, you agree not to modify or redistribute SCO's Product, where the "SCO's Product" is defined as "SCO intellectual property in Object Code format."  The GPL, on the other hand, expressly grants you the right to modify or redistribute Linux, subject to certain restrictions.  This attempt to alter the terms of the licensing terminates all of SCO's right under the GPL, including the right to redistribute Linux.  Your rights under the GPL as a licensee in good faith are not affected by SCO's forfeiture of its own rights.

Furthermore, since SCO refuses to specify what parts of Linux it claims to own, you have no way to modify or redistribute the parts that SCO does not claim to own.  Hence the restrictions of the SCO license effectively apply to all of Linux, including the parts that belong to others.

Even if SCO identified the parts of Linux kernel that it claims to own, it could not license those parts under a license of its own devising while the rest of the kernel remained under the GPL.  The GPL does not permit the commingling of GPL code with code under an incompatible license in the same program.

It would be possible for SCO to use a dual license scheme, licensing its source code under the GPL for use In Linux, but licensing the same code under some other license in other contexts.  Some companies have done so.  SCO has not.

If Linux infringes on SCO's code, don't I need SCO's permission to use it?

If you received your Linux distribution from SCO (formely Caldera), then you already have a license from SCO to use that distribution.  SCO cannot unilaterally and retroactively change the terms of that license, even for code belonging to SCO, and certainly not for code belonging to others.  Even the attempt to do so terminates all of SCO's rights under the GPL.

If you received your copy of Linux from another distributor, then you have a license from that distributor, and from each of the contributors (including SCO).

But SCO says it distributed the infringing code inadvertently, so the GPL doesn't apply.

This argument would be more interesting if SCO had halted its distribution as soon as it became aware of the alleged infringement.  But it didn't.  As recently as December, 2003, SCO was still offering a version of Linux 2.4 for download by FTP.  By knowingly distributing the code after becoming aware of the alleged infringement, SCO has acquiesced in the publication of that code under the GPL.  Therefore SCO itself has cured any alleged infringement.

SCO says that the GPL is invalid, because it is trumped by copyright law.

According to copyright law, you may make a backup copy of a piece of software, and you may copy it as needed for execution (in the sense that the program is copied, for example, to memory), notwithstanding restrictions on copying imposed by the copyright holder.  This provision applies specifically to software, and not (for example) to books, because software is different from books.

SCO's interpretation -- raised in the press but not, so far, in a courtroom -- is that this provision creates a ceiling rather than a floor.  In other words, according to SCO, you cannot legally make multiple copies of copyrighted software, even if the copyright owner explicitly gives you permission to do so.

This legal theory is so bizarre and deranged that no one who is not in the pay of SCO takes it seriously.  It's doubtful that anyone at SCO takes it seriously either, except as a way to confuse and frighten potential users of open source software.  If by some freakish mischance this theory were upheld, Dell and Compaq would not be able to sell you a PC preloaded with Windows, nor with any other copyrighted software that they didn't write themselves.

Despite this novel legal theory, SCO has long redistributed other people's software under the GPL, and continues to do so.

SCO can't have it both ways.  It can't redistribute software under the GPL while insisting that no one else may do the same.

What about SCO's claim that the GPL is unconstitutional?

SCO's constitutional argument is mostly an exercise in flag-waving rhetoric.  So far as any coherent legal theory can be discerned, it appears to be as follows:

A recent Supreme Court decision in the Eldred case recognized direct monetary rewards to be a significant and legitimate incentive for individuals in the promotion of the "Progress of Science and useful Arts."  So far, so good.  The next step was to conclude that direct monetary reward is the only permissible incentive.  Congress has no power to allow anything but greed to motivate a copyright holder.

This astonishing non sequitur was of course greeted by legal scholars with snorts of derision.

In order for SCO to succeed in undermining the GPL, the GPL must fail in a very special way.  It must be valid enough that SCO can continue to redistribute other people's software under the GPL, but not so valid that SCO is obliged to honor its provisions.

Has the GPL ever been upheld in court?

Until SCO came along, no one had ever dared to challenge it in court.

People sometimes cite a case between MySQL and Progress Software as a legal validation of the GPL.  However, while Judge Patti Saris appeared to take the GPL seriously, she avoided ruling on its validity.  The parties settled before trial.

This pattern is typical.  Those caught violating the GPL generally settle out of court rather than challenge the GPL itself.  The absence of challenges is a sign of strength, not of weakness.

A case has recently arisen that, if it ever reaches a courtroom, may resolve some of the legal issues.  However this case does not question the validity of the GPL itself.  Rather, it seeks to clarify the notion of a derivative work, as defined by the GPL.  This notion has always been a little fuzzy, because it's hard for a static, generic legal document to anticipate all the twists and turns of technology.

But the GPL is about copyright, that is, the right to copy.  Don't I also need a run time license?

No.  If you have a legal copy of a program, you may run the program - unless you have agreed to accept other conditions.  Because the law does not require a run time license, proprietary software vendors typically contrive to extract your agreement to such a license, whether a shrink-wrap license, a click-through license, or a signed contract.

Are there any other disadvantages to the SCO license?

If you are using any Linux distribution other than Caldera's, there is the obvious issue of cost.  You would give money to SCO without receiving any additional functionality.

In addition, the SCO license requires you to keep detailed records of your Linux systems and your SCO licenses, and to release that information to SCO at their request.  You agree to let SCO audit your systems at any time, at SCO's expense.  If the audit determines that your records aren't accurate enough, you must pay for the audit.

But at least SCO would promise not to sue me for infringement - right?

Such a promise would be of doubtful value, since according to normal interpretations of the law, an end user is not liable for infringement anyway.  With or without SCO's license, such a suit by SCO would likely be ruled frivolous.

An SCO license may help you avoid such a lawsuit, which would be expensive and burdensome to fend off, even if frivolous.  However, take a close look at the following provision in section 5.0 of the license:

SCO may terminate this Agreement, upon reasonable notice and without judicial or administrative resolution, if Company or any of Company's employees or consultants breach any term or condition hereof.

As a non-lawyer I'm not sure what this verbiage means.  It seems to say that SCO can, at its sole discretion, declare at any time that you have breached the Agreement, and terminate it accordingly.  You would have no right of appeal or other recourse, because you would have already waived all "judicial or administrative resolution."  Then SCO could sue you just as if you had never purchased a license.

SCO's attempt to terminate IBM's UNIX licenses demonstrated this kind of tactic almost precisely.  SCO made vague and unsubstantiated claims of infringement, but refused to provide enough information for IBM to try to cure the alleged infringement.  After the required 100 day waiting period, SCO purported to terminate IBM's UNIX licenses, even though the licenses were clearly defined as irrevocable.

A statement issued by SCO has said that "Contracts are what you use against parties you have relationships with."

Do you really want a relationship with a company that has that kind of attitude?

Neither do I.

References -- Copies of various filings in the SCO/IBM case, including SCO's original complaint, its amended complaint, and IBM's responses. -- Transcript of a court hearing on December 5, 2003, in which (among other things) SCO admits that there are no trade secrets in Unix system files. -- A detailed dissection of SCO's filing, by Rob Landley and Bruce Perens. -- OSI Position Paper on the SCO-vs-IBM Complaint, by Eric S. Raymond and Rob Landley. -- SCO threatens to sue end users. -- News article quoting Darl McBride: "The Linux community would have me publish it now, (so they can have it) laundered by the time we can get to a court hearing." -- Darl McBride seeks a transaction fee for every copy of Linux sold.,aid,110904,00.asp -- News article quoting an SCO statement about the use of contracts. -- SCO announces plans to offer an SCO Intellectual Property License for Linux. -- Bruce Perens, among others, analyzes what SCO claims to be examples of pirated code. -- Eric S. Raymond analyzes what SCO claims to be an example of pirated code. -- Greg Lehey's analysis of what SCO claims to be examples of pirated code.;jsessionid=MELSVVCOMGMYQQSNDBCSKHQ?articleID=13900143&pgno=1 -- Chris Sontag of SCO backpedals on the claims of obfuscated BPF code. -- SCO lists some allegedly infringing files of source code. -- A corrected version of SCO's file list, with commentary. -- A reconstruction of how SCO came up with its file list. -- A detailed discussion of the header files claimed by SCO. -- An interview with Linus Torvalds.,3959,1227128,00.asp -- Another interview with Linus Torvalds, noteworthy for his "smoking crack" remark. -- Interview with Darl McBride, where he accuses IBM of orchestrating the response of the open source community to SCO's actions. -- Eric S. Raymond's angry response to McBride's accusations (above). -- Darl McBride's so-called Open Letter to the Open Source Community, in which he misquotes Bruce Perens, and accuses Linux developers of a "don't ask, don't tell" policy on intellectual property rights.,10801,84819,00.html -- An interview with Darl McBride, following his Open Letter. -- Linus Torvald's laconic response to McBride's Open Letter. -- Eric S. Raymond and Bruce Perens respond to McBride's Open Letter. -- Another response to McBride's open letter, from a group of open source advocates at Groklaw. -- A 1993 court ruling denying injunctive relief to UNIX System Laboratories on the basis of copyright issues.,4149,1300359,00.asp -- An interview with Ransom Love, noting that Unix's code is "full of other companies' copyrights." -- Novell claims ownership of UNIX copyrights. -- Required reading: the GNU General Public License. -- An account of the MySQL vs Progress Software case. -- A news item on the MySQL vs Progress Software case. -- the FSF's spin on the MySQL vs Progress Software case. -- An interview with a lawyer about the intellectual property issues surrounding SCO's claims. -- Eben Moglen, a Columbia University law professor, discusses SCO's claims. -- Eben Moglen again, countering SCO's claim that the GPL is legally invalid. -- Eben Moglen discusses the enforceability of the GPL. -- Another lawyer, Lawrence Rosen, discusses the legal issues. -- The text of the SCO Intellectual Property License for Linux. -- A list of registered products complying with Open Group standards. -- Compares various flavors of UNIX and UNIX-like operating systems, and describes their various degrees of compliance with Open Group standards.,3668,a=43186,00.asp -- Allegations that SCO has violated the GPL by copying Linux code into the Linux Kernel Personality product.


The following sites include many links to SCO-related resources.

UNIX and UnixWare are trademarks of the Open Group. AIX is a trademark of IBM. Linux is a trademark of Linus Torvalds. OpenServer is a trademark of the SCO Group.

Last updated: 2004/01/11 07:43:16 AM CDT. For the most recent version of this document see: Also mirrored at, with thanks to Gregg Sperling.

Copyright 2003, 2004 by Scott McKellar ( You may reproduce this document in its entirety in any medium without restriction, provided that you preserve this notice.