One of the myths surrounding open-source software (“OSS”) is that you can do whatever you like with it; there is even an OSS licence called Do What the F*** You Want To Public Licence (“WTFPL”). This could not be further from the truth.
In this article we explore some of the issues that companies should consider when using OSS.
What is OSS?
The basic concept common to all OSS licence agreements is that they seek to ensure that all downstream users have the freedom to use, modify and distribute the licensed OSS. “Permissive” OSS licence agreements such as MIT and Apache 2.0 impose minimal obligations on the licensee, such as obligations to maintain attribution and legal notices. Importantly, these licences often permit modifications of the OSS and allow such modification to be distributed under any licence (proprietary or open source) of the licensee’s choosing. On the other hand, “restrictive” OSS licence agreements (also referred to as “copyright” or “viral” licence agreements) impose obligations not only with respect to the licensed OSS but also with respect to any works derived from or combined with OSS. Failure to understand which type of licence you are subject to and the associated terms of use can entail huge risks for your business.
The risk involved with derivative works
Making available your source-code
Where proprietary software code is “mixed” with OSS, you may be creating a derivative work. If that OSS is subject to a restrictive licence, then when you license such software, you will have to make the sensitive source code you have created available to end users free of charge with the ability to modify and redistribute.
Copyright infringement
Many OSS licences are subject to United States copyright law, under which a derivative work is defined as:
“a work based upon one or more pre-existing works, such as…any other form in which a work may be recast, transformed or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ‘derivative work’.”
Therefore, when dealing with OSS licences that rely on copyright law principles, a thorough investigation of how much and what part of the OSS code is copied or modified and/or how the OSS is used needs to be made in order to anticipate or predict how a court might rule on the legal implications for a “derivative work”. A key issue is understanding and knowing what may be classified as a “derivative” work, especially as many restrictive licences don’t even define the concept (e.g. Eclipse Public License, Version 1.0). In some cases, there is not necessarily an answer, particularly as there is little case law surrounding the issue. For example, what happens where you are linking to OSS or using Plug-ins?
Linking
Some OSS available is released as a library. Instead of incorporating it into your proprietary software you may want to create a link between your software and these (unmodified) libraries and to distribute them along with your software, either by compiling them together (“static linking”) or not (“dynamic linking”). There are instances where dynamic linking to OSS libraries is allowed while static linking is not. Much of this will depend on the terms of the OSS licence you use and so a case by case analysis is necessary.
Plug-ins
Plug-ins such as Adobe Flash Player are commonly used in web browsers to add video player functionality. Where your software application is configured with a programming interface to support the use of such plug in, a derivative work may be created when either the application or the plug-in is governed by a restrictive OSS licence.
In both these cases, it may well be difficult to determine whether the form of use envisaged might lead to a copyright infringement.
Warranties and limitations of liability
Generally speaking, OSS licences include a broad disclaimer of all representations and warranties or indemnities that might otherwise be expressly or impliedly provided by a commercial software licensor. Further, as there is often more than one contributor to OSS projects, it is impracticable to determine whether any contributor has contributed infringing code (knowingly or otherwise).
Unchecked use of OSS could have significant consequences and result in the need for time consuming remedial action. In a corporate transaction if in the course of due diligence, the prospective investor or purchaser alights upon an intellectual property ownership issue or other problem arising from the use of OSS and the issue cannot be remedied prior to closing, then the investor or acquirer may decide not to proceed or, more probably, seek additional contractual protection such as indemnities, or a cash escrow to cover the cost of any remediation efforts that may be necessary after closing.
How to manage the risk?
As a company, there are several things you can do to manage your risk:
• Establish a policy regarding the management and use of OSS.
• Carry out an OSS audit using a company such as ‘Black Duck’ and find out what OSS licence(s) your organisation is using/has used.
• Appoint someone within the organisation to be responsible for use of OSS.
• Create training programmes for employees.
For further information please contact:
Simon Halberstam, Partner and Head of the Technology Law Group
E: simon.halberstam@smab.co.uk
DDI: 020 3206 2781