Die Geschichte von Open-Source-Software und ihren Lizenzen

Was Open-Source-Software ist und woher sie kommt

Die Geschichte von Open-Source-Software ist größtenteils die Geschichte ihrer Lizenzen, denn eine Lizenz legt als einziges fest, was Sie mit dem von jemand anderem geschriebenen Code tun dürfen. Code wurde schon lange offen geteilt, bevor jemand diese Lizenzen schriftlich festhielt. Das änderte sich, als Code zu einem Produkt wurde. Die Lizenzen wurden formuliert, damit das Teilen auch vor Gericht Bestand hatte.

Das ist die Kurzfassung. Die ausführliche Version ist wichtig, weil die Software, die Sie heute auf einem Server betreiben, noch immer die Spuren dieser Entscheidungen trägt. Einige dieser Entscheidungen wurden 1983 getroffen. Andere stammen aus dem vergangenen Jahr. Sie sind der Grund dafür, dass einige Anwendungen in unseren Anleitungen zum Self-Hosting inzwischen in zwei Versionen mit unterschiedlichen Namen angeboten werden.

Software wurde geteilt, bevor es verkauft wurde

In den 1950er- und 1960er-Jahren wurde Software zusammen mit der Maschine ausgeliefert. IBM lieferte den Quellcode mit seinen Systemen aus, und Benutzergruppen wie SHARE, die 1955 gegründet wurde, gaben Programme auf Magnetband weiter. Zwei Entwicklungen beendeten diese Praxis. IBM kündigte 1969 an, Software getrennt von Hardware zu bepreisen. Dadurch entstand ein eigenständiger Softwaremarkt. Danach zog auch die Gesetzgebung nach. Der Computer Software Copyright Act von 1980 bestätigte in den Vereinigten Staaten, dass Programme urheberrechtlich geschützte Werke sein können. Nach 1980 war Code, den Sie nicht selbst geschrieben hatten, standardmäßig geschlossen. Für seine Weitergabe war daher eine schriftliche Genehmigung des Autors erforderlich.

Der Homebrew Computer Club und der offene Brief an Hobbyisten

Der Homebrew Computer Club hielt sein erstes Treffen im März 1975 in einer Garage in Menlo Park, Kalifornien, ab. Die Mitglieder brachten Hardware und Papierstreifen mit, und das Kopieren gehörte zum Treffen dazu. Altair BASIC, geschrieben von Bill Gates und Paul Allen, wurde auf kopierten Bändern durch den Raum weitergegeben. Im Februar 1976 antwortete Gates im Newsletter des Clubs mit „An Open Letter to Hobbyists“.

Wie der Mehrheit der Hobbyisten bewusst sein muss, stehlen die meisten von Ihnen Ihre Software.

Er schrieb, dass weniger als einer von zehn Altair-Besitzern für BASIC bezahlt habe und dass die für die Entwicklung verwendete Computerzeit mehr als 40,000 Dollar wert gewesen sei. Das gesamte moderne Argument steht bereits in diesem Brief. Das Kopieren von Software kostet nichts und hilft jedem, der sie kopiert. Ihre Entwicklung kostete dennoch jemanden ein Jahr seines Lebens. Jede der unten beschriebenen Lizenzen versucht, diese beiden Tatsachen gleichzeitig zu berücksichtigen.

GNU im Jahr 1983 und die GPL als rechtliche Erfindung

Richard Stallman kündigte GNU im September 1983 auf Usenet an, dem Newsgroup-Netzwerk, das vor dem Web genutzt wurde. GNU steht für „GNU's Not Unix“. Geplant war ein vollständiges, Unix-kompatibles System, das jeder kopieren und ändern konnte.

Free Unix! Starting this Thanksgiving I am going to write a complete Unix-compatible software system called GNU (for Gnu's Not Unix), and give it away free to everyone who can use it.

Die Free Software Foundation (FSF) folgte 1985. Ihre Free Software Definition nennt vier Freiheiten, die bei null beginnen: das Programm für jeden Zweck auszuführen, es zu untersuchen und zu ändern, Kopien weiterzugeben und geänderte Versionen zu verbreiten. Freiheit 1 setzt den Quellcode voraus, weil niemand eine Binärdatei auf praktikable Weise untersuchen kann. „Free“ bedeutet hier Freiheit und nicht Preis. Die eigene Formulierung der FSF lautet free as in free speech, not free beer.

Das Manifest war nicht die Erfindung. Die Lizenz war es. Die GNU General Public License (GPL) nutzt das Urheberrecht, um die Weitergabe zu verlangen, statt sie zu verhindern. Sie erhalten die vier Freiheiten unter einer Bedingung: Jeder, dem Sie die Software übergeben, erhält sie ebenfalls, einschließlich des Quellcodes. Stallman nannte dies Copyleft. Die Lizenz erschien erstmals 1985 zusammen mit GNU Emacs, wurde 1989 zur GPL version 1 und im Juni 1991 zur version 2.

Die GPL funktioniert, weil sie auf dem Urheberrecht beruht und nicht dagegen. Ohne Lizenz haben Sie überhaupt kein Recht, den Code einer anderen Person zu verbreiten. Die GPL gewährt dieses Recht und knüpft Bedingungen daran. Ein Anbieter, der geänderten GPL-Code in einem Router ausliefert und den Quellcode nicht herausgibt, bricht daher kein Versprechen. Er verletzt das Urheberrecht. Der Urheberrechtsinhaber kann dagegen vor Gericht vorgehen. Deshalb ist eine Durchsetzung überhaupt möglich: von den Fällen von Harald Weltes gpl-violations.org in den 2000er-Jahren bis zur 2021 eingereichten Klage der Software Freedom Conservancy gegen Vizio. In dieser Klage wird argumentiert, dass auch eine Person, die das Fernsehgerät gekauft hat, den Quellcode verlangen kann.

Linux stellte das System fertig

Bis 1991 verfügte das GNU-Projekt über den Compiler, die C-Bibliothek, die Shell und die meisten Werkzeuge. Es hatte keinen funktionsfähigen Kernel, weil der eigene GNU-Kernel, der Hurd, deutlich länger als geplant benötigte. Im August 1991 schrieb ein Student in Helsinki in der Newsgroup comp.os.minix:

Ich entwickle ein (freies) Betriebssystem (nur als Hobby, es wird nicht groß und professionell wie gnu) für 386(486)-AT-Klone.

Linux 0.01 erschien im September 1991 unter einer Lizenz, die Linus Torvalds selbst verfasst hatte und die den Verkauf untersagte. Anfang 1992 ersetzte er sie durch GPLv2. Seitdem bezeichnet er das als eine seiner besten Entscheidungen. Die Lizenz machte Beiträge von Unternehmen unproblematisch: Ein Unternehmen konnte Entwickler am Kernel arbeiten lassen, ohne befürchten zu müssen, dass ein Konkurrent diese Verbesserungen proprietär weiterverwendet.

In Berkeley gab es bereits ein freies Unix. Dass nicht BSD (Berkeley Software Distribution), sondern Linux zum freien Unix-Standard wurde, lag teilweise an einem Rechtsstreit. Unix System Laboratories verklagte Berkeley Software Design 1992. Der Rechtsstreit dauerte bis Anfang 1994. Während dieser zwei Jahre waren die BSD-Systeme mit rechtlichen Risiken verbunden, Linux dagegen nicht. In dieser Zeit kamen die Benutzer. Die FSF bittet darum, das kombinierte System GNU/Linux zu nennen, weil Linux der Kernel ist und die meisten umgebenden Werkzeuge aus GNU stammen. Die meisten Menschen sagen Linux. Beide Bezeichnungen meinen dieselbe Softwaresammlung.

1998: Die Umbenennung zu Open Source und die Spaltung, die nie geheilt ist

Im Januar 1998 kündigte Netscape an, den Quellcode seines Browsers zu veröffentlichen. Es war das bis dahin größte Unternehmen, das einen solchen Schritt unternahm, und dadurch wurde ein praktisches Problem sichtbar. Die Bezeichnung „free software“ wird im Englischen als „Software, die nichts kostet“ verstanden, und genau das hörten die Führungskräfte. Im Februar 1998 traf sich eine Gruppe in Palo Alto, um einen besseren Begriff zu finden, und Christine Peterson schlug „open source“ vor. Innerhalb weniger Wochen gründeten Eric Raymond und Bruce Perens die Open Source Initiative (OSI). Sie übernahm die Open Source Definition, die auf den Debian Free Software Guidelines basierte, die Perens 1997 verfasst hatte.

Die Open Source Definition enthält zehn Kriterien. Zwei davon bestimmen die meisten modernen Diskussionen: Der Quellcode muss verfügbar sein, und die Lizenz darf nicht einschränken, wer das Programm verwenden darf oder wofür es verwendet werden darf. Eine Lizenz mit der Vorgabe „Sie dürfen dies nicht als kommerziellen Dienst anbieten“ erfüllt das Kriterium nicht, unabhängig davon, was sie sonst erlaubt. Merken Sie sich diesen Satz. Er bezeichnet die Grenze, die heutige source-available-Lizenzen überschreiten.

Bei der 1998 entstandenen Spaltung geht es um die Gründe, nicht darum, welche Lizenzen akzeptabel sind. Die Position der FSF ist ethisch begründet: Ein Benutzer, der das Programm nicht ändern kann, kontrolliert seinen eigenen Computer nicht. Die Position der OSI, die Raymond in seinem Essay „The Cathedral and the Bazaar“ gegenüber Unternehmen vertrat, ist praktisch: Offene Entwicklung führt zu besserer Software, und ein Unternehmen kann darauf aufbauen. Ställmans Antwort „Why Open Source Misses the Point of Free Software“ wird weiterhin auf gnu.org veröffentlicht, und er hat den neueren Begriff nie akzeptiert. Perens, der an seiner Entstehung beteiligt war, trat 1999 aus dem Vorstand der OSI zurück. Er begründete dies damit, dass sich die Bewegung von freier Software entfernt habe.

Es lohnt sich, genau zu betrachten, wie klein der praktische Abstand ist. Die Liste freier Lizenzen der FSF und die Liste der von der OSI anerkannten Lizenzen stimmen bei fast allen Einträgen überein, darunter GPL, MIT, Apache 2.0 und BSD. Autoren, die beide Bedeutungen gleichzeitig ausdrücken müssen, verwenden FOSS (free and open source software) oder FLOSS (free/libre and open source software).

Wie Unternehmen gelernt haben, Code zu veröffentlichen

Die Börsennotierung von Red Hat im Jahr 1999 zeigte, dass sich mit Support und Paketierung Geld verdienen ließ und nicht mit dem Verkauf von Kopien. IBM sagte 2001 eine Milliarde Dollar für Linux zu. Der CEO von Microsoft bezeichnete Linux 2001 als „Krebs“. Dasselbe Unternehmen trat 2016 als Platinum-Mitglied der Linux Foundation bei und kaufte 2018 GitHub für 7.5 Milliarden Dollar in Aktien. IBM kaufte Red Hat 2019 für 34 Milliarden Dollar. Nichts davon war ein Sinneswandel bei den Lizenzen. Geändert hatte sich nur, wo das Geld verdient wurde. Wenn ein Betriebssystem gemeinschaftlich finanziert wird, ist die Pflege eines eigenen Systems teuer. Daher konkurriert jeder Anbieter lieber auf der darüberliegenden Schicht.

Unternehmenseigentum wirkt sich auch in die andere Richtung aus. Als Oracle 2010 Sun kaufte, übernahm das Unternehmen MySQL und OpenOffice.org. Beide Communities wanderten ab. MariaDB entstand aus MySQL. LibreOffice wurde im September 2010 aus OpenOffice.org geforkt. Ein Fork ist die einzige echte Abstimmungsmöglichkeit einer Benutzer-Community. Die Lizenz macht diese Abstimmung möglich.

Warum einige der von Ihnen selbst gehosteten Anwendungen jetzt Forks haben

Ab 2018 änderte eine Gruppe von Unternehmen die Lizenzbedingungen für Software, die sie bereits veröffentlicht hatten. Die Situation war jedes Mal ähnlich. Ein Unternehmen beschäftigte fast alle Entwickler, ein deutlich größerer Cloud-Anbieter bot dieselbe Software als Managed Service an, und das kleinere Unternehmen kam zu dem Schluss, dass die Lizenz der Grund für seine mangelnde Wettbewerbsfähigkeit sei.

• MongoDB führte im Oktober 2018 die Server Side Public License (SSPL) ein. Die SSPL schreibt vor, dass Sie den Quellcode aller Komponenten veröffentlichen müssen, die Sie für die Bereitstellung der Software als Service verwenden, wenn Sie die Software anderen als Service anbieten. Die OSI erkannte sie nicht als Open Source an, und MongoDB zog sie 2019 aus der Prüfung zurück.
• Redis führte 2018 und 2019 Nutzungsbeschränkungen für einige Module ein und stellte den Hauptserver mit Version 7.4 im März 2024 auf doppelte source-available Lizenzbedingungen um. Tage später erschien ein Fork der letzten BSD-lizenzierten Version als Valkey unter dem Dach der Linux Foundation, unterstützt unter anderem von Amazon, Google und Oracle. Im Mai 2025 ergänzte Redis die Affero General Public License version 3 (AGPLv3) als dritte Option für Redis 8.
• Elastic stellte Elasticsearch und Kibana im Januar 2021 von Apache 2.0 auf eine Kombination aus SSPL und Elastic License um. Amazon erstellte den Fork OpenSearch. Elastic ergänzte AGPLv3 im August 2024 als dritte Option, und OpenSearch wurde im September 2024 als OpenSearch Software Foundation an die Linux Foundation übertragen.
• HashiCorp stellte Terraform und seine anderen Tools im August 2023 auf die Business Source License (BUSL) um. BUSL ist während ihrer Gültigkeitsdauer keine Open-Source-Lizenz, weil sie die konkurrierende Nutzung in Produktionsumgebungen untersagt. Jede Version wird an einem festgelegten Datum in eine offene Lizenz umgewandelt, bei Terraform vier Jahre später. OpenTofu wurde innerhalb weniger Wochen als Fork erstellt und steht inzwischen ebenfalls unter dem Dach der Linux Foundation.

Beide Seiten haben hier berechtigte Argumente, und keine handelt in böser Absicht. Ein Unternehmen, das fünfzig Gehälter bezahlt, während ein deutlich größerer Konzern seine Arbeit weiterverkauft, hat ein Problem, das sich nicht durch guten Willen lösen lässt. Auch ein Benutzer, der auf Grundlage der Apache-2.0-Bedingungen entwickelt hat und plötzlich unter neuen Bedingungen steht, hat ein Problem. Niemand hat ihn vorher gefragt. Achten Sie darauf, was in zwei dieser Fälle als Nächstes geschah. Nachdem sich die Forks etabliert hatten, nahmen Elastic und Redis beide wieder starkes Copyleft auf. Copyleft beantwortete die ursprüngliche Beschwerde, weil AGPLv3 einen Serviceanbieter verpflichtet, die von ihm eingesetzten Änderungen zu veröffentlichen. Im August 2026 sind beide Projekte und beide Forks weiterhin aktiv. Genau dieses Ergebnis sollten die Lizenzen ermöglichen.

Wer eine Lizenz ändern darf

Ein Projekt kann nur dann unter eine andere Lizenz gestellt werden, wenn eine Partei das Urheberrecht an allen Bestandteilen kontrolliert. Unternehmen erlangen diese Kontrolle auf zwei Wegen. Bei einer Übertragung des Urheberrechts geht das Eigentum an jedem Beitrag auf das Unternehmen über. Eine Contributor License Agreement (CLA) belässt das Eigentum bei Ihnen, gewährt dem Unternehmen aber ausreichend weitreichende Rechte, um Ihre Arbeit unter eine andere Lizenz zu stellen. In der Regel wird eine dieser Vereinbarungen durch Klicken auf einen Link unterzeichnet, den ein Bot bei Ihrem ersten Pull Request veröffentlicht.

Für Linux gibt es keine CLA. Beiträge werden unter GPLv2 mit einem Developer Certificate of Origin eingereicht, und das Urheberrecht ist auf Tausende von Personen und Unternehmen verteilt. Niemand kann Linux unter eine andere Lizenz stellen, weil niemand jemals alle diese Unterschriften einholen könnte. Derselbe Schutz gilt für jedes Projekt mit vielen unabhängigen Urheberrechtsinhabern. Er ist stärker als eine Zusage, weil er auf der tatsächlichen Zuordnung der Eigentumsrechte beruht.

Die entscheidende Frage bei Software, von der Sie abhängig sein möchten, lautet daher nicht, ob sie heute Open Source ist. Entscheidend ist, wer die Lizenz ändern könnte und ob diese Person oder Organisation dies allein tun könnte.

Was eine Foundation tatsächlich leistet

Eine Foundation verwaltet die Vermögenswerte und legt die Regeln für Entscheidungsprozesse fest. Die Apache Software Foundation, die Linux Foundation, die darin angesiedelte Cloud Native Computing Foundation und die Software Freedom Conservancy erfüllen diese Aufgabe jeweils auf ihre eigene Weise. Eine Foundation ist nicht automatisch neutral. Mitglieder bezahlen für ihre Sitze, und die meisten Personen, die hauptberuflich an einem großen Foundation-Projekt arbeiten, werden von Mitgliedsunternehmen bezahlt. Der konkrete Vorteil ist enger gefasst und dennoch erheblich: Die Marke und der Release-Prozess gehören nicht einem einzelnen Anbieter. Dadurch kann kein einzelnes Unternehmen das Projekt in ein proprietäres Projekt umwandeln.

Die Marke ist der Aspekt, den viele übersehen. Code steht unter einer Lizenz. Ein Name ist eine Marke, und eine Marke wird nicht durch die Codelizenz abgedeckt. Sie können den Code jederzeit forken. Den Namen dürfen Sie in der Regel nicht weiterverwenden. Deshalb heißen die Forks in dieser Geschichte Valkey, OpenSearch, OpenTofu und Forgejo.

Das Maintainer-Problem

Moderne Infrastrukturen basieren auf Projekten mit ein oder zwei unbezahlten Maintainerinnen oder Maintainer. Erst die daraus entstehenden Fehler machen dieses Problem sichtbar. Die Heartbleed-Sicherheitslücke in OpenSSL traf 2014 eine Bibliothek, die einen großen Teil des verschlüsselten Webverkehrs verarbeitete und von nur wenigen Personen mit nahezu keinen finanziellen Mitteln betreut wurde. Log4Shell leitete im Dezember 2021 die weltweite Reaktion auf Sicherheitsvorfälle an ein kleines freiwilliges Team im Apache-Log4j-Projekt weiter.

Die im März 2024 entdeckte Hintertür in XZ Utils ist das deutlichste Beispiel, weil sich der Angriff gegen den Maintainer und nicht gegen den Code richtete. Ein Benutzerkonto leistete etwa zwei Jahre lang tatsächlich nützliche Beiträge zu einer Komprimierungsbibliothek, die in zahlreichen Linux-Distributionen verwendet wird. Andere Benutzerkonten setzten den erschöpften alleinigen Maintainer unter Druck, Hilfe anzunehmen. Der neue Co-Maintainer pflanzte anschließend eine Hintertür in die Release-Archive ein. Sie zielte auf Systeme, deren SSH-(Secure-Shell-)Daemon gegen liblzma gelinkt ist. Ein Entwickler entdeckte sie, als er untersuchte, warum Anmeldungen etwa eine halbe Sekunde länger als erwartet dauerten. Das war Glück, und alle Beteiligten haben dies öffentlich bestätigt.

Geld fließt inzwischen: über GitHub Sponsors seit 2019, Open Collective, den deutschen Sovereign Tech Fund seit 2022 und das Alpha-Omega-Projekt der OpenSSF. Es kommt ungleichmäßig an und erreicht meist die Projekte, die bereits bekannt sind. Auch die Regulierung kommt. Der Cyber Resilience Act der Europäischen Union trat im Dezember 2024 in Kraft. Die meisten seiner Pflichten gelten ab Dezember 2027. Frühe Entwürfe hätten unbezahlten Freiwilligen die Herstellerhaftung auferlegt. Der endgültige Text schafft daher nach langem Lobbying durch Stiftungen und Distributionen eine weniger weitreichende Kategorie namens „Open-Source-Software-Verwalter“.

Was die Geschichte von Open Source für die Software auf Ihrem VPS bedeutet

Jede Anwendung in unseren Self-Hosting-Anleitungen steht am Ende einer Entwicklung, die durch diese Entscheidungen geprägt wurde. Nextcloud existiert aufgrund eines Forks: 2016 verließen der Gründer von ownCloud und ein großer Teil des Teams das Projekt und starteten es unter AGPLv3 neu. Seitdem werden beide Produkte parallel weiterentwickelt. Diese Geschichte bildet den Hintergrund für die erwähnenswerten Nextcloud-Alternativen und für die selbst gehosteten Dropbox-Alternativen, die mit beiden Produkten konkurrieren.

Dasselbe Muster zeigt sich bei Git-Hosting. Gitea begann 2016 selbst als Fork von Gogs. Ende 2022 gingen die Marke und die Domains des Projekts an ein Unternehmen über. Codeberg erstellte im Dezember desselben Jahres einen Fork namens Forgejo. Forgejo wechselte 2024 mit Version 9 von MIT zu GPLv3. Beide Projekte werden in den Optionen für selbst gehostete Git-Server behandelt. Der Lizenzunterschied ist ein wesentlicher Grund dafür, dass sie sich weiter auseinanderentwickeln. Gleichzeitig wird der Großteil freier Software auf GitHub entwickelt, einer geschlossenen Plattform im Besitz von Microsoft. Das ist ein altbekanntes Argument mit guten Punkten auf beiden Seiten: siehe was GitHub tatsächlich ist.

Bevor Sie einen Server einem Projekt widmen, sind vier Prüfungen in zehn Minuten sinnvoll.

• Lesen Sie die Datei LICENSE im Repository, nicht die Marketingseite. Auf den Seiten steht noch lange „Open Source“, nachdem die Datei dem bereits widerspricht.
• Suchen Sie nach einer CLA oder einer Übertragung des Urheberrechts. Wenn es eine solche Regelung gibt, kann ein einzelner Inhaber die Bedingungen künftiger Releases ändern.
• Ermitteln Sie, wer das Urheberrecht hält: ein Unternehmen, viele Mitwirkende oder eine Stiftung.
• Zählen Sie die aktiven Maintainer. Bei einem einzigen Maintainer besteht für diese Person ebenso ein Risiko wie für Sie.

Nichts davon bedeutet, dass Sie Software eines einzelnen Anbieters vermeiden sollten. Vieles davon ist ausgezeichnet. Dass dafür bezahlt wird, ist oft überhaupt der Grund, warum die Software gepflegt wird. Es zeigt Ihnen, welchen Risiken Sie ausgesetzt sind. Wenn Sie entscheiden, was sich für Self-Hosting lohnt, nehmen Sie die Lizenz neben dem Speicherbedarf in den Vergleich auf.

Sie können einen Teil dieser Geschichte auf dem Rechner vor Ihnen lesen. Jedes Paket auf einem Debian- oder Ubuntu-System liefert seine eigenen Lizenzbedingungen mit:

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

Die erste Zahl gibt an, wie viele installierte Pakete eine Copyright-Datei enthalten. Auf einem kleinen VPS sind es normalerweise einige hundert. Der zweite Befehl gibt den Anfang der Datei für bash aus. Dort wird die GNU General Public License version 3 genannt. Eine fehlende Datei bedeutet, dass das Paket nicht gemäß den Debian-Richtlinien erstellt wurde. Das ist selten und sollte genauer geprüft werden, bevor Sie dem Paket vertrauen.

FAQ

Was ist der Unterschied zwischen freier Software und Open Source?

Sie umfassen nahezu denselben Satz an Lizenzen und unterscheiden sich darin, warum diese Lizenzen wichtig sind. „Freie Software“ ist der ältere Begriff. Er stammt aus dem Jahr 1985 von der Free Software Foundation. Das Argument ist ethischer Natur: Wer ein Programm nicht ändern kann, hat keine Kontrolle über den Computer. „Open Source“ wurde im Februar 1998 geprägt, um dieselben Lizenzen für Unternehmen verständlicher zu erklären. Das Argument ist praktischer Natur. Die Lizenzen GPL, MIT, BSD und Apache 2.0 stehen auf beiden offiziellen Listen. Autoren, die beides gleichzeitig meinen, verwenden FOSS oder FLOSS.

Ist source-available Software dasselbe wie Open Source?

Nein. Source-available bedeutet, dass Sie den Quellcode lesen können. Open Source bedeutet gemäß der Open Source Definition zusätzlich, dass die Lizenz nicht einschränken darf, wer die Software verwendet oder wofür sie verwendet wird. Die Lizenzen SSPL und Business Source License schränken die kommerzielle Nutzung durch Wettbewerber ein. Nach dieser Definition ist daher keine von beiden Open Source, obwohl beide ihren Quellcode veröffentlichen. Wenn Sie die Software nur selbst hosten, betrifft Sie diese Einschränkung möglicherweise nie. Wenn Sie darauf ein Produkt aufbauen möchten, lesen Sie vorher den Lizenztext genau.

Kann ein Unternehmen eine bereits erteilte Open-Source-Lizenz zurücknehmen?

Nicht für Code, den es bereits veröffentlicht hat. Diese Version bleibt unter der Lizenz, unter der sie veröffentlicht wurde. Genau deshalb konnten Forks wie Valkey und OpenTofu beim letzten Commit mit einer freizügigen Lizenz starten. Ein Unternehmen kann künftige Versionen jedoch unter neue Bedingungen stellen. Das ist nur möglich, wenn es über eine Übertragung der Urheberrechte oder eine Contributor License Agreement die Urheberrechte am gesamten Projekt kontrolliert. Projekte mit vielen unabhängigen Urheberrechtsinhabern, darunter Linux, kann niemand um lizenzieren.

Nach welcher Lizenz sollte ich bei selbst gehosteter Software suchen?

Für Software, die Sie selbst betreiben und nicht weiterverkaufen, bietet jede von der OSI genehmigte Lizenz wie GPL, AGPL, MIT oder Apache 2.0 alles, was Sie benötigen. Wichtiger ist die Frage, wer die Urheberrechte hält. Davon hängt ab, ob die Bedingungen später gegen Ihren Willen geändert werden können. Ein Projekt, dessen Rechte bei einer Stiftung oder bei vielen unabhängigen Mitwirkenden liegen, kann nicht gegen seine Nutzer um lizenziert werden. Ein Projekt eines einzelnen Anbieters mit einer Contributor License Agreement kann dagegen um lizenziert werden. Beide können gute Software sein. Nur eines davon kann die Regeln eigenständig ändern.