Understand the common scenarios where your codebase contains unlicensed open source, and the implications of it being embedded in commercial apps.
In 2019, the Black Duck Audit Services team audited 1,253 codebases to identify open source components, their associated licenses, security vulnerabilities, and overall community activity.
Our Audit Services team has extensive experience in not only identifying open source licenses, but also researching the more than 2,700 license permutations that exist in the open source world.
But what happens when an open source component has no license at all? In 2019, our auditors found that there were components with no known license in 33% of the codebases they examined.
Grant of rights
A license is a grant of rights. To use a piece of software, whether it is open source or commercial, you need some grant of rights. In the United States and many other places, creative work (including software) is protected by exclusive copyright by default. This means that no one can legally use, copy, distribute, or modify that software without explicit permission from the creator/author.
This permission comes in the form of a license that grants the right to do so. Without that license, the baseline assumption is that you do not have permission to use the software. Clearly, including an open source component without a license in a commercial application can be problematic for a company.
Organizations that use unlicensed code are at a greater risk of violating copyright law than those using licensed components, because in the absence of a license grant, a user cannot determine what their rights are (if any).
Here are the ways unlicensed open source can make it into a codebase, and the implications of it being embedded in a commercial application.
- Unlicensed components
The most straightforward way is when the creator (and copyright holder) just did not choose or assign a license when creating the open source component. You may think the absence of a license restricting use means it is free to use. But by copyright law, there is no grant of rights without explicit permission from the creator/author.
Thus, the assumcption with components like these is that you do not have permission to use, modify, or distribute the component. In these situations, a company has to decide how risk-adverse it is. Without a license, a company does not have permission to use the component and runs the risk of a costly and time-consuming IP lawsuit. This may seem like a fringe case, but as mentioned, we found this exact scenario in 33% of the codebases we audited.
- Modified components
Another scenario we see during our audits is a developer modifying an open source component to ensure it performs a required function. In making these modifications, the developer might change or remove a header file or the user/license information for the component. But if you are including a component without understanding the associated license, how can you ensure you have the appropriate rights to use the code in the way you intend to use it?
At a minimum, there should be a forensic investigation into the origin of the component to ensure you are complying with any obligations associated with the license. Taking this extra time late in the development cycle, or in the middle of an M&A due diligence exercise, can waste precious time and resources and potentially impact the valuation of an acquisition.
- Open source snippets
Our last scenario is not quite as straightforward. We often find that, when writing code, developers may pull in a snippet of open source code from popular places like the website Stack Overflow. Snippets are not entire components; they are just a small part of a component that performs a specific function. But snippets obtained from places like Stack Overflow are almost never accompanied by applicable license terms.
Some will question if the snippet in and of itself is worthy of copyright protection in the first place. In other words: is there creativity in the snippet, or is it purely functional code and thus not copyrightable subject matter in the first place, and therefore does not require a license?
This debate comes down to how risk-adverse you are, especially given the relatively low threshold for a piece of code to be deemed creative enough for copyright protection.
In the worst-case scenario, a court will decide, and you may need to strip the code out of the application, requiring you to spend precious time reworking the application, as well as money and legal resources resolving the issue.
Staying on top of licenses
Key to any open source compliance program is first identifying with specificity and certainty what open source you are using. Armed with that list, it should be possible to map each identified open source component to an applicable governing open source license.
If the applicable license cannot be identified for unlicensed components, modified components, or code snippets, you should investigate what permission you have to use the software.
Unfortunately, this investigation often takes time and resources that most development and legal teams do not have—particularly when the investigation starts right before deployment or during a time-sensitive due diligence process.
Any company using open source software (and research shows nearly every codebase contains at least some open source) as part of its development process should establish clear policies for open source use, and employ a reliable way to keep track of the open source and open source licenses in their applications.
One way is to use Software Composition Analysis (SCA) to identify the open source components in an application, including modified, undeclared, and snippets of open source. This helps you to understand the associated licenses and set policies that automatically trigger reviews if a component is unlicensed or if the license violates your company policy.
Open source license issues can be complex, up to interpretation, and costly for teams. But proving compliance can be simplified with the right tools and services to ensure compliance and save precious time performing forensic investigations into licenses late in the development cycle.