Multi-licensing

For the project page on multi-licensing Wikipedia content, see Wikipedia:Multi-licensing.

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 typically choose the terms under which they want to use or distribute the software, but the simple presence of multiple licenses in a software package or library does not necessarily indicate that the recipient can freely choose one or the other. In some cases, especially when the software has multiple origins, all the accompanied licenses apply at the same time. The applicability of the different licenses has to be individually checked.^{[ according to whom? ]} The distributor may or may not apply a fee to either option.^{[ citation needed ]} The two usual motivations for multi-licensing are license compatibility ^[1] and market segregation based business models. ^[2]

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. ^{[3] [4]}

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 require outside developers agree to a contributor license agreement before accepting their work in the official code-base and source code repositories. ^[5]

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. ^{[6] [7]}

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, JUCE, wolfSSL, ^[8] 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 ^[9] 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 with some restrictions. 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. ^[10]

Single-vendor commercial open source business model

The term single-vendor commercial open source was coined by Dirk Riehle in 2010, ^{[11] [12]} and has later been further popularized by other scholars, such as Simon R. B. Berdal. ^[13]

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. ^[11]

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. ^[11] In this context, 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 said 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.. ^[14]

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. ^[11]

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. ^[13] 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 ^[13] ):

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.

Only a few months after these friction points were observed, a new fork of the SugarCRM Community Edition was announced.

License compatibility

Main article: License compatibility

A second use of multi-licensing with free software is for license compatibility, ^[1] 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 ^[15] before the latter upgraded to GPL-compatible MPL 2.0, making the tri-licensing unnecessary. ^[16] Other examples are Perl, which is dual-licensed under the GPL or Artistic License, ^[17] 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.

See also

• Business models for open-source software
• Commercial use of copyleft works

References

1. Nikolai Bezroukov (2001). "Comparative merits of GPL, BSD and Artistic licences (Critique of Viral Nature of GPL v.2 - or In Defense of Dual Licensing Idea)". Archived from the original on December 22, 2001. Viral property stimulates proliferation of licenses and contributes to the "GPL-enforced nightmare" -- a situation when many other licenses are logically incompatible with the GPL and make life unnecessary difficult for developers working in the Linux environment (KDE is a good example here, Python is a less known example).
2. Ronacher, Armin (July 23, 2013). "Licensing in a Post Copyright World". lucumr.pocoo.org. Retrieved November 18, 2015. The AGPLv3 was a terrible success, especially among the startup community that found the perfect base license to make dual licensing with a commercial license feasible. MongoDB, RethinkDB, OpenERP, SugarCRM as well as WURFL all now utilize the AGPLv3 as a vehicle for dual commercial licensing. The AGPLv3 makes that generally easy to accomplish as the original copyright author has the rights to make a commercial license possible but nobody who receives the sourcecode itself through the APLv3 inherits that right. I am not sure if that was the intended use of the license, but that's at least what it's definitely being used for now.
3. Linux News: Tech Buzz: Dual Licensing: Having Your Cake and Eating It Too
4. Dual-Licensing Open Source Business Models | Linux
5. Digium Incorporated. "Asterisk Guidelines, The contributor license agreement" . Retrieved February 10, 2009.
6. Netscape Public License - GNU Project - Free Software Foundation (FSF)
7. FSF's Opinion on the Apple Public Source License (APSL) - GNU Project - Free Software Foundation (FSF)
8. "wolfSSL Embedded SSL/TLS Library | Now Supporting TLS 1.3" . Retrieved January 27, 2020.
9. "My SQL Enterprise Edition". Oracle. Retrieved April 25, 2013.
10. "MySQL Community Edition". Oracle, MySQL. Retrieved April 25, 2013.
11. The Single-Vendor Commercial Open Source Business Model, November 9, 2010, retrieved December 8, 2013
12. Riehle, Dirk (March 2012). "The single-vendor commercial open source business model". Information Systems and E-Business Management. 10 (1): 5–17. doi:10.1007/s10257-010-0149-x.
13. Berdal, S.R.B. (January 2013). "Peculiarities of the Commercial Open Source business model: Case study of SugarCRM". 112. Tronheim, Norway.
14. "The Oh-So-Practical Magic of Open-Source Innovation". MIT Sloan Management Review. 50 (1). October 1, 2008. Retrieved December 8, 2013.
15. Mozilla Foundation. "Mozilla Code Licensing" . Retrieved September 17, 2007.
16. "MPL 2 Upgrade" . Retrieved August 18, 2012.
17. The Perl Foundation. "Perl Licensing - perl.org" . Retrieved September 17, 2007.

External links

• 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
• Open Source Business Models leveraging multi-licensing
• "Should code be “dual licensed” under the GPL and a permissive license?" by Software Freedom Law Center
• Combining GPL, closed code at archive.today (archived 2013-01-03)
• Glossary of Software Licensing