Because open source software (OSS) is easily accessible and can save developers time and money, it is becoming an increasingly important tool in the development of commercial software. However, many firms and developers may be unaware that software licensed under an open source licence could expose them to significant legal and commercial risk.
Introduction to OSS
Developers apply OSS licences to their software to grant others certain freedoms, including the freedom to use, copy, modify and redistribute the software, often for no cost. These freedoms are much more extensive than those granted under standard closed source licences. In return for the grant of these freedoms, OSS licences require certain conditions to be met.
There are many types of OSS licence which vary in the nature of the freedoms granted and conditions applied. The most important variable is whether the licence allows downstream licensees who incorporate open source code into their own work (creating a “mixed work”) to distribute the mixed work on the same terms as the original licence. If they are required to do this, the licence is commonly known as a “copyleft” OSS licence or “strong licence”. If they can redistribute the mixed work on more restrictive terms the licence is referred to as a “non-copyleft” OSS licence or “weak licence”.
A common misconception is that OSS licences do not rely on copyright or that copyleft means “not copyright”. In fact, the open source model relies on copyright in that the creator of the software retains copyright and grants others rights (on the terms of an OSS licence) to use the software.
The common goal of the OSS model is to allow downstream developers to build on existing software as opposed to starting from scratch. Many proponents of OSS consider developing software from scratch is costly and a prohibitive barrier to entry, lessening competition and preventing full and efficient exploitation of innovation.
Leaving aside the debate on its merits, OSS is now very common. The most popular OSS licence is the GPL, a copyleft licence. Software licensed under the GPL includes Linux (a widely used operating system) and MySQL (a database management system). Some commentators suggest it would now be difficult to find commercially competitive software that does not contain or rely on some elements of OSS.
With OSS becoming an increasingly popular tool for developers, those who develop and use software should be aware of the associated risks. The most significant risks relating to OSS can be grouped into two main categories: supply and acquisition.
Supply Risk
Supply risks exist where OSS code is supplied to a third party. Mere use of OSS code will never give rise to this risk, as every OSS licence allows use of the OSS. Firms and developers may be at risk in relation to supply (whether they know it or not) where OSS code finds its way into commercial software products. This can happen in a number of ways and often without the supplier’s knowledge.
For example, if:
- Company A contracts Developer B to create a software product to enable Company A to commercialise that product on a closed source basis;
- The development contract between Company A and Developer B does not prohibit Developer B from using OSS code;
- Developer B includes OSS code in the product; and
- The OSS code is licensed under a copyleft licence (or other OSS licence imposing prohibitive conditions or restrictions on the distribution of products incorporating that code on a closed source basis),
Company A will not be able to commercialise the software product it paid for on its own terms. In addition, Company A may have to make the source code of the software product generally available and may not be able to charge a fee for any future licensing of that software product, destroying its commercial value.
From Developer B’s perspective, even if the development contract prohibits the use of OSS code, Developer B would have to be very careful to avoid inadvertently including OSS code in the software product. OSS is very common and, without proper procedures and checks in place, an employee of a developer may include some seemingly insignificant lines of OSS code to save time.
If Company A supplies the software product in breach of the OSS licence, Company A risks legal action from the copyright holder of the OSS. In turn, Developer B risks both legal action from Company A and legal action from the copyright holder of the OSS.
These risks are not limited to commercialising software created by a third party developer. Many in-house developers use OSS code to save time and money. Although in-house development is more easily monitored, there is still a real risk that OSS code licensed under copyleft licences could find its way into commercial software.
One example of supply risk is the US case of Jacobsen v Katzer (535 F.3d 1373 (Fed. Cir. 2008)). In that case, Jacobsen was the author of software for the operation of model trains and made it available under an OSS licence called the Artistic License. The Artistic License stated that anyone had the right to modify the software, provided that Jacobsen was attributed authorship of the mixed product.
Katzer incorporated Jacobsen’s software into its own software product without attributing authorship to Jacobsen. Jacobsen argued copyright infringement and breach of licence against Katzer. While this case was settled, in preliminary hearings the court found that breach of licence and copyright infringement were both available causes of action for Jacobsen in this situation.
Another recent example of supply risk can be found in the dispute between one of the New Zealand copyright holders of a statistical software product called “R” and US-based Revolution Analytics. R is licensed under the GPL. One of the New Zealand copyright holders of R recently alleged that Revolution Analytics had modified R code and created enhancements without revealing the source code in breach of the GPL. That copyright holder is currently considering taking legal action against Revolution Analytics.
In the scenario set out above, supply risk could have been minimised by adopting internal procedures to manage the use of third party code (including OSS code) and tailoring the development contract to address OSS-related risks. Companies carrying out in-house development of commercial software can also implement policies in relation to the use of third party code to minimise supply risk.
Acquisition Risk
The second category of risk is acquisition risk. As mentioned above, the GPL allows modification of the relevant OSS code and redistribution of mixed works, provided that those mixed works are made available on the terms of the GPL. This includes making the source code of mixed works freely available, which can destroy the commercial value of those mixed works. This was the case in a recent dispute between Cisco and the Free Software Foundation (FSF).
Cisco acquired Linksys (a network equipment manufacturer) in 2003 for around US$500m. Linksys’ assets included certain firmware relating to router chips. After completing the purchase, Cisco discovered that this firmware contained code owned by FSF and licensed under the GPL and similar OSS licences stating that the source code in any mixed products must be made freely available.
FSF and Cisco began discussions in 2003 to resolve this issue. After those efforts failed, FSF commenced legal action against Cisco in 2008. FSF alleged breach of the OSS licence terms, and sought an injunction against Cisco distributing the Linksys firmware containing FSF’s code and an account of the profits generated by Cisco by breaching the licence terms.
The dispute between FSF and Cisco was settled in May 2009. Under the terms of the settlement reached, Cisco agreed to:
- appoint a new director to Linksys to monitor compliance with the requirements of OSS licences, which director reported directly to FSF;
- make the source code for the firmware freely available on its website;
- take steps to notify users of Linksys products which incorporate FSF’s copyright code of their rights under the GPL and other licences; and
- make an undisclosed financial contribution to FSF.
This result represented an important victory for FSF and proponents of the OSS model. It also provided an example of the potential risks faced by closed-source software developers and vendors who fail to comply with OSS licence terms.
As it turned out, Linksys had acquired the software from a third party supplier called Broadcom, and Broadcom had in turn acquired the software from a supplier which provided OSS to Broadcom without proper attribution. Neither Broadcom nor Linksys knew the software they provided was licensed under an OSS licence.
Cisco could have avoided this result by identifying OSS code used by Linksys as part of its due diligence review of Linksys’ business . Cisco could then have addressed issues raised by the use of OSS code before problems with FSF arose. Acquisition risk can also be managed by including appropriate provisions relating to the use of third party code in agreements for sale and purchase.
Conclusion
The use of OSS or supply of software that contains OSS code can have significant legal and commercial consequences for software developers and vendors. Software developers and vendors should take steps to mitigate those risks, including using appropriate contractual provisions and implementing internal procedures to manage the use of third party code.
OSS can also present risks in a transactional context, and companies looking to purchase software assets should be wary of software developed using OSS code. Undertaking a careful due diligence review of software assets and including provisions dealing with third party code in sale and purchase contracts can help to minimise those risks.