Open-source software – issues we see cropping up in practice

OSS has been embraced by developers – according to the Synopsis 2023 Open Source Security and Risk Analysis, 96% of scanned codebases contain OSS and 76% of code in those codebases is open source.

However, although use of OSS presents benefits, we are seeing open-source licence issues throwing a spanner in the works in corporate acquisitions. Technology businesses should be aware of these potential issues. 

The issue with restrictive OSS

Different licence terms apply to different types of OSS, and some open-source licence terms are more “aggressive” than others. Broadly speaking, OSS licences can be categorised as either “permissive” or “restrictive”. Permissive licences typically require only that the original OSS continues to be distributed on the same terms as those on which it was provided. This may include attributing copyright to the original author. It is restrictive licences that can cause particular issues – they may impose licensing conditions where the OSS is changed or combined with any other software and a “derivative work” is created. It is in connection with these types of licences that the term “copyleft” gets used.

“Copyleft” is the requirement that the freedoms the OSS licence guarantees (including freedom to use the source code without payment) also apply to new works derived from or containing the original restrictive-licensed software. The most common restrictive OSS licences are the General Public Licence (GPL) family of licences. Businesses should monitor their use of restrictive OSS because its use can create a “viral” chain of freedom-to-use.

In corporate transactions that we have been advising on, unchecked use of OSS has given rise to risks that have troubled potential buyers and raised question marks over the target’s value. Particular licences that have come under scrutiny on transactions we have been working on include the GPL v2, GPL v3, LGPL 2.1, LGPL 3 and the MongoDB Server Side Public Licence (SSPL). The risks have included, among other things:

• Breach of copyright, for which remedies include damages or an account of profits
• Unintended licensing of the target’s core source code under the OSS licence because it is derived from OSS.
• Reputational damage from negative publicity, and potential damage to brand value. There are examples of individuals and organisations looking for signs that certain OSS has been used in software products in breach of OSS licence terms and posting details online where they feel they’ve identified a breach.
• Need for time and expense to be incurred to reduce reliance on OSS licensed on a restrictive basis
• Security vulnerabilities

Recommendations

To avoid the risks referred to above, we recommend that tech businesses have a policy that is followed internally and regulates what OSS is used. Relevant principles to cover include awareness of:

• What OSS is being used – have a process to capture details of OSS used to help governance
• What licence terms apply to the OSS being used – using OSS licensed on “restrictive” terms should only be done when the consequences of the licensing arrangement are understood
• What the OSS does and in which products is it being used – is the OSS being combined with other software that will create a “derivative work”?
• Approvals required for use of OSS in the business – certain OSS licences could be pre-approved, if they are “permissive” licences. Who do developers need permission from if they want to use OSS licensed on terms that haven’t been pre-approved?