Dual Licensing (or multi-licensing) is the practice of releasing source code under multiple licenses. Most open source software is published and distributed under the rubric of a single license: Apache, GPL, Mozilla or about one hundred other licenses recognized by the Open Source Initiative.
The practice of dual licensing is not new – projects and products that employ and publish software under multiple licenses emerged decades ago.
Dual licensing, while adding complexity to use and management of open source software, serves several needs and application use cases:
Enables evaluation of commercial solutions built with open source software
Permits non-commercial integration and deployment of commercial open source software
Supports multiple use cases / interaction with other code, e.g., widget libraries for use in multiple graphical frameworks.
Key Issues with Dual Licensing
Complexity and Confusion: Dual licensing introduces complexity into managing open source software and confusion for integrators and deployers trying to understand the terms of each license and of multiple licenses in concert. This complexity may discourage some potential users from adopting the software.
Compliance Challenges: OSPOs and staffers working in compliance, including attorneys, may face challenges in ensuring compliance with the terms of the licenses involved, especially when using the software across contexts or environments. Understanding which license terms apply in specific scenarios can be daunting.
Community Fragmentation: A unified and engaged project community is crucial for the success of any open source project. Dual licensing can lead to fragmentation, as contributors and users typically have diverse agendas and divergent licensing preferences. This division can result in a divided community.
Limited Contributions: Dual licensing can discourage contributions from a project community (and beyond), as contributors express concern about project direction and their contributions being used in proprietary products.
Dependency Concerns: Consumers of dual-licensed software may be concerned about future changes in licensing terms. This uncertainty can make organizations hesitant to build critical systems or products based on the software.
License Proliferation: Dual licensing adds to the overall landscape of open source licenses, contributing to license proliferation within a software portfolio and in the greater scope of open source communities. Proliferation makes it more challenging to manage and comply with licensing requirements and does not always appear on reports generated by popular Software Composition Analysis (SCA) tools.
The Role and Importance of CLAs
Many open source projects require that participants execute a Contributor License Agreement (CLA). The main purpose of a CLA is to declare that a contributor and/or his or her employer is the original author of the work involved and that he or she has the right to contribute that work to the project. In the case of dual licensing, the CLA also grants the project organization the right to use the contribution as they see fit: to include it in the project and/or to integrate it into a derived commercial product.
Dual License Examples
Qt framework
The venerable Qt framework for GUI creation started out in 1991 as a product from Norwegian company Trolltech. It was initially released un the “Qt Free Edition License” as well as the company’s proprietary software license. Qt proved extremely popular, both in embedded and desktop applications, and was also used as the core for the popular K Desktop Environment (KDE) on Linux. Given the need to be compatible with other software, the project license first changed to a free (but not OSI) license (QPL) and ultimately to GPL v2.
Eight years later in 2008, Nokia acquired the company and the following year, Qt was relicensed adding LGPL to its growing multi-license list. In 2011, Digia acquired rights to Qt from Nokia and took over maintenance and management of the project.
Today, Qt code is multi-licensed (multiple versions of GPL, LGPL and commercial), available from the Qt Group.
MySQL
The history of the most popular open source relational data base is even more torturous.
MySQL was originally developed by a Swedish company called MySQL AB, and released in 1995 under the OSI-recognized MySQL license. In 2008, the company was acquired by Sun Microsystems, raising concerns across the community of developers, integrators and users that MySQL could become fully proprietary software under Sun’s management, or at least be much less open that it had been under MySQL AB. Those concerns were justified when Sun was acquired by Oracle in 2010, with indications that the database would no longer be maintained as a community project under a flexible opens source license.
In anticipation of such a shift, MySQL founder Michael “Monty” Widenius launched the MariaDB project, a fully open source fork whose goal was to maintain compatibility with MySQL. With MariaDB licensed under GPLv2 with commercial licensing as an option for integrators wishing to avoid compliance and copyleft disclosure issues of the GPL. This dual-licensing scenario is joined by Oracle’s continuing productization of its proprietary MySQL version and maintenance of a GPL version. There also exist a number of of forks and specialized versions of the database: AriaDB storage engine, Galera Cluster, TokuDB, Mroonga, SkySQL and MaxScale, each with its own use cases.
Conclusion
Dual-licensing is a strategy popular with both enterprise and embedded software vendors. It is frowned upon by open source “purists”, and often creates management, contribution and compliance challenges from accompanying complexity. However, it is a commercialization mechanism that supports the business models of a number of commercial open source companies.
Dual-licensing is today supplemented by “Source Available” licensing, which we’ll cover in a future blog post.