Lizenzverbreitung

Lizenzverbreitung ist das Phänomen einer Fülle bereits existierender und fortgesetzter Schaffung neuer Software -Lizenzen zum Software und Softwarepakete in dem Foss Ökosystem. Lizenzverletzung betrifft das Ganze Foss Ökosystem negativ durch die Belastung einer zunehmend komplexen Lizenzauswahl, Lizenzinteraktion und Lizenzkompatibilität Überlegungen.[1]

Einfluss

Wenn ein Softwareentwickler Teile verschiedener Softwareprogramme zusammenführen möchte, können er oft nicht in der Lage sein, weil die Lizenzen sind unvereinbar. Wenn Software unter zwei verschiedenen Lizenzen in eine größere Software -Arbeit verschmolzen werden kann, sollen die Lizenzen kompatibel sind. Mit zunehmender Anzahl der Lizenzen die Wahrscheinlichkeit, dass a Kostenlose und Open-Source-Software (FOSS) Der Entwickler möchte Software zusammenführen, die unter inkompatiblen Lizenzen erhältlich sind. Unternehmen, die jede FOSS -Lizenz für die von ihnen verwendeten Softwarepakete bewerten möchten, haben auch größere Kosten.[1] Streng genommen ist niemand für die Lizenzverletzung. Das Problem beruht vielmehr von der Tendenz, dass Organisationen neue Lizenzen schreiben, um die realen oder wahrgenommenen Anforderungen für ihre Software -Releases zu befriedigen.

Lizenzkompatibilität

Die Lizenzverletzung ist insbesondere ein Problem, wenn Lizenzen nur begrenzt oder kompliziert sind Lizenzkompatibilität Beziehungen zu anderen Lizenzen. Einige betrachten daher die Kompatibilität mit den weit verbreiteten GNU Allgemeine öffentliche Lizenz (GPL) Ein wichtiges Merkmal, zum Beispiel David A. Wheeler[2][3] wie auch die Kostenlose Software -Stiftung (FSF), der eine Liste der Lizenzen unterhält, die mit der GPL kompatibel sind.[4] Auf der anderen Seite empfehlen manche einige Zulässige Lizenzen, Anstatt von Copyleft -Lizenzen,[5] Aufgrund der besseren Kompatibilität mit mehr Lizenzen.[6][7] Das Apache Foundation zum Beispiel kritisiert die Tatsache, dass die während der Apache -Lizenz Mit der Copyleft GPLV3 kompatibel, ist der GPLV3 nicht mit der zulässigen Apache -Lizenz kompatibel - Apache -Software kann in die GPLV3 -Software enthalten sein, aber nicht umgekehrt.[8] Als ein weiteres relevantes Beispiel, das GPLV2 ist von selbst nicht kompatibel mit dem GPLV3.[9] Der 2007 veröffentlichte GPLV3 wurde von mehreren Autoren dafür kritisiert, dass sie eine weitere inkompatible Lizenz im Foss -Ökosystem hinzugefügt haben.[10][11][12][13][14][15][16]

Eitelkeitslizenzen

Eine Vanity -Lizenzen ist eine Lizenz, die von einem Unternehmen oder einer Person aus keinem anderen Grund geschrieben wurde, als ihre eigene Lizenz zu schreiben ("NIH -Syndrom").[17] Wenn eine neue Lizenz erstellt wird, die keine offensichtliche Verbesserung oder Unterschiede gegenüber einer anderen häufigeren FOSS -Lizenz hat, kann sie häufig als Eitelkeitslizenz kritisiert werden. Ab 2008 erstellen viele Menschen eine benutzerdefinierte neue Lizenz für ihr neu veröffentlichtes Programm, ohne die Anforderungen für eine FOSS -Lizenz zu kennen und zu erkennen, dass die Verwendung einer nicht standardmäßigen Lizenz dieses Programm für andere fast nutzlos machen kann.[18]

Lösungsansätze

Githubs Haltung

Im Juli 2013, GitHub Startete einen Assistenten für Lizenzauswahl Choosealicense.[19] Githubs Choosealicense FrontPage bietet als schnelle Auswahl nur drei Lizenzen: die MIT -Lizenz, das Apache -Lizenz und die GNU Allgemeine öffentliche Lizenz. Einige zusätzliche Lizenzen werden auf Nebenseite und über Links angeboten.[20] Nachfolgend im Jahr 2015 ca. 77% aller lizenzierten Projekte auf GitHub wurden unter mindestens einer dieser drei Lizenzen lizenziert.[21]

Googles Haltung

Ab 2006 Google -Code Nur akzeptierte Projekte, die nach den folgenden sieben Lizenzen lizenziert wurden:[22]

Ein Jahr später, um 2008, die GNU Allgemeine öffentliche Lizenz 3.0 wurde hinzugefügt und dringend empfohlen, zusammen mit der zulässigen Apache -Lizenz.[23] insbesondere ausgeschlossen war die AGPLV3 Verringerung der Lizenzproliferation.[24]

Im Jahr 2010 hat Google diese Beschränkungen entfernt und angekündigt, dass Projekte eine OSI-zugelassene Lizenz verwenden würden (siehe Osis Haltung unter),[25] aber mit der Einschränkung, dass öffentlich zugänglich Projekte sind nur als Einzelfallentscheidung zulässig.

Osis Haltung

Open Source Initiative (OSI) unterhält eine Liste genehmigter Lizenzen.[26] Zu Beginn seiner Geschichte trug die OSI zur Lizenzverletzung durch die Genehmigung von Eitelkeit und nicht resebaren Lizenzen bei. Im Jahr 2004 wurde ein OSI -Lizenzprojekt gestartet[27] hat 2007 einen Lizenzverbreitungsbericht erstellt.[28] Der Bericht definierte Klassen von Lizenzen:

  • Lizenzen, die beliebt und weit verbreitet sind oder mit starken Gemeinschaften
  • Internationale Lizenzen
  • Besondere Zwecklizenzen
  • Andere/verschiedene Lizenzen
  • Lizenzen, die mit beliebteren Lizenzen überflüssig sind
  • Nicht wiederverwendbare Lizenzen
  • Ersetzte Lizenzen
  • Lizenzen, die freiwillig im Ruhestand waren
  • Nicht kategorisierte Lizenzen

Die Gruppe der "beliebten" Lizenzen umfasst neun Lizenzen: Apache -Lizenz 2.0, Neue BSD -Lizenz, GPLV2, LGPLV2, MIT -Lizenz, Mozilla Public Lizenz 1.1, Gemeinsame Entwicklungs- und Vertriebslizenz, Gemeinsame öffentliche Lizenz, Eclipse Public Lizenz.

FSFs Haltung

Richard Stallman, ehemaliger Präsident von Kostenlose Software -Stiftung, und Bradley M. Kuhn, ehemaliger Exekutivdirektor, haben seit 2000 gegen die Lizenzverletzung argumentiert, als sie die FSF einleiteten Lizenzliste, was Entwickler auffordert, ihre Software unter zu lizenzieren GPL-kompatibel Kostenlose Software-Lizenz (en), obwohl mehrere GPL-inkompatible kostenlose Softwarelizenzen mit einem Kommentar aufgeführt sind, aus denen hervorgeht, dass es kein Problem mit der Verwendung und/oder der Arbeit an einer Software gibt, die bereits unter den betreffenden Lizenzen ist, und gleichzeitig die Leser der Liste auffordert, nicht Um diese Lizenzen für Software zu verwenden, die sie schreiben.[29]

Ciarán O'riordan von FSF Europa argumentiert, dass die Hauptsache, die die FSF zur Verhinderung der Lizenzverletzung durchführen kann Wie GPLV3 die Lizenzverbreitung angeht.[30] Im Allgemeinen das FSF Europa empfiehlt konsequent die Verwendung der GNU GPL so weit wie möglich und wenn dies nicht möglich ist, um GPL-kompatible Lizenzen zu verwenden.

Andere

2005 hat Intel freiwillig ihre zurückgezogen Intel Open Source -Lizenz von dem Osi Liste der Open -Source -Lizenzen und hat diese Lizenz auch nicht mehr verwendet oder empfohlen, um die Lizenzverletzung zu verringern.[31]

Die 451group im Juni 2009 erstellt ein Proliferationsbericht mit dem Titel " Der Mythos der Open -Source -Lizenzverbreitung.[32] Ein Papier 2009 aus dem Rechtsschule der Universität Washington betitelt Open Source -Lizenz Verbreitung: Hilfreiche Vielfalt oder hoffnungslose Verwirrung? forderte drei Dinge als Lösung: "Ein Wizzier Wizzard" (zur Lizenzauswahl), "Best Practices und Legacy -Lizenzen", "Mehr juristische Dienstleistungen für Hacker".[33] Die OpenSource Software Collaboration Counseling (OSSCC) empfiehlt basierend auf den ursprünglich neun empfohlenen OSI -Lizenzen, fünf Lizenz Verwenden und Bieten Sie Patentschutz an. Insbesondere fehlt die GPL als "Diese Lizenz kann nicht in anderen Arbeiten unter einer anderen Lizenz verwendet werden."[34]

Siehe auch

Verweise

  1. ^ a b OSI und Lizenzverbreitung auf fossbazar.com von Martin Michlmayr "Zu viele verschiedene Lizenzen erschweren es den Lizenzgebern zu wählen: Es ist schwierig, eine gute Lizenz für ein Projekt auszuwählen, da es so viele gibt. Einige Lizenzen spielen nicht gut zusammen: Einige Open-Source-Lizenzen funktionieren nicht gut mit anderen offenen Open. Quelllizenzen, die es schwierig machen, Code aus anderen Projekten einzubeziehen. Zu viele Lizenzen erschweren sich schwer zu verstehen, was Sie in einer Mehrfachlizenzverteilung zustimmen: Da eine FOSS-Anwendung in der Regel Code mit unterschiedlichen Lizenzen enthält und Personen viele Anwendungen verwenden, die jeweils jeweils verwendet Ein oder mehrere Lizenzen enthalten, ist es schwierig zu erkennen, welche Verpflichtungen Ihre Verpflichtungen sind. " (am 21. August 2008)
  2. ^ Die Free-Libre / Open-Source-Software (FLOSS) Lizenz Folge von David A. Wheeler am 27. September 2007
  3. ^ "Machen Sie Ihre Open-Source-Software GPL-kompatibel. Oder sonst". www.dwheeler.com.
  4. ^ Lizenzliste Archiviert 2000-08-15 im Wayback -Maschine von gnu.org
  5. ^ Laurent, Philippe (24. September 2008). "Die GPLV3- und Kompatibilitätsprobleme" (PDF). European Open Source Lawyers Event 2008. Universität von Namur - Belgien. p. 7. archiviert von das Original (PDF) am 4. März 2016. Abgerufen 30. Mai, 2015. Copyleft ist die Hauptquelle für Kompatibilitätsprobleme
  6. ^ Hanwell, Marcus D. (28. Januar 2014). "Soll ich eine zulässige Lizenz verwenden? Copyleft? Oder etwas in der Mitte?". OpenSource.com. Abgerufen 30. Mai, 2015. Die zulässige Lizenzierung vereinfacht die Dinge, warum die Geschäftswelt und immer mehr Entwickler [...] die zulässigen Lizenzen für die Wiederverwendung bevorzugen. Die Lizenz bezieht sich normalerweise nur auf den lizenzierten Quellcode und unternimmt keinen Versuch, auf eine andere Komponente zu schließen. Aus diesem Grund müssen nicht definiert werden, was eine abgeleitete Arbeit ausmacht. Ich habe auch noch nie ein Lizenzkompatibilitätsdiagramm für zulässige Lizenzen gesehen. Es scheint, dass sie alle kompatibel sind.
  7. ^ "Lizenzkompatibilität und Interoperabilität". Open -Source -Software - Open -Source -Software für öffentliche Verwaltungen entwickeln, teilen und wiederverwenden. Joinup.ec.europa.eu. Archiviert von das Original am 17. Juni 2015. Abgerufen 30. Mai, 2015. Die Lizenzen für die Verteilung von kostenloser oder Open -Source -Software (FOSS) sind in zwei Familien geteilt: zulässiger und CopyLeft. Zulässige Lizenzen (BSD, MIT, X11, Apache, Zope) sind im Allgemeinen kompatibel und interoperabel mit den meisten anderen Lizenzen, um den abgedeckten Kodex zu verschmelzen, zu kombinieren oder zu verbessern und ihn unter vielen Lizenzen zu verteilt (einschließlich nicht freier oder „proprietär ”).
  8. ^ Apache Foundation (30. Mai 2015). "GPL -Kompatibilität". Abgerufen 30. Mai, 2015. Die Apache 2 -Software kann daher in GPLV3 -Projekte aufgenommen werden, da die GPLV3 -Lizenz unsere Software in GPLV3 funktioniert. Die GPLV3 -Software kann jedoch nicht in Apache -Projekte einbezogen werden. Die Lizenzen sind nur in einer Richtung nicht kompatibel und es ist das Ergebnis der Lizenzphilosophie von ASF und der Interpretation des Urheberrechts durch die GPLV3 -Autoren.
  9. ^ "Häufig gestellte Fragen zu den GNU -Lizenzen - ist GPLV3 mit GPLV2 kompatibel?". gnu.org. Abgerufen 3. Juni, 2014. Nein. Einige der Anforderungen in GPLV3, z. B. die Anforderung zur Bereitstellung von Installationsinformationen, sind in GPLV2 nicht vorhanden. Infolgedessen sind die Lizenzen nicht kompatibel: Wenn Sie versucht haben, Code, das unter beiden Lizenzen veröffentlicht wurde, zu kombinieren, würden Sie gegen Abschnitt 6 von GPLV2 verstoßen. Wenn der Code jedoch unter GPL „Version 2 oder höher“ veröffentlicht wird, ist dies mit GPLV3 kompatibel, da GPLV3 eine der Optionen ist, die es zulässt.
  10. ^ Landley, Rob. "Celf 2013 Toybox Talk". Landley.net. Abgerufen 21. August, 2013. GPLV3 brach die "GPL in inkompatible Gabeln, die Code nicht freigeben können.
  11. ^ Asay, Clark D. "Michigan Telecommunications and Technology Law Review Band 14 - Ausgabe 22008 Die allgemeine öffentliche Lizenzversion 3.0: Erstellen oder Brechen der FOSS -Bewegung". Law.umich.edu. Am Ende ist GPLV3 Lizenzproliferation.
  12. ^ Nikolai Bezroukov (2000). "Vergleichende Verdienste von GPL-, BSD- und künstlerischen Lizenzen (Kritik der viralen Natur von GPL v.2 - oder zur Verteidigung der Doppellizenzidee)". Archiviert von das Original am 22. Dezember 2001. Viruseigenschaft stimuliert die Verbreitung von Lizenzen und trägt zum "GPL-durchlässigen Albtraum" bei-eine Situation, in der viele andere Lizenzen mit der GPL logisch nicht kompatibel sind und das Leben für Entwickler, die in der Linux-Umgebung arbeiten, unnötig erschweren (KDE ist hier ein gutes Beispiel hier. Python ist ein weniger bekanntes Beispiel). Ich denke, dass diese kleinen Bemühungen, GPL als "heiliger Text" zu interpretieren, eine nicht-produktive Diskussion sind, die uns nirgendwo hinbringt. Und sie haben direkt zur Verbreitung verschiedener "freier Software" -Lizenzen beigetragen.
  13. ^ Byfield, Bruce (22. November 2011). "7 Gründe, warum freie Software Einfluss verliert: Seite 2". DataMation.com. Abgerufen 23. August, 2013. Zu dieser Zeit schien die Entscheidung angesichts einer Sackgasse sinnvoll zu sein. Aber jetzt wird GPLV2 für 42,5% der kostenlosen Software und GPLV3 für weniger als 6,5% verwendet, so die Black -Enten -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 (15. September 2006). "Die Position der Kernelentwickler auf GPLV3 - die Gefahren und Probleme mit GPLV3". Lwn.net. Abgerufen 11. März, 2015. [...] Da der FSF vorschlägt, alle Projekte auf GPLV3 zu verschieben und Druck auf jedes andere GPL -lizenzierte Projekt auszuüben, um sich zu bewegen, sehen wir die Veröffentlichung von GPLV3 vor Balkanisierung des gesamten Open -Source -Universums, auf das wir uns verlassen.{{}}: CS1 Wartung: Verwendet Autorenparameter (Link)
  15. ^ Ronacher, Armin (23. Juli 2013). "Lizenzierung in einer Post -Copyright -Welt". lucumr.pocoo.org. Abgerufen 18. November, 2015. Die Lizenzkompatibilität Clusterfuck - Wenn die GPL beteiligt ist, wird die Komplexität der Lizenzierung zu einer nicht lustigen Version eines Rätsels. So viele Dinge zu berücksichtigen und so viele Interaktionen zu berücksichtigen. Und dass GPL -Inkompatibilitäten immer noch ein Thema sind, das sich auf die Menschen auswirkt, ist etwas, das viele zu vergessen scheinen. Zum Beispiel würde man denken, dass die Inkompatibilität des GPLV2 mit der Apache -Softwarelizenz 2.0 der Vergangenheit angehören sollte, dass alles auf GPLV3 aufgerüstet wird, aber es stellt sich heraus GPLV3, dass einige Apache -Software -lizenzierte Projekte migrieren müssen. Zum Beispiel wandert Twitters Bootstrap derzeit von ASL2.0 bis MIT, genau weil einige Menschen noch GPLV2 -Kompatibilität benötigen. Unter den betroffenen Projekten befanden sich Drupal, Wordpress, Joomla, das Moinmoin -Wiki und andere. Und selbst dieser Fall zeigt, dass die Menschen nicht so viel für Lizenzen interessiert, als Joomla 3 nur gebündeltes Bootstrap gebündelt hat, obwohl sie keine kompatiblen Art und Weise waren (GPLV2 gegen ASL 2.0). Der andere traditionelle Fall, in dem nicht GPL -kompatibel ist, ist das OpenSSL -Projekt, das eine Lizenz enthält, die nicht gut zum GPL passt. Diese Lizenz ist auch immer noch nicht mit dem GPLV3 kompatibel. Die gesamte Tortur ist besonders interessant, da einige nicht so nette Parteien begonnen haben, eine Lizenz zu durchführen, die durch GPL -Lizenzen trollt.
  16. ^ Sind Sie sicher, dass Sie die GPL verwenden möchten? Von Armin Ronacher (2009)
  17. ^ Medizinische Software teilen: FOSS -Lizenzierung in der Medizin auf freesoftwaremagazine.com von Fred Trotter (2007-06-14)
  18. ^ "David A. Wheelers Blog". dwheeler.com.
  19. ^ Github nimmt schließlich Open Source -Lizenzen ernst auf InfoWorld von Simon Phipps am Juli 2013
  20. ^ Die Auswahl einer Open -Source -Lizenz muss nicht beängstigend sein. Welche der folgenden Aussagen beschreibt Ihre Situation am besten? auf choosealicense.com (abgerufen 2015-11-29)
  21. ^ Open -Source -Lizenznutzung auf Github.com am 9. März 2015 von Ben Balter auf Github.com "MIT 44,69%, [...] GPLV2 12,96%, Apache 11,19%, GPLV3 8,88%"
  22. ^ Ed Burnette (2. November 2006). "Google sagt nein, um Proliferation zu lizenzieren". Archiviert von das Original am 24. Februar 2007. Abgerufen 11. September, 2010.
  23. ^ Greg Stein (28. Mai 2009). "Gegen Lizenzverbreitung stehen". Archiviert von das Original am 1. Juni 2008. Abgerufen 11. September, 2010.
  24. ^ Lizenzproliferation - weniger ist mehr, einer ist am besten Am 27. Januar 2009 von Ernest M. Park "Chris Dibona aus Google erlitt die Schleudern und Pfeile der OSS -Community, als er die AGPLV3 -Lizenz für Google Code Repository ablehnte, unter Berufung auf die Lizenz -Proliferation als einen der Gründe."
  25. ^ Chris Dibona (10. September 2010). "Lizenzentwicklung und Hosting -Projekte auf Code.google.com". Abgerufen 11. September, 2010.
  26. ^ OSI genehmigte Lizenzen auf OpenSource.org
  27. ^ Lizenzprojekt auf OpenSource.com (2004)
  28. ^ Lizenzverlösungsbericht Archiviert 2012-12-12 bei der Wayback -Maschine auf OpenSource.com (2007)
  29. ^ Die früheste archivierte Version der Lizenzliste spiegelt diese Position wider. Bradley M. Kuhn (15. August 2000). "Verschiedene Lizenzen und Kommentare zu ihnen". Kostenlose Software -Stiftung. S. 37–39. Archiviert von das Original am 15. August 2000. Abgerufen 29. November, 2015.
  30. ^ Wie GPLV3 die Lizenzverbreitung angeht auf LinuxDevices.com
  31. ^ Marson, Ingrid (31. März 2005). "Intel, um keine Open-Source-Lizenz zu verwenden". cnet.com. CNET. Abgerufen 6. Oktober, 2014.
  32. ^ Der Mythos der Open -Source -Lizenzverbreitung auf the451group.com
  33. ^ Open Source -Lizenz Verbreitung: Hilfreiche Vielfalt oder hoffnungslose Verwirrung? über Law.Washington.edu von Robert W. Gomulkiewicz am 2009
  34. ^ Lizenzkompatibilität auf osscc.net

Externe Links