If you’ve reviewed any Black Duck Audit reports recently, you may have noticed improvements in the legal tab and the way we report on findings.
If you have reviewed any Black Duck Audit reports recently, you may have noticed improvements in the legal tab and the way we report on findings. The new report format has received some very positive reviews, the theme being that it makes reported results more actionable.
The biggest change we made on the legal tab was to add a layer of hierarchy in categorizing findings. We classify licenses for components as follows: Research Needed, Potential Conflicts, and OK to Use.
This classification represents license scenarios about which we recommend our clients gather more information and evaluate. For example, we suggest further research in the following cases:
Third Party Commercial code indicates that the code requires a commercial license from a vendor or that the existence of a license agreement needs to be verified.
Dual Licensed indicates code offered under a license that would conflict with the intended use, but the code is also available under a commercial license. So it’s an either/or situation: Either the code owner has a commercial license agreement in place, or there is a license conflict. The dual license business model has become fairly common. The recent Artifex/Hancom case is an example of a problematic scenario where a developer utilized a free version and neither obtained a commercial license nor complied with the open source license.
Custom licenses. Typically these are one-off situations where the copyright holders include some license language of their own creation. If the language is very clearly permissive, we empower senior consultants to call it No Conflict. However, if there is any doubt, we put it under Research Needed to let our clients’ counsel make the call.
When we talk about license conflicts, we use the word “potential” because it’s appropriate for a knowledgeable lawyer to review and make the final call. Different lawyers interpret licenses differently, and different companies have different risk tolerance. That said, attorneys tell us our classifications are extremely helpful to prioritizing their review.
Declared Conflict means that the license and usage conflicts with the declared license and use of the entire work. Usually our clients are looking to either distribute under a commercial license or host as SaaS. We distinguish between conflicts with licenses that have broader reach and narrower reach. Broader reach licenses tend to extend to the entire derivative work, so are more difficult to remediate. Narrower scope means that the impact is confined, perhaps just to a single file in question. Component conflicts are licenses that don’t conflict with the declared license, but do conflict with each other. These have become rare, but we do include them when we find them.
We also treat unlicensed code (or “Not Licensed,” as we designate it) as a Declared Conflict to prioritize it for review. This is code that is freely available on the internet but for which no license information is made available. For example, a developer might share code in a personal blog and simply say: “Hey, look how I implemented this cool algorithm.” But their blog includes no other indication of the permissions. Most attorneys we speak with consider this problematic. Auditors primarily rely on license information in the Black Duck KnowledgeBase. However, if the KB team has been unable to find a license, auditors go the extra step of researching on their own. Only after completing that research will they declare something as Not Licensed.
OK to Use is pretty self-explanatory. The code owner’s proprietary code falls under that heading, as does permissively licensed open source. It’s worth bearing in mind that while it is “OK to use” permissively licensed code, most licenses still carry an attribution obligation with which code owners should comply.
The Black Duck Audit Services team is continuing to evolve our reporting capabilities, so stay tuned for future developments. If you have ideas, requests, issues, or feedback, I’m very open to your thoughts. Contact me at phil.odence at synopsys.com.
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.