Open source code is now so universally incorporated into technology, it's surprising that it can still be treated as a red flag by buyers and investors. To reiterate what we said in the first article in this series, the clearer your knowledge of how your technology, or systems, are built and which licences apply, the better position you are in to identify any risks and show how you have actually managed them.
Article 2 in this series, on IP ownership, touches on this too, flagging that copyleft licences (those in the GPL family especially) are the ones that tend to worry investors, and that knowing what's in your stack, under what licences, is an important starting point. Here we go a little further by identifying the mistakes we see most often and outlining a practical way to get on top of it.
Open source is not a grey area; it's heavily documented and clearly licensed. What can make it a red flag for investors is the uncertainty of use; where very few people in the business (if any) have actually read the licenses, kept track of which are being used, or thought about what they mean for the particular product utilising the code.
Why founders underestimate the risk
Open source is treated like infrastructure, not intellectual property. Developers are constantly making use of multiple different packages often within a single sprint. The legal team is not consulted before installing for example, a logging library or a date-formatting utility, and fair enough, it is understood that no-one wants to have to bring legal into every one of these decisions. The problem is that it is easy to lose track of what's contained in a codebase and what licence terms govern its use, particularly as your business and the teams within it grow.
The fact that open source is free to use, also brings with it some issues: (i) the assumption that because it is free it’s fine to be used; and (ii) that no-one should waste additional business time looking into the terms and conditions. It’s true that you may not have to pay any charges to use open source and it is ‘free’ in that sense; but it is not free of terms or licensing restrictions. Every open source licence is a licence with terms and conditions, much like any other licence you utilise, and some of those conditions can have real commercial consequences.
How is the code being used?
The level of risk really depends on how the code is used, and this is often overlooked:
- Internal use. Tools which are used to build or run the business such as CI/CD pipelines, internal scripts, developer tooling etc, that never leave the company generally present the lowest-risk category (although it should be noted that some licences do attach conditions to modification or internal deployment of the code).
- Embedded in a product, but not distributed. For example, open source components which run inside a SaaS product accessed remotely but never distributed as a copy. This used to be lower-risk under traditional copyleft licences, which are typically triggered by “distribution”, but the gap has been filled by newer licences like the AGPL, by extending obligations to software made available over a network.
- Distributed to customers. Software, SDKs, mobile apps, or on-premise deployments that customers actually receive a copy of. This is generally the highest risk area for open source licences as many are drafted around the act of distribution, and there are many software businesses who may believe they do not distribute software but, in fact, do distribute something be it an app, an SDK, an on-prem agent or other without realising that this is a distribution of software.
Not all open source licences carry the same risk
This is the point that is misunderstood most frequently; the fact that a business uses open source software reveals almost nothing about the level of risk involved. What actually matters is which licences are relevant, and what do they stipulate. In a nutshell:
- Permissive licences (such as MIT, Apache 2.0 and BSD) generally allow free use, modification, and distribution, usually only requiring attribution and preservation of copyright notices. These are low risk licences with minimal obligations and should not present a problem.
- Weak copyleft licences (such as LGPL, MPL) generally only require that any modification of a licence -covered component must be made available under the same licence terms, without necessarily affecting the rest of the codebase. This is a manageable risk but is something to be aware of component by component.
- Strong copyleft licences (such as GPL, AGPL) can require that any software incorporating or linking to the component, potentially including proprietary code, be made available under the same licence terms. This is the category that can force a genuinely uncomfortable conversation about whether proprietary source code needs to be disclosed.
The practical point is not that copyleft licences should be avoided at all costs - plenty of businesses use GPL or AGPL components deliberately and manage the risk. The point is that no risk can be managed if it is not being identified and this should be done ideally, at the outset of use.
Common mistakes we see
- Not knowing what's actually in the codebase. No dependency inventory, no software bill of materials (“SBOM”), no reliable way to respond to the question, “what open source are you using?” other than “a lot!”
- Not tracking licences against components. Knowing the package names but not keeping up with the licence terms attached and potentially relying on assumptions that were true for a previous version but not the next; every time code is used from an open source library it should be tracked against the name and version number of the licence.
- Assuming free means no obligations. Treating the absence of a purchase price as the absence of any terms at all.
- Not checking for disclosure, attribution, or distribution triggers. Not checking to see whether a particular use of a particular component crosses the line into an obligation to share source code, credit the author, or make certain code available.
- No internal policy or approval process. Developers have freedom to add code from under any ‘free’ licence, with no review or requirement to record the decision, meaning the business really only finds out what it has been using when the due diligence team does.
Where this actually comes up
Customer procurement. Enterprise customers increasingly ask for a SBOM, or they run security and licence-compliance questionnaires as part of onboarding and competent knowledge of the licence requirements in your stack is what gets a deal signed.
Investment due diligence. Investors will typically want comfort that no copyleft licence creates a disclosure risk for the IP they're investing in.
M&A and exit preparation. Any buyer's technical diligence team will look at open source use closely, as it may genuinely impact what they're allowed to do with the code after completion. Unresolved questions here may surface as warranties, indemnities, or even price adjustments if the teams are not provided with satisfactory or fulsome responses.
Practical steps to get ahead of it
None of this requires an overnight rewrite. It requires visibility, a simple policy, and a habit of checking before the questions get asked rather than after.
- Generate a SBOM or dependency inventory, so you can actually answer the question “what open source do we use?”
- Map each component to its licence and version number.
- Set a simple, tiered policy which sets out what licences are pre-approved (and for what use) which will need review, and which are completely off-limits and make sure this is implemented within the business.
- Include an approval step in place for any usage requiring a copyleft licence.
- Review your open source position regularly and before any enterprise customer deal, funding round, or sale process.
- Keep a record of what's been reviewed and decided, where any approvals have been granted, so knowledge is not missed when it is required.
Where this leaves you
Open source is important infrastructure that almost every modern tech business relies on, and buyers and investors are aware of this. What is required, when open source queries come up, is a response that shows that you know what you use and have that use under control. As with the rest of this series, the businesses that get caught out aren't usually the ones with the riskiest dependencies, they're simply the businesses that didn’t check what they had and have nothing to show when they're asked.
This article is for general informational purposes only and does not constitute legal advice. If you would like to discuss your specific situation, please get in touch with the ClearCube team at hello@clearcube.law