What You Should Know About Open Source License Compliance for M&A Activity

Companies are increasingly concerned about the security risks lurking within open source code, especially as they navigate complex mergers and acquisitions. Each piece of open source software is governed by a license, a legal contract dictating how the software can be used. While this might sound straightforward, the reality is a complex web of over 200 different licenses. To ensure legal compliance and mitigate risks, companies must meticulously catalog and understand the licenses embedded within their software, especially during M&A deals.

It’s not just about security; it’s about survival.

In this article, you will learn how to navigate the complex world of open source licenses, understanding their implications for software development, especially during mergers and acquisitions, to protect your business from legal and security risks.

This article is part of a series of articles about Open Source License Compliance

Types of open source licenses

Given the nature of open source, it’s unsurprising that licensing rules are also open. Anyone can create an open source license that suits them — that’s why there are so many out there. In general, however, open source licenses can be divided into two main categories: copyleft and permissive. Permissive licenses, like Apache 2.0, are typically referred to as “anything goes” because they place minimal to no restrictions on how others can use these components. Given the lack of restrictions, there is relatively little compliance risk with this category.

Copyleft licenses, such as the GNU General Public License (GPL) family of licenses, are a different story. This category of licenses gives other people the right to use, modify, and share the work, as long as the reciprocity of the obligation is maintained. In layman’s terms, if you’re using a component with this kind of license, you have to make your source code available for use by others.

Risk of copyleft licenses

We’ll use GPL as our example, but these same principles apply to other copyleft licenses.

GPL requires the release of components’ full source code along with the broad rights to modify and distribute that source code. When you build software using GPL license components, you have to release your work under a GPL-compatible license regardless of the percentage of GPL license code being used.

Nobody wants to do that, because anyone, including competitors, can learn how your software is structured and designed. Then they can modify your program, perhaps building out new high-demand functionality that supersedes your product. That’s a big risk.

How do we reduce this risk?

The GPL requirement to share source code applies to all derivative work. However, it doesn’t extend to programs that are separate and independent from the GPL license work. Unfortunately, there’s no clear legal definition of when proprietary software is separate and independent. Nevertheless, you can reduce your exposure by: 

• Using a dynamic rather than a static link between the GPL module and the custom software.
• Using separate names for the GPL and proprietary modules.
• Including separate copyright notices for GPL and proprietary modules.
• If it’s practical, price the software with and without the GPL module.
• Provide the GPL and proprietary modules to be downloaded separately.
• Provide them as separate executables and have separate documentation.

Creating a company policy for the use of components

Every company needs a clear policy regarding how or if certain open source license components can be used. Using GPL as our example, at a minimum, a policy should cover the following: 

• Will you permit any GPL components in products that get distributed?
• Can they only be used in the backend tools and not part of the distributed product?
• If these components are allowed in deliverables, which GPL versions will you prohibit? 

Licensing should be treated just like security where you manage by exception because it’s easier to have “block” lists instead of “allow” lists. Imagine trying to approve hundreds of thousands of components with over 200 different license types instead of just blocking a few unacceptable license types.

How to ensure license compliance with GPL components

Achieving license compliance with GPL components is essential to avoid legal pitfalls. Two primary steps are crucial:creating a compliant notice file and making all source code accessible. A notice file, often referred to as a header file, must be updated with each new release to accurately reflect the open source license terms. This typically includes a copyright notice, disclaimers, and the specific license text. By diligently following these steps, developers can maintain GPL compliance and protect their software projects.

Technical due diligence: Top tips

Due diligence is crucial for accurately valuing a company and determining potential risks. It’s often conducted during major corporate events like M&A, and IPOs.

It involves assessing a company’s technology-related aspects like its products, software, systems, and practices. Our focus here is on third-party software use. You need to keep a record of any third-party and open-source components that you use. Here’s how to prepare and avoid any unpleasant surprises:

• Prohibit people from downloading any software, without first reviewing its licenses.
• Know the intended use of the software.
• Categorize software by its license type, along with its permitted and prohibited uses.
• Document which version you’re using, including a link to the license text.
• Be aware of any license restrictions.
• Document if you have access to the proprietary program.
• Ensure the source code version is available for download for any GPL components..

Be prepared. Use an SBOM

The main lesson is to get your open source license policies and controls ready if you think M&A activity is imminent. Start by inventorying what components you’re using and their associated licenses and risks. Use tools like a software bill of materials (SBOM) to achieve this. It’s something that numerous governments are mandating. 

Learn More: Best Practices for Open Source Governance

Streamlining the process with SCA

This is overwhelming to do manually, but there’s an easier way, using software composition analysis (SCA).

During the due diligence process, you should produce a list of all your third-party software dependencies and relevant metadata. This should include the package names, authors, supplier inversions, declared hidden licenses, dependency paths, and whether the packages have been statically or dynamically linked to the product.  With the right SCA tool, you can do all this automatically in real time when a developer pushes code.

You could commission an external audit on your code base, but typically firms that do this use an SCA tool anyway. If you choose an external audit, ensure it flags any known open source vulnerabilities with contextual data like the CVE score. Ensure it identifies any copyleft license components and includes a license compatibility report.

Finally, a good audit should include an attribution report, containing all the licenses, the license text, the copyrights, and the notice files required for each open source component.