Understand the three common scenarios for why unlicensed open source is found in the codebase 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. Let’s discuss the ways unlicensed open source can make it into a codebase and the implications of it being embedded in a commercial application.

Grant of rights

Before we jump into the implications, let’s define what a license does for software. A license is a grant of rights. To use a piece of software, whether it’s open source or commercial, you need some grant of rights. In the U.S. 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 can’t determine what their rights are (if any).

How unlicensed open source makes its way in

Unlicensed components

An unlicensed component can make its way into a codebase in a few ways. The most straightforward way is when the creator (and copyright holder) just didn’t choose or assign a license when creating the open source component. You may think the absence of a license restricting use means it’s free to use. But given the copyright law stated above, there is no grant of rights without explicit permission from the creator/author. Thus, the assumption with components like these is that you don’t 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’re 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’re 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 isn’t quite as straightforward. We often find that when developers are writing code, they may pull in a snippet of open source code from popular places like the website Stack Overflow. Snippets aren’t entire components; they’re 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 doesn’t 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 open source 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 can’t 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 don’t have—particularly when the investigation starts right before deployment or during a time-sensitive due diligence process.

Development teams

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. Of course, as a software composition analysis (SCA) solution vendor, we recommend using an SCA tool to identify the open source components in an application, including modified, undeclared, and snippets of open source. Our Black Duck SCA product allows 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. This will ensure compliance and save precious time performing forensic investigations into licenses late in the development cycle.

Mergers and acquisitions

Given the findings of our Audit Services team, it seems many companies are still failing to properly manage their use of open source. As a reminder, 33% of the codebases we audited in 2019 contained unlicensed open source components. And an astounding 67% of the codebases contained components with license conflicts (a topic for another blog post). For companies making acquisitions, especially acquisitions where the intellectual property being acquired is software, we suggest you verify that all licenses have been identified and complied with before the deal is done. The majority of our audits are performed during due diligence, so the findings are highly relevant for M&A in particular. Our Black Duck Open Source Audit reports allow you to understand every bit of open source in the software, and know whether or not the proper grant of rights has been received. Our Audit Services team will research any component that appears unlicensed, as well as perform the forensic investigation into modified and open source snippets to get to the root of their license. Understanding this before an acquisition is of paramount importance, as the value of the IP is at risk if it’s found to be out of compliance. And even if potential issues can be fixed, the time needed for remediation still must be accounted for during an integration, and those resources potentially planned for in escrow.

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.