License proliferation

From Wikipedia, the free encyclopedia
Jump to: navigation, search

License proliferation refers to the problems created when additional software licenses are written for software packages. License proliferation affects the free software community. 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 combined 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 together 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 compatibility[edit]

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) a important characteristic, for instance David A. Wheeler[1][2] as also the Free Software Foundation (FSF), who maintains a list of the licenses that are compatible with the GPL.[3] On the other hand, some recommend Permissive licenses, instead of copyleft licenses[4], due to the better compatibility with more licenses.[5][6] 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.[7] As another relevant example, the GPLv2 is, by itself, not compatible with the GPLv3.[8] The 2007 released GPLv3 was criticized by several authors for adding another incompatible license in the FOSS ecosystem.[9][10][11]

Vanity licenses[edit]

Vanity licenses is a term that refers to a license that is written by a company or person for no other reason than to write their own license ("NIH syndrome"). 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.[12]

Solution approaches[edit]

GitHub's stance[edit]

In July 2013 GitHub started a license selection wizard called choosealicense.[13] GitHub's choosealicense frontpage offers as quick selection only three licenses: the MIT license, the Apache license and the GPL license. Additionally licenses are offered on subpages and via links.[14] Following in 2015, the three licenses have approx. 77% of all licensed projects on GitHub.[15]

Google's stance[edit]

From 2006 until 2010, Google Code only accepted projects licensed only under the following licenses:[16]

In 2008, Google started to recommend the Apache License and the GPLv3.[17]

2010, Google removed these restrictions, and announced that it would allow projects to use any OSI-approved license (see #OSI's stance below).[18]

OSI's stance[edit]

Open Source Initiative (OSI) consider themselves the keepers of what licenses can be called open source. They maintain a list of licenses that are OSI Approved Licenses, and early in their history, contributed to license proliferation by approving vanity licenses. The OSI License Proliferation Project[19] has prepared a License Proliferation Report in 2008.[20] The report defined classes of licenses:

  • Licenses that are popular and widely used or with strong communities
  • Special purpose licenses
  • Licenses that are redundant with more popular licenses
  • Non-reusable licenses
  • Other/Miscellaneous 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. Notably missing is the GPLv3.

FSF's stance[edit]

Richard Stallman, president of FSF, 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.[21]

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


The 451group created in June 2009 a proliferation report called The Myth of Open Source License Proliferation.[23] An 2009 paper from the University of Washington School of Law called Open Source License Proliferation: Helpful Diversity or Hopeless Confusion? called for three things as solution: "A Wizzier Wizzard" (for license selection), "Best Practices and Legacy Licenses", "More Legal Services For Hackers".[24]

See also[edit]


  1. ^ The Free-Libre / Open Source Software (FLOSS) License Slide by David A. Wheeler on September 27, 2007
  2. ^
  3. ^ license list of
  4. ^ LAURENT, Philippe (2008-09-24). "The GPLv3 and compatibility issues" (pdf). European Open source Lawyers Event 2008. University of Namur – Belgium. p. 7. Retrieved 2015-05-30. Copyleft is the main source of compatibility problems 
  5. ^ Hanwell, Marcus D. (28 Jan 2014). "Should I use a permissive license? Copyleft? Or something in the middle?". Retrieved 2015-05-30. 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. 
  6. ^ "Licence Compatibility and Interoperability". Open-Source Software - Develop, share, and reuse open source software for public administrations. Retrieved 2015-05-30. 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”). 
  7. ^ Apache foundation (2015-05-30). "GPL compatibility". Retrieved 2015-05-30. 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. 
  8. ^ "Frequently Asked Questions about the GNU Licenses – Is GPLv3 compatible with GPLv2?". Retrieved 2014-06-03. 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. 
  9. ^ Landley, Rob. "CELF 2013 Toybox talk -". Retrieved 2013-08-21. GPLv3 broke "the" GPL into incompatible forks that can't share code. 
  10. ^ Byfield, Bruce (22 November 2011). "7 Reasons Why Free Software Is Losing Influence: Page 2". Retrieved 23 August 2013. 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. 
  11. ^ James E.J. Bottomley, Mauro Carvalho Chehab, Thomas Gleixner, Christoph Hellwig, Dave Jones, Greg Kroah-Hartman, Tony Luck, Andrew Morton, Trond Myklebust, David Woodhouse (15 September 2006). "Kernel developers' position on GPLv3 - The Dangers and Problems with GPLv3". Retrieved 2015-03-11. [...]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. 
  12. ^ "FLOSS License Proliferation: Still a problem" by David A. Wheeler
  13. ^ GitHub finally takes open source licenses seriously on Infoworld by Simon Phipps on July 2013
  14. ^ Choosing an open source license doesn’t need to be scary - Which of the following best describes your situation? on (accessed 2015-11-29)
  15. ^ Open source license usage on on March 9, 2015 by Ben Balter on "MIT 44.69%, [...]GPLv2 12.96%, Apache 11.19%, GPLv3 8.88%"
  16. ^ Ed Burnette (2006-11-02). "Google says no to license proliferation". Archived from the original on 2007-02-24. Retrieved 2010-09-11. 
  17. ^ Greg Stein (2009-05-28). "Standing Against License Proliferation". Archived from the original on 2008-06-01. Retrieved 2010-09-11. 
  18. ^ Chris DiBona (2010-09-10). "License Evolution and Hosting Projects on Code.Google.Com". Retrieved 2010-09-11. 
  19. ^ License Proliferation Project
  20. ^ License Proliferation Report
  21. ^ The earliest archived version of the license list reflects this position. Bradley M. Kuhn (2000-08-15). "Various Licenses and Comments about Them". Free Software Foundation. pp. 37–39. Archived from the original on 2008-07-04. Retrieved 2015-11-29. 
  22. ^ How GPLv3 tackles license proliferation on
  23. ^ The Myth of Open Source License Proliferation on
  24. ^ Open Source License Proliferation: Helpful Diversity or Hopeless Confusion? on by Robert W. Gomulkiewicz on 2009

External links[edit]