My Web Stats

Legal Info

SCO v IBM – Lessons for Developers

SCO's litigation against IBM over the misuse of UNIX technology in Linux has outraged many – but does SCO have a point?

The SCO Group's legal claim against IBM – or some would say against Linux – has aroused a storm of protest, and many critical reports by commentators, including the article “Mad SCO Disease” in August's Australian Developer . But for all SCO's failings, there are some serious issues that its claim raises not only for IBM, but for open source developers around the world. Unless these issues are addressed, it may be that the shadow cast by SCO over the open source development model remains long after its litigation has passed into history.

After outlining the chronology and factual background of the dispute for those who came in late, this article will discuss how the issues raised by SCO's litigation fit into the jigsaw puzzle of Australian intellectual property law, and will try to draw out some recommendations to be applied to open source software engineering processes in order to minimise the risk of similar disputes ensnaring others.

For those who came in late

SCO's first volley in the dispute was its complaint filed on 6 March 2003 in the Utah State Court suing IBM for $1 billion, which it later raised to $3 billion. (For what it is worth, SCO is not the original Santa Cruz Organization, but rather the former Linux vendor and developer known as Caldera Systems, that purchased the UNIX business of the original SCO.)

IBM maintains a version of UNIX called AIX. Its right to do so is governed by a number of contracts with SCO (or actually with AT&T, the original owner of UNIX, who passed these contracts on to Novell before SCO purchased them). SCO claims that IBM breached these contracts by using UNIX source code, or knowledge derived from its work on UNIX source code, in Linux. In response to these claimed breaches, SCO says that it terminated IBM's licence to use UNIX in AIX on 16 June 2003 (IBM, naturally, disputes this).

SCO's original court complaint also implied that IBM had breached SCO's intellectual property rights in UNIX – a subtly different claim that does not depend on any contract between IBM and SCO. This part 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 that SCO purchased from Novell.

Although SCO maintains it does possess copyright to the UNIX code and Novell has now partially conceded this, its amended complaint does seem to retract its claims of breach of intellectual property rights. At least for now, then, the dispute is focused on whether IBM has breached any contracts that can be enforced by SCO, and on SCO's related claims that IBM has engaged in unfair competition and interfered with contracts between SCO and its customers.

The particular UNIX technologies that IBM is claimed to have incorporated into Linux include scalability, performance and scheduling improvements, a journaling filesystem, 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, many even 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.

As to whether there is any actual UNIX code present in Linux, the jury is still out (metaphorically speaking, of course – a real jury won't be empaneled for months). SCO has not released any code to enable its allegation to be tested, except under the terms of a non-disclosure agreement. Meanwhile, allegations have ironically surfaced that SCO is itself guilty of illegally copying Linux kernel code in its UnixWare operating system.

Despite widespread public doubt of the strength of SCO's case, SCO's public statements on this dispute have been even bolder that the claims in its lawsuit. 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. On 16 June, SCO was even reported as raising the spectre of claims against publishers of other operating systems such as Windows and MacOS, to the extent that these were derived from UNIX.

Broader issues raised

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 foster a buy-out than to its belief that its business has been damaged by IBM. But at the core of its claim are a number of simple propositions. Some of these relate specifically to the contractual arrangements between IBM and SCO (or its predecessors), but those that are of broader application include:

  • Is it permissible for the same developers to work on a proprietary software project and a similar open source one?
  • Is it ever permissible to copy the source code from proprietary software?
  • Can the concepts or ideas in software be protected?
  • At what point does an extension to software stop being a “derived work” of that software that the original developer controls?

Before we can answer these questions we need just a bit more background about Australian intellectual property law.

Intellectual property rights

Intellectual property rights fall into a number of categories, including copyright, trade secrets, trademarks and patents. We will briefly look at these in turn.


Copyright in computer software is treated in much the same way as 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.

The presence of identical code in the Linux kernel and in UNIX may indicate an infringement of copyright – but doesn't necessarily, because simple functions can be independently written in the same way, and copyright law permits this. In fact, extremely simple functions or comments may not even attract the protection of copyright to begin with.

Open source software such as the Linux kernel is still subject to copyright, but the copyright owner waives a number of the rights that most copyright owners choose to keep to themselves, such as the right to restrict copying of the software. The copyright owner can however impose conditions on the waiver of these rights; 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.

Trade secrets

The law of trade secrets (or simply “confidential information”) is not written down in a statute book like the copyright laws are, but it is based on a long-standing series of court cases that have decided that a person who is given information in confidence must respect that confidence. Often (as in IBM's case), the obligation of confidence is backed up by a contract, but it need not be.

The benefit 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. On the other hand, unlike copyright protection, the intellectual property owner can destroy 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, 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 it was thought for a long time that software cannot be protected by patent rights, this has now been established to be false. However, 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

Finally, trade mark law only protects identifying marks or symbols, and as such is 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.

Some answers

Let's return, then, to the questions posed above, in the light of what we have learned about intellectual property.

Is it permissible for the same developers to work on a proprietary software project and a similar open source one?

At the very least, it is risky. Whoever is paying them to work on the proprietary project will is entitled to expect that their work on that project will be kept confidential. In most cases, the developers will have to sign a contract which sets out the extent and the duration of their obligations in detail, but even without a contract developers can fall under a duty to keep trade secrets confidential.

On the other hand, developers don't need to be too paranoid about this. Unless they have signed a contract that specifically says so, they can't be prevented by their employer or head contractor from using information that wasn't confidential to begin with. For example, much of the UNIX source code that SCO is claiming as its intellectual property may previously have made its way into the public domain, including by means of SCO's own contributions as a Linux developer when it published the Linux kernel source code, and its publication of “Ancient UNIX” source code on the Web under a free licence.

Neither can a developer be prevented by their employer or head contractor from using information that was confidential to someone other than that employer. An example of this from the SCO case is the JFS filesystem. The version of this filesystem that IBM contributed into Linux was previously developed by IBM for its OS/2 operating system. This could make it difficult for SCO to argue that IBM had a duty to keep the JFS filesystem confidential. (On the other hand, SCO is not dead in the water here: IBM did in fact develop an earlier version of JFS for AIX.)

Is it ever permissible to copy the source code from proprietary software?

Yes, in some cases it is. 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).

Even if code does attract copyright protection, copyright law only prohibits you from copying a “substantial part” of that code. 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.

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 either of the two categories above. However,the possibility certainly can't be ruled out based on early comments of some of those who have viewed that code under non-disclosure agreements with SCO.

There is another exception to the rights of copyright owners that may be of assistance to open source developers. This is that Australian copyright law allows code to be copied for the purpose of developing an interoperable product, although the copying can only be made to the minimum extent necessary to achieve interoperability. Unlike most other of the provisions of copyright law already discussed, this exception does not yet exist throughout the world.

Can the concepts or ideas in software be protected?

Yes, some concepts or ideas in software can be protected either through trade secret rights or patents. The advantage of patents for the software owner, assuming that the software process is innovative enough to qualify for patent protection, is that it prohibits others from using the protected concepts or ideas even accidentally.

Because of this, it is possible – even likely – that the Linux kernel already infringes various software patents, without any intentional wrongdoing by its developers. There is the prospect that the relevant patent holders (possibly, and ironically, including IBM) 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.

On a brighter note, in the context of the SCO litigation, many of the original AT&T UNIX patents have now expired, and few of those that remain are held by SCO, so IBM would be unlikely to have much to fear by way of a claim for patent infringement by SCO.

At what point does an extension to software stop being a “derived work” of that software that the original developer controls?

The answer to this question is surprisingly obscure. In other contexts, a derived (or “derivative”) work can include a translation, musical cover version, stage or screen adaptation, abridgment or artistic rendering of a copyright work. In the context of computer software, the Copyright Act and court cases that have been decided using that Act give us little guidance.

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 statically 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 cannot be described as a derivative work.

On this basis, IBM's development of extensions to the original UNIX code in AIX may well not be in breach of any copyright. In particular, to call a filesystem such as JFS that happens to work with UNIX (but also with OS/2) a “derived work” of UNIX is a bit of a stretch, to say the least.

How developers should respond

The issues raised by the SCO litigation are a challenge to the open source development community, but they are by no means its death knell. By taking third party intellectual property rights seriously and by following procedures that are designed to respect those rights, it is possible for developers to minimise their exposure to litigation such as that brought by SCO against IBM.

Place responsibility on code contributors

It is unrealistic to expect the leaders or coordinators of an open source software development project to vet all contributions of code for intellectual property infringements. Even a well-resourced project manager, let alone a volunteer, would be hard pressed to recognise code lifted from another project unless it was very distinctive indeed. If the other project was a proprietary one which had not released any public code, then the task becomes impossible.

Responsibility for ensuring the cleanliness of contributed code must instead lie squarely with the contributor. The contributor should be required to agree in writing with the project leaders 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 (and any such sources should be clearly documented).

The contributor (and, if applicable, their employer also) should also confirm that they are not constrained by any non-disclosure agreement or duty of confidentiality in the code or ideas that they can contribute to the project. If possible, the contributor 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.

Agreements or declarations covering matters such as these are common practice 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. The paperwork may be an annoyance, but it is much less of an annoyance than a lawsuit.

Know the patents in your field

A more vexed question arises in the case of patents, because as noted above, it is possible to infringe a patent right without knowing it. However, the advantage is that patent specifications are required to be published publicly, so it is possible to search and read them (on-line, in the case of Australian patents), even though it is not possible to make use of what you have learned until the patent has expired!

If conducting an exhaustive search of patent databases is beyond the resources of an open source project, at least read as much literature as you can about the type of project you are working on, and look at the documentation (including the legal fine print!) 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, that is not necessarily the end for the project. Contact the patent owner and see if they will license the patent's subject matter to you under terms that are compatible with your project's licence. If not, consider whether there is another way to accomplish what your project needs to do that doesn't infringe the patent specification (you may however need to get legal advice if you intend to pursue that avenue).

Be modular

If your software needs to interoperate with a proprietary software package or system, link to it at the highest level that you can while maintaining the functionality of your program. Since the dividing line between a “derivative work” of a proprietary package and code that simply uses that package is somewhat grey, it is best to err on the side of modularity. This especially applies if you have access to the source code of the proprietary package or system.

On the other hand, do remember that 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 creating a derivative work.


Although SCO's case against IBM is complex, the issues that developers need to be wary of in order to avoid falling into the same trap are fairly simple. There are three major categories of intellectual property that are usually involved in software development projects; copyright, trade secrets, and patent rights. In the first two cases, developers can protect themselves by making sure each contributor takes responsibility for the cleanliness of the code and ideas they contribute, and that their code is cleanly separated from any proprietary software with which it is designed to interoperate. In the third case, it is more a question of taking the initiative to educate yourself about the patents that are out there that your project might infringe, and licensing or working around them if they exist.

By following procedures such as these, developers will reduce their exposure to litigation-happy intellectual property owners, and will stand in a better position to have any legal claims that may be brought against them determined in their favour – as hopefully will soon happen to IBM.

Please Note: The information contained in this article is general in nature and cannot be regarded as anything more than general comment. Readers of this article should not act on the basis of this comment without consulting one of iLaw’s legal practitioners who will consider their particular circumstances