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 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.[citation needed] The two usual motivations for multi-licensing are license compatibility[1] and market segregation based business models.[2]

Contents

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 copyleftfree 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 demand outside developers agree to a contributor license agreement, before accepting their work in the official codebase 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]

Description on one specific example to illustrate multi-licensing: Oracle MySQL comes in various editions: MySQL Enterprise Edition[8] 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.[9]

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.[10]

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.[10] 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..[13]

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.[10]

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

Friction point

COSS / SugarCRM perspectives

Opposing FOSS perspectives

Copyright assignment

Precondition for dual licensing, without which the business model would not be commercially sustainable.

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.

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

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.

Flask developer Armin Ronacher noted that the AGPLv3 is a "terrible success" as "vehicle for dual commercial licensing" and gave MongoDB, RethinkDB, OpenERP, SugarCRM and WURFL as examples for projects which utilize the AGPL for commercialization.[2]

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.

^ abRonacher, Armin (2013-07-23). "Licensing in a Post Copyright World". lucumr.pocoo.org. Retrieved 2015-11-18. 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.