If your business relies on the creation, licensing or resale of software, you will almost certainly have elements of open-source software (OSS) included within your product suite. 

This briefing note covers:

• What OSS is, and how it’s used

• Common OSS licences, and their implications

• Recent legal cases and their impact

• Implications for you of using OSS

• What to do, if you use OSS in your software products

What OSS is, and how it’s used

Reusing existing code to perform common operational functions is good practice. It reduces development and testing time, improves reliability and keeps costs down. Since software was invented, developers have been making good use of their own and their colleagues’ libraries of useful modules for exactly this purpose.

Extending your access beyond code you and your colleagues have written, into the wider OSS space, can be hugely useful. 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).

As you’ll know from your years in business, though, nothing is ever really free. Even ‘free’ OSS can come with a catch that could create problems for your company in the future.

Common OSS licences, and their implications

Most OSS is licensed under either the GNU General Public Licence (GPL), or another of the many open source licences available. The various versions of GPL account for the majority 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.

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). The LGPL variant of the GPL licence clearly allows the OSS to be linked with (‘used by’, in the case of library modules, the most widely used form of OSS using this licence) by other software, without requiring that the other software’s source code be made public. LGPL can therefore be helpful to those who use open-source libraries, providing fewer restrictions than full-blown GPL.

If you provide runtime-only access to your software over the internet, as a hosted or SAAS application, you may think this avoids the ‘copyleft’ obligation. You still need to pay attention to the OSS modules you use, though – a variation on the GPL, known as AGPL, plugs this gap. This licence extends the scope of the ‘copyleft’ provision so that it applies even to software that is accessed over a network at runtime, requiring the software publisher to make the source cope available to all users who access it. 

Recent legal cases and their impact

As one software developer said to me recently, “the only person in the world who knows exactly what source code is in my product is me”. On this basis, you could argue that there’s no point getting hot under the collar about OSS use in your product, since nobody will ever find out. The difficulty is, however, that information has a habit of leaking out at the most inopportune times!

The 2015 case of Versata v. Ameriprise started out as a straightforward claim for 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.

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.

Using OSS. Implications for you

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 (and subsequent liability to them if the OSS owner finds out and brings a claim);

• 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 3^rd party claims relating to OSS.

Preparing for a company sale is often the time when use of OSS becomes an issue for business owners. Buyers will have a standard set of warranties that include a warranty that the sellers own all of their own intellectual property. If yours is a software business, and your IP is your main asset, your buyer will probably ask some specific questions about your use of OSS. Identifying that some of the OSS you use in your product is under licences requiring ‘copyleft’ could significantly diminish the value of your business. At the very least, it may require some work to extract the OSS from your code library, or procure a paid-for licence to avoid the ‘copyleft’ requirements.

What to do, if you use OSS in your software products

Doing an audit of all the OSS components used by your software, and the licence terms that relate to them, is a great place to start. Ensure the terms of the OSS licence fit your licensing model and that you comply with them. For example, most OSS licences require that you include an appropriate copyright notice in with your licence agreement to your customers, together with links to the source code of the OSS included in your product. This is entirely do-able, but does require some effort – both to put in place, and to manage and maintain as your software evolves over the years.

You might also want to check that your customers are happy to receive products with OSS code, as some organisations have a policy of not accepting software developed on this basis.

If this is a big issue for you, you may consider looking at alternatives – could you develop your own versions of existing library modules that you’d usually use? Are there options for commercially licensing an alternative, on terms that make sense for you financially?

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, or even AGPL. 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 your Devant team. We’d be happy to help.