MODEL TRAIN HOBBYISTS, A PHYSICS PROFESSOR AND THE ENFORCEABILITY OF FREE AND OPEN SOURCE SOFTWARE LICENCES
I INTRODUCTION
Free and Open Source Software (FOSS) licences are now well and truly mainstream in software development. The legal rights and the enforceability of FOSS licences however remains somewhat of a mystery with few cases ruling on the enforceability of these licences. Given the enormous popularity and growth in software distributed under FOSS licences it is vital to understand the legal implications of using such software. Even those who do not use FOSS licensed software may be exposed to the legalities of FOSS licences through third party vendors.

Prior to Jacobsen v Katzer, a detailed analysis of the terms of FOSS licences was absent from legal discourse. The Jacobsen decision offers an important first step in how to interpret the terms of a FOSS licence although the case was only concerned with one FOSS licence, the Artistic Licence. Widely considered a landmark case in favour of the FOSS movement, there appears to be lack of understanding of the applicability of the decision in Jacobsen to any of the other FOSS licences, which may be resulting in a false optimism towards the enforceability of other FOSS licences in the open source community.

This paper explores the reasoning applied in Jacobsen and how it may be used to interpret other more popular FOSS licences. It argues that although Jacobsen has weighed in favour of the enforceability of FOSS licences, it really is only a first step in determining whether the decision concerning only the Artistic Licence can be applied more broadly and whether it will assist in the interpretation of the terms of FOSS licences and whether they are ‘conditions’ and ‘covenants’.

The paper will first introduce the concept of software code and define FOSS including a brief history of the FOSS movement. An analysis of the Jacobsen case will be undertaken to distil the principled distinction between ‘covenant’ and ‘condition’ in the Artistic Licence. The paper then explores the reasoning in Jacobsen and whether it can be applied more broadly to other more popular FOSS licences, in particular GNU-GPL (versions 2 and 3) and the BSD Licence. The paper will then propose a number of steps that can be applied by drafters of FOSS licences that will help reduce the risk of potential copyright infringement by users of FOSS licensed software.

II SOFTWARE AND THE IDEALS OF OPEN SOURCE
This section will attempt to provide the historical context in which the Jacobsen decision was made and assist the reader in appreciating the licensing conventions in FOSS licences by explaining fundamental concepts like the basics of software, a definition of free and open source and a brief history and philosophy of the open source movement culminating in universally accepted FOSS licence standards.

a. Understanding software code: source code and object code

There are two basic forms of software code: source code and object code. A computer programmer writes software in source code which is a programming language that is human -readable but unintelligible unless one speaks the language of a computer programmer. A proficient software programmer is able to discern instructions and logical steps in the source code that communicate with the computer and thus allows the computer to complete a programmed task. In order for a computer to read and process source code, that source code needs to be converted to object code, that is, machine-readable or executable. This conversion is undertaken by a compiler that turns the source code into ones and zeros (often referred to as binary) that the computer can understand.

b. Sharing source code – the beginnings of the FOSS movement

When programming was in its infancy in the 1960s and 1970s, sharing source code was commonplace. Programmers would collaborate and build software that would then be shared and tested by other programmers in the community resulting in higher quality software with fewer bugs. At this time, the companies interested in the technology of computers were mainly concerned with the hardware they were manufacturing and so supplied the software programs free of charge as a bundled package. The software program allowed the hardware to fulfil its function by communicating logical instructions inputted by the user of the hardware in conjunction with the software. This model of distribution of software allowed software programmers to use research facilities funded by the computer hardware companies to develop software and in fact these companies actively encouraged their programmers to cooperate and collaborate with the software development community at large.

The growth of personal computers, along with the larger-scale server systems required to operate larger networks, saw a flourish, resulting in the software becoming an integral part of the hardware. In essence the software itself became a valuable commodity. These realisations lead technology companies to attempt to safeguard software innovations. From once a collaborative community of software programmers that helped hardware manufacturers realise the potential of technological equipment they were now under strict orders to protect their code. Today, software plays an integral role across all mainstream technologies from personal computers to copiers to tablets and so on and is in fact now a multi-billion dollar industry. It is for this reason that most companies closely guard the software they develop by attempting to protect it by any means available including copyright, patents, trade secrets and contract law.

c. The EULA and proprietary software

The vast majority of commercially available software is often referred to as closed source software or proprietary software and is made available to the public usually by way of an end user licence agreement (EULA). It is considered closed source because this proprietary software typically contains only the object code or machine readable ones and zeros. Given that the human readable source code is absent from this software it is virtually impossible to reverse engineer the object code in order for it to be understood, let alone modified and used by software programmers.

The user may agree to the EULA in writing, interactively (called clickwrap licensing), or by opening the box containing the software (called shrink wrap licensing). The licence terms are rarely negotiable. The EULA will licence the right to use the software only under certain conditions, and restricted from other uses, such as modification, sharing, studying, redistributing, or reverse engineering. A breach of the EULA typically subjects the breaching party to substantial compensatory and liquidated damages. The fact that companies often aggressively pursue breaches of licence terms acts as a major deterrent to reverse engineering and dissemination of improvements (or otherwise) to proprietary software.

d. Software licensed as free and open source

There are however other methods that software is distributed one of which is by freely making the source code available albeit under a different type of licence than the usual proprietary licence: a free and open source software licence. As the term suggests, ‘free and open’ embodies the ideals of a movement of software developers originating in 1980’s that believe that source code should always be shared. It is worth noting that a reference to the word ‘free’ does not necessarily mean ‘zero price’ or ‘no value’ but rather the notion of ‘freedom’ from constraint and ‘free’ access to the source code. Although the rationale and ideals motivating free and open source programmers vary considerably there is now general consensus that regarding the main characteristics that must be present for software to be considered free and open source which will be discussed under section f below.

e. Software as intellectual property

It is a well established intellectual property principle that copyright protection attaches to software code and is considered equivalent to ‘literary works’ within the meaning of the Berne Convention for the Protection of Literary and Artistic Works as established by the World Intellectual Property Treaty of 1996 as well as Australian and US copyright law. The programmer owns the copyright in his or her software and therefore secures a number of exclusive rights including the right to reproduce the software in a material form (such as copying the program to hard disk or USB drive and writing or typing the source code of the program); to publish the software (such as offering the program to the public); to make an adaptation of the software (such as making versions in different languages or code: for example, a program in object code may be an adaptation of its source code version or modification of code for different platforms such as Windows or Apple iOS); and to communicate the software to the public (such as making it available for download).

If anyone other than the copyright owner wants to do any of these things with the software, he or she will generally need the owner’s permission. If a copyright owner decides to release software to the public by expressly waiving any and all of the rights in that software, the software, for all intents and purposes is released into the public domain. At this point, software companies or other programmers could take that software released into the public domain and incorporate it into their own software and then rely on the same copyright principals to protect their new ‘literary work’. Effectively, this new software, even though it has been copied, modified, published and communicated pre-existing copyrighted software could be protected and owned by the new ‘owner’ of the software. The public would not realise any benefit of the improvement made by that programmer or software company nor would any benefit, such as attribution, flow to the original programmer. Further, the original programmer would no longer have the rights to compel others to deal with the original code within any constraints. Although it would appear that, when a computer programmer releases software by not restricting the use of that code in any way, would satisfy the ideals of the open source movement since the code would be available to anyone to modify and distribute and the realities of a commercial marketplace render this practice unsustainable and even, in fact, negligent to the open source ideals.

Adapting to commercial market forces and in keeping with the FOSS movement ideals, FOSS programmers developed a new type of licence – the open source software licence. Although open source software licences can vary considerably (just like the motivations of programmers who release their software under FOSS licences), generally speaking, an open source licence allows a user to copy, modify and distribute derivative works based on the original code without completely forfeiting all the inherent copyright protections in the original code. So FOSS licences allow authors to continue to adhere to the free and open source ideals of allowing access to the source code whilst still imposing restrictions on the use of their software.

f. A very brief history of the FOSS movement

Exploring the development of the open source ecosystem is beyond this dissertation, however a very brief re-telling of the history of the FOSS movement and the origins of the GNU-GPL and BSD Licences will aid in the analysis and understanding of the arguments put forward in Jacobsen along with the analysis surrounding these popular FOSS licences.

In 1984 a former programmer at the Massachusetts Institute of Technology artificial intelligence lab named Richard M. Stallman founded the Free Software Foundation (FSF). The main tenant of FSF was to create an open source operating system called GNU which would be based on a Unix system. Although the project to create the operating system as a whole was never completed, Stallman and other FSF programmers were able to produce useful software code like the GNU EMACS and the GNU C compiler. Stallman’s philosophy regarding software development was that “information is community property and all software source should shared”. That is, Stallman believed if source code were to be hidden from other developers, the sort of cooperation and collaboration needed to advance software development would be impossible.

In order to keep source code freely available to allow others to modify and redistribute the software and avoid any possibility of software becoming proprietary, FSF developed a concept of Copyleft. Copyleft is a sort of antithesis of copyright. For code to be considered Copyleft any programmer who incorporates, modifies or derives a new program from the original code, must freely make that new software available to others under the same conditions.

To bring the Copyleft concept into practice Stallman and the FSF created the first example of an open source licence called the GNU General Public Licence (GNU GPL). Since its genesis, the Copyleft approach and the GNU GPL have been subject to some criticism both within the open source community and more broadly by other software developers. Despite any criticism of Stallman’s concept, the present-day open source movement is based on the very ideals contained in the GNU GPL.

Throughout the remainder of the 1980’s only limited progress was made in the open source movement with only one notable development coming in 1987. In 1987, Larry Wall invented Perl, a Unix-based programming language that was designed to scan, manipulate and print text files. Wall’s Perl programming language was released (or licensed) under the GNU GPL. Subsequent to the release of Perl, Wall decided that the GNU GPL licence terms were too restrictive and created his own open source licence and called it the Artistic Licence.

By the late 1980’s, FSF’s attempt at creating an entire operating system based on Unix was unsuccessful, often attributed to injuries to Stallman’s hands preventing him to type the code needed to complete the project. In 1991 however, a 21-year-old Finnish university undergraduate named Linus Torvalds, out of necessity since his computer lacked the power to operate a fully operational Unix system, developed a new operating system based on Unix. The software Torvalds developed would not have been possible without the GNU EMACS and the GNU C compiler software code developed by Stallman which was released under the GNU GPL licence and freely available to be copied, modified and distributed. Torvalds’ new operating system was dubbed ‘Linux’ and was released under the GNU GPL. As a further illustration of the empowerment of the FOSS movement stemming from Stallman’s work, Linux was not the only open source operating system developed in the 1990’s. In fact in 1993, another open source version of the Unix system named FreeBSD was developed and distributed under yet another open source licence called the BSD Licence.

As the use of open source code grew in popularity amongst programmers, so too did open source licences become more prevalent in the computer industry. A number of different FOSS licences emerged to meet the different needs of software developers with each FOSS licence granting different rights to users. As the level of uncertainty arose in the software community about what licensors and licensees were allowed to do under each respective licence, so did the need for a standard set of universally accepted principles that would underpin FOSS licences.

g. The open source standard

Bruce Perens is attributed to have authored the principles that underpin the Open Source Definition (OSD) which were adopted by the Open Source Initiative (OSI) in the late 1990’s. The OSI sought to remove the uncertainty surrounding FOSS licences by endorsing the OSD as an industry-standard norm upon which any purported open source licence can be evaluated.

To determine whether a licence is in fact OSD compliant, the OSI certifies software licences by comparing the terms of the licence with the OSD. What this certification has allowed is the software developer community certainty that a piece of software distributed under a certified licence will generally be safe to modify and distribute despite the recognition that other restrictions may still be imposed.

The remainder of this paper will now focus on the condition v covenant dichotomy and the decision of Jacobsen and how, if at all, the reasoning that determined the outcome can be applied to the two FOSS licences that make up about 75% of software licensed as free and open source. The analysis will primarily be focused on whether the condition v covenant distinction made in Jacobsen assists in the interpretation of these other more popular FOSS licences.

III CONDITION V COVENANT DICHOTOMY
Software code is subject to copyright as a literary work and software licences are by their very nature contracts. To understand how the terms of a licence might apply, a fundamental understanding of the principles of contract is necessary. The following sections will explore the enforcement of FOSS licences under both contract and copyright law in isolation. As will become evident, which cause of action may be appropriate for a breach of the terms of a licence depends on the relationship between the parties and how the terms of the licence are classified. That is, when a licensee breaches a term of a FOSS licence, does it amount to copyright infringement or is it restricted to a breach of contract? The consequences of such a breach vary considerably depending on the classification of terms of the licence.

a. Enforcing FOSS Licences under contract law

For a licence to be enforced under the principles of contract law a number of preconditions must be met namely, offer, acceptance and consideration. In the context of FOSS licensing, the offer is usually made when a software developer makes his or her software available for download along with an accessible copy of the licence agreement under which the software is distributed. Acceptance and consideration however are somewhat more problematic to establish.

Acceptance of the licence terms and a manifestation of that acceptance in some way either by promise or conduct must be present for a contract between a licensor and licensee to exist. That is, a licensee must be afforded an opportunity to accept or reject the licence terms and that, as an indication of acceptance, a conscious and communicated decision has been made. For example when a licensee accepts licence terms by clicking “I Agree” this is considered a sufficient indication that the user has accepted the terms upon which the software can be used. In the FOSS context however documentation accompanying the distribution of software is often made available as a separate download and so it could be argued that a user did not have sufficient notice of the terms under which the licence was distributed and so establishing acceptance of those terms may be difficult to prove. A user of the software in these circumstances could reasonably argue that he or she believed that the software was not accompanied by any restrictions effectively placing the code in the public domain and so acceptance of the licence terms could not have been possible.

Furthermore, for a contract to exist, the licensor must establish consideration. Ordinarily a licensing agreement is a contract between a licensor who is making software available to the licensee in return for monetary compensation. In the context of FOSS licences however this notion of consideration is difficult to apply as there usually is not anything provided by the licensee of the software back to the licensor. Therefore identifying a tangible benefit received by the licensor in return for access to the software is difficult. It may be argued that since the consideration threshold of contract law is low, the benefit received by the licensor is in fact the public’s contribution to the original code and that the benefit from the licensee’s perspective is availability of the code which would not have been possible in the first place but for the FOSS licence.

Even if offer, acceptance and consideration were established and a valid contract is deemed to exist, the difficulty in effectively enforcing FOSS licences under contract law are made even more difficult when considering the issue of remedies. When FOSS licences are distributed free of charge, proving monetary damages for a breach of contract is difficult and the very nature of the contractual agreement precludes a licensor from claiming liquidated damages. The other type of remedies that may be available to the licensor would be the two main equitable remedies for breach of contract namely specific performance and injunctive relief. In the case of specific performance and FOSS licences, this could potentially require a licensee to make the entire derivative work that was based on the original code available under the FOSS licensing terms that is in question. So in effect this ‘viral licensing’ would further preclude a court determining enforceability of FOSS licences as there would be a disproportionately greater harm to the licensee (and any future licensee) than the licensor. Similarly, in the case for injunctive relief a licensor would need to show irreparable harm but again the very nature of FOSS licenses allows licensees to modify and distribute the software and so showing the level of harm to seek a successful claim for injunctive relief is almost impossible.

As discussed above, notwithstanding that a FOSS licence can meet the requirements of a contract, the remedies available to licensors are either very difficult to prove or useless at best. Furthermore, the cost of litigation for a licensor who in the first instance is distributing software for free under a FOSS licence is often prohibitively high and the incentives to pursue a breach of contract are often non-existent. Even if a contract between the licensor and licensee cannot be established or if it could a breach of contract not worth pursuing, another legal regime applies to FOSS licences and that is the copyright regime.

b. Enforcing FOSS Licences under copyright law

Copyright automatically exists in computer software as a literary work and lasts for 50 years (or 70 years in the USA) after the death of an author. Copyright gives the author the exclusive right to control who makes copies of the software and who can create modified versions of the software.

To establish copyright infringement an author must meet three main requirements: that the work in question is in fact subject to copyright law; that the author has the rights to impose conditions on the work, that is, that they authored the work or have, by way of transfer, the rights of the copyright owner; and the work has been used in a way that infringes on the author’s exclusive rights in the work.

In the context of FOSS licences, establishing authorship is somewhat difficult as works are often modified and distributed under the licensing terms that allow this to occur. Determining what portion of the code was authored and therefore potentially infringed by a third party is therefore problematic. Furthermore, establishing a breach of copyright given the often permissive nature of FOSS licences which then lead to a multitude of derivative works, can also be very difficult to establish. Even if an author was able to establish authorship and infringement, the remedies available might be injunctive relief or damages. A very similar line of argument applies with respect to the potential remedies sought as under an action for breach of contract as described in the previous section.

In order for copyright enforcement to be applied however, the licence must contain terms that court considers ‘conditions’. For example, an owner of land can impose certain conditions on entry onto a premises like ‘you enter this shop under the condition that we can check your bag’ or ‘you enter this site at your own risk’. These are not promises or covenants but licensing conditions.

c. Conditions v Covenants

A licence does not grant the licensee a right to the property but rather it allows the licensee to deal with the copyrighted work in a way that is reserved for the copyright owner and that would otherwise be unlawful under copyright law. That is, a licence places limitations or conditions on the licensee’s entitlements to exercise the rights of the author of the copyright work that would otherwise only be exclusively granted to the licensor. Therefore, unlike covenants, licensing conditions that are placed on the licensee cannot provide the licensor any more rights that would have existed under law absent of the licence.

A good example of the differences between covenants as opposed to conditions imposed through a licence was when Mr Eben Moglen, the FSF’s counsel, described a proprietary software company’s approach to the distribution of software. He said …These companies say their software is "licensed" to consumers, but the license contains obligations that copyright law knows nothing about. Software you're not allowed to understand, for example, often requires you to agree not to decompile it. Copyright law doesn't prohibit decompilation, the prohibition is just a contract term you agree to as a condition of getting the software when you buy the product under shrink wrap in a store, or accept a "clickwrap license" on line. Copyright is just leverage for taking even more away from users...”. That is, a licensing condition may be defined as a restriction that “govern[s] the scope of the permission to perform acts that would otherwise constitute copyright infringement” while a contractual condition “govern[s] [the] acts that are additional to or beyond the scope of acts that constitute copyright infringement.

As such, a licensing condition includes actions that the licensee agrees not to do in accepting the license terms, for example, ‘I agree not to distribute this software’ whereas a covenant is a restriction that must be satisfied for the user to be licensed in the first place, like, ‘I agree to be bound by the laws of Australia’. Albeit subtle, the difference is in fact critical. This distinction was brought before the USA Federal Court in Jacobsen v Katzer and was a critical point that determined the outcome of that case.

IV MODEL TRAIN HOBBYISTS AND THE PHYSICS PROFESSOR
In a landmark case of which similar circumstances had not been heard before at the appellate court level in the United States, the Federal Circuit held that the Artistic Licence was enforceable under both copyright and contract law. The Federal Circuit’s decision addressed the question of whether the owner of the copyright in software distributed under an open source licence may successfully pursue a claim of infringement against a party using the software in violation of the licence terms. The District Court for the Northern District of California held that breaching the terms of the Artistic Licence did not constitute copyright infringement. On appeal the Federal Circuit reversed that decision and found that a breach of the terms of the Artistic Licence can constitute copyright infringement.

a. The background, facts and reasoning of Jacobsen v Katzer

The plaintiff, Robert Jacobsen, a physics professor and a model train hobbyist and the defendant, Matthew Katzer, a business man and a model train hobbyist, had each designed competing software programmed to control model trains. Jacobsen, the manager of the Java Model Railroad Interface (JMRI) developed the Decoder Pro and licensed it under the Artistic Licence making it available at no cost on the JMRI website. Katzer was the owner of KAMIND Associates Inc., an Oregon company doing business under the name KAM Industries selling the Decoder Commander. Katzer owned several patents relevant in the model train industry one of which was obtained specifically in relation to the Decoder Commander. In 2005, Katzer accused Jacobsen of infringing on the patent. Jacobsen responded by arguing that the patent was unenforceable and invalid and therefore the Decoder Pro software could not be found to be infringing on Katzer’s patent. During the course of preparing to file the necessary documentation for invalidity of Katzer’s patent, Jacobsen discovered portions of code in Katzer’s Decoder Commander that were copied from Jacobsen’s Decoder Pro without adhering to the terms of the Artistic Licence under which Jacobsen’s software was distributed. Under the Artistic Licence, and among other terms, a user of the software needed to meet certain preconditions before redistributing or modifying the software, namely, that any changes made to the original software resulting in a derivative work are disclosed and that the original software programmer is attributed correctly. In finding that Katzer had copied portions of his code, Jacobsen amended his original claim of patent invalidity to include copyright infringement. Jacobsen sought injunctive relief to prevent Katzer from distributing the Decoder Commander software.

In the first instance, the District Court dismissed Jacobsen’s claim of copyright infringement and reasoned that although Katzer copied portions of the Decoder Pro software it did not amount to copyright infringement but rather a breach of the contractual terms contained in the Artistic Licence. The District Court went further and stated that for copyright infringement to be made out by Jacobsen, he would need to show that Katzer’s actions in copying the software code fell outside the scope of the Artistic Licence which would then give rise to a potential copyright infringement outside the contractual terms of the licence. Ultimately the District Court found that Katzer’s actions did not fall outside the scope of the Artistic Licence and therefore copyright infringement could not be made out. In its reasoning, the District Court found that the scope of the Artistic Licence was intentionally broad and that the attribution requirement did not limit the scope of the licence. Further, the court held that a breach of a term of the Artistic Licence may be considered a breach of contract but did not create an infringement under copyright law where it would not otherwise exist. That is, the court interpreted the restrictions contained in the terms of the Artistic Licence as covenants as opposed to conditions. Based on the court’s interpretation of the Artistic Licence, Katzer’s use of the Decoder Pro software could not be considered outside the scope of the licence as it permitted him to copy, distribute and modify the open source software. Katzer’s failure to properly attribute the portions of code used in his derivative work breached a contract term but not the scope of the licence itself. Jacobsen appealed the decision.

The Federal Circuit overturned the District Circuits judgement and become the first court to recognise and support the terms a FOSS licence. The court’s decision turned on whether the terms of the Artistic Licence could be considered conditions of the licence subject to copyright protection or covenants subject only to contractual remedies. The court expressly stated in its reasoning that the limitations imposed by the Artistic Licence were conditions defining the scope of the licence, and as such a breach gave rise to copyright infringement. The Federal Circuit did not actually explore the covenant v condition dichotomy in its reasoning but relied on its interpretation of the language used in the Artistic Licence. In determining whether a finding of copyright infringement was applicable under the terms of the Artistic Licence, the court first concluded that the language in the Artistic Licence created conditions and not covenants. Relying on the preamble and section 3 of the Artistic Licence, the Federal Circuit court noted the intent of the licence was to create conditions under which copying the software was permissible. The court emphasised the importance of these conditions and noted further that users of software licenced under the Artistic Licence had certain rights “provided that” they adhered to the Licence’s conditions. The court relied somewhat on a Californian case completely unrelated to software to support its argument that the words “provided that” were used to denote the existence of a condition. Furthermore, the District Court emphasised the importance of the conditions imposed by the Artistic Licence by noting the requirements of attribution and the intent of releasing the software as open source so as to increase the number of software programmers in the JMRI project and in fact attributed an economic value to this pursuit. The Federal Circuit court stated that “Copyright licenses [sic] are designed to support the right to exclude [and] money damages alone do not support or enforce that right”. In choosing to licence the Decoder Pro software under the Artistic Licence, Jacobsen chose to require compliance and not compensation for the use of his software.

The Federal Circuit court concluded that because compliance should not be afforded any less protection that compensation, injunctive relief under US copyright law may be considered appropriate and referred the case back to the District Circuit court for determination on injunctive relief. In early 2010, Katzer agreed to an injunction and the case was settled.

b. The issues raised by Jacobsen v Katzer

The Federal Circuit decision was a landmark case indeed but it provides limited guidance on how other FOSS licences can be interpreted and poses further questions that will need to be answered in order for the Jacobsen decision to apply more broadly to other FOSS licences. For example, the Federal Circuit considered the distinction between conditions and covenants and that distinction determining whether or not copyright infringement would apply when a term of a FOSS licence is breached. Very little legal discourse and reasoning was provided by the court as to how that distinction was made. When the terms of other FOSS licences other than the Artistic Licence are being interpreted by courts, what are the key determining factors? Should courts look at the intent of the parties when the contract is being construed as per normal contract law discourse? Should the distinction be left to the drafters of FOSS licences to determine whether a term of the licence is a covenant or a condition? If so, how can FOSS licences be drafted in a way as to clearly differentiate between the two key concepts as determined by Jacobsen to give users of FOSS licensed software certainty? Does this raise a public policy consideration as to the appropriateness of drafters of FOSS licences determining the outcome of the covenant v condition dichotomy simply by using different phrases is the licence itself? In an attempt to answer these questions the next section will analyse the terms of the GNU GPL and the BSD Licence and how the Jacobsen reasoning could apply.

V APPLYING THE JACOBSEN REASONING AND COPYRIGHT LAW TO THE GNU GPL AND THE BSD LICENCE
To further explore how influential the decision in Jacobsen is to the FOSS movement and to the enforceability of FOSS licences under copyright, two of the most commonly used FOSS licences will be assessed against the reasoning in Jacobsen and the concept of a “derivative work” under US and Australian copyright law.

a. Applying Jacobsen to the drafting of the GNU GPL

The preamble to the GNU GPL makes the intention of the licence terms explicit by stating that proprietary licences are ‘designed to take away freedom’ whereas the GNU GPL is intended to ‘guarantee freedom to share and modify software’. In fact the terms of the licence provide a licensee with many of the exclusive rights that would otherwise only be available to the copyright owner. For example the GNU GPL allows a licensee to distribute verbatim copies, modify the whole or parts of the software and then distribute those modified copies. However, the GNU GPL also imposes significant limitations or conditions on the rights of the licensee particular with respect to distribution. The language and tone of the GNU GPL preamble and the licence itself makes it absolutely clear what the intention of the drafters is: that conditions of use of the software exist and that failure to adhere to these conditions alters the relationship between the licensee and licensor. Like the Federal Circuit court found in Jacobsen, the GNU GPL terms would be considered conditions.

For example, the licence provides that a copy of the GNU GPL must be distributed with the derivative software, interactive programs must display a notice that describes the licensing terms as well as the copyright notice and disclaimer of warranty, a copy of the source code must be provided or otherwise available to the licensee and that any distribution of the software is conditional on that distribution being made under the same licensing terms as the GNU GPL. Along with the other rights afforded to licensees under the GPL, they are granted “provided that” the user meets one or more conditions.

Further to the “provided that” language, the GNU GPL contains clear language that any attempt to otherwise not follow the terms of the licence will result in automatic termination of the user’s rights to use the software under the licence. The GNU GPL v3 now includes a new section 8 which goes on to add from v2 that allows for a provisional and permanent reinstatement of the licence if the user stops the breach. Both the new v3 provision and the v2 termination clause is particularly important in the context of applying the reasoning in Jacobsen to the GNU GPL as it makes it unequivocally clear that not following the terms of the licence results in termination of the licence which in turn may expose a user of the licensed software to copyright infringement.

The language of the GNU GPL, consistent and clear use of the words “provided that” and the inclusion of termination clauses indicate conditional use of which a breach, as what happened in Jacobsen, raises the spectre of copyright infringement.

b. Enforcement of the GNU GPL under copyright law

The GNU GPL refers to a “derivative work” as defined under applicable copyright law. Under both Australian and US copyright law, a derivative work must be based on one or more pre-existing works and must recast, transform or adapt an original work. Therefore for a work to be considered a derivative work the licensee must change the code in the original software that was subject to the GPL licence. Further, under US copyright law the copyright owner of the pre-existing work has the right to authorise the creation of derivative works. Copyright subsists in the derivative work for the new author but only to the extent of the modification or addition that was made to pre-existing work. Furthermore, copyright subsisting in the derivative work “does not extend to any part of the work in which such material has been used unlawfully”.

Herein lays an interesting dichotomy that exists between the GPL GNU and copyright law. Copyright law gives the author of a derivative work the right to control the part of a derivative work that has been added or modified from the pre-existing work. If under the GNU GPL the author then must reveal the changes made to the original software even though they created that part of the code, it would seem that the terms of the GNU GPL licence in fact override the rights afforded to an author enshrined by copyright law. That is to say, for the author of a derivative work to actually lay a legitimate copyright claim to the derivative work, they must show that they relied on the pre-existing work lawfully and that the author relied on the permissive terms granted under the GNU GPL, including the obligation to disclose any modifications in the source code, in order to establish the subsistence of copyright in the derivative work. To act according to the licensing terms of the GNU GPL, the author must relinquish control over the part of the derivative work that they created (the non-pre-existing component). In effect therefore the GNU GPL seems to override the right of an author under copyright law. As illustrated, the very nature of the GNU GPL as it relates to US copyright law is ambiguous potentially making the enforceability under copyright law of such a licence cumbersome. Compounding these issues is also the absence of the length of the GNU GPL licence term.

Developers who use software licensed under the GNU GPL must show that their code is an independent work and therefore does not infringe the copyright owner’s right to reproduce or prepare a derivative work in order to comply with copyright law and to be able to rely of the GNU GPL themselves. There are not any definitive cases that establish a precedent that deals with what may constitute a breach of an author’s exclusive right under section 106 of the US Copyright Act. It is accepted that in order for there to be an infringement there must be substantial similarity in the “total concept and feel” of a derivative work as compared to the underlying work. However in another case digital images that were “touched up or modified selections” of original works were not found to make the derivative works infringing the original images. More specific to FOSS developers was the case of Lewis Galoob Toys Inc v Nintendo of Am. Inc were infringement was not found in a derivative work that made improvements to a Nintendo game. The derivative work of the Nintendo game allowed players to add lives to a game character, increase the speed of movements of characters inside the game and allowed the character to perform functions not originality coded in the Nintendo version. However, in yet another case in the 9th Circuit of the US Federal Court system a company that downloaded computer game levels that were created by players of the game using a customise feature and making these levels available on a commercial basis was found to have created an infringing derivative work under section 106. Despite the apparent ambiguity in the interpretation of what can constitute a derivative work by the courts, commentary has suggested that three factors must be present in order for infringement to be made out. Firstly, is the later work substantially similar or does is substantially incorporate the pre-existing work. Secondly, has the original copyright holder been compensated for the use of the pre-existing work by the user and thirdly, related to the first determinate factor is whether the creator of the later work had the right to copy or display the original work. Further it is suggested that the copyright owner must prove that it was not reasonably expected that the original work would be subject to derivative use and as such precluding any right for compensation of use of the original work in a derivative work.

Given the changing nature of derivative works in light of FOSS software, it is in fact customary and expected that other software developers will use code and modify and distribute it with the only form of compensation to the copyright owner being the release of the source code of any derivative works. The harm therefore in not adhering to the terms of the GNU GPL will often be in relation to specific performance of the release of the source code in that part of the derivative work. However, as indicated, the GNU GPL does not apply to programs “reasonably considered independent and separate works in themselves” which could then be distributed within a sufficiently modified work and not fall under the GPL obligations.

c. Applying Jacobsen and copyright law to the BSD Licence

The BSD Licence is significantly shorter in length than the GNU GPL and so applying the reasoning in Jacobsen is more straightforward. The BSD Licence states that redistribution of software and the use of both the source and object code with or without modification is permitted “provided that” the user meets three conditions: (1) if a user redistributes the source code they must include the prescribed copyright notice, the list of conditions contained in the licence itself and a prescribed disclaimer; (2) similarly, if a user redistributes the object code they must follow the same conditions; and (3) the user must not use the name of an organisation nor the names of its contributors to endorse or promote products derived from the software without specific prior written permission. Given that the licence specifically uses the phrase “provided that”, a literal interpretation of Jacobsen would render the terms of the BSD Licence a condition.

Unlike the GNU GPL, the BSD Licence does not include any supporting documentation like a preamble that would assist in interpreting its terms and the intention of the drafter. Further, BSD Licence is lacking a termination clause that expressly states that a breach of its terms will result in a termination of the user’s rights to use the software licensed under the BSD Licence. These additional supporting statements in the GNU GPL help strengthen the applicability of Jacobsen to establish conditions rather than covenants. Notwithstanding, it is very unlikely that the similar reasoning applied in Jacobsen would not be followed when interpreting the BSD Licence.

Furthermore, the BSD Licence is also lacking any detail with respect to derivative works and the concept of copyright. That is to say, in situations where a derivative work has actually been created by a licensee, the same reasoning with respect to copyright law applies to the BSD Licence.

Having applied then the reasoning in Jacobsen to the GNU GPL and the BSD Licence and considering the issues of the creation of a derivative work, it is clear that the Federal Circuit court’s reasoning in Jacobsen assists in the interpretation of other FOSS licences. Notwithstanding the potential difficulties surrounding the reconciliation of derivative works under FOSS licences and copyright law, it is not only the language contained in the terms of FOSS licences that is critical to determining whether they are conditions or covenants but the intention of licence is equally important too. As such the next section of this paper will offer some proposals both in terms of the language that can be used by drafters of FOSS licences but also how to structure a FOSS licence in order to remove any ambiguity with respect to the intention of the licence and whether its terms are conditions or covenants.

VI DRAFTING FOSS LICENCES
As discussed, the decision in Jacobsen goes some way in providing an authority in the interpretation of FOSS licences by confirming the enforceability of the Artistic Licence both under contract and copyright law. However the Federal Circuit court’s decision does not provide a precedent to the interpretation of other FOSS licences. By adopting the following measures and using the GNU GPL language and structure, drafters of FOSS licences may be able to assist the courts in applying the law to FOSS licences.

Any new FOSS licence or amendments to current FOSS licences should remove any doubt as to whether its terms should be considered conditions or covenants by making deliberate and unequivocal statements either in the preamble or by the use of clear language in the body of the licence. As the courts reasoning in Jacobsen indicated, statements like “provided that”, “subject to”, “contingent on”, “a condition of” all indicate an intention to create a condition (and not a covenant) upon a licensee. Although the use of these terms in themselves will not necessarily result in an interpretation of a term being a condition, use of phrases like these will certainly strengthen any argument towards the intention of creating a condition of use. Although the GNU GPL includes a preamble, the BSD Licence along with many other FOSS licences do not. To assist in the courts’ interpretation of FOSS licences, a preamble should be drafted to include clear statements of intention towards the use of a FOSS licence being contingent on certain terms along with a statement dealing with any potential consequences of non-compliance with the terms of the licence. Like the GNU GPL, other FOSS licences should include language that deals with both copyright infringement and traditional breach of contract and termination clauses. In doing so, a FOSS licence will not only raise the spectre of a breach of a contract covenant, which in itself does not prevent a user from using the licence, but also a breach of a condition of use which may result in the revocation of the licence and expose the user of the FOSS licence to copyright infringement. Another technique drafters can use to assist courts in the interpretation of FOSS licences is to provide some guidance with respect to jurisdiction. A FOSS licence should indicate which country and or state laws the licence is intended to be governed by as there is a real possibility of vastly different outcomes when interpreting FOSS licences between states of the US let alone across common and civil law international jurisdictions. Finally, in order to remove any ambiguity as to the intention of the terms of FOSS licences is to incorporate all of the above proposals and have expert and experienced licensing and contract lawyers draft the licence so as to ensure the licence accurately reflects the original intention of the licensor.

If any FOSS licence is badly drafted or remains ambiguous, the possibility of litigation and the actual number of FOSS licences will both increase. Currently there are approximately seventy odd FOSS licences. Software developers intending to release their software need to know for certain the terms under which they are licensing their software otherwise they will inevitable write their own licence, which may create further ambiguity for licensees and courts alike. Even if any new or amended FOSS licences are drafted with the proposals suggested above in mind and clearly state the intention of the licensor removing any ambiguity, these developments cannot be applied retrospectively to software already released under existing FOSS licences.

VII CONCLUSION
Jacobsen v Katzer has been heralded as a win for the FOSS movement and has established somewhat of a precedent for enforcing copyright in FOSS licences. The Federal Circuit court in the United States resuscitated the debate surrounding the enforcement and interpretation of conditions and covenants in FOSS licenses and provided some clarity to licensors and licensees of open source software. Although the decision weighed in favour of the FOSS movement there are many more issues and questions that are left unanswered. This paper has attempted to illustrate the difficulty in simply applying the reasoning in Jacobsen to distil the condition v covenant dichotomy still inherent in other more popular FOSS licences and has illustrated further issues that will remain in software released under a FOSS licence.

As the use of software and its distribution reaches epic proportions, so too will the amount of software being released under FOSS licences. Jacobsen is really only the very early beginnings of an area of law that will continue to develop and shape the free and open source movement into the future.

PDF with references. Back to list...