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.
Contents |
Compatible licenses [edit]
The Free Software Foundation (FSF) who maintains the GNU General Public License (GPL) also maintains a list of the licenses that are compatible with the GPL. Another popular FOSS license is the Apache License. The Apache Foundation has a page discussing the fact that the Apache License is listed compatible with the GPLv3 but only one way — Apache software can be included in GPLv3 software but not vice versa.
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. 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.[1]
Google's stance [edit]
From 2006 until 2010, Google Code only accepted projects licensed only under the following licenses:[2]
- Apache License 2.0
- Artistic License/GPL (often used by the Perl community)
- GNU General Public License 3.0
- GNU General Public License 2.0
- GNU Lesser General Public License
- MIT License
- New BSD License
- Mozilla Public License 1.1
- Eclipse Public License
In 2008, Google started to recommend the Apache License and the GPLv3.[3]
2010, Google reversed these restrictions, and announced that it would require that projects hosted on Google Code be licensed under an OSI-approved license (see #OSI's stance below).[4]
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 some to license proliferation by assisting in the production and approving vanity licenses. The OSI License Proliferation Project has prepared a License Proliferation Report.
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.[5]
FSFE's stance [edit]
Ciarán O'Riordan 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.
See also [edit]
References [edit]
- ^ "FLOSS License Proliferation: Still a problem" by David A. Wheeler
- ^ Ed Burnette (2006-11-02). "Google says no to license proliferation". Archived from the original on 2007-02-24. Retrieved 2010-09-11.
- ^ Greg Stein (2009-05-28). "Standing Against License Proliferation". Archived from the original on 2008-06-01. Retrieved 2010-09-11.
- ^ Chris DiBona (2010-09-10). "License Evolution and Hosting Projects on Code.Google.Com". Retrieved 2010-09-11.
- ^ 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 2000-08-15.
External links [edit]
- 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.
A portion of the proceeds from advertising on Digplanet goes to supporting Wikipedia.
