Well that depends!
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 OS 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?
The answers to those questions merit a dissertation not a mere article. 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 OS 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.
Simon Halberstam, Partner and Head of Technology Law Team, May 2015 – simon.halberstam@smab.co.uk 020 3206 2781