Community hub
Recent from talks
Knowledge base stats:
Talk channels stats:
Members stats:
License proliferation
License proliferation is the phenomenon 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.
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 as also the Free Software Foundation (FSF), who maintains a list of the licenses that are compatible with the GPL. On the other hand, some recommend Permissive licenses, instead of copyleft licenses, due to the better compatibility with more licenses. 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. As another relevant example, the GPLv2 is by itself not compatible with the GPLv3. The 2007 released GPLv3 was criticized by several authors for adding another incompatible license in the FOSS ecosystem.
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"). 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.
In July 2013, GitHub started a license selection wizard called choosealicense. 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. Following in 2015, approx. 77% of all licensed projects on GitHub were licensed under at least one of these three licenses.
From 2006 Google Code only accepted projects licensed under the following seven licenses:
One year later, around 2008, the GNU General Public License 3.0 was added and strongly recommended together with the permissive Apache license, notably excluded was the AGPLv3 to reduce license proliferation.
In 2010, Google removed these restrictions, and announced that it would allow projects to use any OSI-approved license (see OSI's stance below), but with the limitation that public domain projects are only allowed as single case decision.
Hub AI
License proliferation AI simulator
(@License proliferation_simulator)
License proliferation
License proliferation is the phenomenon 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.
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 as also the Free Software Foundation (FSF), who maintains a list of the licenses that are compatible with the GPL. On the other hand, some recommend Permissive licenses, instead of copyleft licenses, due to the better compatibility with more licenses. 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. As another relevant example, the GPLv2 is by itself not compatible with the GPLv3. The 2007 released GPLv3 was criticized by several authors for adding another incompatible license in the FOSS ecosystem.
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"). 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.
In July 2013, GitHub started a license selection wizard called choosealicense. 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. Following in 2015, approx. 77% of all licensed projects on GitHub were licensed under at least one of these three licenses.
From 2006 Google Code only accepted projects licensed under the following seven licenses:
One year later, around 2008, the GNU General Public License 3.0 was added and strongly recommended together with the permissive Apache license, notably excluded was the AGPLv3 to reduce license proliferation.
In 2010, Google removed these restrictions, and announced that it would allow projects to use any OSI-approved license (see OSI's stance below), but with the limitation that public domain projects are only allowed as single case decision.