What You Should Know About Open Source License Compliance for M&A Activity
Companies are increasingly concerned about the security of applications built on open source components, especially when they’re involved in mergers and acquisitions. Just like copyright for works of art, each piece of open source software has a license that states legally binding conditions for its use. Licenses allow developers to use the software as components, providing they keep to the specific terms and conditions that define what they are permitted and prohibited to do with the software.
This sounds simple, but there are over 200 open source licenses out there. When you prepare for M&A, you need to know and catalog each one that you use. And you need to know what licenses apply to your software to ensure that your use is legally compliant.
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
There are two key steps to comply with GPL.
- Prepare a notice file that complies with GPL requirements.
- Make all source code available.
A notice file, sometimes called a header file, must be updated as a new release of your program comes out. It contains disclosures required by the open source license. Typically, these include a standard copyright notice, relevant disclaimers, and specific license text.
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.
Learn more about readying your open source licenses for M&A. Watch this webinar
