At Devant, we support lots of software companies throughout their journey from start-up to sale. A recent company sale negotiation highlighted the importance of the correct management of open-source software to potential acquirers. As a result, I’ve revisited a post I wrote in 2011, updating it with the latest case law. I share the updated version with you here. If your business involves the creation, modification or licensing of software it’s a topic worth getting to grips with now, before pre-sale due-diligence makes it into an expensive issue!
In today’s fast-moving technological environment, using open-source software (OSS) is often essential to get companies where they need to be, quickly. There are huge reserves of open-source code available to individuals and organisations, many of which are free of charge, or very competitively priced.
They vary from discrete modules offering a small but essential function (displaying a popup window, for example) to operating systems (Linux) and even entire CRM systems (such as SugarCRM).
So far, so good. So what’s the catch?
The catch is, as in so many cases, in the small print.
Most OSS is licensed under either the GNU General Public Licence (GPL), or another of the many open source licences available. As of August 2011, the various versions of GPL accounted for over 60% of all open source licences, which makes it a useful one to examine.
While some of the lesser-used OSS licences are rather benign, mostly consisting of a disclaimer of any warranties on the code, the GPL is more intrusive. Most significantly, it contains what are referred to as ‘copyleft’ terms, which state that if you use GPL-licensed OSS code in your product, you must then make available the source code of your product to any subsequent licensee.
Really? I have to give my source code away if I use OSS?
The part of the GPL that covers this issue has been much discussed, and much disputed. It sits in section 2(b) of GPLv2 (there are currently three versions of this licence, but over 45% of all OSS software is licensed under v2). This section reads:
“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.”
Not surprisingly, the confusion arises over what “contains or is derived from” actually means. If I have a million-lines-of-code application which uses 50 lines of OSS to perform a relatively simple operation, does that mean that the full source code of my application must be disclosed to all licensees?
The answer to this question is far from clear, and depends upon many factors of the particular architecture of the software concerned, including:
- Is the OSS software incorporated into your application at compile time, using static linking?
- Is it incorporated by reference, using dynamic linking?
- Is the OSS software accessed at run-time using an API (application programmer’s interface)?
- Is the OSS software accessed at run-time using a system call?
These are fairly technical distinctions, and will be subject to intensive analysis of the individual programmes concerned. From a licensing perspective, there is a (reasonably) general consensus that incorporating OSS software into your application at compile time, using static linking, does constitute ‘containing’ the OSS code in accordance with section 2(b).
It is also generally agreed that system calls, and in particular any calls to OSS made via an API, do not ‘contain the OSS code as set out in section 2(b).
The area of dynamic linking, where there is no permanent combination of your code with the OSS code, is more heavily debated, and many of those fighting to protect the open source community and its principles argue strongly in favour of dynamically linked code being considered to ‘contain’ OSS, and thus be subject to section 2(b).
But who is actually going to police my OSS use?
In the first instance, any programmer or company who has made its source code available under an OSS licence would be entitled to enforce the terms of that licence against anyone using the OSS code.
The case of Jacobsen v Katzer and Kamind Associates Inc. was in relation to use of OSS software by the defendants without making available the resulting source code to its licensees. After a four-year Court battle, in which Mr Jacobsen benefitted from the support of leading members of the OSS community including the OSI, SFLC and the Linux Foundation, the parties reached a settlement. Katzer and Kamind Associates Inc agreed to pay Mr Jacobsen the sum of US$100,000, and to accept a permanent injunction against copying or modifying the OSS software developed by Mr Jacobsen.
Given the complex genealogy of most OSS code, with multiple contributors ranging from students in bedrooms, to professional programmers, to large corporations, it is unlikely that any one of them will be particularly enthusiastic about policing use of their code. However, there is an increasing trend towards action being taken by organisations claiming to represent the OSS community (like the Free Software Foundation, or FSF, established in 1985 as a non-profit organisation dedicated to the development of ‘free software’).
There have been a number of cases in which these organisations have identified companies in breach of the GPL, by searching through their products for OSS code and then investigating the company’s compliance with the terms of the GPL. Generally, these organisations have focused on ‘naming and shaming’ offenders, and such actions have resulted in the publishing of source code by the companies concerned in a number of cases.
The law of unintended consequences
The recent case of Versata v. Ameriprise started out as a straightforward claim breach of licence (because Ameriprise had permitted access to the Versata software to some contractors, in violation of Versata’s licence terms). But when Ameriprise looked into the software it had been licensed by Versata, it identified that the code included OSS from Ximpleware.
On this basis, it argued that actually the whole product was open source, and therefore Versata had no right to prevent it sharing the software with whomever it chose. And (just to make things even more exciting), Versata had failed to include the necessary GPL declarations and source-code statements in its software, making it in breach of GPL.
A nod and a wink from Ameriprise to Ximpleware, and Ximpleware jumped on the litigation train, bringing cases against Versata and others. So as a result of Versata attempting to protect the intellectual property rights it believed itself to have in its DCM product, it ended up effectively losing some of those rights in the course of a follow-on claim from Ximpleware.
But you’re talking about the big boys. Nobody’s going to worry about little old me…
While high profile and highly profitable software vendors are obviously a much bigger target for the OSS community, there remain significant risks for even small companies in using OSS software without a comprehensive process for ensuring that the relevant licence terms are properly complied with. These include:
- Most obviously, being sued by the OSS licensors;
- Being in breach of your own contracts with customers if you have given warranties or indemnities stating that your grant of this licence to them does not breach third party intellectual property rights;
- Being unable to successfully protect your own IP, as litigation could result in related claims from providers of OSS you’ve incorporated in your product; and
- Significant devaluing of your intellectual property assets by potential purchasers or VCs looking to invest, or a requirement for you to indemnify them against 3rd party claims relating to OSS.
This last point is a particular stinker – when selling a business, the buyer will usually require a certain number of indemnities. But as the seller, your objective is to keep these to a minimum and keep them under control. Having to stash a ‘potential litigation fund’ out of your hard-earned proceeds of sale can take some of the shine off the deal for years to come.
What should I do?
It’s essential that you’re commercially aware when using OSS. Ensure the terms of the OSS licence fit your licensing model and that you comply with them. Check that your customers are happy to receive products with OSS code as some organizations have a policy of not accepting software developed on this basis.
And finally, make sure your development teams are aware of your policies and comply with them, so you aren’t unknowingly being caught out by the actions of your developers. Often, they won’t think twice before using whatever help comes to hand, and this may well include modules provided under GPL V2. Raising awareness of the implications of this among your developers (and any contractors you use) will help manage your exposure.
If you use, or would like to use, open source software in your business and would welcome some support in establishing appropriate guidelines and contract terms, contact us. We’d be happy to help.
Tiffany Kemp
Founder and Managing Director, Devant
