Freie Softwarelizenz - Free-software license

Das freie Software-Lizenzierungsspektrum und einige Beispiele für Programme unter diesen Lizenzen

Eine Freie-Software-Lizenz ist ein Hinweis, der dem Empfänger einer Software umfassende Rechte einräumt , diese Software zu ändern und weiterzugeben . Diese Handlungen sind normalerweise durch das Urheberrecht verboten , aber der Rechteinhaber (normalerweise der Autor) einer Software kann diese Einschränkungen aufheben, indem er der Software eine Softwarelizenz beifügt, die dem Empfänger diese Rechte einräumt. Software, die eine solche Lizenz verwendet, ist freie Software (oder freie und Open-Source-Software ), wie sie vom Urheberrechtsinhaber übertragen wurde. Freie Softwarelizenzen werden auf Software in Quellcode- und auch binäre Objektcode- Form angewendet , da das Urheberrecht beide Formen anerkennt.

Vergleich

Arten von Softwarelizenzen und ähnlichen Lizenzen. Die hervorgehobenen Spalten sind freie Software .
Gemeinfrei und Äquivalente Zulässige Lizenz Copyleft (Schutzlizenz) Nichtkommerzielle Lizenz Proprietäre Lizenz Geschäftsgeheimnis
Beschreibung Gewährt alle Rechte Gewährt Nutzungsrechte, einschließlich Recht zur Neulizenzierung (erlaubt Eigentumsrechte , Lizenzkompatibilität ) Gewährt Nutzungsrechte, verbietet Eigentumsrechte Gewährt nur Rechte zur nicht-kommerziellen Nutzung. Kann mit Copyleft kombiniert werden. Traditionelle Nutzung des Urheberrechts ; es müssen keine Rechte gewährt werden Es werden keine Informationen veröffentlicht
Software PD, CC0 MIT , Apache , MPL GPL , AGPL JRL , AFPL proprietäre Software , keine öffentliche Lizenz private, interne Software
Andere kreative Werke PD, CC0 CC-BY CC-BY-SA CC-BY-NC Urheberrecht , keine öffentliche Lizenz unveröffentlicht

Lizenzen für freie Software bieten eine Risikominderung gegen verschiedene rechtliche Bedrohungen oder Verhaltensweisen, die von Entwicklern als potenziell schädlich angesehen werden:

Häufig verwendete Schutz- und Freizügigkeitslizenzen
AGPLv3 GPLv3 GPLv2.1 LGPLv3 LGPLv2.1 MPL-2 BSD
SaaS/Cloud Jawohl Nein Nein Nein Nein Nein Nein
Tivoisierung Jawohl Jawohl Nein Jawohl Nein Nein Nein
Patent-Trolling Jawohl Jawohl Nein Jawohl Nein Nein Nein
Eigentumsvorbehalt Jawohl Jawohl Jawohl Teilweise Teilweise Teilweise Nein
Granularität / Reichweite Projekt Projekt Projekt Bücherei Bücherei Datei N / A
Markenzuschuss Jawohl Jawohl ? Jawohl ? Nein Nein

Geschichte

Vor den 1980er Jahren

In den frühen Zeiten der Software war die gemeinsame Nutzung von Software und Quellcode in bestimmten Gemeinschaften, beispielsweise in akademischen Einrichtungen, üblich. Bevor die US Commission on New Technological Uses of Copyrighted Works (CONTU) im Jahr 1974 entschied, dass "Computerprogramme, soweit sie die Originalkreation eines Autors verkörpern, richtiger Gegenstand des Urheberrechts sind", galt Software nicht als urheberrechtlich geschützt. Daher waren der Software keine Lizenzen beigefügt und sie wurde als Public-Domain-Software geteilt . Die CONTU-Entscheidung sowie Gerichtsurteile wie Apple gegen Franklin im Jahr 1983 für Objektcode stellten klar, dass das Urheberrechtsgesetz Computerprogrammen den Urheberrechtsstatus literarischer Werke verlieh und die Lizenzierung von Software begann .

Freie Softwarelizenzen vor den späten 1980er Jahren waren im Allgemeinen informelle Mitteilungen, die von den Entwicklern selbst verfasst wurden. Diese frühen Lizenzen waren von der „ permissiven “ Art.

1980er Jahre

Mitte der 1980er Jahre produzierte das GNU-Projekt für jedes seiner Softwarepakete freie Softwarelizenzen mit Copyleft . Eine frühe solche Lizenz (die "GNU Emacs Copying Permission Notice") wurde 1985 für GNU Emacs verwendet , die Ende 1985 in die "GNU Emacs General Public License" überarbeitet und im März 1987 und Februar 1988 geklärt wurde eine ähnliche GCC General Public License wurde auf die GNU Compiler Collection angewendet , die erstmals 1987 veröffentlicht wurde. Die ursprüngliche BSD-Lizenz ist auch eine der ersten freien Softwarelizenzen aus dem Jahr 1988. 1989, Version  1 der GNU General Public License (GPL) veröffentlicht. Die 1991 veröffentlichte Version  2 der GPL wurde zur am weitesten verbreiteten Lizenz für freie Software.

1990er bis 2000er

Ab Mitte der 1990er und bis Mitte der 2000er Jahre hat die Open-Source- Bewegung die Idee der freien Software in der breiten Öffentlichkeit und in der geschäftlichen Wahrnehmung vorangetrieben und fokussiert. In der Dot-Com - Blase Zeit, Netscape Communications Schritt 'seinen Web - Browser unter einer FOSS - Lizenz im Jahr 1998 zu veröffentlichen, inspirierte viele anderen Unternehmen auf das FOSS Ökosystem anzupassen. In diesem Trend haben Unternehmen und neue Projekte ( Mozilla , Apache Foundation und Sun , siehe auch diese Liste ) eigene FOSS-Lizenzen geschrieben oder bestehende Lizenzen angepasst. Diese Lizenzvermehrung wurde später aufgrund der zunehmenden Komplexität von Lizenzkompatibilitätsüberlegungen als Problem für das freie und Open-Source- Ökosystem erkannt . Während sich die Entwicklung neuer Lizenzen später verlangsamte, gelten die Lizenzverbreitung und ihre Auswirkungen als anhaltende ernsthafte Herausforderung für das freie und Open-Source-Ökosystem.

Von den Freie-Software-Lizenzen wurde die GNU GPL Version  2 zunächst in Deutschland 2004 und später in den USA gerichtlich geprüft. Im deutschen Fall diskutierte der Richter die Gültigkeit der GPL-Klauseln nicht ausdrücklich, sondern akzeptierte, dass die GPL eingehalten werden musste: "Wenn die GPL von den Parteien nicht vereinbart würde, würden der Beklagten trotzdem die erforderlichen Rechte zum Kopieren, Verbreiten" fehlen , und machen Sie die Software 'netfilter/iptables' öffentlich verfügbar." Da die Beklagte die GPL nicht einhielt, musste sie die Nutzung der Software einstellen. Der US-Fall ( MySQL vs Progress) wurde beigelegt, bevor ein Urteil gefällt wurde, aber bei einer ersten Anhörung sah Richter Saris "keinen Grund", dass die GPL nicht durchsetzbar sein würde.

Um 2004 argumentierte der Anwalt Lawrence Rosen in dem Essay Why the public domain is not a license Software könne nicht wirklich in die Public Domain übergehen und nicht als sehr freizügige FOSS-Lizenz interpretiert werden, eine Position, die von Daniel J. Bernstein und Andere. Im Jahr 2012 wurde der Streit endgültig beigelegt, als Rosen die CC0 als Open-Source-Lizenz akzeptierte , während er zugab, dass das Urheberrecht entgegen seinen früheren Behauptungen aufgehoben werden kann, gestützt durch Entscheidungen des Neunten Kreises .

Im Jahr 2007 wurde nach jahrelanger Diskussion des Entwurfs die GPLv3 als wichtiges Update der GPLv2 veröffentlicht. Die Veröffentlichung war aufgrund des erheblich erweiterten Lizenzumfangs umstritten, der sie mit der GPLv2 inkompatibel machte. Mehrere große FOSS-Projekte ( Linux-Kernel , MySQL , BusyBox , Blender , VLC Media Player ) haben sich gegen die Einführung der GPLv3 entschieden. Auf der anderen Seite, im Jahr 2009, zwei Jahre nach der Veröffentlichung der GPLv3, Google Open-Source - Programm Office Manager berichtete Chris DiBona , dass die Anzahl von Open-Source - Projekten Software lizenziert, die GPLv3 von GPLv2 wurde 50%, das Zählen der bewegt hatte Projekte, die bei Google Code gehostet werden .

2010er Jahre

Im Jahr 2011, vier Jahre nach der Veröffentlichung der GPLv3, waren laut Black Duck Software-Daten 6,5% aller Open-Source-lizenzierten Projekte GPLv3, während 42,5% immer noch GPLv2 waren. Im Jahr 2011 argumentierte der 451 Group- Analyst Matthew Aslett in einem Blogbeitrag, dass Copyleft-Lizenzen zurückgingen und freizügige Lizenzen zunahmen, basierend auf Statistiken von Black Duck Software.

Im Jahr 2015 entthronte laut Black Duck Software und GitHub- Statistiken die permissive MIT-Lizenz die GPLv2 als beliebteste freie Software-Lizenz auf den zweiten Platz, während die permissive Apache-Lizenz bereits auf Platz drei folgt. Im Juni 2016 ergab eine Analyse der Pakete des Fedora-Projekts als am häufigsten verwendete Lizenzen die GPL, MIT, BSD und die LGPL .

Definitionen

Von OSI genehmigte Open-Source-Lizenzen

Die Gruppe Open Source Initiative (OSI) definiert und pflegt eine Liste genehmigter Open-Source-Lizenzen . OSI stimmt mit der FSF bei allen weit verbreiteten Lizenzen für freie Software überein, weicht jedoch von der Liste der FSF ab, da sie eher der Open Source Definition als der Free Software Definition zustimmt . Sie betrachtet die Freie-Software-Lizenzgruppe als Referenzimplementierung einer Freie-Software-Lizenz. Daher sind die Anforderungen für die Genehmigung von Lizenzen unterschiedlich.

Von der FSF genehmigte freie Softwarelizenzen

Die Free Software Foundation , die Gruppe, die die Free Software Definition pflegt, führt eine nicht erschöpfende Liste von Lizenzen für freie Software.

Die Free Software Foundation bevorzugt für die meisten Zwecke eine Copyleft -Lizenzierung für freie Software ( Share-Alike ) gegenüber einer freizügigen Lizenzierung für freie Software. Seine Liste unterscheidet zwischen freien Softwarelizenzen, die mit der Copyleft- GNU General Public License der FSF kompatibel oder nicht kompatibel sind .

Bedingungen in Lizenzen für freie Software

Innerhalb der Freie-Software-Gemeinschaft gibt es eine anhaltende Debatte über den schmalen Grat zwischen den Einschränkungen, die angewendet werden können und die immer noch als "frei" bezeichnet werden.

Nur „ Public-Domain-Software “ und Software unter einer Public-Domain-ähnlichen Lizenz ist frei von Beschränkungen. Beispiele für Public-Domain-ähnliche Lizenzen sind beispielsweise die WTFPL- und die CC0- Lizenz. Permissive Lizenzen können kleine Verpflichtungen wie die Namensnennung des Autors mit sich bringen, erlauben aber praktisch alle Anwendungsfälle von Code. Bestimmte Lizenzen, namentlich die Copyleft-Lizenzen , enthalten bewusst stärkere Beschränkungen (insbesondere bezüglich des Vertriebs/Vertriebs), um abgeleitete Projekte zu zwingen, bestimmte Rechte zu garantieren, die nicht weggenommen werden können.

Copyleft

Die Share-Alike-Lizenzen für freie Software, die Mitte der 1980er Jahre von Richard Stallman geschrieben wurden, waren der Wegbereiter eines Konzepts, das als "Copyleft" bekannt ist. Nachfolgende Copyleft-Bestimmungen besagen, dass modifizierte Versionen freier Software unter den gleichen Bedingungen wie die Originalsoftware vertrieben werden müssen. Daher werden sie auch als „share and share alike “ oder „ quid pro quo “ bezeichnet. Dies führt dazu, dass auch die neue Software Open Source ist. Da Copyleft sicherstellt, dass spätere Generationen der Software die Freiheit gewähren, den Code zu modifizieren, handelt es sich um "freie Software". Nicht-Copyleft-Lizenzen stellen nicht sicher, dass spätere Generationen der Software kostenlos bleiben.

Entwickler, die GPL-Code in ihrem Produkt verwenden, müssen den Quellcode jedem zugänglich machen, wenn sie den Objektcode teilen oder verkaufen . In diesem Fall muss der Quellcode auch alle Änderungen enthalten, die die Entwickler vorgenommen haben. Wenn GPL-Code verwendet, aber nicht weitergegeben oder verkauft wird, muss der Code nicht verfügbar gemacht werden und alle Änderungen können privat bleiben. Dies ermöglicht Entwicklern und Organisationen, GPL-Code für private Zwecke zu verwenden und zu ändern (d. h. wenn der Code oder das Projekt nicht verkauft oder anderweitig weitergegeben wird), ohne ihre Änderungen der Öffentlichkeit zugänglich zu machen.

Befürworter der GPL behaupten, dass sie das Wachstum freier Software fördert und eine gleichberechtigte Beteiligung aller Benutzer erfordert, indem sie vorschreibt, dass abgeleitete Werke unter der GPL bleiben. Gegner der GPL behaupten, dass "keine Lizenz die zukünftige Softwareverfügbarkeit garantieren kann" und dass die Nachteile der GPL ihre Vorteile überwiegen. Einige argumentieren auch, dass die Beschränkung der Verbreitung die Lizenz weniger frei macht. Wohingegen Befürworter argumentieren würden, dass die Freiheit während der Verteilung nicht so frei wäre, dass sie weniger frei würde. Zum Beispiel gewährt eine Nicht-Copyleft-Lizenz dem Autor nicht die Freiheit, modifizierte Versionen seines oder ihres Werkes zu sehen, wenn es öffentlich veröffentlicht wird, während eine Copyleft-Lizenz diese Freiheit gewährt.

Patentvergeltung

In den 1990er Jahren begannen freie Softwarelizenzen mit Klauseln wie Patentvergeltung , um sich vor Softwarepatentstreitigkeiten zu schützen – ein Problem, das es zuvor nicht gegeben hatte. Diese neue Bedrohung war einer der Gründe für das Schreiben von Version  3 der GNU GPL im Jahr 2006. In den letzten Jahren beschreibt der Begriff tivoization einen Prozess, bei dem Hardwarebeschränkungen verwendet werden, um zu verhindern, dass Benutzer modifizierte Versionen der Software auf dieser Hardware ausführen wofür das TiVo- Gerät ein Beispiel ist. Es wird von der FSF als eine Möglichkeit angesehen, freie Software effektiv unfrei zu machen, und deshalb haben sie sich entschieden, sie in der GPLv3 zu verbieten . Die meisten seit Ende der 1990er Jahre neu geschriebenen Lizenzen für freie Software enthalten eine Form von Patentvergeltungsklauseln. Diese Maßnahmen sehen vor, dass die Rechte aus der Lizenz (z. B. auf Weiterverteilung) unter bestimmten Umständen beendet werden können, wenn versucht wird, Patente in Bezug auf die lizenzierte Software durchzusetzen. Beispielsweise kann die Apple Public Source License die Rechte eines Benutzers beenden, wenn dieser Benutzer wegen eines Patentstreits ein Gerichtsverfahren gegen ihn einleitet. Als Reaktion auf die Verbreitung und den Missbrauch von Softwarepatenten kam es zu Patentvergeltung .

Hardware-Einschränkungen

Version  3 der GNU GPL enthält eine spezielle Sprache, die es verbietet, zusätzliche Einschränkungen durch Hardwarebeschränkungen und Digital Rights Management (DRM) durchzusetzen , eine Praxis, die FSF als Tivoization bezeichnet, nachdem Tivo GPL-Software auf Geräten verwendet hat, die eine Änderung dieser Software durch den Benutzer nicht erlaubten.

Namensnennung, Haftungsausschlüsse und Hinweise

Die Mehrheit der Lizenzen für freie Software setzt voraus, dass modifizierte Software nicht den Anspruch hat, unverändert zu sein. Einige Lizenzen erfordern auch die Nennung der Urheberrechtsinhaber. Ein solches Beispiel ist Version  2 der GNU GPL, die verlangt, dass interaktive Programme, die Garantie- oder Lizenzinformationen drucken, diese Hinweise nicht aus modifizierten Versionen entfernen dürfen, die für die Verbreitung bestimmt sind.

Praktische Probleme mit Lizenzen

Lizenzkompatibilität

Lizenzkompatibilität zwischen gängigen FOSS- Softwarelizenzen nach David A. Wheeler (2007): die Vektorpfeile bezeichnen eine unidirektionale Kompatibilität, daher bessere Kompatibilität auf der linken Seite ("permissive license") als auf der rechten Seite ("copyleft licenses")

Lizenzen von Softwarepaketen mit widersprüchlichen Anforderungen machen es unmöglich, Quellcode aus solchen Paketen zu kombinieren, um neue Softwarepakete zu erstellen. Die Lizenzkompatibilität zwischen einer Copyleft-Lizenz und einer anderen Lizenz ist oft nur eine unidirektionale Kompatibilität. Diese Eigenschaft der "Einwegkompatibilität" wird beispielsweise von der Apache Foundation kritisiert , die die freizügigere Apache-Lizenz anbietet, die diese Eigenschaft nicht hat. Nicht-Copyleft-Lizenzen, wie z. B. die freizügigen FOSS- Lizenzen , haben eine weniger komplizierte Lizenzinteraktion und weisen normalerweise eine bessere Lizenzkompatibilität auf. Wenn zum Beispiel eine Lizenz sagt "modifizierte Versionen müssen die Entwickler in allen Werbematerialien erwähnen" und eine andere Lizenz sagt "modifizierte Versionen dürfen keine zusätzlichen Anforderungen an die Namensnennung enthalten", dann, wenn jemand ein Softwarepaket kombiniert, das eine Lizenz verwendet, mit einem Softwarepaket die die andere verwendet, wäre es unmöglich, die Kombination zu verteilen, da diese widersprüchlichen Anforderungen nicht gleichzeitig erfüllt werden können. Somit wären diese beiden Pakete lizenzinkompatibel. Wenn es darum geht , Copyleft - Software - Lizenzen, sind sie mit anderen Copyleft - Lizenzen nicht von Natur aus kompatibel, auch die GPLv2 ist, von selbst, nicht mit der GPLv3 kompatibel.

Anwendungszweck

Einschränkungen bei der Nutzung einer Software ("Nutzungsbeschränkungen") sind gemäß der FSF-, OSI- , Debian- oder BSD-basierten Distributionen im Allgemeinen nicht akzeptabel . Beispiele hierfür sind das Verbot der Verwendung der Software für nicht-private Anwendungen, für militärische Zwecke, zum Vergleich oder Benchmarking, für den guten Gebrauch, für ethisch fragwürdige Zwecke oder in kommerziellen Organisationen. Während einige Beschränkungen der Benutzerfreiheit, zB in Bezug auf einen Atomkrieg, von den meisten Entwicklern freier Software moralisch unterstützt zu werden scheinen, wird allgemein angenommen, dass solche Agenden nicht durch Softwarelizenzen bedient werden sollten; unter anderem wegen praktischer Aspekte wie daraus resultierende Rechtsunsicherheiten und Probleme bei der Durchsetzbarkeit von vagen, weiten und/oder subjektiven Kriterien oder weil Werkzeugmacher generell nicht für die Verwendung ihrer Werkzeuge durch andere Personen verantwortlich gemacht werden. Dennoch beinhalten einige Projekte rechtlich unverbindliche Aufforderungen an den Benutzer, allen voran SQLite . Zu den wiederholten Versuchen von Entwicklern, das Benutzerverhalten durch die Lizenz zu regulieren, die eine breitere Debatte auslösten, gehört Douglas Crockfords (scherzhafter) „No Evil“-Klausel, die den Veröffentlichungsprozess der Debian-Distribution im Jahr 2012 beeinflusste und zum Ausschluss des JSMin-PHP-Projekts führte von Google Code , die Aufnahme einer pazifistischen Bedingung basierend auf Asimovs First Law of Robotics in die GPL für die verteilte Computersoftware GPU im Jahr 2005 sowie mehrere Softwareprojekte, die versuchen, die Nutzung durch große Cloud-Anbieter auszuschließen.

Definitionskonflikte

Da es mehrere definierende Organisationen und Gruppen gibt, die Definitionen und Richtlinien zu FOSS-Lizenzen veröffentlichen, insbesondere die FSF, das OSI, das Debian-Projekt und die BSDs, gibt es manchmal widersprüchliche Meinungen und Interpretationen.

Permissive versus Copyleft-Meinungen

Viele Benutzer und Entwickler von BSD- basierten Betriebssystemen haben eine andere Position zur Lizenzierung. Der Hauptunterschied besteht darin, dass die Copyleft- Lizenzen, insbesondere die GNU General Public License (GPL), unerwünscht kompliziert und/oder restriktiv sind. Die GPL erfordert, dass alle abgeleiteten Werke auch gemäß der GPL veröffentlicht werden, während dies bei der BSD-Lizenz nicht der Fall ist. Im Wesentlichen besteht die einzige Anforderung der BSD-Lizenz darin, die ursprünglichen Autoren anzugeben, und stellt keine Beschränkungen dar, wie der Quellcode verwendet werden darf.

Dadurch kann BSD-Code in proprietärer Software verwendet werden , die nur die Autoren anerkennt. Zum Beispiel haben Microsoft Windows NT 3.1 und macOS proprietäre IP-Stacks, die von BSD-lizenzierter Software abgeleitet sind. Im Extremfall können die Unter- oder Neulizenzierungsmöglichkeiten mit BSD oder anderen freizügigen Lizenzen eine weitere Nutzung im Open-Source-Ökosystem verhindern. Zum Beispiel MathWorks FileExchange 'Repository bietet die BSD - Lizenz für die Beiträge des Benutzers aber verhindert mit zusätzlichen Nutzungsbedingungen jede Nutzung neben ihrer eigenen proprietären MATLAB - Software, zum Beispiel mit der FOSS GNU Octave - Software.

Positiv ist zu vermerken, dass BSD-ähnliche permissive Lizenzen sehr begrenzte Einschränkungen haben (normalerweise nur Attribution ), sie haben auch eine ausgezeichnete Lizenzkompatibilität , sogar mit Copyleft-Lizenzen.

Befürworter der BSD-Lizenz argumentieren, dass sie freier als die GPL ist, da sie das Recht einräumt, alles mit dem Quellcode zu tun, vorausgesetzt, die Namensnennung bleibt erhalten. Beispielsweise könnten Benutzer den BSD-lizenzierten Code in proprietäre Produkte integrieren. Der Ansatz hat dazu geführt, dass BSD-Code in gängiger, weit verbreiteter proprietärer Software verwendet wird. Als Reaktion darauf weisen Befürworter der GPL darauf hin, dass Benutzern, sobald Code proprietär wird, die Freiheiten fehlen, die freie Software definieren. Aus diesem Grund betrachten sie die BSD-Lizenz als weniger frei als die GPL, und diese Freiheit ist mehr als ein Mangel an Beschränkungen. Da die BSD-Lizenz das Recht von Entwicklern einschränkt, Änderungen in die Community einbringen zu lassen, ist weder sie noch die GPL "frei" im Sinne von "ohne Einschränkungen".

Code, der unter einer freizügigen freien Softwarelizenz wie der BSD-Lizenz lizenziert ist, kann in Projekte mit Copyleft (z. B. GPL'd) integriert werden. Ein solcher Code ist somit "GPL-kompatibel". Es ist nicht erforderlich, die Zustimmung der ursprünglichen Autoren einzuholen. Im Gegensatz dazu Code unter der GPL kann nicht neu lizenziert unter der BSD - Lizenz ohne Sicherung die Zustimmung aller Rechteinhaber. Somit sind die beiden Lizenzen kompatibel, aber (sofern eine solche Zustimmung nicht eingeholt wurde) muss die Kombination als Ganzes unter den Bedingungen der GPL und nicht der freizügigen Lizenz vertrieben werden.

Bestehende freie Software BSD-lizenzierte Projekte neigen dazu, Software, die unter der GPL lizenziert ist, in das Kernbetriebssystem oder das Basissystem aufzunehmen , außer als letzter Ausweg, wenn Alternativen nicht existieren oder erheblich weniger leistungsfähig sind, wie bei GCC . Zum Beispiel wurde der GCC ab FreeBSD  10.0 durch den Clang / LLVM- Compiler ersetzt, vielleicht hauptsächlich aus diesem Grund. Das OpenBSD- Projekt hat gehandelt, um GPL-lizenzierte Tools zugunsten von BSD-lizenzierten Alternativen zu entfernen, einige neu geschrieben und andere von älterem Code angepasst.

Debian

Das Debian- Projekt verwendet die Kriterien, die in seinen Debian-Richtlinien für Freie Software (DFSG) dargelegt sind. Die einzigen bemerkenswerten Fälle, in denen Debian und die Free Software Foundation uneinig sind, sind die Artistic License und die GNU Free Documentation License (GFDL). Debian akzeptiert die ursprüngliche künstlerische Lizenz als freie Softwarelizenz, aber FSF ist anderer Meinung. Dies hat jedoch nur sehr geringe Auswirkungen, da die Artistic License fast immer zusammen mit der GNU General Public License in einem Dual-Lizenz- Setup verwendet wird .

Umstrittene Grenzfälle

Die überwiegende Mehrheit der freien Software verwendet unbestrittene Lizenzen für freie Software; Es gab jedoch viele Debatten darüber, ob bestimmte andere Lizenzen für die Definition in Frage kommen oder nicht.

Beispiele für Lizenzen, die Diskussionen auslösten, waren die 1.x-Serie der Apple Public Source License , die von der Open Source Initiative akzeptiert wurde, aber nicht von der Free Software Foundation oder Debian und die RealNetworks Public Source License , die von der Open Source Initiative akzeptiert wurde und Free Software Foundation, aber nicht von Debian .

Außerdem wurde die von der FSF empfohlene GNU Free Documentation License , die mit der GPL inkompatibel ist, vom Debian- Projekt um 2006, Nathanael Nerode und Bruce Perens , als "unfrei" angesehen . Die FSF argumentiert, dass sich Dokumentation qualitativ von Software unterscheidet und anderen Anforderungen unterliegt. Debian akzeptierte in einer späteren Resolution, dass die GNU FDL den Debian-Richtlinien für Freie Software entsprach, als der umstrittene "invariante Abschnitt" entfernt wurde, betrachtet ihn jedoch als "noch nicht störungsfrei". Ungeachtet dessen enthält die meiste GNU-Dokumentation "invariante Abschnitte". In ähnlicher Weise beschloss die FLOSS Manuals Foundation, eine Organisation, die sich der Erstellung von Handbüchern für freie Software widmet, im Jahr 2007, die GFDL zugunsten der GPL für ihre Texte zu meiden, unter Berufung auf die Inkompatibilität zwischen den beiden, Schwierigkeiten bei der Implementierung der GFDL und die Tatsache, dass die GFDL "erlaubt keine einfache Vervielfältigung und Änderung", insbesondere für die digitale Dokumentation.

SLUC ist eine im Dezember 2006 in Spanien veröffentlichte Softwarelizenz, die alle außer militärischen Nutzungen erlaubt. Die Autoren der Lizenz behaupten, dass es sich um freie Software handelt, aber die Free Software Foundation sagt, dass sie nicht frei ist, weil sie die sogenannte "Nullfreiheit" der GPL verletzt, dh die Freiheit, die Software für jeden Zweck zu verwenden.

Marktanteil

Während die GPLv2 in der Vergangenheit die am weitesten verbreitete FOSS- Lizenz war, hat die freizügige MIT-Lizenz laut Black Duck Software die GPLv2 im Jahr 2015 auf den zweiten Platz entthront, während die freizügige Apache-Lizenz auf dem dritten Platz folgt. Eine Studie aus dem Jahr 2012, die öffentlich zugängliche Daten verwendet, kritisierte Black Duck Software dafür, dass sie ihre bei der Erhebung von Statistiken verwendete Methodik nicht veröffentlichte. Daniel German, Professor am Department of Computer Science der University of Victoria in Kanada, hielt 2013 einen Vortrag über die methodischen Herausforderungen bei der Bestimmung der am weitesten verbreiteten Freie-Software-Lizenzen und zeigte, wie er das Ergebnis nicht replizieren konnte Black Duck-Software.

Eine GitHub- Studie im Jahr 2015 zu ihren statistischen Daten ergab, dass die MIT-Lizenz die bekannteste FOSS-Lizenz auf dieser Plattform war.

Im Juni 2016 zeigte eine Analyse der Pakete des Fedora-Projekts als am häufigsten verwendete Lizenzen die GPL-Familie, gefolgt von MIT, BSD, der LGP-Familie, Artistic (für Perl-Pakete), LPPL (für Texlive- Pakete) und ASL. Die GNU GPLv2+ war die beliebteste Einzellizenz

Siehe auch

Anmerkungen

Verweise

Externe Links