Sorting through open source license risks

Software audits are the best way to uncover open source license risks before you go to production. Here’s how our audit group categorizes license risks.

The Black Duck Audits group analyzes thousands of codebases annually. Our customers are focused primarily on open source license compliance. So in this article, I’ll provide you with a general understanding of how we categorize open source license risks for our customers. Please note that I am not an attorney and these views do not represent a legal opinion.

Many factors determine which license scenarios are safe to use and which are not. This is complicated by the fact that some open source licenses are safe only when the code is used in specific ways.

When we audit codebases, we focus on identifying all open source and third-party components along with their associated licenses. As much as possible, we also identify how those components are used so we can determine if there are any potential license conflicts. This gives our customers actionable information about the open source and third-party code in the codebases that we audit.

Sponsorships Available

Sponsorships Available

Sponsorships Available

As part of an audit, we give each component that we find a category and status according to the risk based on its combined license and usage. These categories and statuses help customers determine level of risk and prioritize any required mitigation. Given that the vast majority of the codebases that we audit are proprietary and commercial, that’s the type of codebase I’ll discuss in this article.

Categories of open source license risks

We group open source and third-party commercial components into three categories to help customers prioritize potential issues:

• Conflicts contains components whose licenses appear to conflict with commercial (or open source) licenses found within the same codebase.
• Research contains components whose licenses require further research to determine if they are being (or can be) used properly.
• OK to Use contains components that may be used without creating licensing conflicts.

NOTE: Whether or not licenses conflict can depend on how components are compiled or linked within the larger software product. It can also be affected by how (or if) the software is distributed.

For example, code under the GNU General Public License v2.0 (GPLv2) poses a problem when compiled into a normally distributed piece of commercial software. But the same code is not a problem when used in software that is considered “software-as-a-service,” or SaaS (e-commerce sites are typical of this). This is because the obligations of the GPL are triggered only on distribution of the associated software. SaaS code is not considered “distributed” by the GPL.

Open source license statuses

Within our three license categories, we use eight distinct statuses to group components based on open source license risks:

• Conflicts: Declared Conflict (Broader Reach), Declared Conflict (Narrower Reach), Component Conflict
• Research: Dual Licensed (Commercial vs. Conflict), Custom, Third-Party Commercial
• OK to Use: No Conflict, Original Code

Conflicts

Declared Conflict (Broad Reach)

A declared conflict exists when the open source license in question shows a potential conflict with the declared license for the codebase under audit. “Broad reach” refers to the fact that (1) the reach of the license goes well beyond the open source code that the license comes with or (2) it’s difficult to use the code in a way that avoids a conflict.

An example of this is the GPL. This license stipulates that any code that is compiled or linked with the GPL code and distributed must then be under the GPL license. This stipulation clearly has a negative impact on the intellectual property (IP) of any commercial product that uses that code.

NOTE: Under copyright law, you need to have a license to use code. We give this status to all code with unknown licenses.

Declared Conflict (Narrow Reach)

Licenses in this category also have a declared conflict. However, they typically have less reach or are easier to use appropriately to prevent a conflict.

An example of this is the Common Development and Distribution License (CDDL). This license can be used in conjunction with commercial software. It requires that any source code combined in the same physical source files with code under the CDDL be made available under the CDDL. A safe way to use CDDL code would be to use it unmodified (or you must contribute your modifications back to the project).

NOTE: We flag this license only if the corresponding code is used improperly. If it is used properly, there are no open source license risks, and we assign the “No Conflict” status (explained below).

Compound Conflict

We use this status when two or more components have licenses that conflict with one another but can be used safely by themselves in a commercial codebase. This situation occurs infrequently. When it does, we recommend that the code owner research the interaction between the components to see if their interaction would cause a conflict.

Research

Dual Licensed (Commercial vs. Conflict)

Sometimes a component has two or more licenses that you’re allowed to choose from. If one of the licenses is a commercial license and all alternative licenses would cause a declared conflict, we use this status. You should validate that a commercial license is in place.

This situation occurs when the authors wish to make their code freely available to noncommercial developers but want commercial developers to pay for its use. It has become a common business model.

Custom

We use the status “Custom” for components that have licenses that we have not seen before or had reviewed by an attorney. We provide the license text in our report so that your attorneys can review and research that license.

Third-Party Commercial

This status indicates code that is only under a commercial license. An example of this is when we discover third-party copyright notices from commercial companies or wording to the effect that the author has reserved all rights to the code. You would need to validate that you have acquired a proper license to use the code.

OK to Use

No Conflict

We use the status “No Conflict” for code that can be used with commercial code without any issues. Many people refer to the typical licenses that fall into this status as permissive licenses. The most common examples of permissive licenses are the MIT and BSD licenses.

NOTE: Just because a license falls into the “No Conflict” status does not mean that it doesn’t have obligations. The distinction here is that the obligations shouldn’t cause a conflict with a typical proprietary commercial license.

Original Code

This status “Original Code” refers to code that we have determined was written by the code owner of the codebase being audited and is not from another source. Of course, truly original code carries no open source license risks.

Do you know what’s in your code?

I hope this article provides some insight into the potential interactions and risks of open source licenses. We advocate the proper use of open source, and we’ve designed Black Duck Audits to help you understand the open source license risks in your codebase so that you can address them.

Learn more about open source software audits