Could SCO v IBM happen to you?1

By Jeremy Malcolm2


SCO's litigation against IBM is widely and properly regarded as an opportunistic and disingenuous gambit that has seriously backfired on the company. However, SCO's point is that the open source development model does not adequately vet contributors' code for violations of intellectual property rights. There is some truth in this, particularly since it is possible to breach intellectual property rights (such as patent rights) completely innocently. Regardless of the merits of SCO's claim, open source developers do need to sit up and take notice of the issues the litigation has raised. This paper will enumerate those issues, and suggest some of the steps that open source developers should be taking to address them, and thereby protect themselves against litigious intellectual property owners.

The players

The emergence of SCO as the Great Satan in this battle has come as something of a surprise to many, especially since the corporation that now calls itself The SCO Group is not actually the original Santa Cruz Organization, but rather the former Linux vendor and developer known as Caldera Systems.

The former Caldera's metamorphosis from a participant in the open source world to its greatest enemy began when the company purchased the UNIX business of the original SCO, which was the vendor of a UNIX variant for the SME market called Openserver, and a higher-end, more modern UNIX called Unixware.

More important however than the operating systems that SCO purchased were the intellectual property rights behind them. This package of rights can be traced back to AT&T, the original owner of UNIX, who passed these contracts on to Novell before SCO purchased them in 1995.

One of the licensees of SCO's intellectual property in UNIX is IBM, as the vendor of its own UNIX variant called AIX. IBM's licence to develop and release AIX based on the original UNIX sources is dependent on a couple of contracts that SCO now has the benefit of.

What stage are we at?

The litigation is still at its early stages. It began on 6 March 2003 when SCO filed a complaint in the Utah State Court suing IBM for $1 billion, which it later raised to $3 billion. It will be more than two years later on 11 April 2005 when the case will finally be determined. In the meantime there is a whole lot of uncertainty for Linux users, which some would say is exactly what SCO wants.

Looking into our crystal ball, we can have a fair amount of confidence that SCO will eventually fail. For one thing, there is no evidence that there is any actual UNIX code present in Linux. SCO has presented some supposedly copied code under the terms of a non-disclosure agreement. But all the public has been shown has been a couple of Powerpoint slides in a presentation by SCO CEO Darl McBride at last year's SCO Forum in Las Vegas. One of these slides didn't actually contain any UNIX System V code, but pre-existing BSD code that later made its way into System V. The other slide showed some old pre-System V code that, if it wasn't already public domain, SCO released into the public domain in 2002.

So, as far as we know, there isn't any actual proprietary SCO code that has been copied into Linux. Even if there is, arguably it isn't proprietary code any more, because SCO itself has been distributing the Linux source code under the terms of the GPL, and as soon as they did that, it became free software. Their only defence to that argument is along the lines of, “Oops, we didn't mean to do that”. Whether that washes in court is to be seen. As an aside, if UNIX code has been copied into the Linux kernel, there is also an allegation that SCO has copied Linux kernel code into UnixWare, so perhaps the borrowing has not been one-way.

Regardless of the dubious legal strength of its case, SCO is making as much mileage as it can from the fear, uncertainty and doubt that the case has generated in the community. In a letter to 1500 of its customers on May 12, SCO warned them not only about their use of the Linux kernel, but also of other open source software. They then sent another more specific letter on 19 December to several hundred large customers notifying them of a number of allegedly infringing header files supposedly taken from BSD.

As another aside, these header files are the same files that SCO's predecessor AT&T already sued the University of California Berkeley over. As you may recall, in 1992 AT&T and Berkeley settled that dispute resulting in half a dozen files in the 4.4BSD-Lite distribution being removed, and a bunch of others being changed or having AT&T's copyright attribution reinserted. Although the court didn't make a final decision on this because the case was settled, there was a strong suggestion that the remainder of what was common between 4.4BSD-Lite and UNIX System V had already passed into the public domain.

On 19 November 2003 SCO released a statement threatening to broaden its legal onslaught to users of BSD code during the first half of 2004. Presumably the BSD code SCO is referring to is what was required to be removed or changed in the 4.4BSD-Lite distribution, because as part of the settlement users of the rest of the BSD code are protected. SCO's latest letter to its customers of 19 December would appear to be the first step in this new initiative, which goes beyond the scope of its claim against IBM.

Linux and BSD-based operating systems aren't the only ones in SCO's firing line. On 16 June 2003, SCO hinted that it could have the right to take action against publishers of other operating systems such as Windows and MacOS, to the extent that those have been derived from UNIX also. So far however, when last I checked, Microsoft Windows is still on sale.

So is SCO's bark worse than its bite, or will it be following through on any of its bluster? Well, so far it is difficult to say. On 19 November SCO claimed it was about to sue just one major Linux customer for copyright infringement. That hasn't happened so far. It has also made vague threats against certain other of its competitors, such as Novell whose merger with SuSE SCO threatened to block on the grounds that it contravened a non-compete agreement between them. SCO hasn't however taken any action on these threats so far.

On the other hand, SCO's actions have not gone unanswered by its competitors. On 4 August 2003 Red Hat sued SCO seeking a declaration from the Delaware Federal Court that the Red Hat Linux distribution did not infringe SCO's intellectual property. Two days later, IBM sued SCO essentially for breaching the GPL. IBM and Hewlett Packard have also taken the initiative of offering a limited indemnity to their customers against claims of intellectual property infringement by SCO.

So where are we now in the litigation process? The most recent development was when IBM obtained a court order on 5 December requiring SCO to produce the code that it claims is infringing by 11 January, which should be made public at the next court hearing on 23 January 2004.

Meanwhile, Australia has not been entirely exempt from the effects of the SCO litigation. SCO's Australia and New Zealand manager Kieran O'Shaughnessy is in London this very week to finalise the terms of Linux licences to be offered by SCO to Australian users. Its licences to American users have been priced at about AU$900 per server and about AU$250 per desktop. Meanwhile back in July, Open Source Victoria filed a complaint with the ACCC over SCO's actions claiming it had engaged in misleading and deceptive conduct. No formal investigation has yet been launched.

What is SCO saying?

So that is the history of the litigation so far. But let's back-track a little and look at what it is that SCO claims against IBM in a little more detail. SCO is claiming that by using UNIX source code, or knowledge derived from its work on UNIX source code in Linux, IBM breached contracts that it had entered into with SCO.

Powerpoint slides notwithstanding, SCO's claim against IBM doesn't entirely depend on IBM having directly copied code from the UNIX kernel sources into Linux. It also extends to IBM having used the knowledge and expertise that it obtained from the UNIX kernel sources in developing similar technologies for Linux. These include scalability, performance and scheduling improvements, a journaling filesystem (JFS), volume management, clustering, and 32 and 64-bit processor support. Many of these technologies were not part of the UNIX code that IBM originally licensed, but were developed subsequently. Some of them were even developed by IBM itself. However, SCO claims to be entitled to prevent IBM from introducing these technologies into Linux because they are works that are derived from the UNIX code.

SCO says that IBM's breaches of contract entitle it to terminate IBM's licence to use UNIX in AIX, and in fact it claims to have done that on 16 June 2003 (which IBM disputes). But frankly, the contractual arrangements between IBM and SCO (or originally with AT&T) are complex, and not particularly interesting to us.

Much more interesting is the question whether IBM has breached any intellectual property rights in UNIX, because that question is potentially of relevance to the rest of us. SCO's original court complaint did indeed seem to claim that IBM had breached SCO's intellectual property rights in UNIX, independently of the contractual arrangements between them. But this arm of SCO's claim was thrown into doubt on 28 May 2003 when Novell stated in a press release that copyright and patent rights were never included in the package of rights over UNIX that SCO purchased from Novell.

SCO and Novell are currently fighting over whether SCO did obtain copyright to the UNIX code pursuant to a 1996 amendment of its contract with Novell, and how many unexpired patents if any SCO might have over the code, however the question is somewhat moot because its amended complaint against IBM has retracted the previous claims of breach of intellectual property rights. This means that as far as the court case is concerned, we are not necessarily going to get an answer to the question of whether IBM has committed copyright and patent infringement, but only whether it has breached any contracts that can be enforced by SCO, and whether it has engaged in unfair competition or interfered with contracts between SCO and its customers.

Intellectual Property Law 101

As I have indicated, the legal issues that are going to be ventilated specifically in the case against IBM may not be particularly useful to the open source community because we are interested in whether Linux infringes any intellectual property rights, rather than whether IBM has breached its contracts with SCO. But because SCO is making noise about suing other Linux customers directly, it is still important for us to consider intellectual property law.

Intellectual property rights fall into a number of categories, including copyright, trade secrets, trademarks and patents. I will briefly summarise each of the types of intellectual property rights before we consider the risks that developers of open source software such as the Linux kernel could inadvertently be in breach of these rights.


Copyright is the most obvious form of protection of computer software and probably the easiest not to accidentally infringe. Like copyright in a novel, it is not the ideas in the software (or the novel) that are protected, but the expression of those ideas. So, the fact that Linux may work in much the same was as UNIX does not give SCO any grounds of complaint under copyright law; that could only be the province of patent law.

The existence of copyright over software doesn't necessarily imply it cannot be copied. It is well within the power of the copyright owner to licence you to copy the software, and of course this is exactly what open source software is all about. The copyright owner can however impose conditions on the licence you have been given; for example, in the case of software released under the GNU Public Licence (GPL), it is a condition that any modifications of the software are also released under the GPL.

Assuming that there is identical code in the Linux kernel and in UNIX and that the UNIX code hadn't been freely licensed, this may indicate that there has been an infringement of copyright. However it doesn't necessarily mean that, because simple functions can be independently written in the same way, and copyright law permits this. This is the explanation that has been given for the similarity of some of the header files between BSD and Linux. In fact, extremely simple functions or comments may not even attract the protection of copyright to begin with.

Trade secrets

Quite unlike copyright law is the law of trade secrets or confidential information. The idea behind trade secrets law, as developed by judges over hundreds of years, is that if you are given information in confidence you must respect that confidence. Often (as in IBM's case), the obligation of confidence that the law imposes is backed up by a contract, but it need not be.

The advantage of trade secrets protection as against copyright protection is that it can in fact protect ideas, rather than just the form in which those ideas are expressed. The main disadvantage is that, unlike copyright protection, the intellectual property owner can lose the protection that they enjoy if they allow their secrets to become known to the public.


Patents are in some ways like a statutory form of trade secret rights, except that they are only available to protect new and innovative products or processes rather than just any secret information, and that they prevent the public at large from using that information, rather than just those who were given the information in secret.

In Australia patents last for twenty years (or in some cases eight years). Although this is a long time, it is substantially shorter than the period that copyright lasts for, so for example in the context of the SCO litigation, many of the original AT&T UNIX patents have now expired.

Although for a long time software couldn't be protected by patent rights, this is no longer the case, so there are a lot more software patents than their used to be. The main advantage of patents for the protection of software is that the concepts or ideas in that software can be protected, rather than just the code. Assuming that the software process is innovative enough to qualify for patent protection, it prohibits others from using the protected concepts or ideas even accidentally.

The main disadvantage is that the costs of gaining patent protection can be quite high, and such protection must generally be taken out separately in every country of the world in which protection is required.

Trade marks

The final form of intellectual property protection is trade mark law, which only protects identifying marks or symbols, and is therefore less relevant to the SCO case. As a point of interest, however, despite SCO's ownership of a number of intellectual property rights to UNIX, it doesn't own the name “UNIX” itself. This is a trademark registered to The Open Group Inc, which controls the basic standards for UNIX systems.

What issues does the litigation raise?

Now that we know all about the facts of the SCO case and the basics of intellectual property law, we are in a better position to assess the vulnerabilities of the Linux kernel and other open source software to attack by companies like SCO. Some of the issues that arise out of the facts of the IBM case in particular are these:

When are you allowed to copy?

There are at least three circumstances in which you can copy code from proprietary software:

  • Where the software has entered the public domain. This automatically happens after the copyright expires, but that doesn't happen for 50 years (70 years in America). Software can also be placed into the public domain deliberately by the copyright owner if they abandon their copyright or “licence” it into the public domain.

  • Where the copying is not of a substantial part. The phrase “substantial part” is given both a quantitative and a qualitative meaning; in other words a small but vital code snippet might be protected by copyright where a longer and less important section of code might not be. It can be risky to rely too much on this copyright exception without taking legal advice.

  • Where the material copied is trivial. Again, this is a judgment call. Sometimes, there is only one way in which something can be coded or commented (a “hello world” program might be a good example). In those cases, the code or comments would not be treated as a literary work that attracts the protection of copyright at all (and they would be unlikely to enjoy trade secret protection either, subject to the terms of any contract the developer may have signed).

  • Where the copying is non-literal. There is nothing to prevent you from re-engineering the functionality of a copyright program. At least, there is nothing in copyright law that prevents you from doing so. This of course was what the GNU project was originally all about.

  • In Australia you have the benefit of a provision of the Copyright Act that allows you to copy proprietary code (including decompiling or reverse-engineering it), in order to create an interoperable product, so if that is what you are doing it is not necessary to be too paranoid about breaching copyright.

It is impossible to say at this stage whether the code that is alleged to have been copied from UNIX into the Linux kernel would fall within any of the categories above. However, the possibility can't be absolutely ruled out based on early comments of some of those who have viewed that code under non-disclosure agreements with SCO.

But I didn't copy anything!

On the other hand, the fact that you didn't copy any code doesn't necessarily clear you from a breach of intellectual property rights. There are at least three cases in which you can still be liable for code that you wrote yourself:

  • If a trade secret covers the code. In IBM's case, the fact that it was working on two UNIX-like operating systems at once was always a danger. It was not unmindful of this danger, but for smaller developers it can be more difficult to protect yourself from being infected by confidential information if you have taken on trade secret obligations.

  • If the technology is patented. This is much the same problem, only more so, since you do not have to knowingly take on a duty of confidentiality in order to be subject to the obligation to honour other peoples' patents.

  • If you have created a derivative work of someone else's copyright software. This normally occurs when you are creating a patch or a fork of someone else's software, but it can also occur when you are just creating a library or plugin to work with other software, so you have to be careful.

What is a derivative work?

It is probably worth investigating this last issue in more detail. The question of what is and isn't a derived or derivative work of another in the context of computer software is probably the most important unanswered question of copyright law. There is no clear dividing line at which an extension to software stops being a “derived work” of that software that the original developer controls. There are other contexts in which the answer is much clearer, such as in the case of a translation, a musical cover version, stage or screen adaptation, an abridgment or artistic rendering.

At one extreme, the Free Software Foundation contends that a derivative work of GPL code is created simply by linking to that code, even if the linking is dynamic rather than static, ie. the GPL code is accessed at run-time from a separate library file. At the other extreme, it can be argued that neither static nor dynamic linking creates a derivative work, because no modifications to the linked code itself are made when it is referenced or accessed through the API that it provides.

The correct position probably lies somewhere between the two. A program that dynamically links to a library probably does create a derivative work of that library. On the other hand, a program that simply interfaces or interoperates with another, using an API or higher-level interface, does not for the purposes of copyright law make the first program a work that is based on the second program, and hence it probably cannot usually be described as a derivative work.

To use a concrete example, user-space programs that interface with the operating system using standard system calls fairly clearly aren't derived works of the system. What about kernel modules? If they are derivative works, they would have to be released under the GPL because that is the licence under which the kernel is released, and binary-only kernel modules would therefore be illegal. Linus Torvalds expressed the view on the kernel mailing list on 3 December 2003 that it depends on whether it “plays with fundamental Linux behaviour”. He could well be correct. The question really hasn't ever been considered by a court.

Relating this back to the SCO case, IBM's development of extensions to the original UNIX code in AIX may well not be in breach of any copyright if it did not create a derived work of that original code. In particular, for SCO to call a filesystem such as JFS, the first implementation of which IBM developed for AIX (but which then re-implemented for OS/2 and ported from there to Linux), a “derived work” of UNIX is a bit of a stretch, to say the least.

How to protect yourself

The open source community has been quite lucky that it has not suffered an attack like the one from SCO earlier. Perhaps this is because the open source community does not, in general, have deep pockets from which to satisfy a court judgment, and that the appropriate defendant to legal proceedings is not always obvious, particularly in the case of something like the Linux kernel that no single person controls.

So although the SCO case is the first significant legal attack against the open source community, it is unlikely to be the last. For example, it is likely that the Linux kernel already infringes various software patents. Holders of these patents could take action against the Linux kernel developers requiring them either to licence the protected concepts or to cease using those concepts in the Linux kernel. The same applies equally to other open source projects.

We obviously have to look hard at what lessons we can learn from SCO, then, in order to protect ourselves against future litigation of this type. There are several ways in which we can attempt to do that.

Chinese Walls

The first one only applies to those who wish to work on proprietary projects and open source projects at the same time. A so-called “Chinese wall” is an invisible barrier that a company can erect to separate two areas of the firm from each other in order to restrict their ability to pass confidential information from each other. IBM essentially claims to have done this between its AIX developers and its Linux developers. Will this wash?

If it is done properly, I think it can, but it is risky. To begin with, the developer may have a contract with those who hold rights over the proprietary software which could prevent them from working on any competitive product, and this is one of SCO's arguments against IBM. But even if not, there will be obligations of confidentiality, and the argument that you have breached such obligations even inadvertently is one that you don't want to have to face in court.

On the other hand, you cannot be prevented from using information that wasn't confidential to begin with, unless you have signed a contract that specifically says so. A practical result of this is that much of the UNIX source code that SCO is claiming as its intellectual property will have lost its trade secret protection because it is no longer confidential, having been disclosed through SCO's own contributions to the Linux kernel source code, and its publication of “Ancient UNIX” source code on the Web under a free licence.

The buck stops with the developer

It may sound mercenary, but the best protection for an open source project against liability for the actions of its developers, is to make the developers assume that liability themselves. This is only sensible, because it is the developers, rather than the leaders or coordinators of an open source software project, who are in the best position to ensure that the code is free of intellectual property infringements.

To ensure that responsibility for the cleanliness of contributed code lies with the developers, the project leader should require them to agree in writing that all of the code they contribute has either been written by them, or has been taken from a source that is in the public domain or has compatible licensing terms. This should be kept on a register along with full details of any open source or public domain code that has been incorporated into the project.

If an open source developer is involved in any proprietary projects, they and their employers should provide clearance to allow them to work on the open source project, specifically acknowleding any non-disclosure agreement or duty of confidentiality to which they are subject. Ideally, although this may be a bit much to ask of a volunteer, the developer should also agree to grant his or her colleagues in the project an indemnity for any loss they might suffer if the contributor's statements about code cleanliness and confidentiality are false.

Examples of these kinds of agreements and declarations are often found in larger open source development projects such as the GNU project, Mozilla and, but smaller projects would also greatly reduce their risk of liability if they required their developers to acknowledge their responsibilities in this way. Some developers may be scared away by such legal bunkum, but this has to be balanced against the legal liability that could otherwise attach to the project leads.

Choose the right licence

Some software licences provide greater protection than others against contributors who introduce patented technologies into the project. One of the best licences in this respect is the Mozilla Public License which provides in clause 8.2 amongst other things that if a licensee of software brings a patent claim against any developer or contributor of that software, then unless they can agree with the developer or contributor on a reasonable fee for their own past use of the software, their licence to use it will be terminated and their right to damages will be limited.

The GNU General Public License simply provides in clause 7 that if patents or other legal obligations would prevent a person from freely distributing the software, then they may not distribute the software at all. Other common licences such as the BSD and Artistic licences do not contain any specific reference to patent claims, and you should therefore consider avoiding those licences in favour of more comprehensive open source licences such as the MPL.

Read up on patents

As noted above, it is possible to infringe a patent right without knowing it, and ignorance is no excuse. So, it is a good idea for you to reduce your ignorance before you start coding an application that might infringe a patent claim. Patent specifications are required to be published publicly, so it is possible to search and read them, and that can be done on-line in the case of Australian patents. Being able to read them doesn't allow you to make use of what you have read directly, but it may give you some clues about how to engineer the same result in a different and unpatented way.

Searching the patent database can be a bit daunting, and it is the kind of task that will usually be entrusted to a lawyer or patent attorney. This can be a problem for open source projects, which might not have any funding. As a minimal alternative to an exhaustive search, you can at least read as much literature as you can about the type of project you are working on, and look at the documentation of similar proprietary software. With luck, if a patent exists to cover a particular software process, you may uncover it in the course of your reading.

If you think your project may infringe an existing patent, you have two choices. First, consider whether there is another way to accomplish what your project needs to do that doesn't infringe the patent specification (this may still require you to obtain legal advice, though). Second, contact the patent owner and see if they will give you a royalty free patent licence that is compatible with your project's licence.

Don't derive, plug in

Remembering the grayness of the definition of a derivative work, you should attempt to avoid copyright problems by extracting your project out from the internals of any proprietary software that it is dependent on or needs to interoperate with. If the proprietary software provides a high-level API for modules or plug-ins, use that rather than linking with the software at a lower level. This reduces (but does not eliminate) the risk that your software will be found to be a derivative work of the proprietary package, particularly if you have access to the source code of the proprietary package.


Undoubtedly, SCO's statements are mostly bluster, and its motives for sowing fear, uncertainty and doubt within the IT world may relate more to its ambitions to bolster its stock price and/or foster a buy-out than to its belief that its business has been damaged by IBM. This theory is bolstered by the fact that SCO has been so lax in even allowing businesses to purchase Linux licences, which were supposedly released on September 2 but which customers have had notorious difficulty in purchasing (although Microsoft famously did purchase a licence in May).

But if nothing else, the SCO litigation against IBM is a wake-up call for all of us. It is the kind of attack that could have happened before and almost certainly will happen again. Although the fact that SCO is going to end up losing is really a foregone conclusion, the damage has already been done. Just as the Internet has had to deal with spam and security attacks, the open source software world is no longer such a friendly place and it never will be again. Open source projects need to be conscious of that and start to take legal issues seriously.

Project leaders in particular need to be aware of the differences between the three main types of intellectual property protection, and the steps that they need to take to protect their projects from attack on any of those grounds. In the case of copyright, make sure the developers on the project are prepared to guarantee the cleanliness of their code, and that you do not accidentally taint your code by tying it too closely to proprietary software. In the case of trade secrets, get clearance from your developers and their employers if there is any confidential information they are working on, and avoid working on similar proprietary and open source projects at the same time. In the case of patents, know the technologies that you are prevented from using, and either work around those technologies carefully, or obtain a royalty free licence for them that is compatible with your open source licence.

By having the discipline to think about these issues, you will not only protect yourselves from liability, you will also protect your contributors, and your users. SCO has to some extent already shaken the confidence particularly of government and enterprise users in the use of Linux and open source software. Open source projects will now have to be able to demonstrate that they are on top of these issues if the open source development model is to survive and thrive in the post-SCO world.

1This is a paper presented at Australia's national Linux conference, on 15 January 2004. Copyright © 2004 Jeremy Malcolm. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. Portions of this paper are based on the author's article titled SCO v IBM – Lessons for Developers published in the September 2003 issue of Australian Developer, to which the author wishes to record his thanks.

2Jeremy Malcolm is an Information Technology lawyer with a successful niche practice in Internet-related law, and is involved at board level in a number of relevant organisations such as the Society of Linux Professionals of WA, the Internet Society of Australia, the Western Australian Internet Association, the Australian Public Access Network Association (as Secretary), the WA Society for Computers and the Law (as President) and previously Electronic Frontiers Australia. He has been since 1998 the Manager of Terminus Network Services which specialises in the use of open source software in networked environments and in the development of online systems; he has also established the portal for Linux consultants, and is a developer of the Debian operating system.