Open Source Lizenzvergleich

Kurz : Diese ausführliche Anleitung bietet Ihnen einen effektiven Vergleich von Open Source-Lizenzen. Die hier erläuterten Open Source-Lizenzen sollen Ihnen bei der Auswahl der richtigen Open Source-Lizenz für Ihr Projekt helfen.

Sie arbeiten also eine Weile an diesem coolen neuen Projekt - und sind jetzt bereit für den entscheidenden Wechsel von Closed Source zu Open Source .

Es scheint nicht viel mehr Arbeit zu sein, als die Quellen und den Commit-Verlauf zu bereinigen, bevor Sie Ihr Repository auf GitHub oder Bitbucket verschieben ... ... bis die Frage nach der Lizenz auftaucht. Es gibt so viele Möglichkeiten. Welches soll ich wählen? Und brauchen Sie wirklich eine Lizenz?

Die kurze Antwort auf letztere Frage ist einfach: Ja, Sie benötigen wirklich eine Lizenz. Was die Lizenz angeht, die Sie benötigen, kann ich sogar eine kürzere Antwort geben: Es kommt darauf an .

Aber wenn Sie es mit Ihrem Projekt ernst meinen, möchten Sie wahrscheinlich ein bisschen mehr Details. Lesen Sie weiter - und denken Sie daran: Sie betreten jetzt das Gebiet des Heiligen Krieges!

Benötige ich eine Lizenz? Und was ist eigentlich eine Lizenz?

Eine Lizenz ist eine offizielle Erlaubnis, die der Eigentümer eines Werks (der „Lizenzgeber“) anderen Personen (dem „Lizenznehmer“) erteilt und regelt, wie der Lizenznehmer das Werk des Lizenzgebers nutzen darf.

Dies erfolgt in Form eines Vertrages, dem beide Parteien zustimmen müssen. Heutzutage ist die Annahme eher implizit: Allein durch die Nutzung von Work stimmen Sie der Nutzungslizenz zu.

Nur um zu verdeutlichen, dass Sie der Lizenzgeber sind, wenn Sie Ihre eigenen Werke freigeben. Und der Lizenznehmer, jeder, der Ihren Code verwendet. Im Großen und Ganzen umfasst dies zwei Hauptkategorien: Entwickler und Endbenutzer .

Um ein paar weitere Vokabeln zu ändern, erstellt ein Lizenznehmer ein sogenanntes Derivatives Werk. Es stimmen jedoch nicht alle Lizenzen überein, ob die Verwendung Ihres Werks in einem größeren Werk dieses als Derivativwerk qualifiziert oder nicht. Wie Sie unten sehen werden, sind einige Lizenzen speziell auf diese Probleme ausgerichtet.

Was ist der Zweck der Lizenz?

Grundsätzlich ist die Lizenz eine Möglichkeit für den Lizenzgeber und den Lizenznehmer, die Rechte und Pflichten beider zu vereinbaren. Diese mit einer Lizenz verbundenen Rechte und Pflichten können alles sein - bis zu dem Umfang, der gesetzlich zulässig ist . Beispielsweise kann ein Lizenzgeber verlangen, dass der Lizenznehmer bei der Verwendung seiner Arbeit seinen Namen angibt. Oder können autorisieren, ihre Arbeit zu kopieren, aber nicht in irgendeiner Weise zu ändern. Oder verlangen Sie, dass abgeleitete Werke zu denselben Bedingungen wie das Originalwerk veröffentlicht werden.

Andererseits ist die Lizenz eine Möglichkeit, den Lizenznehmer ebenfalls zu schützen. Durch die eindeutige Angabe, wie er Ihre Arbeit verwenden kann, besteht für ihn nicht die Gefahr, dass Sie unerwartet Lizenzgebühren oder eine andere Form der Entschädigung für die Verwendung Ihrer Arbeit verlangen. Etwas, das für Ihre Arbeitsübernahme entscheidend ist.

Die Lizenz schützt also Ihre Arbeit. Schützt den Lizenzgeber. Aber wird dich auch beschützen. Ich meine dich persönlich . Zum Beispiel durch Einschränkung der Haftung der Lizenzgeberin für mögliche Schäden, die durch ihre Arbeit verursacht werden.

Und wenn ich überhaupt keine Lizenz benutze?

In Abwesenheit einer Lizenz, die ausdrücklich mit einem Werk verbunden ist, gilt das „Standard“ -Rechtsrecht für die Gerichtsbarkeit des Urhebers. Mit anderen Worten, betrachten Sie das Fehlen einer Lizenz niemals als implizite Gewährung, damit wir mit Ihrer Arbeit tun können, was wir wollen. Dies ist genau das Gegenteil: Ohne eine bestimmte Lizenz haben Sie als Urheber auf KEINE Ihrer gesetzlich festgelegten Rechte verzichtet.

Denken Sie jedoch immer daran, dass eine Lizenz Rechte und Pflichten regelt. Haben Sie sich jemals gefragt, warum so viele Lizenztexte in ALLEN GROSSBUCHSTABEN einen Haftungsausschluss über die mit einem Produkt gewährten Garantien enthalten - oder häufiger über das Fehlen von Garantien? Dies dient dem Schutz des Werkbesitzers vor impliziten Garantien oder Benutzerannahmen. Das Letzte, was Sie wollen, ist, als Folge der Veröffentlichung Ihrer Arbeit als Open Source verklagt zu werden!

Kann ich eine benutzerdefinierte Lizenz verwenden?

Ja, du kannst. Aber das solltest du wahrscheinlich nicht.

Da es sich um einen Vertrag handelt, kann eine Lizenz (in den meisten Gerichtsbarkeiten? Alle?) Nicht Vorrang vor den regionalen Gesetzen haben. Daher die Schwierigkeit, die Lizenzrechte in einer globalisierten Welt durchzusetzen. Es wäre wahrscheinlich einfacher (ich meine, weniger schwierig), eine "Standard" -Lizenz vor einem Richter zu verteidigen. Tatsächlich wurden solche Fälle bereits in mehreren Gerichtsbarkeiten verteidigt und können als Präzedenzfälle angeführt werden. Offensichtlich etwas, das mit einer benutzerdefinierten Lizenz nicht möglich ist.

Darüber hinaus können benutzerdefinierte Lizenzen (manchmal auch als Vanity-Lizenzen bezeichnet) zu Inkompatibilitäten mit anderen Lizenzen führen, was rechtlich gesehen zu einer schlechten Kompatibilität Ihrer Arbeit führt.

Darf ich mehrere Lizenzen verwenden?

Ja. Multi-Licensing - insbesondere Dual-Licensing - ist keine Seltenheit. Dies gilt insbesondere dann, wenn Sie ein Geschäft rund um Ihre freie Arbeit aufbauen möchten. In diesem Fall wird Ihr Projekt wahrscheinlich sowohl unter einer FOSS-Lizenz als auch unter einer kommerziellen Lizenz veröffentlicht.

Eine weitere Verwendung der Mehrfachlizenzierung besteht in der Erhöhung der Kompatibilität, indem Ihre Arbeit mit Werken kombiniert werden kann, die unter verschiedenen Bedingungen veröffentlicht wurden, oder um unterschiedliche Benutzeranforderungen zu erfüllen. Dies ist ein Grund, warum einige Projekte unter mehreren FOSS-Lizenzen veröffentlicht werden.

Aber seien Sie gewarnt: Nicht alle Lizenzen sind miteinander kompatibel! Ich möchte Sie erneut davon abhalten, das Rad neu zu erfinden, indem Sie bei bekannten kompatiblen Lizenzen bleiben, wenn Sie diesen Weg einschlagen möchten.

Kann ich die Lizenz "später" ändern?

Ja. Der Inhaber des Urheberrechts ist für die Lizenzbedingungen verantwortlich. Es ist ziemlich einfach, die Lizenz zu ändern, solange Sie der einzige Mitwirkende sind. Aber um ein extremes Beispiel zu nehmen, wenn Linus Torvald den Linux-Kernel unter einer anderen Lizenz veröffentlichen möchte, würde er wahrscheinlich zuerst die Zustimmung von Tausenden von Mitwirkenden zu diesem Projekt benötigen. Etwas Unmögliches in der Praxis.

Für ein Projekt mit angemessener Größe kann dies durchgeführt werden. Und tatsächlich war es so, wie Sie in einigen Beispielen unten sehen werden.

Welche Open Source Lizenz soll ich verwenden?

Ok, jetzt sind Sie überzeugt, dass Sie eine Standardlizenz verwenden sollten. Aber welches soll ich wählen? Die endgültige Wahl liegt bei Ihnen. Und es gibt sehr gut gemachte Komparatoren im Internet, die Ihnen bei Ihrer Auswahl helfen. Um nur meine Favoriten zu zitieren:

  • //oss.ly/licdif
  • //choosealicense.com/ / //choosealicense.com/appendix/
  • //opensource.org/licenses
  • //tldrlegal.com/

Die endgültige Antwort wird jedoch, wie immer in Bezug auf rechtliche Angelegenheiten, darin bestehen, den maßgeblichen Text der Lizenz zu lesen und zu verstehen. Dies kann die Hilfe eines professionellen Anwalts erfordern. Sowas bin ich nicht.

Ich kann Ihnen jedoch eine Einführung in die gängigsten Lizenzen geben, um Sie bei Ihren ersten Schritten zu unterstützen.

GNU General Public License (GPL)

Die GPL ist eine der beliebtesten Open Source-Lizenzen. Es gibt mehrere Versionen - für ein neues Projekt sollten Sie jedoch die aktuellste Version in Betracht ziehen, nämlich die GPL 3, die zum Zeitpunkt des Schreibens dieses Dokuments verfügbar war.

Die GPL unterstützt ein starkes Copyleft und ist wahrscheinlich die am meisten schützende freie Softwarelizenz. Etwas, das je nach Ihrer Sichtweise gelobt oder kritisiert werden kann. Das Kernkonzept hinter der GPL, bei dem es sich um Derivative Work handelt, muss ebenfalls unter der GPL veröffentlicht werden.

  • Starkes Copyleft
  • Das Werk ist für den gewerblichen Gebrauch geeignet.
  • Lizenznehmer können die Arbeit ändern.
  • Lizenznehmer müssen die Quelle zusammen mit Derivative Work freigeben.
  • Abgeleitete Arbeiten müssen unter den gleichen Bedingungen freigegeben werden.

Beliebte Projekte

Die GPL ist die natürliche Lizenz für die Projekte der Free Software Foundation. Einschließlich der GNU-Tools, die das Herz eines jeden Linux-Systems bilden. Große Projekte - erst recht kommerzielle - verwenden die GPL in der Regel in Verbindung mit einer oder mehreren anderen Lizenzen.

  • Inkscape (Vektorzeichnung): GPLv2
  • Drupal (Web Content Management System): GPLv2
  • MariaDB (Datenbanken): GPL v2
  • MySQL (Datenbanken): GPL und kommerzielle Lizenz
  • Qt (plattformübergreifendes Anwendungsframework): LGPL, GPL und Commercial - je nach Modul und Servicevereinbarung

GNU Lesser General Public License (LGPL)

Die GPL ist in dem Sinne sehr restriktiv, dass sie die Veröffentlichung von Derivaten unter denselben Bedingungen als Open-Source-Version erzwingt. Dies betrifft insbesondere Bibliotheken, die Bausteine ​​für größere Software sind. Wenn Sie eine Bibliothek unter der GPL freigeben, wird jede Anwendung , die diese Bibliothek verwendet, auch als GPL freigegeben. Sowas spricht die LGPL an.

Für Bibliotheken unterscheidet die FSF drei Fälle:

  • Ihre Bibliothek implementiert einen Standard, der mit einem nicht freien Standard konkurriert. In diesem Fall hilft eine breite Akzeptanz Ihrer Bibliothek der freien Software. Die FSF schlägt die recht zulässige Apache-Lizenz für diesen Fall vor (weiter unten in diesem Artikel beschrieben).
  • Ihre Bibliothek implementiert einen Standard, der bereits von anderen Bibliotheken implementiert wurde. In diesem Fall hat die Freie Software keinen Vorteil, wenn sie auf Copyleft verzichtet. Die FSF empfiehlt daher die LGPL.
  • Wenn Ihre Bibliothek nicht mit anderen Bibliotheken oder anderen Standards konkurriert, empfiehlt die FSF die GPL.

Die Argumente der FSF sind meist ethisch und philosophisch. In der Praxis können Entwickler andere Bedenken haben. Vor allem, wenn sie planen, ein Geschäft auf der Grundlage der lizenzierten Arbeit zu entwickeln. Auch hier kann eine doppelte Lizenzierung in Betracht gezogen werden.

  • Schwaches Copyleft (gebunden an dynamisch verknüpfte Bibliothek)
  • Das Werk ist für den gewerblichen Gebrauch geeignet.
  • Lizenznehmer können die Arbeit ändern.
  • Lizenznehmer müssen die Quelle zusammen mit Derivative Work freigeben.
  • Wenn Sie das Werk ändern, müssen Sie das geänderte Werk unter denselben Bedingungen freigeben.
  • Wenn Sie das Werk verwenden, brauchen Sie das abgeleitete Werk nicht unter denselben Bedingungen freizugeben.

Beliebte Projekte

  • OpenOffice.org 3 (Office Suite): LGPLv3 - Apache OpenOffice 4 hat jedoch auf Apache License 2.0 umgestellt.
  • GTK +, das GIMP Toolkit (GUI Toolkit): LGPLv2.1
  • CUPS (Cross-Platform-Printing-System): GPL oder LGPLv2 mit Ausnahme von Apple-Betriebssystemen - abhängig von den Komponenten.
  • WineHQ (Windows-Kompatibilitätsebene): LGPLv2.1
  • GNU Aspell (Rechtschreibprüfung): LGPLv2.1

Eclipse Public License (EPL 1.0)

Mit einem schwächeren Copyleft als die LGPL ist die Eclipse-Lizenz wirtschaftsfreundlicher, da sie die Unterlizenzierung und Erstellung von Software aus EPL- und Nicht-EPL- (auch proprietärem) lizenziertem Code ermöglicht, vorausgesetzt, der Nicht-EPL-Code ist ein „separater“ Code Softwaremodul “ .

Darüber hinaus bietet die EPL den Mitwirkenden am EPL-Code zusätzlichen Schutz für den Fall von Rechtsstreitigkeiten / Schäden, die durch ein kommerzielles Angebot einschließlich dieses Werks verursacht werden.

  • Schwaches Copyleft (an Software „Modul“ gebunden)
  • Das Werk ist für den gewerblichen Gebrauch geeignet.
  • Die Lizenznehmer können die Arbeit ändern.
  • Wenn Sie das Werk ändern, müssen Sie das geänderte Werk unter denselben Bedingungen freigeben.
  • Wenn Sie das Werk verwenden, brauchen Sie das abgeleitete Werk nicht unter denselben Bedingungen freizugeben.
  • Kommerzielle Distributoren der Software müssen die ursprünglichen EPL-Mitarbeiter vor Rechtsstreitigkeiten / Schäden, die durch das kommerzielle Angebot verursacht werden, schützen oder entschädigen.

Beliebte Projekte

Offensichtlich ist die EPL die natürliche Lizenz für die Projekte der Eclipse Foundation. Einschließlich der beliebten Eclipse-IDE. Aber darüber hinaus hat es eine gewisse Popularität erlangt - insbesondere in der Java-Welt:

  • Clojure (Programmiersprache)
  • Graphviz (Graphvisualisierungspaket)
  • Anlegestelle (Anwendungsserver): Dual License EPL1.0 / Apache License 2.0 seit Anlegestelle 7
  • JUnit (Java Unit Testing Framework)

Mozilla Public License (MPL)

Die Mozilla Public License ist eine Lizenz für Software, die von der Mozilla Foundation entwickelt wurde. Aber es ist sicherlich nicht auf diesen Bereich beschränkt. Die MPL soll ein Kompromissschritt zwischen strengen Lizenzen (wie der GPL) und zulässigen Lizenzen (wie der MIT-Lizenz) sein.

In der MPL ist die "Lizenzierungseinheit" die Quelldatei. Lizenzgeber dürfen die Benutzerrechte und den Zugriff auf Dateien, die unter die MPL fallen, nicht einschränken. Das gleiche Projekt kann jedoch auch proprietäre Dateien ohne MPL-Lizenz enthalten. Das resultierende Projekt kann unter einer beliebigen Lizenz veröffentlicht werden, sofern der Zugriff auf die MPL-lizenzierten Dateien gewährt wird.

  • Schwaches Copyleft (an einzelne Dateien gebunden)
  • Das Werk ist für den gewerblichen Gebrauch geeignet.
  • Lizenznehmer können die Arbeit ändern.
  • Lizenznehmer müssen eine ordnungsgemäße Namensnennung für das Werk vorlegen.
  • Lizenznehmer können Derivative Work unter anderen Bedingungen weitergeben
  • Lizenznehmer können keine MPL-lizenzierten Quellen neu lizenzieren
  • Lizenznehmer müssen MPL-lizenzierten Quellcode zusammen mit ihren Derivativen Arbeiten vertreiben.

Beliebte Projekte

  • Mozilla Firefox (Webbrowser), Mozilla Thunderbird (E-Mail-Client): MPL
  • LibreOffice (Office-Suite): MPL2.0
  • H2 Database Engine (Datenbank): MPL2.0 und Eclipse License 1.0
  • Cairo (2D-Grafik-Engine): MPL 1.1 oder LGPLv2.1

Apache License 2.0 (ASL 2.0)

Mit der ASL betreten wir den Bereich der freien Lizenzen. Aber auch die FSF schlägt in einigen Fällen eine Apache-Lizenz vor. Die Apache-Lizenz ist zulässig, da keine abgeleiteten Werke unter denselben Bedingungen verbreitet werden müssen. Dies ist also eine Nicht-Copyleft-Lizenz.

Die ASL ist die einzige Lizenz, die für Projekte der Apache Software Foundation verwendet wird. Als unternehmensfreundlich erachtet, hat es eine weitverbreitete Akzeptanz außerhalb dieser Organisation gefunden. Es ist nicht ungewöhnlich, dass Enterprise-Projekte unter der ASL veröffentlicht werden.

  • Nicht-Copyleft
  • Das Werk ist für den gewerblichen Gebrauch geeignet.
  • Lizenznehmer können die Arbeit ändern.
  • Lizenznehmer müssen eine ordnungsgemäße Namensnennung für das Werk vorlegen.
  • Lizenznehmer können Derivative Work unter anderen Bedingungen weitergeben.
  • Lizenznehmer müssen den Quellcode nicht zusammen mit ihrem Derivative Work vertreiben.

Beliebte Projekte

  • Android (Betriebssystem): ASL 2.0 mit einigen Ausnahmen (insbesondere bezüglich des Linux-Kernels)
  • Apache httpd (Webserver): ASL 2.0
  • Apache Spark (Cluster Computing Framework): ASL 2.0
  • Spring Framework (Framework für Java-basierte Unternehmensanwendungen): ASL 2.0

MIT-Lizenz

Dies ist eine sehr beliebte Lizenz. Sogar der wahrscheinlich beliebteste. Durch die Beschränkung der Wiederverwendung kann die MIT-Lizenz problemlos mit anderen Lizenzen verknüpft werden, von der GPL bis zu proprietären Lizenzen.

  • Nicht-Copyleft
  • Das Werk ist für den gewerblichen Gebrauch geeignet.
  • Lizenznehmer können die Arbeit ändern.
  • Lizenznehmer müssen eine ordnungsgemäße Namensnennung für das Werk vorlegen.
  • Lizenznehmer können Derivative Work unter anderen Bedingungen weitergeben
  • Lizenznehmer müssen den Quellcode nicht zusammen mit ihrem Derivative Work vertreiben.

Beliebte Projekte

  • node.js (JavaScript-Laufzeitumgebung): MIT-Lizenz
  • jQuery (clientseitige JavaScript-Bibliothek): MIT-Lizenz (bis 2012 Dual-License MIT / GPL)
  • Atom (Texteditor): MIT-Lizenz
  • AngularJS (JavaScript-Anwendungsframework): MIT-Lizenz
  • SQLAlchemy (SQL-Toolkit und Object Relational Mapper für Python): MIT-Lizenz

BSD-Lizenzen

Die BSD-Lizenz gibt es in drei Varianten. Die ursprüngliche 4-Klausel-Lizenz, die überarbeitete 3-Klausel-Lizenz und die vereinfachte 2-Klausel-Lizenz. Alle im Geiste sind sehr nah an der MIT-Lizenz. In der Tat gibt es kaum praktische Unterschiede zwischen der 2-Klausel-BSD-Lizenz und der MIT-Lizenz.

3- und 4-Klausel-BSD-Lizenzen stellen zusätzliche Anforderungen an die Wiederverwendung von Namen und Werbung. Dies sollten Sie berücksichtigen, wenn Sie Ihr Produkt oder Ihren Markennamen schützen möchten.

  • Nicht-Copyleft
  • Das Werk ist für den gewerblichen Gebrauch geeignet.
  • Lizenznehmer können die Arbeit ändern.
  • Lizenznehmer müssen eine ordnungsgemäße Namensnennung für das Werk vorlegen.
  • Lizenznehmer können Derivative Work unter anderen Bedingungen weitergeben.
  • Lizenznehmer müssen den Quellcode nicht zusammen mit ihrem Derivative Work vertreiben.
  • Lizenznehmer können den ursprünglichen Autorennamen oder das ursprüngliche Warenzeichen nicht verwenden, um abgeleitete Arbeiten zu unterstützen (3- und 4-Klausel BSD).
  • Lizenznehmer müssen den Originalautor in allen Werbematerialien, in denen Merkmale oder die Verwendung des Werks erwähnt werden, angeben (4-Klausel-BSD).

Beliebte Projekte

  • Django (Web-Framework): 3-Klausel-BSD
  • Redis (Datenspeicher): 3-Klausel-BSD
  • Ruby (Programmiersprache): 2-Klausel-BSD und benutzerdefinierte Lizenz
  • Nginx (Webserver): 2-Klausel-BSD
  • NetBSD (Betriebssystem): 2-Klausel-BSD - 4-Klausel-BSD bis 2008

Das letzte Wort zu Open Source-Lizenzen

Wenn Sie so weit kommen, herzlichen Glückwunsch! Sie verstehen es jetzt, Lizenzierung ist wirklich ein riesiges und komplexes Thema. Es lohnt sich jedoch, sich die Zeit zu nehmen, um die richtige Lizenz für Ihr Projekt auszuwählen - und diese Entscheidung frühzeitig zu treffen. Sie könnten später viele Probleme ersparen, sodass Sie Ihre Zeit und Energie für Ihr Projekt verwenden können, anstatt sich mit Urheberrechts- oder Kompatibilitätsproblemen zu befassen.

Auch wenn ich mein Bestes getan habe, um dieses Thema zugänglich zu machen, ist es nicht immer einfach, die Feinheiten der verschiedenen Lizenzen zusammenzufassen. Abgesehen von den wenigen wichtigen Lizenzen, die hier vorgestellt werden, werden Dutzende andere mehr oder weniger häufig verwendet.

Zögern Sie also nicht, den Kommentarbereich unten zu verwenden, um uns mitzuteilen, welche Lizenz IHRE bevorzugte ist und warum. Oder um einige wichtige Eigenschaften zu erwähnen, die ich vielleicht vergessen habe!

Empfohlen

Xenlism WildFire: Minimales Icon-Theme für Linux Desktop
2019
Beschleunigen Sie Ubuntu Unity auf Low-End-Systemen
2019
MAUJ rüstet sich zum 30. Geburtstag der Free Software Foundation
2019