What is dual licensing? 3 software licensing models to consider

Selecting the optimal model for licensing software is a fundamental determination that, if successful, may drive business, encourage innovation, and provide safeguards for valuable intellectual property rights. As a copyright holder, the owner of a piece of software has broad latitude in determining how that software can be licensed.

For some businesses or individuals, licensing software under a “pay-for” proprietary (OEM-style) license creates the right balance of revenue generation, customer satisfaction, and legal protection. In contrast, others may find that licensing software under one of various open source licenses, such as the GNU General Public License (“GPL”), strikes the right balance of accessibility, adaptability, and ease of implementation. Often times, this software licensing decision is seen as a dichotomous one, with businesses or individuals having to make a choice between licensing under either a proprietary license or an open source license. However, such a determination is not so limited, as many licensors have come to adopt a “dual licensing” model.

Dual licensing usually refers to licensing software under both a proprietary license and an open source license, typically the GPL. While this may seem like a conflicting approach, it has become a popular means by which licensors gain the economic benefits associated with commercial licensing while leveraging the community benefits associated with open source licensing.

For licensees, the fact that the same piece of code can be licensed under a proprietary license and also under an open source license (again, typically the GPL) can prove a trap for the unwary licensee who is not diligent when it comes to compliance and oversight. Licensees, especially those looking to make commercial re-use of a piece of code, must be especially careful that they avail themselves of the code under the appropriate license.

I. Proprietary licensing

Generally, proprietary software licenses create advantageous environments for maintaining confidentiality, controlling distribution, and generating a profit. Often, individuals or companies distributing software containing commercially valuable, confidential information turn to proprietary licenses because these types of licenses aim to maintain the confidentiality of such value-creating information through various licensee obligations, such as restricting licensees’ ability to relicense or modify the software, restricting licensees’ ability to inspect the underlying source code, and/or restricting licensees’ ability to attempt to reverse engineer the software. Frequently, proprietary software licenses also require licensees to pay a fee in order to utilize the product, monetizing licensor’s software. From a licensee’s prospective, software subject to proprietary licenses typically contain additional features and licensor technical support beyond what would be offered by similar software governed by open source licenses.

II. Open source licensing

If proprietary licenses occupy a pole at one end of a licensing spectrum, the open source family of licenses occupy the opposing pole. Some estimate that over 2,500 open source-style licenses govern the more than 2 million open source projects available online. Open source licenses typically do not preclude licensors from using the corresponding software commercially, but rather create possible obligations upon future licensee distribution of that software or of products incorporating that software. These open source licenses are generally classified as permissive, reciprocal (restrictive), or falling somewhere in between, depending on the nature of the restrictions and obligations contained in the license.

Permissive open source licenses, such as the MIT license, the Apache Software License, and the Berkeley Software Distribution license (BSD), are generally characterized by more lenient obligations. These less stringent obligations may include allowing secondary distribution so long as the distributor provides attribution, or allowing secondary software alterations or improvements to remain proprietary. This flexibility facilitates the ability of end users or licensors to incorporate the licensed software into derivative products.

Reciprocal or restrictive open source licenses, such as the GPL, create more stringent restrictions and obligations for end users or licensors of open source software. The distinguishing feature of a reciprocal open source license is the so called “copyleft” requirement. The copyleft requirement obligates those who incorporate and later distribute code to do so under same terms and conditions as the original piece of open source software, even if that software has been modified. Additionally, open source licenses containing copyleft obligations will frequently require licensors to reveal the underlying source code or make it available when requested by others. These copyleft obligations can create risky exposure for licensee’s failing to monitor the terms and conditions governing the open source components being incorporated into such licensee’s software code.

Open source licenses may prove appealing for those businesses or individuals who are not intent on maintaining the confidentiality of proprietary information; who value the support and knowledge of the open source community in improving or adapting code, or correcting potential errors; and/or who desire the flexibility for potential customers to test software without being locked into a fee. From the prospective of a licensee, software subject to open source licenses is frequently inexpensive, or even free, to use but may also be subject to those additional obligations discussed above, depending on the nature of the underlying open source license.

III. Dual licensing

Dual licensing provides a third option for distributing software. Using dual licensing, licensors can distribute software to licensees under a proprietary model as well as an open source model, allowing the licensor to simultaneously leverage the advantages of both types of licenses. That is, some companies use a dual licensing model to distribute the same software under two different license forms: (1) a version subject to a proprietary license (which may come with the right to further develop and commercially distribute that software and with licensor technical support and added features), and (2) a version licensed under, and subject to, the restrictions and obligations of an open source license, such as the GPL.

One well known example of dual licensing is Oracle’s MySQL database management system. Oracle uses a dual licensing model for MySQL to meet the needs of its consumers. Oracle offers MySQL under a proprietary (OEM style) license for licensees who want to create and commercially distribute proprietary derivative works incorporating MySQL without revealing the underlying source code and do not wish to be subject to other restrictions and obligations of the GPL. Additionally, Oracle licenses MySQL under the GPL for licensees who simply want to use the software or who want to incorporate MySQL into a product to be later distributed likewise under the GPL.

With two licensing options available for software subject to a dual licensing model, such as MySQL, a licensee must (1) make sure to ask the right questions when considering and determining which license best fits the licensee’s intended use case for that code and (2) be certain that the code the licensee eventually uses is subject to a license that accurately meets the licensee’s intended use. Failure to take these fundamental precautions can have significant consequences.