One of the myths surrounding open-source software (“Open Source”) is that you can do whatever you like with it; there is even an Open Source licence called Do What the F*** You Want To Public Licence (“WTFPL”). This could not be further from the truth.
We explore some of the issues that companies should consider when using Open Source.
What is Open Source?
The basic concept common to all Open Source licence agreements is that they seek to ensure that all downstream users have the freedom to use, modify and distribute the licensed Open Source. “Permissive” Open Source 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 Open Source and allow such modification to be distributed under any licence (proprietary or Open Source) of the licensee’s choosing. On the other hand, “restrictive” Open Source licence agreements (also referred to as “copyright” or “viral” licence agreements) impose obligations not only with respect to the licensed Open Source but also with respect to any works derived from or combined with Open Source. 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 Open Source, you may be creating a derivative work. If that Open Source 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 Open Source 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 Open Source licences that rely on copyright law principles, a thorough investigation of how much and what part of the Open Source code is copied or modified and/or how the Open Source 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 Open Source or using Plug-ins?
Linking
Some Open Source 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 Open Source libraries is allowed while static linking is not. Much of this will depend on the terms of the Open Source 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 Open Source 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, Open Source 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 Open Source projects, it is impracticable to determine whether any contributor has contributed infringing code (knowingly or otherwise).
Unchecked use of Open Source 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 Open Source 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 Open Source.
• Carry out an Open Source audit using a company such as ‘Black Duck’ and find out what Open Source licence(s) your organisation is using/has used.
• Appoint someone within the organisation to be responsible for use of Open Source.
• Create training programmes for employees.
Is it worth it?
If the relevant governing licence is benign then it may be a “win-win” situation enabling you to save money and time on software development without having to comply with any disadvantageous conditions relating to Intellectual Property rights or otherwise. However, if the governing licence is less liberal, you may end up feeling that the deployment of the Open Source was a false economy. The common Open Source licences generally regarded as permissive are Apache, Berkeley Software Distribution (BSD) and MIT. There are no precise statistics but together these 3 are estimated to cover about 40 percent of Open Source projects whereas the more restrictive GNU General Public Licenses, notably GPL 2 and GPL 3 account for about 35 percent.
The main concerns re GPL can be traced to GPL 2 section 2(b) which stipulates that
“You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work.. provided that you also meet all of these conditions….b) You must cause any work that you distribute or publish that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License”
The attempt to interpret this wording definitively and without ambiguity is at the very least challenging. The dearth of relevant case law makes matters more complex. Many complex issues arise, notably:
- what constitutes a “derivative work?”
- does distribution within a company constitute “distribution or publication?”
- do resultant executables “contain or derive from” GPL code?
- what is the difference between “static” and “dynamic” linking?
- can one hermetically “seal” GPL code from proprietary code to avoid contamination of the latter by the former?
Suffice it to say, one has to tread very carefully in this area. It may well be that the benefits of using Open Source would be outweighed by the detriment to the existence and value of the company’s IPR. Where the development team sits in-house, then with proper analysis and relevant expert input one should be able to reach an informed decision. However, where development is outsourced, matters become more complicated as the interests of the developer and the company may well diverge. The developer can save a lot of time by deploying Open Source and if the project is fixed-price or time-bound, this will be an attractive option. However, the company may not be aware of the potential impact on its IPR or may be aware but unable to monitor the developer’s coding processes. In some cases, companies that think they have a valuable IPR repository are only disabused when a potential investor or acquirer runs its slide rule over the company in the context of due diligence and finds that some or all of the company’s key code is not proprietary to the company. Indeed, if the Open Source runes are negative, investors who saw the company’s IPR as a major reason for investing or acquiring may seek to renegotiate or be deterred completely.
IPR in Jeopardy? Dynamic v Static Linking
The major IPR risk stems from use of GPL2 or GPL3 code. Those licences are commonly referred to as “infectious” because they generally mandate publication of modifications to the GPL code. This is so even in SAAS cases where the software supplier is executing on its own server. Other Open Source licences may prescribe such publication but generally in less frequent circumstances e.g. EPL i.e. Eclipse Public License. Whereas under EPL, pure execution of modified EPL code on one’s own server via SAAS would be unlikely to require disclosure of the modifications, the situation would be different if the modified code were distributed. The need to publish such modifications would probably depend on whether the modifications were “hermetically” sealed in separate modules or took the form of adaptations to the original EPL code modules.
Under GPL 3, the situation is more clear-cut as the distinction between separate modules and modified GPL modules seems to fall away with publication required of any modifications to the GPL 3 code. The risk of contamination under GPL 3 arises from the apparent requirement in certain circumstances to publish pre-existing proprietary code that is intermingled with GPL 3 code. However, the need to publish will depend on the extent of the “coupling” between the proprietary and GPL 3 modules. “Dynamic linking” mandates publication whereas “static linking” may not. Guidance, albeit legally not definitive, is set out in more detail in the GNU FAQ at www.gnu.org/licenses/gpl-faq.html#MereAggregation
Turning back to GPL 2 which still accounts for about 25% of the Open Source market, it does not talk in terms of “dynamic linking”. However, the best view seems to be that linking of proprietary code to GPL 2 code would mandate that the former be published.
Please click here to email Simon Halberstam, Head of Technology Law, or call 020 3206 2781.