Scheibner, James --- "What price freedom (of software)? A guide for Australian legal practitioners on open source licensing" [2017] PrecedentAULA 23; (2017) 139 Precedent 39

---

WHAT PRICE FREEDOM (OF SOFTWARE)?

A GUIDE FOR AUSTRALIAN LEGAL PRACTITIONERS ON OPEN SOURCE LICENSING

By James Scheibner

Intellectual property lawyers will no doubt be familiar with software licensing agreements. These licence agreements control the use and reproduction of software through a combination of contract law, copyright and trade secrecy. Where the method implemented by the software is novel, inventive and useful, patent rights may also be involved. For the most part, these agreements will entail exclusive rights vesting in a developer, a team of developers or the software distributor. This is typically referred to as a proprietary licence.

This article aims to introduce legal practitioners to a new subset of licences; open source licences. This term refers to a set of software licences that, broadly speaking, give permission to others to exercise the exclusive rights of copyright. Within free and open source software (FOSS) development, this refers to the right to copy, modify and redistribute the underlying design, or source code, of the software. Although it seems economically counter-intuitive, many successful software programs, including the operating systems Linux and Android, the database software MySQL and the web server Apache, are all licensed under various open source licences. This concept has spread beyond FOSS development into artistic, musical, literary and open access scientific works through Creative Commons licensing.

DANGEROUS LIAISONS – THE POSSIBILITY OF OPEN SOURCE SOFTWARE LITIGATION

However, the term ‘open source licensing’ is itself slippery and encompasses a variety of different licensing models (hence the need for this article). Crucially, the fact that open source licences give permission to exercise certain exclusive rights does not mean that an open source licensor abandons their rights at law. The US-based Software Freedom Law Center (SFLC), the Software Freedom Conservancy (SFC) and the Free Software Foundation (FSF) have all been proactive in seeking licence compliance against infringing software and hardware manufacturers.

While infringing an open source licence may not lead to catastrophic litigation between two technology multinationals, open source projects are frequently community supported initiatives. In addition to the cost of litigation, perceived or actual attacks on open source projects are regarded poorly (as the SCO Group found to its cost^[1]). As alluded to previously, the term open source is wide enough to encompass a wide variety of licences, some of which are entirely incompatible with one another. This can cause problems where software packages with incompatible licences are used alongside one another, particularly for restrictive open source licences (as described below).

This article illustrates the boundaries of different open source licences with specific reference to Australian case law and legislation. It then highlights some specific issues that may arise with respect to open source licences, including issues surrounding software patents and the assignment of copyright.

PERMISSIVE VERSUS RESTRICTIVE: DIFFERENT TYPES OF OPEN SOURCE LICENCE

As a general rule, open source licences are divided into two categories of licence;^[2] permissive licences and restrictive licences. Permissive licences are the least restrictive licence beyond public domain licensing, and only require developers of derivative source code to include an attribution to the original developer. Licences that are classified as permissive licences include the Massachusetts Institute of Technology (MIT), Berkeley Software Distribution (BSD) and Mozilla licences. These licences are primarily designed to be used in an academic context to maximise citation of the software. Permissive open source licences are also designed to prevent upstream copyright claims from blocking downstream research.^[3] In other words, permissive open source licences are designed to allow for future commercialisation of the software without the potential for infringing upon the licence conditions.

Restrictive licences are designed to create ongoing obligations for the re-release of source code on publication. Perhaps the most notable example of a restrictive licence is the GNU General Public License (GPL) family of licences. These requirements are controversial, as the FSF defines all software that refers to a GPL licensed work as a ‘derivative work’ without defining the scope of reference. This can include software that refers to a GPL-licensed library or method through an application programming interface (API).^[4] To this end, the FSF recommends the lesser GPL licence (or LGPL), which allows for GPL-licensed software to be linked with proprietary software without the need for the latter to be treated as a derivative work.^[5] The breadth of the definition of derivative work under the GPL has generated concern among proprietary developers that, should restrictively licensed software be packaged with software released under a permissive open source licence or a standard proprietary licence, the non-restrictively licensed software would automatically be relicensed. In part, this concern is somewhat exaggerated; the GPL does not tie to use of software but only to the creation of derivative works.^[6] Nevertheless, while permissive licences are backwards compatible, restrictive licences are not.^[7] In other words, it is possible to incorporate permissively licensed code into a restrictively licensed or proprietary project, but it is not possible to incorporate a restrictively licensed or proprietary software into a permissively licensed project.^[8] Unfortunately there is limited case law on the operation of open source licences in Australia; the main litigation that has occurred has been in the US and parts of the European Union. This leads us to open source licensing case law.

CASE LAW ON OPEN SOURCE LICENCES OUTSIDE AUSTRALIA

United States

In the US, the enforceability of open source licences was confirmed in Jacobsen v Katzer (Jacobsen),^[9] where the Federal Circuit held that, where drafted as such, requirements in an open source licence are conditions on, rather than covenants to, open source licences. Accordingly, these requirements under US copyright law gave rise to copyright remedies as well as contractual remedies. This is important because the appellant could seek an injunction under copyright law to prevent the respondent from using the open source licensed software without attribution. However, this is very much dependent on the drafting of the open source licence in question; in Jacobsen, the requirements on use in the Artistic Licence (the licence in question) were explicitly drafted as ‘conditions’ and were interpreted as such. Indeed, it is clear from the subsequent case of Drauglis v Kappa Map Group LLC^[10] (Drauglis) that courts will interpret the remedies under open source licences only as far as the terms of the licence permit. This case revolved around the licensing of a photo released under the restrictive Creative Commons licence ‘CC BY-SA’. Jackson J of the District Court of Columbia held that the map book that the photo was released with was not a derivative work and therefore the respondent had done all that was required to comply with the licence (that is, provide attribution to the original author).

These cases illustrate a number of points about open source licences in addition to the issue of licence incompatibility described above. First, it is important to check the terms of the licence to determine how they are drafted. Despite the Artistic Licence being held to be valid in Jacobsen, subsequent commentators have noticed that the obligations under the licence were poorly drafted, adding to the confusion around the case.^[11] Although this is less concerning for permissive licences, where attribution is usually the only requirement, it can undermine the operation of the copyleft provisions in restrictive licences. Accordingly, it pays to use a licence where the obligations under that licence are clearly defined so as to ensure that the terms of the licence can be interpreted as conditions.

Secondly, Drauglis established that the terms of an open source licence will be interpreted only as far as they apply to the subject matter in the circumstances. In particular, Drauglis established that the copyleft^[12] licensing requirements under a restrictive open source licence will be activated when the original licensed work is ‘recast[ed], transform[ed] or adapt[ed]’. Applying this condition to open source licensing for software indicates that restrictive open source licences are limited in their application to dynamically linked software. This includes libraries and APIs that are only referenced by non-restrictively licensed software rather than directly integrated into software. Therefore, when confronted with a potential litigation action or when prosecuting a case of open source licence infringement, it is important to consider what software is the subject of the litigation in question and whether it is protected by an open source licence.

How are open source licences enforced in European courts?

European Union

There has been judicial consideration of the operation of the GPL in a number of European jurisdictions, most notably Germany. The first of these, the ‘Netfilter/Sitecom case’ (heard in the Munich District Court) concerned the enforceability of the GPL for licensed software on a firewall router. The Court held that the licence conditions were equivalent to a ‘browserwrap contract’ insofar as the licensee had to assent to the terms of the licence before downloading the software. Accordingly, as reasonable efforts had been made to make the licensee (in this case the defendant) aware of the conditions of the licence, they were bound by these conditions.^[13]

Turning to the question of whether the licence conditions were enforceable under the German Civil Code (Bürgerliches Gesetzbuch), the Court characterised the conditions of the GPL (specifically sections 2, 3 and 4) as conditions on use rather than waivers of copyright. Sections 2 and 3 entail the ‘copyleft’ requirements of the licence, which require relicensing under the GPL and inclusion of the source code along with relicensed source code. Section 4 includes a termination clause where there has been a failure to comply with the terms of this licence. For this reason, the Court held that the existence of copyright was fundamental to the operation of these conditions. Applying these principles to the facts in the case at hand, the Court held that the defendants had infringed the GPL by failing to distribute the totality of the modified source code under the GPL.^[14]

This demonstrates a resounding endorsement of the principles of open source licensing in Europe, particularly for restrictive open source licences. However, with respect to Australian law the enforcement of open source licences is far more opaque.

OPERATION OF OPEN SOURCE LICENCES UNDER THE COPYRIGHT ACT 1968 (CTH)

What implications, if any, does this open source licensing case law in the US and Europe have for Australia? As Huang notes, many open source licences, including the commonly used MIT, BSD and GPL, are drafted to operate under US copyright law.^[15] While some cases may be decided under the copyright law of the country where the software was developed, other cases may be decided under the law of the jurisdiction where the case was opened.^[16] To this end, the principles from the open source cases described above may not apply evenly in other jurisdictions. Practitioners in this area must accordingly be alert to the possibility of open source licence enforcement in an Australian court.

As Huang notes, literature and jurisprudence on open source licence enforcement under Australian copyright law are limited. The Copyright Act 1968 (Cth) declares that copyright vests in both the source and object code associated with a computer program, but non-literal elements are not capable of being copyrighted.^[17] Section 4A of the Copyright Act, which establishes exceptions to infringement, includes only incidental copying and reverse engineering as legitimate exceptions to infringement for computer programs. Unfortunately, there is no explicit exception for the creation of derivative software works, or indeed a definition for derivative works within the Copyright Act. This is problematic, as the derivative work definition forms the crux of the operation of the copyleft provisions within restrictive open source licences.

The closest analogy that exists within Australian copyright law is the statutory definition of ‘adaptation’ within s10 of the Copyright Act and the broader requirement for copyright to vest in an original work. In the context of software, the scope of ‘adaptation’ was considered in Coogi Australia Pty Ltd v Hysport International Pty Ltd.^[18] In this case, the issue in question was whether copyright extended to just a particular pattern within a garment or the software for generating the pattern in addition to the pattern itself. In interpreting whether a version of the software in a different language amounted to adaptation, Drummond J held that in the circumstances, adaptation extended only to a complete rewriting of the software in a different form or language, rather than reuse of the component. This means that in Australia, the enforceability of an open source licence may vary on a case-by-case basis. That is, a forked open source work that includes a substantial modification of the original source code may qualify as an adaptation. However, a purely functional API may not be sufficient to attract copyright to qualify as an adaptation.

As for copyright law, there is limited case law in Australia on the enforcement of non-commercial software licenses. The closest available case is Trumpet Software v OzEmail Software.^[19] Rather than open source licensed software, this case concerned functionally limited proprietary software released under a shareware licence. The purpose of shareware software, unlike open source software, is to provide users with a trial version of the software to encourage them to buy the full package. However, the defendant then distributed a modified version of the software, with copyright notices edited out, without the plaintiff's permission. In this case, the question was whether the defendant could distribute the plaintiff's software without permission, given that the shareware licence was designed to ensure that the software was shared as widely as possible. This in turn rested on the question of whether a restriction of the defendant's use of the software could be implied into the licence.^[20] Here, Heerey J held that in the circumstances, a term could be implied into the shareware licence for the software to be distributed in its entirety, so that users could ensure that they were receiving the totality of the software that they would later buy.

This is analogous to the conclusions reached by the Munich District Court in Germany regarding the rationale for ss2 and 3 of the GPL. However, Heerey J also stated that by releasing its software under a shareware licence without consideration, the licensor impliedly licensed others to distribute it in an unmodified form. Heerey J further held that the absence of consideration left open the question of whether his Honour's decision precluded the availability of copyright remedies for shareware and other open source licences. In particular, more recent case law on the availability of remedies for non-monetary contracts suggests that Heerey J's judgment may no longer apply in Australia. Nevertheless, the uncertainty in Australian law surrounding open source licensing demonstrates the importance of making sure that you pay attention to how developers you are advising are licensing their software.

CONCLUSION: STRATEGIES TO PROTECT OPEN SOURCE SOFTWARE AND AVOID INFRINGEMENT

Regardless of the legal status of open source licences in Australia, it is important for software developers to license their work. Without an open source licence, unlicensed software could be treated as released under a bare licence (where the licensor has no control) or abandoned under copyright.^[21] If you are advising a developer who wishes to release its software openly, you should advise it to use an open source licence that is suitable for what it wishes to achieve. Although the use of a restrictive licence does not necessarily preclude the sale of software, copyleft requirements do prevent the combination of software packages. You should suggest restrictive licensing if the developer wishes to impose copyleft requirements to keep its code open in perpetuity and does not wish to combine its software with restrictively licensed software. On the other hand, if the developer you are advising wishes to combine its software with other proprietary software later, you should recommend a permissive open source licence, which will allow the developer to relicense or recombine its software should it wish to do so.

Ultimately, the degree to which open source licences apply will depend largely on the originality and nature of the software. It is important to work closely with the developer to determine the exact nature of the openly licensed work. Open source software on collaborative development websites such as Github and Sourceforge could be used to determine other available software. In addition, there are a number of non-profit legal foundations both inside and outside of Australia who are willing to assist with open source licensing and licence enforcement. These include the SFLC, the SFC and the Electronic Frontier Foundation.

James Scheibner is a PhD student based at the Centre for Law and Genetics at the University of Tasmania. Prior to undertaking his PhD, James completed undergraduate computer science and law degrees at the University of Tasmania. James’s research specifically focuses on the intersection between formal intellectual property rights and informal norms in open science research. PHONE [phone] EMAIL [e-mail].

---

^[1] Since 2003, the software company SCO Group has been involved in a series of legal disputes with various Linux vendors and users. The SCO Group alleges that its license agreements with IBM means that source code that IBM wrote and donated to be incorporated into Linux was added in violation of SCO's contractual rights.

^[2] G Vetter, ‘Slouching toward open Innovation: Free and open Source Software for Electronic Health Information’ (2009) 30 Washington University Journal of Law & Policy 183.

^[3] Upstream inventions refer to basic inventions which are essential for other inventors to perform research in a particular field. Downstream inventions are inventions that are dependent on upstream inventions. For examples in patent law, see M Heller and R Eisenberg, ‘Can Patents Deter Innovation? The Anticommons in Biomedical Research’ (1998) 280(5364) Science 699.

^[4] An API provides a standard set of methods that can be ported to multiple different programs. An example of an API is the Portable Operating System Interface (POSIX) API, which is designed to ensure compatibility between operating systems. J West and J Dedrick, ‘Open source standardization: The rise of Linux in the network era’ (2001) 14(2) Knowledge, Technology & Policy 88-112.

^[5] B Fitzgerald, ‘The Transformation of Open Source Software’ (2006) 30(3) MIS Quarterly 590.

^[6] ‘Copyleft’ is an arrangement whereby software or artistic work may be used, modified, and distributed freely on condition that anything derived from it is bound by the same conditions.

^[7] A Morin, J Urban and P Sliz, ‘A Quick Guide to Software Licensing for the Scientist-Programmer’ (2012) 8(7) PLoS Comput Biol e1002598. In the context of open source licensing, backwards compatibility refers to the ability of an open source licensed package to be included in a larger package under a different licence. As the diagram demonstrates, a restrictively licensed package is not backwards compatible; that is, it cannot be included in a larger work unless that larger work is also released under an open source licence.

^[8] B Fitzgerald and N Suzor, ‘Legal Issues for the Use of Free and Open Source Software in Government’ (2005) 29 Melbourne University Law Review 439.

^[9] 535 F 3d 1373 (Fed Cir, 2008).

^[10] 128 F Supp 3d 46 (D D C, 2015).

^[11] H R Reddy, ‘Jacobsen v Katzer: The Federal Circuit Weighs in on the Enforceability of Free and Open Source Software Licenses’ (2009) 24 Berkeley Technology Law Journal 299; A Guadamuz-González, ‘The License/Contract Dichotomy in Open Licenses: A Comparative Analysis’ (2009) 30(2) University of La Verne Law Review 101; V Nemiah, ‘License and Registration, Please: Using Copyright Conditions to Protect Free/Open Source Software’ 2013 3 New York University Journal of Intellectual Property and Entertainment Law 358.

^[12] See above note 6.

^[13] LG München I [District Court of Münich], 2004 MMR 693, 19 May 2004 reported in (2004) O 6123/04.

^[14] Ibid, 694.

^[15] M Huang, ‘The Problems of Openness – Effective Regulation of Open Source Software’ (2012) 1(1) International Journal of Technology Policy and Law 54.

^[16] J Peeters, ‘General Public License in Court – Analysis of the case law in European Countries’ (2007-8) 44(4) Jura Falconis 631-656.

^[17] See above note 15, 54.

^[18] [1998] FCA 10; (1998) 41 IPR 593.

^[19] [1996] FCA 560; (1996) 34 IPR 481.

^[20] BP Refinery (Westernport) v Shire of Hastings (1977) 180 CLR 266.

^[21] E Hudson and R Burrell, ‘Abandonment, Copyright and Orphaned Works: What Does it Mean to Take the Proprietary Nature of Intellectual Property Rights Seriously?’ [2011] MelbULawRw 33; (2011) 35 Melbourne University Law Review 971.