It’s critical to have the right people and approach when it comes to understanding and resolving licensing issues in open source audits.
Many of our regular Black Duck Audit customers have well-honed processes that kick in after we deliver reports. We’ve gleaned some ideas and approaches from working with these clients and the biggest pro tip? You need a pro, i.e., make sure you have an open source-savvy attorney involved. The Black Duck team and its reports will provide guidance, but as non-lawyers, we can’t give legal advice, and in the end, each client and scenario is unique, so it’s best to involve your own legal counsel. Take advantage of a review call and include your attorney so they can ask questions of the audit team.
Our report findings provide a wealth of information in three categories: Potential conflicts, research needed, and OK to use.
“Conflict” refers to incompatible licenses, and declared conflicts can have a broad or narrow scope, meaning they can only apply to certain files and not the whole work. Typically, these are conflicts between the license of an open source component and the declared license of the work as a whole. The most common we see is a GPL-licensed component in distributed commercial code, but conflicts may depend on the usage scenario. A GPL license in code that’s not distributed does not constitute a conflict. Component conflicts indicate incompatibility between two open source licenses and are generally considered less serious.
Note that we count “not licensed” components as declared conflicts with a broad scope. These components were copied from the internet, but the copyright holder didn’t specify a license or provide any other indication of usage permissions. Most lawyers consider this problematic.
Your attorney should review all the conflicts, but you may want to ask some questions about targets, or the company being acquired, first. Targets frequently cover internal tools that aren’t part of the product. One of the most common ways a “conflict” is resolved is for a target to respond, “Oh, that’s just a debugging tool we use.” Never mind!
After winnowing it down to a solid list, your attorney can use our red/yellow/green indications to prioritize their review and help determine what needs to be fixed and when—and what protections you need in the definitive agreement.
Components that our auditors have deemed worthy of legal review fall into the “research needed” category. Commercial components have non-open source third-party code that requires a license from the vendor. Dual-licensed components are available under an open source license, often the AGPL, which makes it difficult to use them in a commercial product—in this use case, the vendor will offer a commercial license.
As with conflicts, it’s possible that the target is only using dual-licensed components for internal tooling, so you’ll want to have that conversation with the target. Get a copy of the licenses and have an attorney review them for both commercial and dual-licensed components. Some of the types of issues to be explored:
Also included under “research needed,” custom licenses and variants are components with license language either made up from scratch by the developer or standard license language modified by a developer. Senior consultants use judgment with these. If there was a comment that was clearly permissive—”you can do anything you want with this software”—they didn’t include it as a custom variant. Instead, they included language they felt a lawyer should review. For your attorney’s convenience, text of these licenses (as well as all the standard licenses that apply to the code) is found in the license text report.
As the name implies, “ok to use” components generally do not require a lot of prior close attention. This category comprises components under permissive licenses and “original code,” meaning software developed by the target’s developers. It is worth noting, however, that even permissive licenses include obligations, such as attribution in the final product. See if the target includes a notices file with their product and how comprehensive it is in comparison to the list of “no conflict” components. Typically, acquirers need to build in some time to create a notices file as part of integration.
Soon after you receive your audit reports, you should sift through the results with the target. An open source-savvy lawyer is likely familiar with Black Duck reports and can help navigate all the issues and provide the legal knowhow where needed.
Visit our website to learn more about Black Duck Audit Services, or download a copy of our Software Due Diligence Checklist.
Phil is the general manager of Synopsys’s Black Duck Audit business auditing the composition, security and quality of software for companies on both sides of M&A transactions. He focuses on software due diligence best practices and the M&A market. He also works closely with the company’s law firm partners and the open source community and is a frequent speaker on open source management and M&A. Phil chairs the Linux Foundation's Software Package Data Exchange (SPDX) working group which created an ISO standard for Software Bills of Materials (SBOMs). With decades of software industry experience, Phil held senior management positions at Hammer/Empirix and High Performance Systems, a startup in computer simulation modeling. He began his career in marketing and sales with Teradyne's electronic design and test automation (EDA) software group. He’s also written a book on fly fishing. Phil has an AB and an MS in engineering from Dartmouth College.