Black Duck Open Source Audits: Working through licensing issues like a pro

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.

Potential conflicts

“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.

Research needed

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:

• Are the licenses assignable upon acquisition?
• Are the terms favorable?
• Can the vendor terminate for convenience?
• Is the target using this code in a way that is consistent with the commercial license?
• Are there royalty arrangements, and are they properly accounting for?
• Might costs scale with the size of company?

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.

OK to use

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.