GPL vs. MIT vs. Apache: Welche Lizenz verlangt was?

GPL vs. MIT vs. Apache: Was die einzelnen Lizenzen von Ihnen verlangen

GPL, MIT und Apache 2.0 beantworten dieselbe Frage auf unterschiedliche Weise: Was schulden Sie anderen, wenn Sie die Software weitergeben? Die MIT-Lizenz verlangt einen Urheberrechtshinweis und nichts weiter. Apache 2.0 verlangt diesen Hinweis sowie eine Patentvereinbarung zwischen allen Beteiligten am Code. Die GPL verlangt, dass Sie den Quellcode Ihrer darauf aufbauenden Änderungen unter derselben Lizenz veröffentlichen, unter der Sie die Software erhalten haben.

Das wirkt so lange wie eine Frage für Juristen, bis ein von Ihnen betriebener Projekt seine Lizenz ändert und in zwei Projekte aufgeteilt wird. Dann wird es zu einer Betriebsfrage. Sie müssen zwischen zwei Paket-Repositories wählen, und Client-Bibliotheken kommunizieren nicht mehr miteinander. In diesem Leitfaden geht es um die Lizenzen und ihre Funktionsweise, nicht um die Bewegung, aus der sie hervorgegangen sind. Deshalb endet jeder Abschnitt dort, wo er Sie betrifft: bei der Person, die das Upgrade durchführen muss.

Warum die GPL existiert: ein Drucker, den niemand reparieren durfte

Um 1980 erhielt das MIT Artificial Intelligence Lab einen Laserdrucker Xerox 9700. Das Labor hatte die Software eines früheren Druckers so angepasst, dass sie meldete, wenn ein Druckauftrag stecken blieb. Für das neue Gerät gab es keinen Quellcode. Die Anfrage danach wurde wegen einer Geheimhaltungsvereinbarung abgelehnt. Richard Stallman, damals Programmierer am Labor, betrachtete diese Ablehnung als allgemeinen Zustand und nicht als einmaligen schlechten Tag. Am 27. September 1983 kündigte er das GNU-Projekt an.

Copyleft basiert auf dem Urheberrecht und richtet sich nicht gegen es. Standardmäßig haben Sie überhaupt kein Recht, den Code anderer zu kopieren. Die GPL gewährt dieses Recht unter einer Bedingung: Wenn Sie das Programm an jemand anderen weitergeben, müssen Sie dieser Person den Quellcode unter denselben Bedingungen zur Verfügung stellen. Dadurch kann sie tun, was dem Labor nicht möglich war. Die Bedingung ist durchsetzbar, weil Sie ohne die Lizenz ursprünglich überhaupt keine Erlaubnis hatten.

Stallman schrieb zuerst eine Lizenz für GNU Emacs. Anschließend verallgemeinerte er sie zur GPL version 1, die am 25. Februar 1989 veröffentlicht wurde. GPL version 2 folgte im Juni 1991. Sie ist weiterhin die Lizenz für den größten Teil der Systemsoftware, die Sie ausführen. Die Lesser GPL wurde für Bibliotheken eingeführt. Dadurch konnte ein Copyleft-Bibliothek von einem Programm unter einer beliebigen Lizenz eingebunden werden, ohne dass dieses Programm selbst unter die GPL fallen musste.

Ein Detail bestimmt, wie sich die GPL auf Self-Hosting auswirkt. Die Verpflichtung wird durch die Weitergabe ausgelöst, nicht durch die Nutzung. Sie können ein GPL-Programm ändern, auf Ihrem eigenen Server ausführen und damit öffentliche Dienste bereitstellen, ohne jemandem etwas zu schulden. Sie haben schließlich keine Kopie weitergegeben. Diese Lücke ist der Grund, aus dem die AGPL existiert.

Die permissive Tradition: BSD, dann MIT

Berkeley schlug einen anderen Weg ein. Die Computer Systems Research Group veröffentlichte ihre Unix-Arbeiten unter einer Lizenz, die die Beibehaltung des Copyright-Hinweises verlangte und jede Gewährleistung ausschloss. Die ursprüngliche Version hatte vier Klauseln. Die vierte Klausel, die sogenannte Werbeklausel, verlangte einen Hinweis auf die Universität in jedem Werbematerial, das Funktionen der Software erwähnte. Das ist nicht skalierbar. Stallman zählte in einer Version von NetBSD aus dem Jahr 1997 75 separate Hinweise. UC Berkeley strich die Klausel am 22. Juli 1999 in einem Schreiben von William Hoskins aus dem Office of Technology Licensing.

Übrig bleiben die BSD-Lizenz mit 3 Klauseln, die zusätzlich die Verwendung der Namen von Mitwirkenden zur Unterstützung Ihres Produkts untersagt, und die Version mit 2 Klauseln, die auch dieses Verbot fallen lässt. Der Text der MIT-Lizenz entstand in den 1980er-Jahren am MIT. Dort galt er für das X Window System. In der Praxis erfüllt er dieselbe Funktion wie BSD mit 2 Klauseln.

Die Motive waren unterschiedlich. Eine aus öffentlichen Mitteln finanzierte Universität wollte, dass ihre Arbeit überall eingesetzt wird, auch von Unternehmen. Das GNU-Projekt wollte eine gemeinsame Basis schaffen, die nicht geschlossen werden konnte. Beide Positionen sind nachvollziehbar. Beide haben jedoch einen Schwachpunkt. Permissiver Code kann in proprietäre Software übernommen werden, ohne dass etwas zurückfließt. Copyleft-Code wird von Unternehmen abgelehnt, deren Rechtsabteilungen die Bedingung nicht akzeptieren.

Aus Berkeley lässt sich noch eine zweite Lehre ziehen. Auf sie kommt dieser Beitrag immer wieder zurück. AT&T's Unix System Laboratories verklagte Berkeley Software Design 1992 wegen des BSD-Codes. Der Rechtsstreit wurde Anfang 1994 beigelegt. Zwei Jahre lang war nicht klar, ob BSD eine sichere Grundlage war. Die Verbreitung kam ins Stocken, während Linux weiter wuchs. Rechtliche Unsicherheit bremst die Verbreitung schneller als eine fehlende Funktion.

Warum Apache 2.0 eine Patentlizenz ergänzt hat

Die erste Lizenz der Apache Group war ein von der BSD-4-Klausel-Lizenz abgeleiteter Lizenztext mit demselben Problem bei der Werbeklausel. Version 1.1 entfernte diese Klausel im Jahr 2000. Version 2.0, veröffentlicht im Januar 2004, war eine Neufassung und kein nachträglicher Patch.

Die wichtigste Ergänzung betrifft Patente. MIT und BSD enthalten dazu überhaupt keine Regelungen. Ein Mitwirkender kann Ihnen eine eindeutige urheberrechtliche Erlaubnis für seinen Code erteilen und trotzdem ein Patent besitzen, das die Funktionsweise des Codes abdeckt. Anschließend kann er die Personen verklagen, die den Code verwenden. Apache 2.0 schließt diese Lücke: Jeder Mitwirkende gewährt eine Patentlizenz für seinen Beitrag. Wer klagt und behauptet, das Werk verletze seine Patente, verliert seine eigene Patentlizenz für dieses Werk. Die Drohung gilt gegenseitig. In der Praxis setzt deshalb niemand sie ein.

Der übrige Inhalt von 2.0 ist administrativer Natur. Genau deshalb bevorzugen Unternehmen diese Lizenz. Es gibt eine eindeutig definierte NOTICE-Datei. Dadurch hat die Attribution einen zentralen Ort, statt über den gesamten Quellbaum verteilt zu sein. Die Lizenz kann durch Verweis angewendet werden, anstatt in jede Quelldatei kopiert zu werden. Für Beiträge gelten ausdrücklich festgelegte Bedingungen. Marken sind ausgeschlossen. Bei der rechtlichen Prüfung einer Abhängigkeit unter Apache 2.0 sind alle Fragen, die geprüft werden sollen, bereits im Lizenztext beantwortet. Dadurch wird die Freigabe zum Routineprozess. Das ist im Wesentlichen die Bedeutung von „Unternehmensstandard“.

Was GPLv3 geändert hat und warum Linux bei GPLv2 blieb

TiVo veröffentlichte einen Videorekorder mit Linux und stellte den Kernel-Quellcode bereit, genau wie es GPLv2 verlangt. Die Hardware prüfte beim Booten anschließend eine kryptografische Signatur und verweigerte den Start eines Kernels, den sie nicht erkannte. Sie konnten den Quellcode lesen, ändern und kompilieren. Sie konnten ihn jedoch nicht auf dem Gerät ausführen, von dem er stammte. Der Wortlaut der Lizenz war erfüllt, ihr Zweck jedoch vereitelt. Für diese Praxis setzte sich die Bezeichnung Tivoisierung durch.

Die am 29. Juni 2007 veröffentlichte Version 3 der GPL reagiert direkt darauf. Wenn Sie die Binärdatei in einem Verbrauchergerät weitergeben, müssen Sie auch die „Installationsinformationen“ bereitstellen: die Schlüssel oder die Anweisungen, die erforderlich sind, um eine geänderte Version zu installieren und auszuführen. Version 3 fügte außerdem eine ausdrückliche Patenterteilung hinzu, Bestimmungen als Reaktion auf das Patentabkommen zwischen Microsoft und Novell vom November 2006 sowie eine einseitige Kompatibilität mit Apache 2.0.

Linux folgte diesem Schritt nicht. Der Kernel steht ausschließlich unter GPL Version 2. Eine Ausweichklausel „oder jede spätere Version“ gibt es nicht, und die Datei COPYING sagt dies ausdrücklich. Linus Torvalds lehnte die Bestimmungen zur Tivoisierung signierter Hardware öffentlich ab. Die praktische Hürde ist jedoch größer als diese Meinungsverschiedenheit: Der Kernel hat Tausende von Urheberrechtsinhabern. Daher könnte niemand die für eine Neulizenzierung erforderlichen Zustimmungen einholen, selbst wenn alle Beteiligten dies wollten. Diese einzelne Tatsache ist der stärkste Schutz, den ein Projekt haben kann. Das sollten Sie berücksichtigen, wenn ein Projekt einem einzigen Unternehmen gehört.

Die andere Lizenz aus dem Jahr 2007 ist für Sie wichtiger. Die im November desselben Jahres veröffentlichte GNU Affero GPL Version 3 erweitert die Pflicht zur Bereitstellung des Quellcodes auf Personen, die über ein Netzwerk mit dem Programm interagieren. Wenn Sie einen geänderten AGPL-Dienst öffentlich betreiben, müssen Sie diesen Benutzern den Quellcode bereitstellen. Deshalb steht so viel selbst gehostete Websoftware unter AGPL. Nextcloud ist ein Beispiel dafür. Wenn Sie die selbst gehosteten Alternativen zu Nextcloud vergleichen, sagt Ihnen die Lizenzangabe im Repository jedes Kandidaten mehr über dessen nächste fünf Jahre als die Funktionsliste.

Welche Lizenzen können Sie tatsächlich kombinieren?

Die Kompatibilität gilt nur in eine Richtung: von permissiven Lizenzen hin zu Copyleft-Lizenzen.

• Code unter MIT- oder BSD-Lizenz kann in beliebige Projekte übernommen werden, auch in ein proprietäres Produkt.
• Code unter Apache 2.0 kann in ein GPLv3-Projekt aufgenommen werden. Das kombinierte Werk steht dann unter GPLv3.
• Code unter Apache 2.0 kann nicht in ein Projekt aufgenommen werden, das ausschließlich GPLv2 zulässt. Die Bestimmungen zur Beendigung des Patentschutzes und zur Freistellung sind zusätzliche Bedingungen, deren Ergänzung GPLv2 nicht erlaubt. Sowohl die FSF als auch die ASF veröffentlichen diese Schlussfolgerung.
• GPL-Code kann von Ihnen nicht auf eine permissive Lizenz umgestellt werden. Das können nur die Inhaber der Urheberrechte. Damit stellt sich erneut die Frage, wer diese Rechteinhaber sind.

Die Ära der Relizenzierung: SSPL, BUSL und was sie nicht sind

Der Auslöser war kommerzieller Natur. Ein Unternehmen besitzt das Urheberrecht an einem Produkt, ein Cloud-Anbieter verkauft es in großem Maßstab als Managed Service und trägt nur wenig zurück bei, woraufhin das Unternehmen die Lizenz ändert, um dies zu unterbinden. Redis Labs machte im August 2018 den ersten sichtbaren Schritt und fügte für mehrere Module die Commons Clause zu Apache 2.0 hinzu. MongoDB folgte am 16. Oktober 2018 und wechselte von AGPLv3 zur Server Side Public License.

Die SSPL ist die AGPL mit einem neu formulierten Abschnitt. Bieten Sie das Programm Dritten als Dienst an, müssen Sie den Quellcode aller Komponenten veröffentlichen, die Sie dafür verwenden, einschließlich der Verwaltungs- und Orchestrierungssoftware. Diese Verpflichtung hat keine klare Abgrenzung, und kein Gericht hat sie bisher geprüft. Die OSI hat die Lizenz nie genehmigt, und MongoDB zog seinen Antrag im März 2019 zurück. Debian hatte bereits im Dezember 2018 erklärt, dass SSPL-Software nicht in sein Archiv gehört. Fedora entschied im Januar 2019, dass die Lizenz nicht frei ist. Daraufhin entfernte Red Hat MongoDB aus Fedora und aus Red Hat Enterprise Linux. Das ist das unmittelbare Ergebnis einer Relizenzierung: Die Distribution stellt die Software nicht mehr als Paket bereit. Ihre Updates kommen dann aus einem Anbieter-Repository nach dem Zeitplan des Anbieters.

Die Business Source License ist ein anderes Modell. Sie stammt von den Gründern von MariaDB, und Version 1.1 datiert aus dem Jahr 2017. Sie ist weder Copyleft noch Open Source. Der Quellcode ist öffentlich. Die Nutzung ist kostenlos, mit Ausnahme der Nutzung, die der Anbieter ausdrücklich ausschließt. Dabei handelt es sich normalerweise um den Betrieb eines konkurrierenden gehosteten Dienstes. Jede Version wird an einem Änderungsdatum automatisch in eine echte Open-Source-Lizenz umgewandelt, das höchstens vier Jahre nach der Veröffentlichung dieser Version liegen darf. Die Ziellizenz muss mit GPLv2 kompatibel sein. HashiCorp stellte Terraform und seine anderen Produkte am 10. August 2023 auf BUSL 1.1 um. Auch Outline verwendet diese Lizenz. Das ist wichtig, wenn Sie unter den selbst gehosteten Notion-Alternativen auswählen: Der Betrieb für Ihr eigenes Team ist zulässig, der Aufbau eines darauf basierenden Dienstes nicht.

Keine der beiden Lizenzen ist irreführend. Beide erklären ausdrücklich, dass sie den Quellcode verfügbar machen. Nach der Definition der OSI ist keine von beiden Open Source. Die Folgen treffen jedoch Sie und nicht den Cloud-Anbieter, gegen den sich die Lizenz ursprünglich richtete.

OpenSearch: Was eine Lizenzänderung den Betreiber kostet

Elastic kündigte am 14. Januar 2021 an, dass Elasticsearch und Kibana ab Release 7.11 Apache 2.0 verlassen und stattdessen unter der SSPL oder der Elastic License stehen würden. Version 7.10.2 war das letzte Release unter Apache 2.0. Etwa eine Woche später teilte AWS mit, einen Apache-2.0-Fork beider Projekte zu erstellen und zu pflegen. Am 12. April 2021 erhielt der Fork den Namen OpenSearch; Kibana wurde in OpenSearch Dashboards umbenannt. OpenSearch 1.0 wurde am 12. Juli 2021 allgemein verfügbar. Es basierte auf Elasticsearch 7.10.2 und Kibana 7.10.2.

Sehen Sie sich an, was das für die Betreiber von Clustern bedeutete. Paketnamen und Repositories änderten sich. Jeder Verweis auf Kibana in einem Runbook wurde zu OpenSearch Dashboards. Plugin-Namen änderten sich. Dann erreichte die Aufspaltung den Anwendungscode: Ab Version 7.13 der offiziellen Clientbibliotheken von Elastic prüft der Client, womit er verbunden ist, und verweigert die weitere Ausführung, wenn es sich nicht um Elasticsearch handelt. Dabei meldet er, dass der Server ein unbekanntes Produkt ist. Eine Lizenzentscheidung bei einem Unternehmen, für das Sie nicht arbeiten, führte dadurch zu einem fehlschlagenden Aufruf in Ihrer eigenen Anwendung.

Danach änderte sich die Situation noch zweimal. Elastic fügte am 29. August 2024 AGPLv3 als dritte Lizenzoption hinzu. Damit ist das aktuelle Elasticsearch wieder von der OSI anerkannt Open Source. Am 16. September 2024 übertrug AWS OpenSearch an die OpenSearch Software Foundation, die von der Linux Foundation getragen wird. Dadurch erhielt der Fork eine Governance-Struktur, die nicht von einem einzelnen Unternehmen abhängt. Fünf Jahre nach der Aufspaltung sind beide Projekte Open Source und werden gepflegt. OpenSearch befindet sich im August 2026 in der 3.x-Serie.

Das ist die eigentliche Lehre. Die Lizenz wurde wieder geändert, aber der Fork blieb bestehen. Sobald ein Ökosystem von allem zwei Varianten hat, führt eine Rücknahme der Lizenzänderung nicht wieder zu einer Zusammenführung.

Die entscheidende Zahl dafür, wie stark eine Lizenzänderung schadet, ist der Abstand zwischen der Ankündigung und einem stabilen Fork, den Sie tatsächlich einsetzen können.

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

Jeder Abstand wird von der öffentlichen Ankündigung des Herstellers bis zum ersten stabilen Release des Forks gezählt. Grundlage sind die unten aufgeführten Daten. OpenSearch 1.0 benötigte 179 Tage, weil der Fork umbenannt und neu erstellt werden musste und kein früherer Fork als Vorlage verfügbar war. OpenTofu benötigte 153 Tage. Valkey benötigte 27 Tage, weil es von Redis 7.2.4 geforkt wurde und das Protokoll sowie das Format auf dem Datenträger unverändert beibehielt. Der entscheidende Punkt ist die Entwicklung: Ein belastbarer Fork ist inzwischen innerhalb weniger Wochen verfügbar, mit einer Foundation und bezahlten Maintainerinnen und Maintainer von Anfang an.

Valkey und OpenTofu: dasselbe Muster, schneller

Redis Ltd wechselte Redis am 20 March 2024 von der 3-clause-BSD-Lizenz zu einer Auswahl aus RSALv2 oder SSPLv1. Acht Tage später kündigte die Linux Foundation Valkey an, einen Fork von Redis 7.2.4, der weiterhin unter der 3-clause-BSD-Lizenz steht. Valkey 7.2.5 erschien am 16 April 2024 mit demselben Protokoll und denselben Datendateien. Für die meisten Betreiber bestand die Migration daher lediglich aus einer Änderung des Paketnamens. Im May 2025 ergänzte Redis in Redis 8 AGPLv3 als dritte Option. Nach der Definition der OSI ist Redis damit wieder Open Source, während Valkey weiterhin unter seiner eigenen Governance entwickelt wird. Das Muster entspricht weitgehend dem von Elasticsearch.

Terraform nahm denselben Verlauf, allerdings mit einem zusätzlichen Kapitel. OpenTofu wurde aus der letzten Version unter der Mozilla Public License 2.0 geforkt, trat im September 2023 der Linux Foundation bei und veröffentlichte am 10 January 2024 Version 1.6.0. Am 3 April 2024 schickten die Anwälte von HashiCorp dem Projekt eine Unterlassungsaufforderung. Sie behaupteten, dass Code aus einer unter BUSL lizenzierten Terraform-Version in den Fork übernommen worden sei. OpenTofu veröffentlichte am 11 April 2024 eine ausführliche Stellungnahme, wies die Behauptung zurück und führte den strittigen Code auf die MPL-lizierte gemeinsame Historie beider Projekte zurück. Danach gab es öffentlich keine weiteren Entwicklungen. Das eigentliche Risiko dieses Vorgangs ist entscheidend: Bereits eine Anschuldigung kann die Einführung für ein Quartal zum Erliegen bringen. Genau denselben Effekt hatte die Klage von Berkeley dreißig Jahre zuvor.

Nicht jeder Fork beginnt mit einer Lizenzfrage. Forgejo wurde 2022 aus Gitea geforkt, nachdem die Entwicklung von Gitea unter die Kontrolle eines Unternehmens gelangt war. Es handelte sich daher um einen Governance-Konflikt und nicht um einen Lizenzkonflikt. Forgejo blieb in seiner Versionsreihe 8 unter MIT lizenziert und wechselte ab Version 9.0 im Jahr 2024 zu GPLv3 oder höher. Dadurch konnte der Code nicht wieder in ein kommerziell kontrolliertes Produkt zurückgeführt werden. Wenn Sie die Optionen für selbst gehostete Git-Server abwägen, ist dieses Paar das deutlichste aktuelle Beispiel für eine Codebasis und zwei unterschiedliche Philosophien.

Der Test vor dem Einsatz

Vier Fragen sollten Sie vor der ersten Installation beantworten, nicht erst danach.

1. Wer hält das Urheberrecht? Eine Neulizenzierung erfordert die Zustimmung aller Urheberrechtsinhaber. Ein Projekt mit Hunderten unabhängigen Beitragenden, die ihre Rechte nicht übertragen haben, kann daher realistisch nicht unter eine andere Lizenz gestellt werden. Bei einem Projekt, dessen Rechte vollständig einem Unternehmen gehören, kann die Neulizenzierung in einer Vorstandssitzung beschlossen werden.
2. Gibt es ein CLA, und was räumt es ein? Ein Contributor Licence Agreement, das dem Unternehmen erlaubt, Ihren Beitrag unter beliebigen Bedingungen neu zu lizenzieren, ist genau der Mechanismus hinter jeder der genannten Neulizenzierungen. Ein DCO (Developer Certificate of Origin), also die Sign-off-Zeile, die der Linux-Kernel 2004 übernommen hat, überträgt keinerlei Rechte. Ein von einer Foundation gehaltenes CLA ist sicherer als eines, das einem Unternehmen gehört, weil ein Unternehmen verkauft werden kann.
3. Wer besitzt die Marke? Elastic behielt den Namen Elasticsearch. Daher musste der Fork sich umbenennen, und jedes Runbook, in dem Kibana erwähnt wurde, musste überarbeitet werden.
4. Welche konkreten Kosten hätte eine Neulizenzierung für Sie? Berücksichtigen Sie das Datenformat, die Client-Bibliotheken, die Konfiguration, die Sie neu schreiben müssten, und die Frage, ob bereits ein kompatibler Fork existiert.

Zwei Befehle beantworten einen Teil dieser Fragen innerhalb von Sekunden.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

Jedes Debian- und Ubuntu-Paket enthält eine Datei unter /usr/share/doc/<package>/copyright. Sie dokumentiert die Lizenz der installierten Version, nicht die Lizenz, die das Projekt heute verwendet. Für bash unter Ubuntu 24.04 nennt diese Datei die GNU General Public License version 3. Führen Sie den zweiten Befehl in einem ausgecheckten Quellcode-Repository aus, erhalten Sie die Historie der Lizenzdatei selbst. Ein Commit dieser Datei aus den letzten zwei Jahren sollte gelesen werden, bevor Sie etwas auf dem Projekt aufbauen. Gibt der Befehl nichts aus, verwendet das Repository einen anderen Namen für die Lizenzdatei. Listen Sie dann das Root-Verzeichnis auf und suchen Sie dort.

Keine Lizenz schützt Sie vor jedem möglichen Ergebnis, und eine Auswahl nach ideologischen Kriterien führt oft zu unerwarteten Problemen. Bevorzugen Sie Projekte, deren Urheberrechte auf viele Beteiligte verteilt sind oder von einer Foundation gehalten werden. Speichern Sie Ihre Daten in einem Format, das Sie exportieren können. Ermitteln Sie anschließend, zu welchem Fork Sie wechseln würden, und notieren Sie den Namen, bevor Sie ihn benötigen. Diese Prüfung für jeden Kandidaten dauert weniger als eine Stunde. Sie entscheidet darüber, ob ein Upgrade oder eine Migration erforderlich ist, wenn Sie entscheiden, was Sie 2026 selbst hosten möchten.

FAQ

Ist die MIT-Lizenz dasselbe wie die BSD-Lizenz?

Praktisch entspricht die MIT-Lizenz der BSD-2-Klausel-Lizenz: Sie müssen den Copyright-Hinweis und den Haftungsausschluss beibehalten und können den Code anschließend beliebig verwenden, auch für ein proprietäres Produkt. Die BSD-3-Klausel-Lizenz ergänzt eine Einschränkung: Die Namen der Beitragenden dürfen ohne deren Zustimmung nicht zur Empfehlung Ihres Produkts verwendet werden. Die ältere Version mit 4 Klauseln verlangte außerdem einen Hinweis in Werbematerialien. UC Berkeley entfernte diese Klausel am 22 July 1999. Daher wird sie heute kaum noch verwendet.

Kann ich Code unter Apache 2.0 in ein GPLv2-Projekt übernehmen?

Nein. Apache 2.0 enthält Bedingungen, die GPLv2 nicht zulässt. Dazu gehört insbesondere die Klausel zur Beendigung von Patentrechten. Ein kombiniertes Werk kann daher nicht gleichzeitig beide Lizenzen erfüllen. Die FSF und die ASF veröffentlichen beide diese Schlussfolgerung. In die andere Richtung funktioniert es: Code unter Apache 2.0 kann in ein GPLv3-Projekt aufgenommen werden, und das Ergebnis steht unter GPLv3. Aus diesem Grund kann Code unter Apache 2.0 auch nicht in den Linux-Kernel übernommen werden, der ausschließlich unter GPL version 2 steht.

Ist SSPL eine Open-Source-Lizenz?

Nein, und das hat praktische Konsequenzen. Die OSI hat sie nie genehmigt. MongoDB zog seinen Antrag im March 2019 zurück. Debian erklärte im December 2018, dass Software unter SSPL nicht in sein Archiv gehört. Fedora entschied im January 2019, dass die Lizenz nicht frei ist. Anschließend entfernte Red Hat MongoDB aus Fedora und Red Hat Enterprise Linux. Für Sie bedeutet das: Ein Paket, das Ihre Distribution früher gepflegt hat, stammt nun aus einem Repository des Anbieters und folgt dessen Support-Zeitplan. Die Business Source License stellt ebenfalls den Quellcode bereit, ist aber keine Open-Source-Lizenz. Jede Version wird jedoch innerhalb von vier Jahren in eine Open-Source-Lizenz umgewandelt.

Gilt eine Lizenzänderung für die Version, die ich bereits ausführe?

Nein. Eine mit einer Veröffentlichung erteilte Lizenz kann für bereits veröffentlichte Kopien nicht zurückgezogen werden. Genau deshalb sind Forks möglich. OpenSearch wurde aus Elasticsearch 7.10.2 erstellt, der letzten von Elastic unter Apache 2.0 veröffentlichten Version. Was Sie verlieren, ist die Zukunft: Der nächste Security-Fix wird unter den neuen Bedingungen veröffentlicht. Die letzte permissiv lizenzierte Version festzuschreiben, verschafft Ihnen einige Monate. Das ist jedoch kein tragfähiger Plan.