Dual Licensing for Open Source Components: Yeah or Meh?
Table of Contents
While open source components have become an integral part of developing software products and services, few developers give a thought to the open source licenses behind them. However, stakeholders and investors in software development organizations can’t afford to ignore the importance of open source license compliance and in the earlier days of open source adoption, many head honchos were wary of the limitations open source licenses might put on their commercial products. That is probably the main reason dual licensing for open source components came to be.
Open Source Dual Licensing — Two Licenses for One Product
Dual licensing emerged as an open source business model in the early 2000’s, and it typically refers to the release of a software component under two licenses simultaneously: a traditional proprietary license and an open source one, often from the GPL (GNU General Public License) family.
The dual licensing model answered a need for commercial organizations that wanted to find a way to make open source development economically viable. According to Philip H. Albert, patent attorney, “the biggest motivation for using the dual licensing model is to make money through price discrimination by monetizing your intellectual property”. However, many in both the commercial and open source communities wondered whether dual licensing really allowed businesses to have their cake and eat it too.
GPL and Commercial Licenses: How Does It Work?
The GPL is a copyleft, or viral license. According to the terms of the GPL, if software is based on, or derivative of, a GPL component, and distributed, it must be made available subject to the GPL. This includes the obligation to release the source code, as well as granting recipients the GPL rights to modify and distribute the entire code. The released source code must also be under the same GPL (hence the name viral license since it jumps from project to project).
When a company releases a product under the GPL, explains Heather Meeker, specialist in open source software licensing, anyone integrating that software in a proprietary product would have to violate GPL to distribute its product. That is the reason that the company offers an alternative, proprietary license, for those wishing to distribute the software as part of a proprietary product.
According to Meeker, the dual licensing model worked because GPL does not allow distribution of GPL code within a proprietary product, and because vendors of proprietary products were not willing to lay open their proprietary code under a compatible license. This resulted in a situation where “the vendor of a dual licensed product places its developer community between a rock and hard place, with an option to buy their way out”.
The Problem with Dual Licensing
While using dual licensing helped some companies find the right business model to enable them to use open source components and stay in business, others from both the business community and the open source community were not happy with it, for several reasons.
Many open source community members, were quick to point out that dual licensing might not benefit the community, but rather result in less contributions to an open source project, because contributors are reluctant to contribute to projects with severe licensing limitations, like the GPL that requires they re-assign their copyrights.
Meeker points out that the dual licensing model only works under two conditions: the software is not an entire program, and the software is mainly used in distributed products. If the software is an entire program, then anyone can use and distribute the software under GPL. The pain point comes when the GPL code must be integrated with proprietary code to make it work. In this sense, dual licensing is like an intentional “license bug” that has to be solved with a proprietary license.”
Open Source Dual Licensing and Compliance
Happily, the days that commercial companies were worried about using open source licensing are long gone. Everyone in the software development industry is in agreement that open source components are a great resource that helps development teams create great products, faster. The popularity of permissive open source licenses is on the rise, and the variety of open source licenses out there is most probably enough so that any company can find the right fit for their business needs.
One thing that hasn’t changed is the need to manage your organization’s open source usage and ensure license compliance. From viral to permissive to dual licensing and everything in between, open source license compliance requires companies make sure that they know which licenses they are using, so that they can avoid any licensing compliance risks.
*This post is not legal advice, it is for informational purposes only. If you need legal advice, you should consult with an attorney, who has reviewed all relevant facts and applicable law.
