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.

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 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 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 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.<ref>{{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 }}</ref> 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.

 Vanity licenses 
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.

 Solution approaches 

 GitHub's stance 
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.

 Google's stance 
From 2006 Google Code only accepted projects licensed under the following seven licenses:
 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, 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.

 OSI's stance 
Open Source Initiative (OSI) maintains a list of approved licenses. 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 has prepared a License Proliferation Report in 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.

 FSF's stance 
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.

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. 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.

The 451group created in June 2009 a proliferation report called The Myth of Open Source License Proliferation. 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". 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."''

See also 
 License compatibility
 Rights Expression Language

References

External links 
 Open source license proliferation, a broader view by Raymond Nimmer
 Larry Rosen argues that different licenses can be a good thing Larry Rosen
Licensing howto by Eric S. Raymond
License proliferation for Medical Software by Fred Trotter Advocates that for Health Software, only the Google seven should be used.
How to choose a license for your own work Free Software Foundation

Proliferation
Licensing
라이선스 범람()은 소프트웨어 패키지마다 라이선스를 재부여하면서 생기는 여러 폐해를 가리키는 용어이다. 종종 소프트웨어 개발자가 다른 소프트웨어 프로그램의 부분을 병합할 때 발생하기도 하는데, 개발자들은 이 병합을 행할 수 없게 된다. 그 이유는 라이선스가 서로 호환되지 않기 때문이다. 두 개의 서로 다른 라이선스 아래의 소프트웨어가 서로 혼합될 수 있을 때에는 라이선스가 서로 호환됨을 의미한다. 라이선스 종류가 많아지면서 자유 또는 오픈소스 소프트웨어(FOSS) 개발자들이 함께 하고자 하는 소프트웨어가 이용 가능하더라도, 서로 호환되지 않는 라이선스 하에서 이루어질 가능성이 높아진다. 또한, 사용하는 소프트웨어 패키지의 각 라이선스에 대한 비교와 평가에 큰 비용이 들어가게 된다. 엄밀하게, 라이선스 범람에 동참하고 있는 인물이나 조직은 존재하지 않는다. 오히려 이 문제는 소프트웨어의 출시를 위해 새로운 라이선스를 작성하는 현실적인 요구나 그러한 요구가 인식한 것에서, 또 그 문제를 해결하려고 하는 경향에서 비롯된다.

호환되는 라이선스 
GNU General Public License(GPL)를 관리하는 자유 소프트웨어 재단(Free Software Foundation, FSF)은 GPL과 호환되는 라이선스의 목록을 정리하고 있다. 다른 유명한 자유 또는 오픈소스 소프트웨어로 아파치 라이선스(Apache License)가 존재한다. 아파치 소프트웨어 재단은 각 단체와의 논의를 거쳐 웹 사이트에서 “아파치 라이선스는 GPLv3과 호환된다. 그러나 그것은 일방적으로 되는 것이다. 즉, GPLv3 소프트웨어는 아파치 라이선스 소프트웨어를 포함할 수 있으나, 그 역은 불가능하다는 의미이다.”

공허한 라이선스 
공허한 라이선스()는 한 기업이나 인물이 특별한 이유도 없이 만들어 낸 라이선스를 비판하는 용어이다. 자유 또는 오픈소스 소프트웨어보다 더 널리 알려진 라이선스보다 확실한 개선 또는 차이점이 없는 라이선스를 만들어 낸 경우, 해당 라이선스가 공허하다는 비판을 하는 일이 종종 있다. 자유 또는 오픈소스 소프트웨어 라이선스로 요구를 충족하지 않고, 또한 그 요구 자체도 알지 못하며, 표준이 아닌 라이선스를 이용하는 것이 프로그램을 제3자에게 있어서 거의 의미가 없다는 것을 알지 못하고 새로 선보인 프로그램이라는 이유로 새로운 라이선스를 작성하는 이들이 2008년 시점에서 많이 존재하였다.

OSI의 입장 
Open Source Initiative(OSI)는 모든 오픈 소스 라이선스를 관리하는 입장에서 자신들을 보고 있다. 그들은 OSI 인증 라이선스 목록을 관리하고 있다. 초기에는 공허한 라이선스를 만들고 승인을 조장하는 움직임이 있었으나, 사실 마크 셔틀 워스를 비롯한 사람들은 OSI가 새로운 라이선스를 계속 승인하면서 라이선스 범람의 문제가 되고 있다고 생각하였다. 그래서 OSI에 그 문제에 있어서 중대한 책임이 있다고 주장하였다. 이 주장에 대응하기 위하여 OSI는 ‘라이선스 범람 문제 프로젝트’를 시작하였고, ‘라이선스 범람 보고서’를 준비하였다.

구글의 입장 
2006년부터 2010년까지 구글은 라이선스 범람에 대해 독자적인 입장을 취하였다. 특히 2006년에 구글은 자사의 코드 호스팅 사이트인 구글 코드(Google Code)에서 다음의 라이선스로 허락된 소프트웨어 프로젝트만 허용하는 방침을 발표하였다.

 Apache License 2.0
 Artistic License 와 GPL의 듀얼 라이선스
 GNU General Public License 3.0
 GNU General Public License 2.0
 GNU Lesser General Public License
 MIT License
 새로운 BSD License
 Mozilla Public License 1.1
 Eclipse Public License
2008년, 구글이 호스팅하는 프로젝트에 아파치 라이선스 또는 GPLv3을 추천한다는 추가적인 발표를 하였다. 그러나 2010년에 이러한 엄격한 운영에 역행하여, 결과적으로 OSI의 입장과 동일해졌다. OSI 승인 라이선스의 프로젝트가 모든 구글 코드에서 호스팅할 수 있게 된 것이다. 이로 인하여 APGL 등의 라이선스로 진행되는 프로젝트까지 호스트할 수 있게 되었다.

FSF의 입장 
FSF의 대표 리처드 스톨먼과 집행위원(Executive Director) 브랜들리.M.쿤은 2000년부터 라이선스 범람에 대한 주장을 해 왔다. 그들은 FSF License List를 책정하고, 소프트웨어 개발자가 만든 소프트웨어 라이선스로 GPL과 호환되는 무료 소프트웨어 라이선스를 채택하도록 개발자에게 권장하고 있다. 그러나 GPL과 호환되지 않는 여러 소프트웨어 프로그램이 이 목록에 코멘트 첨부 방식으로 게재되었는데, 그들은 “해당 라이선스 하에 이미 부여된 소프트웨어의 사용 또는 동작 또는 그 쌍방에 관해서는 전혀 문제가 없다. 그러나 다른 한편으로는 이 목록의 독자가 작성하는 소프트웨어에는 그들의 라이선스를 이용하지 않도록 권한다.”

각주 

자유 소프트웨어
자유 및 오픈 소스 소프트웨어 사용권