Article Source: Nick Valentine, LinkedIn
Open source software is a fundamental building block in almost all development projects. Being aware of some of the inherent risks with open source code, and implementing effective strategies to mitigate them, will go a long way to maximising the value of your technology.
Source code is very rarely written from scratch – third party code provides the building blocks for software development. Often a core component of any program is open source software.
There are clear advantages to using open source code in software development, including:
- cost – generally, open source software is available for free and is a whole lot cheaper than the development resources needed to write bespoke code; and
- in the case of projects that have a large and established community following, the software is arguably more secure and resilient because of the large number of developers making improvements to the code.
However, there are a few things you should be aware of before using open source software in your development. If you are aware of the risks and have taken steps to address them, you’re ahead of the game in terms of maximising the value of your company.
This post focuses on the risks associated with ‘copyleft’ licence terms, but don’t discount the technical issues around open source security (and known vulnerabilities) and quality assurance.
TL;DR
- Some open source licences (‘copyleft’ or ‘restrictive’ licences, like the GNU General Public License (GPL)) can ‘infect’ your code, which means you have to distribute your software with the source code, on open source terms. This ‘worst case’ scenario could torpedo your commercialisation strategy.
- For start-ups, the risk of being sued is relatively remote. The bigger issue is the impact on the value of your company at IPO/equity investment stage.
- Savvy investors know about these issues. During due diligence you’ll have to satisfy them that you’ve addressed the risks. If you can’t, they might walk away or reduce the amount they’re prepared to invest.
- We get it – you need to use open source code and we’re not saying you can’t! Just be aware of the issues and implement best practice to manage them. This includes developing a robust open source policy and thinking about how you use copyleft code.
Going viral – in a bad way
By definition, when open source software is distributed, it must be distributed with the source code (or the source code must be available to licensees), and open source licences require free redistribution of, and the right to modify, the code. The Open Source Initiative’s full definition of ‘Open Source’ is available here.
Some licences have minimal restrictions on how the software can be used and redistributed (for example, crediting the creators of the original code through attribution). These are known as ‘permissive’ licences. A key characteristic is that they do not restrict the creation of proprietary derivative works – you can modify the code and redistribute it as proprietary software. The MIT and Apache 2.0 licences are widely used permissive licences.
Other licences, known as ‘copyleft’ licences, require derivative works or modifications of the open source software to be distributed under the same open source terms (ie you cannot distribute a modified version of the code on proprietary terms). The goal of copyleft licences is to make sure all versions of a program remain ‘free’ for all its users (in terms of freedom to use, not free of charge). The GPL, and the increasingly popular GNU Affero General Public License (AGPL) are examples of copyleft licences.
Incorporating software licensed under these terms into your code can result in ‘infection’ by the copyleft licence terms. By ‘infection’, we mean that incorporating the copyleft code into your proprietary program could mean the whole program is considered a modified version of the open source code, which needs to be licensed on the same open source terms (not just the open source components of the program). If you distribute the software on proprietary terms, you’ll be in breach of the open source licence, making yourself vulnerable to being sued for copyright infringement and/or breach of contract.
How does this affect a tech company’s value?
If proprietary software is a company’s core asset, one of the first questions any sophisticated investor will ask during due diligence is what open source code has been used in the development of that software. Investors may also want to run an automated scan of the code to identify incorporated open source components. The purpose of this process is to assess your compliance with the open source licence terms, and the risk of infection. If any concerns are raised, investors will want to delve deeper via Q&A.
Investors know that, realistically, the risk of a start-up being sued for incorporating some open source code in its proprietary program is probably low. However, when making the decision as to whether to invest (and how much they’ll pay) they will factor in the possibility of losing the ability to license software on proprietary terms, and the associated loss of licensing revenue. They will also not completely rule out the possibility of a costly law suit – there are examples of where copyright owners have enforced open source terms, such as Artifex Software’s case against Hancom for copyright infringement and breach of the GPL relating to Hancom’s distribution of Artifex’s PDF interpreter ‘Ghostscript’. The case recently settled for an undisclosed amount.
Ultimately, this could cause an investor to walk away from the transaction, or devalue the business. Not ideal if you’ve already leveraged yourself to the hilt for that Ferrari or Queenstown holiday house!
Avoid infection – use protection from the outset
Don’t panic – we’re not saying you can’t use open source code, you just need to be smart about it. If you are using open source software in the development of your proprietary code, you should:
- Implement an open source policy – make sure you know what open source software your team (including contractors) is using in your projects, and understand the licence terms for that software. Be particularly vigilant around copyleft licences like the GPL. As well as setting parameters to minimise the risk of inadvertently infecting your code or breaching the open source licence terms, a documented policy will give investors comfort that you have taken a considered approach to your software development and that you have internal processes for minimising infection risk.
- Think about how you use the open source code. For example, linking to an open source program through an API, rather than incorporating it into your proprietary code, should reduce the risk of infection. There is debate as to whether linking proprietary and open source programs (eg linking to a GPL library) is captured by copyleft licences. GNU’s FAQs indicate that they think linking code licensed under the GPL with other code makes the entire program subject to the GPL (eg see here) – I think that’s overstating it, but be aware that it is a technical area that carries a level or risk.
- Have a chat with us. A bit of time with your lawyers at the start of a project could save you a whole lot of stress down the track.
