Dual licensing often refers to the scenario where a developer makes software available under a choice between two licenses: generally a copyleft open source license and a commercial license.

However, dual licensing can also refer to the scenario where multiple licenses apply simultaneously; in these situations, users are required to comply with the terms of multiple licenses at the same time.

For clarity, in this article, I’ll use the term “choice of license” to describe the scenario where software is offered under a choice between licenses. And, I’ll use the term “multi-license” to refer to the scenario where multiple licenses apply simultaneously. (I’ll use the term “dual license” when referring to both scenarios collectively.)

There are several reasons why an organization may choose to dual license its software:

  • Choice of license: Many private companies offer a choice of license so that casual or small users can use the software free of charge, but enterprise users must negotiate for an alternative, commercial license.
  • Multi license: To ensure compatibility with other code with which the project should interoperate, such as GPL v2 and Apache, since there are questions about whether these licenses are compatible. 

In this blog, I’ll discuss the nuances of both dual-licensing models (choice-of-license and multi-license), along with considerations for managing some of the IP risks that can come with them.

Editor’s Note: Heather Meeker is one of the world’s foremost legal experts on open source software licensing and compliance. She’s authored the go-to book on the topic, “Open Source for Business,” and is a General Partner at OSS Capital. Heather is also the author of the new book, “From Project to Profit: How to Build Your Business Around Your Open Source Project,” now available on Amazon.

Choice-of-License Scenarios

Like I mentioned earlier, dual licensing can refer to a scenario where vendors (often private companies) make software available under either an open source license or a commercial license. Software vendors that adopt a choice-of-license model generally use AGPL (but sometimes GPL, e.g. GPL v2 or GPL v3) as the open source option.

The reason why AGPL (and GPL) are popular choice-of-license options is because they’re the copyleft licenses that impose the most conditions. As such, they have the effect of driving users who don’t want to comply with the license terms toward negotiating alternative (read: commercial) licenses.

In contrast, it wouldn’t make sense to offer a dual-licensed product under a permissive license like Apache 2.0 because there wouldn’t be an incentive for an end-user to pay for an alternative.

When vendors use a choice-of-license model, they almost always make the options clear on a public-facing website. This is because the vendor wants users to know there’s an option to negotiate commercial licenses — it’s a way of generating business for their company. 

The flip side of this is that, although it may not be ideal to pay for a commercial licensing option, end-users should have some peace of mind knowing that they can solve compliance problems by negotiating a regular commercial license.

Commercial licenses in this kind of situation are usually conventional enterprise end-user licenses or software distribution licenses.

Multi-License Scenarios

Perhaps the most famous example of a scenario where multiple open source licenses apply simultaneously (multi-licensing) is OpenSSL. OpenSSL is a very popular open source utility licensed under two slightly different permissive licenses (the OpenSSL license and the SSleay license). (Note that this project has since migrated to Apache 2.0, in part due to confusion over its multi-license. However, there are many legacy copies of OpenSSL in the wild that are still licensed under the OpenSSL/SSleay model.)

You may also find situations where certain components in a project are under one license and certain components are under another — for example, some might be GPL, and some might be the MIT license. This happens mostly when a downstream project will not accept code under any license other than GPL.

A question that I’ve heard come up in true multi-license situations (where both open source licenses do cover and apply to the entire work): Should we be worried about conflicts between the licenses? My view is that they probably won’t conflict because they’re both going to grant unlimited rights — it’s just that you have to comply with all of the conditions for at least one of the licenses.

Managing Dual-Licensing Risks

If you’ve worked with SBOMs (software bill of materials), you might recognize that the SPDX specification has properties that distinguish between choice-of-license and multi-license scenarios. (These are known as SPDX license expressions.) In SPDX, choice-of-license scenarios are communicated using “OR,” and multi-license scenarios are communicated using “AND.”

Scenario Explanation Example
AND Comply with both licenses Apache 2.0 AND MIT
OR Comply with either license AGPL OR Proprietary

When you get information in an SBOM or software audit about dual licenses, you need to understand whether you’re looking at “OR” or “AND.” However, the tracking tools that you (or your vendors) use may struggle to track these nuances, so it does sometimes take some additional work to distinguish between these dual-licensing scenarios. 

For example, let’s say you get a license report and it says “GPL/MIT.” That will usually mean both licenses apply. But, if you get a license report and it says “AGPL/Commercial,” that means it’s usually a choice. 

The only reason you would know this is based on context. I’ve gone through lots of licensing reports, and it’s often not clear — sometimes you have to look at the information on the relevant website to figure it out. But it’s important that you understand what the universe of choices can be so that when you get a single line item that lists multiple licenses, you understand how to determine the licensing model.

Learn More About Dual Licensing

This blog is based on a webinar I recently conducted with FOSSA: When “Open Source" Isn’t Open Source. If you’re interested in more perspective around dual-licensing scenarios (and source-available software licenses), consider watching the on-demand recording. You can do so by clicking this link.