License proliferation

Last updated

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

Contents

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

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"). [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 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. [20] Following in 2015, approx. 77% of all licensed projects on GitHub were licensed under at least one of these three licenses. [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) maintains a list of approved licenses. [26] 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 [27] has prepared a License Proliferation Report in 2007. [28] The report defined classes of 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. [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] 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". [33] 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." [34]

See also

Related Research Articles

<span class="mw-page-title-main">Free software</span> Software licensed to be freely used, modified and distributed

Free software, libre software, or libreware is computer software distributed under terms that allow users to run the software for any purpose as well as to study, change, and distribute it and any adapted versions. Free software is a matter of liberty, not price; all users are legally free to do what they want with their copies of a free software regardless of how much is paid to obtain the program. Computer programs are deemed "free" if they give end-users ultimate control over the software and, subsequently, over their devices.

The free software movement is a social movement with the goal of obtaining and guaranteeing certain freedoms for software users, namely the freedoms to run, study, modify, and share copies of software. Software which meets these requirements, The Four Essential Freedoms of Free Software, is termed free software.

<span class="mw-page-title-main">GNU Lesser General Public License</span> Free-software license

The GNU Lesser General Public License (LGPL) is a free-software license published by the Free Software Foundation (FSF). The license allows developers and companies to use and integrate a software component released under the LGPL into their own software without being required by the terms of a strong copyleft license to release the source code of their own components. However, any developer who modifies an LGPL-covered component is required to make their modified version available under the same LGPL license. For proprietary software, code under the LGPL is usually used in the form of a shared library, so that there is a clear separation between the proprietary and LGPL components. The LGPL is primarily used for software libraries, although it is also used by some stand-alone applications.

The MIT License is a permissive free software license originating at the Massachusetts Institute of Technology (MIT) in the late 1980s. As a permissive license, it puts only very limited restriction on reuse and has, therefore, high license compatibility.

<span class="mw-page-title-main">Open-source license</span> Software license allowing source code to be used, modified, and shared

Open-source licenses facilitate free and open-source software (FOSS) development. Intellectual property (IP) laws restrict the modification and sharing of creative works. Free and open-source software licenses use these existing legal structures for the inverse purpose of granting freedoms that promote sharing and collaboration. They grant the recipient the rights to use the software, examine the source code, modify it, and distribute the modifications. These licenses target computer software where source code can be necessary to create modifications. They also cover situations where there is no difference between the source code and the executable program distributed to end users. Open-source licenses can cover hardware, infrastructure, drinks, books, and music.

<span class="mw-page-title-main">Apache License</span> Free software license developed by the ASF

The Apache License is a permissive free software license written by the Apache Software Foundation (ASF). It allows users to use the software for any purpose, to distribute it, to modify it, and to distribute modified versions of the software under the terms of the license, without concern for royalties. The ASF and its projects release their software products under the Apache License. The license is also used by many non-ASF projects.

The Open Software License (OSL) is a software license created by Lawrence Rosen. The Open Source Initiative (OSI) has certified it as an open-source license, but the Debian project judged version 1.1 to be incompatible with the DFSG. The OSL is a copyleft license, with a termination clause triggered by filing a lawsuit alleging patent infringement.

The Common Development and Distribution License (CDDL) is a free and open-source software license, produced by Sun Microsystems, based on the Mozilla Public License (MPL). Files licensed under the CDDL can be combined with files licensed under other licenses, whether open source or proprietary. In 2005 the Open Source Initiative approved the license. The Free Software Foundation (FSF) considers it a free software license, but one which is incompatible with the GNU General Public License (GPL).

<span class="mw-page-title-main">Free and open-source software</span> Software whose source code is available and which is permissively licensed

Free and open-source software (FOSS) is a term used to refer to groups of software consisting of both free software and open-source software where anyone is freely licensed to use, copy, study, and change the software in any way, and the source code is openly shared so that people are encouraged to voluntarily improve the design of the software. This is in contrast to proprietary software, where the software is under restrictive copyright licensing and the source code is usually hidden from the users.

A permissive software license, sometimes also called BSD-like or BSD-style license, is a free-software license which instead of copyleft protections, carries only minimal restrictions on how the software can be used, modified, and redistributed, usually including a warranty disclaimer. Examples include the GNU All-permissive License, MIT License, BSD licenses, Apple Public Source License and Apache license. As of 2016, the most popular free-software license is the permissive MIT license.

Alternative terms for free software, such as open source, FOSS, and FLOSS, have been a controversial issue among free and open-source software users from the late 1990s onwards. These terms share almost identical licence criteria and development practices.

This comparison only covers software licenses which have a linked Wikipedia article for details and which are approved by at least one of the following expert groups: the Free Software Foundation, the Open Source Initiative, the Debian Project and the Fedora Project. For a list of licenses not specifically intended for software, see List of free-content licences.

<span class="mw-page-title-main">Public-domain-equivalent license</span> License that waives all copyright

Public-domain-equivalent license are licenses that grant public-domain-like rights and/or act as waivers. They are used to make copyrighted works usable by anyone without conditions, while avoiding the complexities of attribution or license compatibility that occur with other licenses.

The Affero General Public License is a free software license. The first version of the Affero General Public License (AGPLv1), was published by Affero, Inc. in March 2002, and based on the GNU General Public License, version 2 (GPLv2). The second version (AGPLv2) was published in November 2007, as a transitional license to allow an upgrade path from AGPLv1 to the GNU Affero General Public License.

License compatibility is a legal framework that allows for pieces of software with different software licenses to be distributed together. The need for such a framework arises because the different licenses can contain contradictory requirements, rendering it impossible to legally combine source code from separately-licensed software in order to create and publish a new program. Proprietary licenses are generally program-specific and incompatible; authors must negotiate to combine code. Copyleft licenses are commonly deliberately incompatible with proprietary licenses, in order to prevent copyleft software from being re-licensed under a proprietary license, turning it into proprietary software. Many copyleft licenses explicitly allow relicensing under some other copyleft licenses. Permissive licenses are compatible with everything, including proprietary licenses; there is thus no guarantee that all derived works will remain under a permissive license.

<span class="mw-page-title-main">Free-software license</span> License allowing software modification and redistribution

A free-software license is a notice that grants the recipient of a piece of software extensive rights to modify and redistribute that software. These actions are usually prohibited by copyright law, but the rights-holder of a piece of software can remove these restrictions by accompanying the software with a software license which grants the recipient these rights. Software using such a license is free software as conferred by the copyright holder. Free-software licenses are applied to software in source code and also binary object-code form, as the copyright law recognizes both forms.

BSD licenses are a family of permissive free software licenses, imposing minimal restrictions on the use and distribution of covered software. This is in contrast to copyleft licenses, which have share-alike requirements. The original BSD license was used for its namesake, the Berkeley Software Distribution (BSD), a Unix-like operating system. The original version has since been revised, and its descendants are referred to as modified BSD licenses.

<span class="mw-page-title-main">GNU General Public License</span> Series of free software licenses

The GNU General Public License is a series of widely used free software licenses that guarantee end users the four freedoms to run, study, share, and modify the software. The license was the first copyleft for general use and was originally written by Richard Stallman, the founder of the Free Software Foundation (FSF), for the GNU Project. The license grants the recipients of a computer program the rights of the Free Software Definition. These GPL series are all copyleft licenses, which means that any derivative work must be distributed under the same or equivalent license terms. It is more restrictive than the Lesser General Public License and even further distinct from the more widely used permissive software licenses BSD, MIT, and Apache.

GNU LibreDWG is a software library programmed in C to manage DWG computer files, native proprietary format of computer-aided design software AutoCAD. It aims to be a free software replacement for the OpenDWG libraries. The project is managed by the Free Software Foundation (FSF).

Software sublicensing is applied in open-source software development when software licenses of software modules are incompatible and are required to be compatible for a greater combined work. Licenses applied to software as copyrightable works, in source code as binary form, can contain contradictory clauses. These requirements can make it impossible to combine source code or content of several software works to create a new combined one.

References

  1. 1 2 "OSI and License Proliferation" on FOSSBazaar by Martin Michlmayr on August 21st, 2008. "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."
  2. ↑ "The Free-Libre / Open Source Software (FLOSS) License Slide" by David A. Wheeler on September 27, 2007.
  3. ↑ Wheeler, David A. (February 16, 2014). "Make Your Open Source Software GPL-Compatible. Or Else". Archived from the original on November 13, 2023.
  4. ↑ "Various Licenses and Comments about Them", GNU. Archived 2000-08-15 at the Wayback Machine .
  5. ↑ Laurent, Philippe (September 24, 2008). "The GPLv3 and compatibility issues" (PDF). European Open source Lawyers Event 2008. University of Namur – Belgium. p. 7. Archived from the original (PDF) on March 4, 2016. Retrieved May 30, 2015. Copyleft is the main source of compatibility problems
  6. ↑ Hanwell, Marcus D. (January 28, 2014). "Should I use a permissive license? Copyleft? Or something in the middle?". opensource.com. Retrieved May 30, 2015. 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.
  7. ↑ "Licence Compatibility and Interoperability". Open-Source Software - Develop, share, and reuse open source software for public administrations. joinup.ec.europa.eu. Archived from the original on June 17, 2015. Retrieved May 30, 2015. 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").
  8. ↑ Apache foundation (May 30, 2015). "GPL compatibility" . Retrieved May 30, 2015. 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.
  9. ↑ "Frequently Asked Questions about the GNU Licenses – Is GPLv3 compatible with GPLv2?". gnu.org. Retrieved June 3, 2014. 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.
  10. ↑ Landley, Rob. "CELF 2013 Toybox talk". landley.net. Retrieved August 21, 2013. GPLv3 broke "the" GPL into incompatible forks that can't share code.
  11. ↑ Asay, Clark D. "Michigan Telecommunications and Technology Law Review Volume 14 - Issue 22008 The General Public License Version 3.0: Making or Breaking the Foss Movement". law.umich.edu. In the end, GPLv3 constitutes license proliferation.
  12. ↑ Nikolai Bezroukov (2000). "Comparative merits of GPL, BSD and Artistic licences (Critique of Viral Nature of GPL v.2 - or In Defense of Dual Licensing Idea)". Archived from the original on December 22, 2001. Viral property stimulates proliferation of licenses and contributes to the "GPL-enforced nightmare" -- a situation when many other licenses are logically incompatible with the GPL and make life unnecessary difficult for developers working in the Linux environment (KDE is a good example here, Python is a less known example). I think that this petty efforts to interpret GPL as a "holy text" are non-productive discussion that does not bring us anywhere. And they directly contributed to the proliferation of different "free software" licenses.
  13. ↑ Byfield, Bruce (November 22, 2011). "7 Reasons Why Free Software Is Losing Influence: Page 2". Datamation.com. Retrieved August 23, 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.
  14. ↑ James E.J. Bottomley; Mauro Carvalho Chehab; Thomas Gleixner; Christoph Hellwig; Dave Jones; Greg Kroah-Hartman; Tony Luck; Andrew Morton; Trond Myklebust; David Woodhouse (September 15, 2006). "Kernel developers' position on GPLv3 - The Dangers and Problems with GPLv3". LWN.net . Retrieved March 11, 2015. [...]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.
  15. ↑ Ronacher, Armin (July 23, 2013). "Licensing in a Post Copyright World". lucumr.pocoo.org. Retrieved November 18, 2015. The License Compatibility Clusterfuck - When the GPL is involved the complexities of licensing becomes a non fun version of a riddle. So many things to consider and so many interactions to consider. And that GPL incompatibilities are still an issue that actively effects people is something many appear to forget. For instance one would think that the incompatibility of the GPLv2 with the Apache Software License 2.0 should be a thing of the past now that everything upgrades to GPLv3, but it turns out that enough people are either stuck with GPLv2 only or do not agree with the GPLv3 that some Apache Software licensed projects are required to migrate. For instance Twitter's Bootstrap is currently migrating from ASL2.0 to MIT precisely because some people still need GPLv2 compatibility. Among those projects that were affected were Drupal, WordPress, Joomla, the MoinMoin Wiki and others. And even that case shows that people don't care that much about licenses any more as Joomla 3 just bundled bootstrap even though they were not licenses in a compatible way (GPLv2 vs ASL 2.0). The other traditional case of things not being GPL compatible is the OpenSSL project which has a license that does not go well with the GPL. That license is also still incompatible with the GPLv3. The whole ordeal is particularly interesting as some not so nice parties have started doing license trolling through GPL licenses.
  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. ↑ "David A. Wheeler's Blog". dwheeler.com.
  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. ↑ Ed Burnette (November 2, 2006). "Google says no to license proliferation". ZDNet . Archived from the original on February 24, 2007. Retrieved September 11, 2010.
  23. ↑ Greg Stein (May 28, 2009). "Standing Against License Proliferation". Archived from the original on June 1, 2008. Retrieved September 11, 2010.
  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. ↑ Chris DiBona (September 10, 2010). "License Evolution and Hosting Projects on Code.Google.Com" . Retrieved September 11, 2010.
  26. ↑ OSI Approved Licenses on opensource.org
  27. ↑ License Proliferation Project on opensource.com (2004)
  28. ↑ License Proliferation Report Archived 2012-12-12 at the Wayback Machine on opensource.com (2007)
  29. ↑ The earliest archived version of the license list reflects this position. Bradley M. Kuhn (August 15, 2000). "Various Licenses and Comments about Them". Free Software Foundation. pp. 37–39. Archived from the original on August 15, 2000. Retrieved November 29, 2015.
  30. ↑ How GPLv3 tackles license proliferation on linuxdevices.com
  31. ↑ Marson, Ingrid (March 31, 2005). "Intel to stop using open-source license". cnet.com. CNet. Retrieved October 6, 2014.
  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
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.