License proliferation#Vanity licenses

Often when a software developer would like to merge portions of different software programs they are unable to do so because the licenses are incompatible. When software under two different licenses can be merged into a larger software work, the licenses are said to be compatible. As the number of licenses increases, the probability that a free and open-source software (FOSS) developer will want to merge software that are available under incompatible licenses increases. There is also a greater cost to companies that wish to evaluate every FOSS license for software packages that they use. Strictly speaking, no one is in favor of license proliferation. Rather, the issue stems from the tendency for organizations to write new licenses in order to address real or perceived needs for their software releases.

License proliferation is especially a problem when licenses have only limited or complicated license compatibility relationships with other licenses. Therefore, some consider compatibility with the widely used GNU General Public License (GPL) an important characteristic, for instance David A. Wheeler"[http://www.dwheeler.com/essays/floss-license-slide.html The Free-Libre / Open Source Software (FLOSS) License Slide]" by David A. Wheeler on September 27, 2007.{{cite web|url=http://www.dwheeler.com/essays/gpl-compatible.html|title=Make Your Open Source Software GPL-Compatible. Or Else.|first1=David A. |last1=Wheeler |date=Feb 16, 2014 |url-status=live |archive-url=https://web.archive.org/web/20231113231043/https://www.dwheeler.com/essays/gpl-compatible.html |archive-date= Nov 13, 2023 }} as also the Free Software Foundation (FSF), who maintains a list of the licenses that are compatible with the GPL."[https://www.gnu.org/philosophy/license-list.html Various Licenses and Comments about Them]", GNU. {{webarchive|url=https://web.archive.org/web/20000815065020/https://www.gnu.org/philosophy/license-list.html |date=2000-08-15 }}. On the other hand, some recommend Permissive licenses, instead of copyleft licenses,{{cite web |url=http://www.eolevent.eu/sites/default/files/EOLE%202008%20%E2%80%94%20Philippe%20Laurent%20%E2%80%94%20The%20GPLv3%20and%20Compatibility%20Issues.pdf |work=European Open source Lawyers Event 2008 |date=2008-09-24 |access-date=2015-05-30 |first=Philippe |last=Laurent |publisher=University of Namur – Belgium |title=The GPLv3 and compatibility issues |page=7 |quote=Copyleft is the main source of compatibility problems |archive-url=https://web.archive.org/web/20160304082732/http://www.eolevent.eu/sites/default/files/EOLE%202008%20%E2%80%94%20Philippe%20Laurent%20%E2%80%94%20The%20GPLv3%20and%20Compatibility%20Issues.pdf |archive-date=2016-03-04 }} due to the better compatibility with more licenses.{{cite web|url=http://opensource.com/business/14/1/what-license-should-i-use-open-source-project|quote=Permissive licensing simplifies things One reason the business world, and more and more developers [...], favor permissive licenses is in the simplicity of reuse. The license usually only pertains to the source code that is licensed and makes no attempt to infer any conditions upon any other component, and because of this there is no need to define what constitutes a derived work. I have also never seen a license compatibility chart for permissive licenses; it seems that they are all compatible. |title=Should I use a permissive license? Copyleft? Or something in the middle? |date=28 Jan 2014 |access-date=2015-05-30 |first=Marcus D. |last=Hanwell |publisher=opensource.com}}{{cite web |url=https://joinup.ec.europa.eu/software/page/licence_compatibility_and_interoperability |work=Open-Source Software - Develop, share, and reuse open source software for public administrations |title=Licence Compatibility and Interoperability |publisher=joinup.ec.europa.eu |quote=The licences for distributing free or open source software (FOSS) are divided in two families: permissive and copyleft. Permissive licences (BSD, MIT, X11, Apache, Zope) are generally compatible and interoperable with most other licences, tolerating to merge, combine or improve the covered code and to re-distribute it under many licences (including non-free or "proprietary"). |access-date=2015-05-30 |archive-url=https://web.archive.org/web/20150617130550/https://joinup.ec.europa.eu/software/page/licence_compatibility_and_interoperability |archive-date=2015-06-17 }} The Apache Foundation for instance criticizes the fact that while the Apache License is compatible with the copyleft GPLv3, the GPLv3 is not compatible with the permissive Apache license — Apache software can be included in GPLv3 software but not vice versa.{{cite web|url=https://www.apache.org/licenses/GPL-compatibility.html |quote=Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law. |access-date=2015-05-30 |date=2015-05-30 |title=GPL compatibility |author=Apache foundation |author-link=Apache foundation }} As another relevant example, the GPLv2 is by itself not compatible with the GPLv3.{{cite web| url=https://www.gnu.org/licenses/gpl-faq.html#v2v3Compatibility| title=Frequently Asked Questions about the GNU Licenses – Is GPLv3 compatible with GPLv2?| publisher=gnu.org| access-date=2014-06-03 |quote=No. Some of the requirements in GPLv3, such as the requirement to provide Installation Information, do not exist in GPLv2. As a result, the licenses are not compatible: if you tried to combine code released under both these licenses, you would violate section 6 of GPLv2. However, if code is released under GPL "version 2 or later," that is compatible with GPLv3 because GPLv3 is one of the options it permits.}} The 2007 released GPLv3 was criticized by several authors for adding another incompatible license in the FOSS ecosystem.{{cite web|url=http://landley.net/talks/celf-2013.txt |title=CELF 2013 Toybox talk |publisher=landley.net |first=Rob |last=Landley |quote=GPLv3 broke "the" GPL into incompatible forks that can't share code. |access-date=2013-08-21}}{{cite web|url=http://repository.law.umich.edu/cgi/viewcontent.cgi?article=1074&context=mttlr |title=Michigan Telecommunications and Technology Law Review Volume 14 - Issue 22008 The General Public License Version 3.0: Making or Breaking the Foss Movement |publisher=law.umich.edu |first=Clark D. |last=Asay |quote=In the end, GPLv3 constitutes license proliferation.}}{{cite web|archive-url=https://web.archive.org/web/20011222205401/http://icfcst.kiev.ua/panorama/OSS/bsd_vs_gpl.shtml |title=Comparative merits of GPL, BSD and Artistic licences (Critique of Viral Nature of GPL v.2 - or In Defense of Dual Licensing Idea) |archive-date=2001-12-22 |url=http://icfcst.kiev.ua/panorama/OSS/bsd_vs_gpl.shtml |author=Nikolai Bezroukov |author-link=Nikolai Bezroukov |quote=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). I think that this petty efforts to interpret GPL as a "holy text" are non-productive discussion that does not bring us anywhere. And they directly contributed to the proliferation of different "free software" licenses. |date=2000}}{{cite web|url=http://www.datamation.com/open-source/7-reasons-why-free-software-is-losing-influence_2.html |quote=At the time, the decision seemed sensible in the face of a deadlock. But now, GPLv2 is used for 42.5% of free software, and GPLv3 for less than 6.5%, according to Black Duck Software. |title=7 Reasons Why Free Software Is Losing Influence: Page 2 |date=22 November 2011 |first=Bruce |last=Byfield |publisher=Datamation.com |access-date=23 August 2013}}{{cite web | url=https://lwn.net/Articles/200422/ | title=Kernel developers' position on GPLv3 - The Dangers and Problems with GPLv3 |author=James E.J. Bottomley |author2=Mauro Carvalho Chehab |author3=Thomas Gleixner |author4=Christoph Hellwig |author5=Dave Jones |author6=Greg Kroah-Hartman |author7=Tony Luck |author8=Andrew Morton |author9=Trond Myklebust |author10=David Woodhouse |date=15 September 2006 |publisher=LWN.net |access-date=2015-03-11 |quote="[...]since the FSF is proposing to shift all of its projects to GPLv3 and apply pressure to every other GPL licensed project to move, we foresee the release of GPLv3 portends the Balkanisation of the entire Open Source Universe upon which we rely."}}{{cite web|url=http://lucumr.pocoo.org/2013/7/23/licensing/ |title=Licensing in a Post Copyright World |date=2013-07-23 |access-date=2015-11-18|first=Armin |last=Ronacher |publisher=lucumr.pocoo.org |quote=The License Compatibility Clusterfuck - When the GPL is involved the complexities of licensing becomes a non fun version of a riddle. So many things to consider and so many interactions to consider. And that GPL incompatibilities are still an issue that actively effects people is something many appear to forget. For instance one would think that the incompatibility of the GPLv2 with the Apache Software License 2.0 should be a thing of the past now that everything upgrades to GPLv3, but it turns out that enough people are either stuck with GPLv2 only or do not agree with the GPLv3 that some Apache Software licensed projects are required to migrate. For instance Twitter's Bootstrap is currently migrating from ASL2.0 to MIT precisely because some people still need GPLv2 compatibility. Among those projects that were affected were Drupal, WordPress, Joomla, the MoinMoin Wiki and others. And even that case shows that people don't care that much about licenses any more as Joomla 3 just bundled bootstrap even though they were not licenses in a compatible way (GPLv2 vs ASL 2.0). The other traditional case of things not being GPL compatible is the OpenSSL project which has a license that does not go well with the GPL. That license is also still incompatible with the GPLv3. The whole ordeal is particularly interesting as some not so nice parties have started doing license trolling through GPL licenses.''}}[http://lucumr.pocoo.org/2009/2/12/are-you-sure-you-want-to-use-gpl/ Are you sure you want to use the GPL?] by Armin Ronacher (2009)

A vanity license is a license that is written by a company or person for no other reason than to write their own license ("NIH syndrome").[http://www.freesoftwaremagazine.com/articles/sharing_medical_software_foss_licensing_in_medicine Sharing medical software: FOSS licensing in medicine] on freesoftwaremagazine.com by Fred Trotter (2007-06-14) If a new license is created that has no obvious improvement or difference over another more common FOSS license it can often be criticized as a vanity license. As of 2008, many people create a custom new license for their newly released program, without knowing the requirements for a FOSS license and without realizing that using a nonstandard license can make that program almost useless to others.{{cite web|url=https://dwheeler.com/blog/2008/08/20/|title=David A. Wheeler's Blog|website=dwheeler.com}}

In July 2013, GitHub started a license selection wizard called choosealicense.[http://www.infoworld.com/article/2611422/open-source-software/github-finally-takes-open-source-licenses-seriously.html GitHub finally takes open source licenses seriously] on Infoworld by Simon Phipps on July 2013 GitHub's choosealicense frontpage offers as a quick selection only three licenses: the MIT License, the Apache License and the GNU General Public License. Some additional licenses are offered on subpages and via links.[http://choosealicense.com/ Choosing an open source license doesn't need to be scary - Which of the following best describes your situation?] on choosealicense.com (accessed 2015-11-29) Following in 2015, approx. 77% of all licensed projects on GitHub were licensed under at least one of these three licenses.[https://github.com/blog/1964-license-usage-on-github-com Open source license usage on GitHub.com] on March 9, 2015 by Ben Balter on github.com "MIT 44.69%, [...]GPLv2 12.96%, Apache 11.19%, GPLv3 8.88%"

From 2006 Google Code only accepted projects licensed under the following seven licenses:

{{cite web | author=Ed Burnette | title=Google says no to license proliferation | website=ZDNet | url=https://www.zdnet.com/article/google-says-no-to-license-proliferation/ | date=2006-11-02 | access-date=2010-09-11 | url-status=live | archive-url=https://web.archive.org/web/20070224072515/http://blogs.zdnet.com/Burnette/?p=192 | archive-date=2007-02-24 }}

• Apache License 2.0
• New BSD License
• MIT License
• GNU General Public License 2.0
• GNU Lesser General Public License 2.1
• Mozilla Public License 1.1
• Artistic License/GPL dual-licensed (often used by the Perl community)

One year later, around 2008, the GNU General Public License 3.0 was added and strongly recommended together with the permissive Apache license,{{cite web | author=Greg Stein | author-link = Greg Stein | title=Standing Against License Proliferation | url=http://google-opensource.blogspot.com/2008/05/standing-against-license-proliferation.html | date=2009-05-28 | access-date=2010-09-11 | archive-url=https://web.archive.org/web/20080601023839/http://google-opensource.blogspot.com/2008/05/standing-against-license-proliferation.html | archive-date=2008-06-01 }} notably excluded was the AGPLv3 to reduce license proliferation.[https://fossbazaar.org/content/license-proliferation-less-more-one-best/ License Proliferation - Less is More, One is Best] on January 27th, 2009 by Ernest M. Park "Chris DiBona from Google suffered the slings and arrows of the OSS community when he rejected the AGPLv3 license for Google Code repository, citing license proliferation as one of the reasons."

In 2010, Google removed these restrictions, and announced that it would allow projects to use any OSI-approved license (see OSI's stance below),{{cite web | author=Chris DiBona | author-link = Chris DiBona | title=License Evolution and Hosting Projects on Code.Google.Com | url=http://googlecode.blogspot.com/2010/09/license-evolution-and-hosting-projects.html | date=2010-09-10 | access-date=2010-09-11}} but with the limitation that public domain projects are only allowed as single case decision.

Open Source Initiative (OSI) maintains a list of approved licenses.[http://opensource.org/licenses/alphabetical OSI Approved Licenses] on opensource.org Early in its history, the OSI contributed to license proliferation by approving vanity and non-reusable licenses. In 2004 an OSI License Proliferation Project was started[http://opensource.org/proliferation License Proliferation Project] on opensource.com (2004) has prepared a License Proliferation Report in 2007.[http://opensource.org/proliferation-report License Proliferation Report] {{Webarchive|url=https://web.archive.org/web/20121212025006/http://opensource.org/proliferation-report |date=2012-12-12 }} on opensource.com (2007) The report defined classes of licenses:

• Licenses that are popular and widely used or with strong communities
• International licenses
• Special purpose licenses
• Other/Miscellaneous licenses
• Licenses that are redundant with more popular licenses
• Non-reusable licenses
• Superseded licenses
• Licenses that have been voluntarily retired
• Uncategorized Licenses

The group of "popular" licenses include nine licenses: Apache License 2.0, New BSD license, GPLv2, LGPLv2, MIT license, Mozilla Public License 1.1, Common Development and Distribution License, Common Public License, Eclipse Public License.

Richard Stallman, former president of Free Software Foundation, and Bradley M. Kuhn, former Executive Director, have argued against license proliferation since 2000, when they instituted the FSF license list, which urges developers to license their software under GPL-compatible free software license(s), though multiple GPL-incompatible free software licenses are listed with a comment stating that there is no problem using and/or working on a piece of software already under the licenses in question while also urging readers of the list not to use those licenses on software they write.The earliest archived version of the license list reflects this position. {{cite news | author=Bradley M. Kuhn | author-link=Bradley M. Kuhn | title=Various Licenses and Comments about Them | url=https://www.gnu.org/philosophy/license-list.html | publisher=Free Software Foundation | pages= 37–39 | date=2000-08-15 | access-date=2015-11-29 | archive-url=https://web.archive.org/web/20000815065020/https://www.gnu.org/philosophy/license-list.html | archive-date=2000-08-15 }}

Ciarán O'Riordan of FSF Europe argues that the main thing that the FSF can do to prevent license proliferation is to reduce the reasons for making new licenses in the first place, in an editorial entitled How GPLv3 tackles license proliferation.[https://archive.today/20070215145800/http://www.linuxdevices.com/articles/AT7188273245.html How GPLv3 tackles license proliferation] on linuxdevices.com Generally the FSF Europe consistently recommends the use of the GNU GPL as much as possible, and when that is not possible, to use GPL-compatible licenses.

In 2005 Intel has voluntarily retracted their Intel Open Source License from the OSI list of open source licenses and has also ceased to use or recommend this license to reduce license proliferation.{{cite web | url=http://news.cnet.com/Intel-to-stop-using-open-source-license/2100-7344_3-5648518.html | title=Intel to stop using open-source license | first=Ingrid | last=Marson | date=March 31, 2005 | access-date=October 6, 2014 | publisher=CNet | website=cnet.com }}

The 451group created in June 2009 a proliferation report called The Myth of Open Source License Proliferation.[https://web.archive.org/web/20111018133015/http://the451group.com/caos/caos_detail.php?icid=843 The Myth of Open Source License Proliferation] on the451group.com A 2009 paper from the University of Washington School of Law titled Open Source License Proliferation: Helpful Diversity or Hopeless Confusion? called for three things as a solution: "A Wizzier Wizzard" (for license selection), "Best Practices and Legacy Licenses", "More Legal Services For Hackers".[http://www.law.washington.edu/Directory/docs/Gomulkiewicz/Open%20Source%20License%20Proliferation.pdf Open Source License Proliferation: Helpful Diversity or Hopeless Confusion?] on law.washington.edu by Robert W. Gomulkiewicz on 2009 The OpenSource Software Collaboration Counseling (OSSCC) recommends, based on the originally nine recommended OSI licenses, five licenses: the Apache License 2.0, New BSD License, CDDL, MIT license, and to some degree the MPL, as they support collaboration, grant patent use and offer patent protection. Notably missing is the GPL as "this license cannot be used inside other works under a different license."[http://www.osscc.net/en/licenses.html#compatibility License compatibility] on osscc.net

• License compatibility
• Rights Expression Language

{{Reflist|30em}}

• [http://www.ipinfoblog.com/archives/licensing-law-issues-open-source-license-proliferation-a-broader-view.html Open source license proliferation, a broader view] by Raymond Nimmer
• [https://web.archive.org/web/20070927225757/http://old.linux-foundation.org/newsroom/articles/License_Proliferation.pdf Larry Rosen argues that different licenses can be a good thing] Larry Rosen
• [http://www.catb.org/~esr/Licensing-HOWTO.html Licensing howto] by Eric S. Raymond
• [https://web.archive.org/web/20110927140032/http://www.freesoftwaremagazine.com/columns/sharing_medical_software_foss_licensing_in_medicine License proliferation for Medical Software] by [http://www.fredtrotter.com Fred Trotter] Advocates that for Health Software, only the Google seven should be used.
• [https://www.gnu.org/licenses/license-recommendations How to choose a license for your own work] Free Software Foundation

{{FOSS}}

{{DEFAULTSORT:License Proliferation}}

Proliferation

Category:Licensing