Multi-licensing is the practice of distributing software under two or more different sets of terms and conditions. This may mean multiple different software licenses or sets of licenses. Prefixes may be used to indicate the number of licenses used, e.g. dual-licensed for software licensed under two different licenses.
When software is multi-licensed, recipients can choose the terms under which they want to use or distribute the software. The distributor may or may not apply a fee to either option. The two usual motivations for multi-licensing are license compatibility and market segregation based business models.
Multi-licensing is commonly done to support free software business models in a commercial environment. In this scenario, one option is a proprietary software license, which allows the possibility of creating proprietary applications derived from it, while the other license is a copyleft free software/open-source license, thus requiring any derived work to be released under the same license. The copyright holder of the software then typically provides the free version of the software at little or no cost, and profits by selling proprietary licenses to commercial operations looking to incorporate the software into their own business. This model can be compared to shareware.
Since in most cases, only the copyright holder can change the licensing terms of a software, multi licensing is mostly used by companies that wholly own the software which they are licensing. Confusion may arise when a person outside the company creates additional source code, using the less restrictive license. Because the company with the official code is not the copyright holder of the additional code, they may not legally include this new work in their more restrictively licensed version. Companies may demand outside developers agree to a contributor license agreement, before accepting their work in the official codebase and source code repositories.
Multi licensing is used by the copyright holders of some free software packages advertising their willingness to distribute using both a copyleft free software license and a non-free software license. The latter license typically offers users the software as proprietary software or offers third parties the source code without copyleft provisions. Copyright holders are exercising the monopoly they're provided under copyright in this scenario, but also use multi licensing to distinguish the rights and freedoms different recipients receive.
Such licensing allows the holder to offer customizations and early releases, generate other derivative works or grant rights to third parties to redistribute proprietary versions all while offering everyone a free version of the software. Sharing the package as copyleft free software can benefit the copyright holder by receiving contributions from users and hackers of the free software community. These contributions can be the support of a dedicated user community, word of mouth marketing or modifications that are made available as stipulated by a copyleft license. However, a copyright holder's commitment to elude copyleft provisions and advertise proprietary redistributions risks losing confidence and support from free software users.
Examples of multi-licensed software include Oracle's NetBeans IDE, MySQL AB's database, Asterisk, Oracle Corporation's Berkeley DB, Modelio, ZeroC's Ice, Magnolia CMS and Qt Software's Qt development toolkit.
Description on one specific example to illustrate multi-licensing: Oracle MySQL comes in various editions: MySQL Enterprise Edition is a commercial edition, hence to be purchased. The license is only offered as a subscription, named MySQL Enterprise Edition Subscription. The same applies for MySQL Standard Edition (MySQL Standard Edition Subscription) and MySQL Cluster CGE (MySQL Cluster Carrier Grade Edition Subscription). The other editions, such as the MySQL Classic Edition or MySQL Community Edition, are free to use (attention to user: some restrictions apply). For instance, the MySQL Community Edition is a freely downloadable version, available under the GPL license and is supported by a community of open source developers.
Single-Vendor Commercial Open Source Business Model
According to Riehle:
Single-vendor commercial open source firms build their business around an open source software project that they fully control, typically by having developed the software and never having shared control with third parties. This is done by owning the full copyright to the code and related intellectual property such as patents and trademarks... Typically, the free open source form is provided under a reciprocal license like the GPL to drive adoption but stall possible competitors. Paid-for versions of the software are then provided under a commercial license like traditional software vendors do. This is also known as the dual-license strategy of commercial open source.
In contrast to traditional open source projects, a Single-vendor commercial open source project is controlled by exactly one stakeholder with the purpose of commercially exploiting it. In this context, one should note that the open source community is less engaged in the development of core functionality, as they typically are in conventional (pure) open source projects. As the then CEO Mårten Mikos of MySQL himself noted in an interview:
The depth of the contributions varies by product and situation. The deeper you go into the core of the database engine, the more difficult it is for somebody to contribute because it takes five years to learn. If you build something on the outskirts of the kernel - some tool or function that you add on top of it - then that is much easier because there's less risk that you will mess up the whole product. But something great can emerge out of many tiny-looking contributions. It's analogous to how, in economic development, microloans can have such a huge impact - each entry is minimal, but when you multiply it by the number of people who are involved, it grows massive. It starts getting a momentum of its own..
Hence, the community of multi-license software as a rule includes employees of the code-owning firm, as well as strategic partners that have vested interest in the software. As Riehle notes, In single-vendor open source, almost all of the core product development work is carried out by the commercial firm, with occasional contributions from the community.
As Berdal notes, the governance of the open source community becomes a key business management process in this context: As such, it needs to be aligned with other business activities. Governance models of dual-licensed OSS editions may therefore display a tendency towards commercial bias. To prevent the community from being provoked or alienated it may therefore seem imperative to balance commercial inclinations against “open” interests. This is by no means an easy task. As Berdal demonstrated through a case study of SugarCRM, this commercial open source software (COSS) business model can trigger substantial friction points, which can eventually lead to pure open source forks (table adapted from Berdal, Table 3, page 75):
|Friction point||COSS / SugarCRM perspectives||Opposing FOSS perspectives|
|Copyright assignment||Precondition for dual licensing, without which the business model would not be commercially sustainable.||Disincentive to contribute because of fears of going (partially) private. Free Software purists: “Immoral”.|
|Withholding of value driving functionality from Sugar CE||1) Pre-emptive competitive advantage against OSS clones, 2) wider scope for price discrimination and product differentiation for commercial editions, and 3) stronger incentives for Sugar CE users to migrate to a commercial edition.||"Crippleware" / damaged good, "open core". Disincentive to contribute because of lacking assurances against potentially exclusive proprietary use.|
|"Powered by SugarCRM" logo||1) Official stance: Legitimate author attribution in recognition of invested work. Not confirmed, but highly plausible: 2) brand promotion, and 3) thwart forking attempts / stifle unsolicited external code reuse.||"Badgeware". Violation of basic FOSS principles, especially when coupled with the SugarCRM Trademark Policy.|
|"Closed" governance practices, even restrictive by COSS standards||1) Need for managerial control to ensure that customers’ needs are efficiently met.
2) Speculative: Diminish the influence of FOSS enthusiasts and vigilantes, who could interfere with a commercially guided development process.
|Overly restrictive, lack of procedural fairness. No real influence over shared Sugar CE code base. De facto relegation to work on small-scale peripheral complements, which not need to be open source.|
|Preferential treatment of commercially affiliated community constituents and third parties||Reasonable supplementary approach of differentiation to utilize and enhance commercially vested interests in SugarCRM’s product platform. This is 1) to strengthen the firm’s sales channels through a co-evolution of capabilities with partners, and to 2) stimulate demand driven customization and development of modular complements (extensions, plug-ins etc.), 3) triggering network effects which increase the overall value of the product platform.||Deficient distributional fairness (in terms of underprovided focus and priority). Perception of being kept out of the loop.|
A second use of multi-licensing with free software is for license compatibility, allowing code from differently licensed free software projects to be combined, or to provide users the preference to pick a license.
Examples include the source code of Mozilla Application Suite and previously Mozilla Thunderbird and Mozilla Firefox, that have used tri-licensing under the Mozilla Public License (MPL) 1.1, GNU General Public License (GPL) 2.0 or GNU Lesser General Public License (LGPL) 2.1 before the latter upgraded to GPL-compatible MPL 2.0, making the tri-licensing unnecessary; Perl, which is dual-licensed under the GPL or Artistic License; and Ruby, whose license contains explicit GPL dual licensing.
Market segregation in proprietary software
Multi-licensing is also used by distributors of non-free software. Sometimes this is done to proprietary software to segregate a market. By splitting customers into multiple categories such as home users, professional users, and academic users, copyright holders can set different prices for each group. However, among proprietary software companies, it is more common to release a "home edition" and a "professional edition" of a given product, which differ by the software and software features included, not just the license.
- Business models for open source software
- Commercial use of copyleft works
- Commercial open source applications
- Professional open-source
- Linux News: Tech Buzz: Dual Licensing: Having Your Cake and Eating It Too
- Dual-Licensing Open Source Business Models | Linux
- Digium Incorporated. "Asterisk Guidelines, The contributor license agreement". Retrieved 2009-02-10.
- Netscape Public License - GNU Project - Free Software Foundation (FSF)
- FSF's Opinion on the Apple Public Source License (APSL) - GNU Project - Free Software Foundation (FSF)
- "My SQL Enterprise Edition". Oracle. Retrieved 25 April 2013.
- "MySQL Community Edition". Oracle, MySQL. Retrieved 25 April 2013.
- The Single-Vendor Commercial Open Source Business Model, 2010-11-09, retrieved 8 December 2013
- Riehle, Dirk (March 2012). "The single-vendor commercial open source business model." 10 (1). Information Systems and e-Business Management. pp. 5–17. doi:10.1007/s10257-010-0149-x.
- Berdal, S.R.B. (January 2013). "Peculiarities of the Commercial Open Source business model: Case study of SugarCRM". Tronheim, Norway: Norwegian University of Science and Technology, Faculty of Social Sciences and Technology Management, Department of Industrial Economics and Technology Management.
- "The Oh-So-Practical Magic of Open-Source Innovation". MIT Sloan Management Review 50 (1). October 1, 2008. Retrieved 8 December 2013.
- Mozilla Foundation. "Mozilla Code Licensing". Retrieved 2007-09-17.
- "MPL 2 Upgrade". Retrieved 2012-08-18.
- The Perl Foundation. "Perl Licensing - perl.org". Retrieved 2007-09-17.
- Dual Licensing information from OSS Watch
- Article "The Dual-Licensing Model" May 1, 2002 by Don Marti
- Article "Dual Licensing: Having Your Cake and Eating It Too" Nov 16 2004 by Philip H. Albert
- Article "Does dual licensing threaten free software?" Jul 27 2006 by Glyn Moody
- Article "Dual-Licensing Open Source Business Models" by Heather Meeker
- Paper "Dual Licensing in Open Source Software Industry" by Mikko Välimäki
- Dual Licensing Schemes
- "Should code be “dual licensed” under the GPL and a permissive license?" by Software Freedom Law Center
- Combining GPL, closed code
- Glossary of Software Licensing