Entwicklerleitfaden zu Open-Source-Lizenzen

Nicht alle Open-Source-Lizenzen sind gleich. Einige von ihnen verpflichten den Softwarelieferanten, Benutzern und Entwicklern der Software Patentlizenzen zu erteilen. Andere Lizenzen verpflichten den Entwickler, der das lizenzierte Produkt oder die Bibliothek verwendet, den Quellcode dieses Produkts oder dieser Bibliothek unter den gleichen Bedingungen anzubieten. Andere geben den Code einfach weiter, ohne jegliche Gewährleistung oder Bedenken. In diesem Artikel werde ich versuchen, die Hauptunterschiede zwischen den am häufigsten verwendeten Open-Source-Lizenzen aus der Sicht eines Softwarebenutzers und eines Softwareentwicklers hervorzuheben.

Als Richard Stallman 1984 das GNU-Projekt zur Schaffung eines freien Betriebssystems begann, kam er auf die Idee zurück, dass Software zwischen Entwicklern, Ingenieuren und Benutzern geteilt werden sollte; und sie sollten in der Lage sein, es auf kollaborative Weise zu verbessern, so wie dies normalerweise in der Wissenschaft der Fall ist.

Diese Option stand im Gegensatz zu dem üblichen Konzept lizenzierter Software, das von den meisten Softwareunternehmen und -entwicklern zum Verteilen und Verkaufen ihrer Programme gewählt wurde. Heute, mehr als dreißig Jahre später, erobert Open-Source-Software langsam weiter weite Bereiche unserer Branche: Linux, Android, Apache und Git sind Beispiele für führende Open-Source-Produkte in ihren Kategorien.

Open Source oder Freie Software?

In diesem Artikel verwende ich die Begriffe „Open Source“ und „kostenlos“ als Synonyme, wenn ich mich auf Software oder Lizenzen beziehe. Meiner Meinung nach drücken beide Begriffe dieselbe Idee aus. „Open-Source“ drückt es praktisch und technisch aus, und mit „Free“ wird der Fokus auf eine philosophische und politische Bedeutung des Konzepts gelegt.

Leider bedeutet das Wort „kostenlos“ im Englischen nicht nur das Adjektiv, das mit „Freiheit“ assoziiert wird, sondern auch „ohne Kosten“. Das ist der Grund, warum ich normalerweise lieber „Open Source“ sage.

Gemeinsame Eigenschaften von Open-Source-Software

Ich nehme an, Sie haben bereits eine ungefähre Vorstellung davon, was Open-Source-Software ist. Aber da wir über die Details der verschiedenen Lizenzen sprechen werden, müssen wir zuerst über die spezifischen Eigenschaften sprechen, die Open-Source-Software definieren.

Vorweg: Ich bin kein Anwalt, und dies ist keine Rechtsberatung. Im Zweifelsfall wenden Sie sich bitte an den tatsächlichen Text der Lizenzen, von denen ich spreche, und an Ihren Rechtsberater.

Alle Open-Source-Software wird gemäß der Open-Source-Initiative unter einer Lizenz vertrieben, die ihren Benutzern und Entwicklern (den Lizenznehmern) einige Rechte einräumt. Die vollständige Liste kann in der Open-Source-Definition eingesehen werden, aber hier ist eine grundlegende Zusammenfassung:

1. Kostenlose Weiterverteilung der Software: Die Software kann als Produkt verkauft oder verschenkt oder in einem Softwarepaket enthalten sein. Dies ist ohne Zahlung von Lizenzgebühren möglich.
2. Der Quellcode der lizenzierten Software ist entweder in der Distribution enthalten, oder es gibt zumindest gut publizierte Mittel, um den Quellcode zu erhalten. Dieser Quellcode ist für die Entwicklung modifizierter Versionen der Software verwendbar.
3. Die Erstellung abgeleiteter Werke ist erlaubt, und die Lizenz erlaubt deren Verbreitung unter den gleichen Bedingungen und Lizenzen wie die Originalsoftware. Abhängig von der Lizenz der Originalsoftware müssen diese abgeleiteten Werke in einigen Fällen von der Originalsoftware durch Änderung ihres Namens oder ihrer Versionsnummer unterschieden werden oder können nur in Form von Quellcode-Patches vertrieben werden.
4. Die Software kann von jeder Person oder Personengruppe und in allen Tätigkeitsbereichen ohne Einschränkungen verwendet werden.

Sie müssen jedoch bedenken, dass Softwarelizenzen nur über die Verwendung oder Verbreitung von Genehmigungen sprechen, die von den Urheberrechtsinhabern gewährt wurden. Open-Source-Lizenzen können Ihnen erlauben, die Software oder abgeleitete Werke frei weiterzuverbreiten, aber diese Erlaubnis kann auch in einigen Ländern eingeschränkt sein, in denen der Export kryptografischer Software verboten ist. In ähnlicher Weise erlauben Ihnen Open-Source-Lizenzen, die Software für jeden Zweck zu verwenden, aber das bedeutet nicht, dass Sie sich mit Open-Source-lizenzierter Software in eine Bank hacken können. Softwarepatente sind ein weiteres Beispiel dafür: Einige Open-Source-Lizenzen gewähren die Erlaubnis, Patente frei zu nutzen, aber nicht alle.

Können wir also eine Open-Source-Software bei der Entwicklung eines Produkts oder Projekts verwenden? Grundsätzlich kommt es auf die Lizenz der verwendeten Software und die vorgesehene Lizenz für das Endprodukt an. Die unterschiedlichen Lizenzen spielen auch eine Rolle, wenn Sie Ihren eigenen Code als Open Source veröffentlichen möchten und Sie entscheiden, welche Lizenz Sie verwenden sollen.

Copyleft

Ein ziemlich interessantes Konzept über Open-Source-Lizenzen ist das, was üblicherweise als Copyleft bezeichnet wird, das Gegenteil von Urheberrecht. Wenn das Urheberrecht verwendet wird, um geistiges Eigentum (einschließlich Software) vor dem Kopieren oder Verteilen zu schützen, wird Copyleft verwendet, um sicherzustellen, dass geistiges Eigentum und Software aus Open-Source-Quellen als Open Source kopiert oder verteilt werden können.

Je nach Stärke gibt es zwei Arten von Copyleft:

• Starkes Copyleft: Wenn Werke, die von anderen Werken mit starker Copyleft-Lizenz abgeleitet sind oder mit diesen Werken verknüpft sind, weiterhin starke Copyleft-Lizenzen oder sogar genau dieselbe Lizenz haben müssen. Das heißt, diese Open-Source-Werke können in Zukunft nicht mehr geschlossen werden.
• Schwaches Copyleft: Wenn Werke, die lizenzierte Werke mit schwachem Copyleft verwenden oder damit verknüpft sind, unter anderen Lizenzen lizenziert werden können, sogar unter Closed-Source-Lizenzen. In diesem Fall wirkt sich das Copyleft nur auf das ursprünglich mit schwachem Copyleft lizenzierte Werk aus.

Es gibt auch Open-Source-Lizenzen ohne Copyleft: Sie kümmern sich einfach nicht um die zukünftige Offenheit abgeleiteter Software.

Freizügigkeit

Je nach Freizügigkeit können die Lizenzen auch eingeteilt werden in:

• Strenge Lizenzen: Wenn Sie stark lizenzierte Software nicht mit Closed-Source- oder sogar mit freizügiger lizenzierter Software mischen können.
• Freizügige Lizenzen: Wenn Produkte normalerweise mit Closed-Source-Software oder Software mit einer vollständigen Open-Source-Lizenz gemischt werden können.

Normalerweise sind starke Copyleft-Lizenzen auch streng, und schwache Copyleft-Lizenzen sind freizügiger, aber das muss nicht so sein.

Unterschiede bei Open-Source-Lizenzen

Es gibt viele Open-Source-Lizenzen. Mehr als 80 davon hat die Open Source Initiative bereits genehmigt. Einige sind redundant und könnten anderen als gleichwertig angesehen werden. Andere sind spezifisch für die Interessen des Softwareherausgebers (z. B. die NASA-Lizenz) oder für eine bestimmte Umgebung oder einen bestimmten Zweck (z. B. die Educational Community License oder die Open Font License).

Diese Verbreitung von Lizenzen basiert auf bestimmten Bedingungen in der Lizenz, die, zusätzlich zu den grundlegenden Open-Source-Eigenschaften, andere Verwendungen zulassen oder verbieten. Beispiele für diese zusätzlichen Bedingungen können sein:

• Art des Copylefts: schwach oder stark oder nicht vorhanden.
• Art der Freizügigkeit: freizügig oder streng.
• Die Verpflichtung, einen Urheberrechtsvermerk im Quellcode oder in der Benutzeroberfläche hinzuzufügen.
• Automatische Patenterteilung an die Lizenznehmer.
• Betrachtet man als Lizenznehmer nicht nur die Parteien, an die die Software vertrieben wird, sondern auch die Benutzer der Software (so dass Personen, die einen Dienst in der Cloud verwenden, der diese Art von Open-Source-Software verwendet, die Wahl haben sollten, den Quellcode von herunterzuladen die Software)

Problem des Mischens von Code mit unterschiedlichen Lizenzen

Wie wir bereits zuvor gesagt haben, sind einige Lizenzen freizügig, was den Benutzern erlaubt, den Code mit anders lizenziertem Quellcode (möglicherweise mit zusätzlichen Bedingungen) zu kombinieren. Dieser Fall würde es ermöglichen, diese Art von lizenzierter Open-Source-Software mit Closed-Source-Software zu mischen. Ein Beispiel für diese Art von Lizenz ist die MIT-Lizenz.

Andere sind restriktiver, sodass der Quellcode nur mit Code kombiniert werden kann, der auf ähnliche Weise lizenziert ist, und das Endergebnis muss mit derselben Originallizenz lizenziert werden. Ein Beispiel für diese Art von Lizenz ist die General Public License (GPL).

Vielleicht möchten Sie Code kombinieren, der mit zwei verschiedenen restriktiven Open-Source-Lizenzen lizenziert ist. Mit der Open-Source-Freiheit, die Software nach Belieben zu verwenden, können Sie dies tun. Das endgültige Programm kann jedoch nicht weiterverbreitet werden, da es unter zwei Lizenzen verteilt werden sollte, die nicht miteinander kompatibel sind.

Ein Beispiel für diese Situation war ZFS. ZFS ist ein sehr fortschrittliches und innovatives Dateisystem, das 2005 in OpenSolaris enthalten war. Es ist eine Open-Source-Software, die unter den Bedingungen der Common Development and Distribution License (CDDL) lizenziert ist. Obwohl es sich um Open-Source-Code handelt, kann er nicht in den Linux-Kernel integriert werden, da der Quellcode von Linux unter den Bedingungen der General Public License vertrieben wird, einer weiteren restriktiven Open-Source-Lizenz. Binärdateien des Linux-Kernels, die mit ZFS-Unterstützung kompiliert wurden, können aufgrund des Lizenzkonflikts nicht verteilt werden.

Solche Konflikte können nur gelöst werden, wenn sich alle Eigentümer eines der Open-Source-Programme darauf einigen, die Lizenz zu ändern oder Ausnahmebedingungen in die Softwarelizenz aufzunehmen. Zum Beispiel: Viele GPL-lizenzierte Programme sind mit der OpenSSL-Bibliothek verknüpft. Die Verteilung der OpenSSL-Bibliothek ist lizenziert und erfordert, dass ein Satz in Werbematerial und allen Weiterverteilungen erscheint. Diese zusätzlichen Bedingungen sind nicht mit der GPL kompatibel, und aus diesem Grund haben Entwickler von GPL-Produkten, die OpenSSL verwenden, eine Ausnahme in ihre Lizenz aufgenommen, die speziell die Verknüpfung mit OpenSSL erlaubt.

Unterschiedliche Merkmale von Open-Source-Lizenzen

Jetzt werde ich versuchen, die beliebtesten Open-Source-Lizenzen zu analysieren, ihre unterschiedlichen Merkmale anmerken und eine kleine Anleitung dazu geben, wann sie verwendet werden sollten oder nicht. Ich habe sie gemäß der Black Duck Knowledgebase von mehr zu weniger verwendet sortiert.

Allgemeine öffentliche GNU-Lizenz (GPL)

Die GPL ist die beliebteste Open-Source-Lizenz. Es wurde von der FSF als Lizenz für das GNU-Projekt erstellt und ist auch die Lizenz des Linux-Kernels.

Seine differenziellen Eigenschaften:

• Starkes Copyleft.
• Sehr strenge Lizenz.
• Dies wird normalerweise als „virale“ Lizenz bezeichnet: Wenn Sie Ihren Code mit einem anderen unter der GPL lizenzierten Code verlinken und die Ergebnisse verteilen möchten, muss das gesamte Produkt GPL-lizenziert sein.
• Es ist auch eine umfassende Lizenz: Wenn Sie eine Software entwickeln und sie unter der GPL lizenzieren möchten, können Sie sie verlinken oder andere Open-Source-Software einbinden, solange diese Software eine mit der GPL kompatible Lizenz hat. Es erfordert keine Verpflichtung, die nicht von der GPL verlangt wird.

Normalerweise enthält der verwendete Lizenztext den Text, der besagt, dass die Software unter den Bedingungen der GPL-Version N (oder einer späteren Version) vertrieben wird.

Derzeit werden zwei Versionen der GPL-Lizenz verwendet: v2 und v3. Die Version 3 wurde 2007 veröffentlicht, um einige Probleme zu beheben, die seit der Veröffentlichung von Version 2 im Jahr 1991 aufgetreten waren.

Die GPL v3 enthält einige zusätzliche Klauseln und Bedingungen, die sich mit Kompatibilitätsbestimmungen mit anderen Open-Source-Lizenzen befassen, die Patentlizenzierung verpflichten, die Bedingungen für die Verwendung von GPL-lizenzierter Software als Firmware in Geräten definieren und Konzepte wie die Verwaltung digitaler Rechte berücksichtigen.

MIT-Lizenz

Die Open-Source-Lizenz, die normalerweise als MIT-Lizenz, auch bekannt als X11-Lizenz, bekannt ist, ist eine sehr freizügige Nicht-Copyleft-Lizenz, die es jedem erlaubt, den so lizenzierten Code grundsätzlich für alles zu verwenden, was Sie wollen, solange Sie die Copyright-Meldung beibehalten und das wissen Die Software wird ohne jegliche Gewährleistung geliefert.

Diese Lizenz ist sehr beliebt und wird von mehreren Projekten wie dem X Window System, Ruby on Rails, jQuery oder Node.js verwendet.

Es ist mit der GPL kompatibel, sodass Sie MIT-lizenzierten Code in GPL-Software mischen können.

Apache-Lizenz 2.0

Die Apache-Lizenz wurde von der Apache Software Foundation (ASF) als Lizenz für ihren Apache HTTP-Server erstellt.

Genau wie die MIT-Lizenz ist es eine sehr freizügige Nicht-Copyleft-Lizenz, die es erlaubt, die Software für jeden Zweck zu verwenden, sie zu verteilen, zu modifizieren und abgeleitete Werke davon zu verteilen, ohne Rücksicht auf Lizenzgebühren zu nehmen. Die Hauptunterschiede zur MIT-Lizenz sind:

• Unter Verwendung der Apache-Lizenz erteilen die Autoren der Software jedem Benutzer oder Vertreiber des Codes Patentlizenzen. Diese Patentlizenzen gelten für alle Patente, die von einem der Softwareautoren lizenzierbar sind und durch den von ihnen erstellten Code verletzt würden.
• Die Apache-Lizenz erfordert, dass unveränderte Teile in abgeleiteten Werken die Lizenz behalten.
• In jeder lizenzierten Datei müssen alle ursprünglichen Urheberrechts-, Patent-, Marken- oder Namensnennungshinweise erhalten bleiben.
• Bei jeder lizenzierten Dateiänderung muss ein Hinweis erfolgen, dass Änderungen in der Datei vorgenommen wurden.
• Wenn die von Apache lizenzierte Software eine NOTICE-Datei enthält, müssen diese Datei und ihr Inhalt in allen abgeleiteten Werken erhalten bleiben.
• Wenn jemand absichtlich einen Beitrag für eine Apache-lizenzierte Software an deren Autoren sendet, kann dieser Beitrag automatisch unter der Apache-Lizenz verwendet werden.

Diese Lizenz ist wegen der automatischen Patentlizenz und der Klausel zur Beitragseinreichung interessant.

Es ist mit der GPL kompatibel, sodass Sie lizenzierten Apache-Code in GPL-Software mischen können.

BSD-Lizenz

Es gibt 3 verschiedene BSD-Lizenzen. Alle von ihnen sind sehr freizügige Lizenzen ohne Copyleft.

Die 2-Klausel-BSD-Lizenz (oder Vereinfachte BSD-Lizenz) entspricht vollständig der zuvor erläuterten MIT-Lizenz.

Die 3-Klausel-BSD-Lizenz (oder Neue BSD-Lizenz) fügt eine Klausel hinzu, die festlegt, dass weder der Name des Urheberrechtsinhabers noch die Namen seiner Mitwirkenden ohne ausdrückliche vorherige schriftliche Genehmigung verwendet werden dürfen, um von der Software abgeleitete Produkte zu unterstützen oder zu bewerben. Diese Version ist mit der GPL kompatibel und ermöglicht es Ihnen, 3-Klausel-BSD-lizenzierten Code in GPL-Software zu mischen.

Die 4-Klausel-BSD-Lizenz (oder Original-BSD-Lizenz) fügt eine weitere Klausel hinzu, die festlegt, dass alle Werbematerialien, die Funktionen oder die Verwendung der Software erwähnen, eine Bestätigung enthalten müssen, die besagt, dass das Produkt Software enthält, die vom Urheberrechtsinhaber entwickelt wurde. Diese 4-Klausel-BSD-Lizenz ist nicht mit der GPL kompatibel. Code mit dieser Lizenz kann gemäß den GPL-Bedingungen nicht neu lizenziert werden, da die vierte Klausel eine Anforderung hinzufügt, die in der GPL nicht erforderlich ist.

GNU Lesser General Public License (LGPL)

Die LGPL wurde von der FSF als Modifikation der GPL mit einem schwächeren Copyleft geschaffen, das die Verknüpfung von LGPL-lizenzierter Software mit beliebiger anderer Software ermöglicht. In ihren Ursprüngen stand LGPL für „Library General Public License“, nahm aber später ihren heutigen Namen „Lesser General Public License“ an, der für die Meinung der FSF steht, dass alle Software frei sein sollte und die LGPL deshalb nicht sein sollte allgemein verwendet.

Sie können Closed-Source-Code mit einer LGPL-Bibliothek oder -Software verknüpfen und die Endergebnisse verteilen, solange:

• Sie stellen den Quellcode des LGPL-Teils mit allen Änderungen bereit, die Sie daran vorgenommen haben.
• Jeder Benutzer mit genügend Wissen kann den LGPL-Teil des Programms durch eine modifizierte Version ersetzen. Dies kann durch Verteilen des LGPL-Teils des Programms als dynamische Bibliothek (DLL in Windows, .so in Linux/Unix) oder durch Bereitstellen des Objektcodes des nicht LGPL-Teils des Programms erfolgen.

LGPL v3 ist mit GPLv3 kompatibel, sodass Sie LGPLv3-Code in GPL-Software eingeben können.

Künstlerische Lizenz

Die Artistic License ist in ihrer aktuellen Version 2.0 eine freizügige Open-Source-Lizenz ohne Copyleft ähnlich der MIT-Lizenz.

Der Hauptunterschied zwischen der MIT-Lizenz und der künstlerischen Lizenz besteht darin, dass letztere erfordert, dass jede am Code vorgenommene Änderung klar angegeben werden muss.

Diese Lizenz wird fast ausschließlich in der Perl-Community verwendet.

Die aktuelle Artistic License 2.0 ist mit GPL kompatibel: Sie können künstlerisch lizenzierten Code in GPL-Software mischen.

Öffentliche Microsoft-Lizenz (MS-PL)

Die Microsoft Public License wurde 2008 von diesem Unternehmen als eine der Open-Source-Lizenzen erstellt, die von ihrer Shared Source Initiative erstellt wurden.

Es handelt sich um eine strenge, schwache Copyleft-Lizenz: Sie erlaubt die Erstellung und Verbreitung von Closed-Source-Programmen mit MS-PL-Code, verpflichtet jedoch dazu, die MS-PL als Lizenz abgeleiteter Werke zu verwenden, wenn diese im Quellcode vertrieben werden.

Ich persönlich denke, dass diese Lizenz ein bisschen pervers ist und dem Geist von Open Source widerspricht, indem sie das Schließen von Code erlaubt, so dass sich der Urheberrechtsinhaber in gewisser Weise nicht darum kümmert, was Sie mit der Software tun können, aber Sie können es nicht Teilen Sie den Code, um ihn mit anderem Copyleft-Quellcode zu mischen. Auf andere Weise kümmert sich der Urheberrechtsinhaber wirklich darum, was Sie tun können, und er möchte nicht, dass Sie den Code verwenden, um beispielsweise Linux zu verbessern.

Die MS-PL ist mit der GPL nicht kompatibel.

Öffentliche Eclipse-Lizenz (EPL)

Die Eclipse Public License ist die Lizenz, die von der Eclipse Foundation für ihre integrierte Entwicklungsumgebung erstellt wurde. Es ist eine restriktive und schwache Copyleft-Lizenz, ähnlich wie LGPL in vielerlei Hinsicht. Es enthält auch Klauseln für die automatische Erteilung von Patentlizenzen.

Die EPL ist mit der GPL nicht kompatibel.

Öffentliche Mozilla-Lizenz (MPL)

Die Mozilla Public License Version 2.0 ist eine freizügige Lizenz mit schwachem Copyleft, die von der Mozilla Foundation für ihre Produkte erstellt wurde.

Wir könnten diese Lizenz als ähnlich zu LGPL betrachten, aber mit dem Hauptunterschied, dass MPL auch das statische Linken der MPL-Code-Teile in Closed-Source-Software erlaubt.

Die MPL ist in ihrer aktuellen Version 2.0 kompatibel zur GPL. Dies gilt nicht für frühere Versionen der MPL.

Gemeinsame Entwicklungs- und Vertriebslizenz (CDDL)

Die CDDL ist eine freizügige Lizenz mit schwachem Copyleft, die von Sun (jetzt Oracle) basierend auf MPL Version 1.1 erstellt wurde. Grundsätzlich hat es die gleichen Eigenschaften wie die MPL. Die Bedingungen wurden präzisiert, aber nicht wesentlich geändert.

Die CDDL ist die Open-Source-Lizenz, die Sun (jetzt Oracle) für viele seiner Produkte gewählt hat, unter anderem für OpenSolaris oder NetBeans.

Da diese Lizenz auf MPLv1.1 basierte, ist diese Lizenz nicht mit GPL kompatibel, sodass Sie keine CDDL-lizenzierten Quellen in eine GPL-lizenzierte Software mischen können. Viele Leute sagen, dass dies beabsichtigt war, sodass OpenSolaris-Quellcode nicht in den Linux-Kernel eingeführt werden kann.

GNU Affero General Public License (AGPL)

Die AGPL ist eine Version der GPL mit noch stärkerem und restriktiverem Copyleft. Es verpflichtet, den Quellcode der Anwendung nicht nur den Personen zur Verfügung zu stellen, die eine Kopie der Software erhalten, sondern auch den Personen, die diese Software über ein Computernetzwerk verwenden.

Diese Lizenz wurde von der FSF geschaffen, um den Entwicklern die Möglichkeit zu geben, die praktische Schließung von Open-Source-Software zu vermeiden, wenn sie auf Netzwerkservern oder in der Cloud ausgeführt wird, da die GPL die Dienstanbieter nicht zwingen kann, den Benutzern Quellcode zu geben . In diesem Fall wird die Software nicht verteilt.

Die AGPLv3 ist mit der GPL3 kompatibel. Sie können AGPLv3-Code in GPLv3-Code einfügen, solange das Endergebnis unter AGPLv3 lizenziert ist.

ISC-Lizenz

Die ISC-Lizenz ist eine freizügige Lizenz für freie Software, die vom Internet Software Consortium (ISC) geschrieben wurde. Es entspricht funktional den 2-Klausel-BSD- und MIT-Lizenzen, nachdem einige als unnötig erachtete Sprache entfernt wurde.

Ursprünglich für die eigenen Software-Releases von ISC verwendet, ist es seitdem neben anderen Projekten die bevorzugte Lizenz von OpenBSD (ab Juni 2003).

Es ist mit der GPL kompatibel: Sie können ISC-lizenzierten Code in GPL-Software mischen.

Gegenseitige Microsoft-Lizenz (MS-RL)

Die Microsoft Reciprocal License wurde 2008 von diesem Unternehmen als eine der Open-Source-Lizenzen erstellt, die von ihrer Shared Source Initiative erstellt wurden.

Es ähnelt der zuvor erläuterten MS-PL, hat aber ein etwas stärkeres Copyleft, das den Bedingungen der LGPL, CDDL und EPL ähnelt. Wenn Sie Ihren Code mit MS-RL-lizenziertem Quellcode mischen und die Endergebnisse verteilen möchten, muss zumindest der ursprüngliche MS-RL-lizenzierte Teil weiterhin mit dieser Lizenz lizenziert werden.

Es ist nicht mit der GPL kompatibel.

Gemeinfrei (CC0)

Laut Wikipedia sind „gemeinfreie Werke Werke, deren geistige Eigentumsrechte abgelaufen, verwirkt oder nicht anwendbar sind“. Durch die Zuweisung eines Werkes an die Gemeinfreiheit verzichtet der Urheber auf alle seine urheberrechtlichen Rechte daran.

Es gibt mehrere Softwareprojekte unter Public Domain, zum Beispiel SQLite, die Bibliothek, die eine einbettbare und einfache SQL-Datenbank-Engine implementiert, die in mehreren anderen Projekten wie Mozilla-Projekten, Android usw. enthalten ist.

Es gibt viele Möglichkeiten, ein Stück Software gemeinfrei zu machen. Creative Commons hat die CC0 Public Domain Dedication entwickelt, eine universelle Möglichkeit, ein Werk gemeinfrei zu machen. Die FSF empfiehlt, diesen Text zu verwenden, um Software gemeinfrei zu machen.

Gemeinfreie Werke sind mit allen Open- oder Closed-Source-Lizenzen kompatibel und können in jede andere Software gemischt werden.

Mehrfachlizenzierung

Es gibt Open-Source-Software, die doppelt oder sogar dreifach lizenziert ist. Dies bedeutet, dass eine Person, die diese mehrfach lizenzierte Software erhält, wählen kann, unter welcher Lizenz sie sie verteilen möchte. Da jede Lizenz unterschiedliche Berechtigungen gewährt und unterschiedliche Verpflichtungen auferlegt, muss eine Auswahl getroffen werden, um die Lizenz auszuwählen, die den Anforderungen am besten entspricht.

Dies ist ein normaler Fall für einige Bibliotheken. Beispielsweise ist NSS eine von Mozilla erstellte Bibliothek, die neben anderen sicherheitsrelevanten Funktionen die SSL/TLS-Unterstützung implementiert. Es ist dreifach lizenziert unter MPL-, GPL- und LGPL-Lizenzen.

Bitte wählen Sie eine Lizenz

Viele Leute veröffentlichen Code auf Plattformen als GitHub ohne schriftliche Lizenz. Niemand sollte diesen Code verwenden. Wir haben keine Ahnung, welche Berechtigungen wir für die Verwendung haben. Wenn Sie es verwenden, können Sie dafür verklagt werden. Es ist, als würden uns diese Leute aufziehen und sagen: „Hey, schau, was ich gemacht habe! Cool, oder? Aber du kannst es nicht benutzen, ich wollte es dir nur zeigen!“.

Bitte sei keiner von ihnen. Wenn Sie Ihren Code auf GitHub oder ähnliche öffentliche Websites hochladen, erlauben Sie anderen, ihn zu verwenden und zu verbessern. Wenn Sie nicht viel nachdenken wollen, hier meine Empfehlungen:

• Wenn Sie es einfach und freizügig halten und jedem erlauben möchten, mit Ihrem Code zu tun, was er will, solange er Ihnen eine Zuordnung zuteilt und Sie nicht haftbar macht, verwenden Sie die MIT-Lizenz.
• Wenn Sie es freizügig halten möchten, jedem erlauben, mit Ihrem Code zu tun, was er will, aber die Rechte nach dem Urheberrechtsgesetz klug aufzählen und diese Rechte gewähren, zusammen mit einer ausdrücklichen Gewährung von Patentrechten von Mitwirkenden an Benutzer, verwenden Sie die Apache 2.0-Lizenz .

• Wenn Ihnen Änderungen wichtig sind und Sie nicht möchten, dass Ihr Code in geschlossenen Entwicklungen verwendet wird (weder in geschlossenen Softwareprodukten noch in geschlossenen Hardwareanwendungen), verwenden Sie GPL v3.

  • Wenn Sie sich nicht um die Möglichkeit kümmern, dass Ihre Software in einer geschlossenen Appliance verwendet wird, verwenden Sie GPL v2. Aber bitte mit dem Satz „or any later version“, damit Ihr Code auch in GPLv3-Projekten verwendet werden kann.
  • Wenn Sie sich nicht um die Möglichkeit kümmern, dass Ihre Software in geschlossener Software verwendet wird, solange Ihre Software oder der Teil, der sie verwendet, weiterhin unter denselben Bedingungen Open Source ist, verwenden Sie die LGPL v3.
  • Wenn Sie möchten, dass jeder, der Ihre Software über ein Netzwerk verwendet, das Recht hat, den Quellcode zu erhalten, verwenden Sie AGPL v3.

Nach all dem sind Sie vielleicht erschöpft von all diesem fast unsinnigen, quasi-rechtlichen Kauderwelsch. Aber weißt du was? Es ist nötig. Denn ohne Lizenz sind Sie nicht berechtigt, Code zu verwenden oder zu verbreiten.