Software Licensing Decisions: Consider Dual Licensing

Software Licensing Decisions: Consider Dual Licensing

This post was co-authored by Benjamin Rosen.

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.

Implications of a licensee’s failure to ask the right questions is playing out in a California court room in on-going litigation between Artifex Software, Inc. (“Artifex”) and Hancom, Inc. (“Hancom”). Artifex is the owner of a popular PDF software, an Adobe alternative, known as “Ghostscript.” Complaint for 1. Breach of Contract, 2. Copyright Infringement & Demand for Jury Trial at ¶ 1, Artifex Software, Inc. v. Hancom, Inc., No. 3:16-cv-06982 (N.D.  Cal. Dec. 5, 2016). Artifex offers Ghostscript under both a proprietary license, for those who wish to incorporate Ghostscript into a licensee’s commercially distributed products, and under a GPL open source license. Id. In its complaint against Hancom, Artifex alleges that Hancom used and incorporated the freely available (GPL-licensed) version of Ghostscript into Hancom’s own commercial software called “Hangul” and that Hancom then failed to abide by the corresponding obligations under the GPL license. Id. at ¶ 2.

Under the GPL, Hancom’s use of Ghostscript required it to distribute the source of Hangul along with the product. Id. at ¶ 24. Distributing the source code for Hangul would clearly be to the great detriment of Hancom’s ability to monetize their product. Artifex argues that Hancom’s failure to distribute this source code breached Hancom’s license to use and distribute Ghostscript under the GPL, triggering a termination of the license.[1] Id. at ¶ 25, 27. Hancom’s refusal to cease its actions led Artifex to seek a legal remedy.

This case exemplifies the caution licensees must exercise and the questions a licensee must ask. Licensees must first ask whether a dual licensing model exists. If so, a licensee must then weigh the two license options and ask which set of underlying obligations inherent in the particular licensing option permits the licensee to use or incorporate the software in a way that fits the licensee’s intended purpose. After selecting the licensing option that best aligns with the intended use, a licensee must be sure to ask if any future license obligations exist. Licensees subject to future license obligations should then work to implement a sensible plan to monitor and ensure license compliance.

A licensee must remember that just because software may be freely available, it does not mean there are no obligations. Unknowingly or negligently using software subject to a restrictive open source license such as the GPL may create unintended consequences for licensees who fail to understand the underlying obligations. A licensee prepared to ask the right questions is the most equipped to avoid compliance issue and avoid costly compliance failures.       

AGPL: Out of the Shadows

[1] It is unclear if Hancom intentionally misused the GPL licensed Ghostscript or if Hancom simply was unaware of the infringing nature of their use of Ghostscript due to lack of awareness of which licensed version of Ghostscript Hancom was incorporating into their Hangul product. In either case, the end result is a breach of the GPL.

Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.


Dramatic Shifts in Open Source License Enforcement

| May 12, 2017

In February I wrote a post exploring dual licensing. Part of my message was to call out that open source license enforcement is steadily going through a dramatic shift. Historically, open source licenses such as the GNU General Public License were enforced primarily by groups such as the Free

| MORE >

How to Create an Open Source Management Policy

| Nov 7, 2016

Creating an open source software policy is a strategic imperative for organizations in the software industry. But what does a strategic policy include, and how can you implement one? What is an Open Source Software Management Policy? Let’s start by defining an open source management policy. It is

| MORE >