License proliferation

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

Lua error in package.lua at line 80: module 'strict' not found. License proliferation refers to the phenomena of an abundance of already existing and the continued creation of new software licenses for software and software packages in the FOSS ecosystem. License proliferation affects the whole FOSS ecosystem negatively by the burden of increasingly complex license selection, license interaction, and license compatibility considerations.[1]

Impact

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

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

Vanity licenses

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").[17] 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.[18]

Solution approaches

GitHub's stance

In July 2013 GitHub started a license selection wizard called choosealicense.[19] 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.[20] Following in 2015, the three licenses have approx. 77% of all licensed projects on GitHub.[21]

Google's stance

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

One year later, around 2008, the GNU General Public License 3.0 was added and strongly recommended together with the permissive Apache license,[23] notably excluded was the AGPLv3 to reduce license proliferation.[24]

In 2010, Google removed these restrictions, and announced that it would allow projects to use any OSI-approved license (see #OSI's stance below),[25] but with the limitation that public domain projects are only allowed as single case decision.

OSI's stance

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,[26] and early in their history, contributed to license proliferation by approving vanity licenses. In 2004 a OSI License Proliferation Project was started[27] has prepared a License Proliferation Report in 2007.[28] 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 are the GPLv3, LGPLv3 and AGPLv3.

FSF's stance

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

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

Others

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

The 451group created in June 2009 a proliferation report called The Myth of Open Source License Proliferation.[32] 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".[33] The OpenSource Software Collaboration Counseling (OSCCC) 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."[34]

See also

References

  1. ↑ 1.0 1.1 OSI and License Proliferation on fossbazar.com by Martin Michlmayr "Too many different licenses makes it difficult for licensors to choose: it's difficult to choose a good license for a project because there are so many. Some licenses do not play well together: some open source licenses do not inter-operate well with other open source licenses, making it hard to incorporate code from other projects. Too many licenses makes it difficult to understand what you are agreeing to in a multi-license distribution: since a FOSS application typically contains code with different licenses and people use many applications which each contain one or several licenses, it's difficult to see what your obligations are." (on August 21st, 2008)
  2. ↑ The Free-Libre / Open Source Software (FLOSS) License Slide by David A. Wheeler on September 27, 2007
  3. ↑ http://www.dwheeler.com/essays/gpl-compatible.html
  4. ↑ license list of gnu.org
  5. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  6. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  7. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  8. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  9. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  10. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  11. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  12. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  13. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  14. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  15. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  16. ↑ Are you sure you want to use the GPL? by Armin Ronacher (2009)
  17. ↑ Sharing medical software: FOSS licensing in medicine on freesoftwaremagazine.com by Fred Trotter (2007-06-14)
  18. ↑ "FLOSS License Proliferation: Still a problem" by David A. Wheeler
  19. ↑ GitHub finally takes open source licenses seriously on Infoworld by Simon Phipps on July 2013
  20. ↑ 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)
  21. ↑ 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%"
  22. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  23. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  24. ↑ 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."
  25. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  26. ↑ OSI Approved Licenses on opensource.com
  27. ↑ License Proliferation Project on opensource.com (2004)
  28. ↑ License Proliferation Report on opensource.com (2007)
  29. ↑ The earliest archived version of the license list reflects this position. Lua error in package.lua at line 80: module 'strict' not found.
  30. ↑ How GPLv3 tackles license proliferation on linuxdevices.com
  31. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  32. ↑ The Myth of Open Source License Proliferation on the451group.com
  33. ↑ Open Source License Proliferation: Helpful Diversity or Hopeless Confusion? on law.washington.edu by Robert W. Gomulkiewicz on 2009
  34. ↑ License compatibility on osscc.net

External links

Retrieved from "https://infogalactic.com/w/index.php?title=License_proliferation&oldid=713674454"