Es gibt einen Moment, der in fast jedem größeren Projekt irgendwann kommt. Irgendwer — meistens ein Jurist oder ein nervöser Einkauf — fragt: „Welche Lizenz soll das eigentlich bekommen?"

Bis dahin lief alles wunderbar. Code geschrieben, Tests grün, Repository gepusht. Und plötzlich diskutieren Leute über Copyleft, Patentklauseln und abgeleitete Werke, als hinge davon alles ab.

In gewisser Weise hängt davon auch alles ab.

Lizenzen sind keine Formalität. Sie sind die Spielregeln, unter denen Software existiert. Wer sie ignoriert, spielt trotzdem — nur nach Regeln, die jemand anderes bestimmt.

Warum es so viele Lizenzen gibt

Die kurze Antwort: Weil Freie Software zwei Bewegungen hatte, die nie ganz dieselben waren.

Auf der einen Seite Richard Stallman und die 1985 gegründete Free Software Foundation mit einer klaren ethischen Position: Software, die man nicht studieren, verändern und weitergeben darf, entzieht ihren Nutzern grundlegende Freiheiten. Daraus entstand die GPL — starkes Copyleft, ansteckend, kompromisslos.

Auf der anderen Seite die Pragmatiker aus der Berkeley-Unix-Tradition und später die 1998 gegründete Open Source Initiative (OSI), die Freie Software eher als effizientes Entwicklungsmodell begriffen denn als moralische Pflicht. Daraus kamen die permissiven Lizenzen — MIT, BSD — kurz, liberal, kommerzialisierungsfreundlich.

Zwischen diesen Polen entstand ein Spektrum. Dazu kamen Anwälte, Firmeninteressen, Patente, Kompatibilitätsnöte und der ständige Drang, das Rad neu zu erfinden. Heute listet SPDX über dreihundert gültige Lizenzbezeichnungen. Niemand kennt alle. Man muss es auch nicht. Aber man sollte die wichtigen kennen.

Zwei Familien, eine Grundfrage

Im Kern antwortet jede Lizenz auf dieselbe Frage: Was darf jemand anderes mit meinem Code anfangen — und was muss er dafür zurückgeben?

Permissive Lizenzen geben fast alles frei. Verwenden, modifizieren, verkaufen, in proprietäre Produkte einbetten — solange mein Name im Copyright-Hinweis stehen bleibt. Gebt mir Anerkennung, behaltet den Rest.

Copyleft-Lizenzen fordern dagegen Gegenseitigkeit. Wer meinen Code verändert und weitergibt, muss seine Versionen unter derselben Lizenz freigeben. Was du empfängst, gibst du weiter.

Schwache Copyleft-Lizenzen liegen dazwischen: Sie infizieren nur die Bibliothek, nicht das Programm, das sie einbindet. Ein Kompromiss, der Bibliotheksautoren schützt, ohne Anwender zu verprellen.

Mit diesem Raster lassen sich die bekannten Lizenzen ordnen.

Die Lizenzen, die man kennen sollte

MIT. Die kürzeste ernsthafte Lizenz der Welt. Rund 170 Wörter. Erlaubt praktisch alles, verlangt nur den Copyright-Hinweis. React, Ruby on Rails, jQuery, Kubernetes-Clientbibliotheken — alles MIT. Wer maximale Verbreitung will, wählt MIT.

BSD. Existiert in drei relevanten Varianten. Die 2-Klausel-Version ähnelt praktisch der MIT. Die 3-Klausel-Version verbietet zusätzlich die Verwendung des Autorennamens für Werbung eigener Derivate. Die historische 4-Klausel-Variante verlangte sogar eine Nennung in jedweder Produktwerbung — was bei hunderten Abhängigkeiten zu absurden Copyright-Hinweisen führte und lange Zeit die Aufnahme von BSD-Code in GPL-Projekte unmöglich machte. FreeBSD, nginx, PostgreSQL verwenden BSD-Varianten.

Apache 2.0. Die erwachsene Variante der permissiven Familie. Veröffentlicht 2004, ergänzt MIT und BSD um drei Dinge, die in der Praxis zählen: eine explizite Patentlizenz (wer Code beisteuert, räumt Nutzern seine Patente ein), eine Retaliationsklausel (wer wegen Patenten klagt, verliert seine Rechte) und die Pflege einer NOTICE-Datei für Attributionen. Apache Kafka, der Kubernetes-Core, TensorFlow stehen unter Apache 2.0. Für kommerzielle Stacks oft die beste Wahl.

GPL v2. Seit 1991 der Klebstoff des Linux-Kernels. Starkes Copyleft: Wer Derivate weitergibt, muss deren vollständigen Quellcode ebenfalls unter GPL v2 offenlegen. Bewusst knapp gehalten, bewusst ohne Patentklausel. Die berühmteste Einzelbestimmung heißt „Liberty or Death" — wenn du die Bedingungen nicht erfüllen kannst, darfst du auch gar nicht weitergeben.

GPL v3. Überarbeitet 2007, nachdem Patente, DRM und geschlossene Geräte („Tivoisierung") neue Angriffsvektoren gegen Freie Software eröffnet hatten. Ergänzte die Patentlizenz, verlangte bei Geräten die Herausgabe von Installationsinformationen, schrieb Anti-Umgehungs-Klauseln fest und verbesserte die Kompatibilität mit anderen Lizenzen. Politisch umstritten, juristisch sauberer. Viele große Projekte blieben bei v2 (Linux), andere migrierten (Bash, GCC, Samba).

LGPL v2.1 und v3. Die „Lesser"-Varianten. Schwaches Copyleft für Bibliotheken: Wer die Bibliothek verändert und weitergibt, muss die Änderungen unter LGPL stellen — aber Programme, die lediglich gegen die Bibliothek linken, dürfen proprietär bleiben. Der klassische Deal: Schutz der Bibliothek, Freiheit für den Konsumenten. glibc, GTK, Qt (zeitweise) stehen unter LGPL.

MPL 2.0. Mozillas Eigenbau, Januar 2012. Schwaches Copyleft auf Dateiebene: Wer einzelne MPL-Dateien ändert und weitergibt, muss diese Dateien unter MPL freigeben — der Rest eines Programms darf proprietär bleiben. Sauber definiert, pragmatisch, beliebt bei Firmenkonsortien. Firefox, Thunderbird, zahlreiche Rust-Crates verwenden MPL.

AGPL v3. Die Netzwerk-GPL. Sie schließt die sogenannte ASP-Lücke: Klassisches Copyleft triggert erst beim Weitergeben der Software. Wer sie aber nur als Dienst im Netz betreibt, gibt nichts weiter — und musste bisher keinen Quellcode offenlegen. Die AGPL drehte das um: Bereits die netzwerkseitige Nutzung löst die Offenlegungspflicht aus. Beliebt bei SaaS-Anbietern, die Wettbewerbern das ungefragte Hosting ihrer Arbeit erschweren wollen. Mastodon, Nextcloud, Plausible Analytics, MinIO.

EPL. Die Eclipse Public License, IBM-traditioniert, aktuell in Version 2.0. Schwaches Copyleft ähnlich MPL, mit klarer Patentlizenz und ausdrücklicher Kommerzialisierungsfreundlichkeit. Eclipse IDE, Jakarta EE, die meisten Java-Stiftungsprojekte, Adoptium/Temurin-JDKs. Häufig die pragmatische Alternative, wenn GPL-geschäftsscheu, aber BSD-permissiv zu schwach wirkt.

Unlicense und CC0. Die radikalen. Beide verzichten vollständig aufs Urheberrecht — soweit das in einzelnen Rechtsräumen überhaupt möglich ist. Unlicense (2010) zielt direkt auf Software, CC0 (2009, Creative Commons) ursprünglich auf Daten, Kunstwerke und Texte. Beide haben ein Problem: Wo das Urheberrecht unverzichtbar ist (Deutschland etwa), bleibt rechtlich Unsicherheit. Zudem enthält CC0 keine Patentklausel. Für robuste Produktionssysteme empfiehlt sich deshalb meist MIT statt CC0.

Was Lizenzen einschränken oder ermöglichen

Konkret steuern Lizenzen fünf Achsen:

  1. Nutzung — Darf ich das kommerziell einsetzen? Bei allen hier Genannten: ja.
  2. Modifikation — Darf ich den Code ändern? Ja, überall.
  3. Weitergabe — Unter welchen Bedingungen? Hier trennt sich die Schar.
  4. Patente — Bekomme ich eine ausdrückliche Patentlizenz? Nur Apache 2.0, GPLv3, MPL 2.0, EPL 2.0, AGPL v3.
  5. Netzwerknutzung — Löst Hosting eine Offenlegungspflicht aus? Nur AGPL.

Dazu kommen Nebenpunkte: Markenrechte (bleiben stets beim Ursprungsprojekt), Haftungsausschluss (überall), Attribution (überall) und Kompatibilität miteinander — ein eigenes Feld, in dem ganze Anwaltskanzleien ihr Geld verdienen. Die bittere Wahrheit: Lizenzen sind nicht notwendigerweise untereinander kombinierbar. GPLv2-Code lässt sich nicht mit Apache-2.0-Code mischen, ohne eine Ausnahmeregel. CDDL und GPL gelten als inkompatibel — Grundlage jahrelanger Streitigkeiten um ZFS-on-Linux.

Geschichten, die man kennen sollte

Das BusyBox-Massaker. Ab 2007 verfolgten Erik Andersen, die Software Freedom Law Center und später die Software Freedom Conservancy rund vierzehn Elektronikhersteller — Verizon, Samsung, Best Buy, Westinghouse —, weil diese Router, Festplattenrekorder und Kameras mit eingebettetem BusyBox auslieferten, ohne den angepassten Quellcode zugänglich zu machen. Die Klagen endeten in Vergleichszahlungen und richtungsweisenden Unterlassungsverfügungen. Sie bewiesen: Die GPL ist durchsetzbar. Wer Copyleft-Code nimmt und die Bedingungen ignoriert, hat ein echtes rechtliches Risiko.

Der Linksys WRT54G und die Geburtsstunde von OpenWrt. 2003 entdeckten Bastler, dass der damals enorm beliebte WLAN-Router Linksys WRT54G intern auf Linux und BusyBox lief — beides GPL-lizenziert. Linksys, inzwischen zu Cisco gehörend, hatte den Quellcode nicht veröffentlicht. Nach Kontaktaufnahme durch die Free Software Foundation und Bradley Kuhn veröffentlichte Cisco schließlich den gesamten Quellbaum. Was als Compliance-Ereignis begann, wurde zu einem der fruchtbarsten Momente der Verbraucher-IT: aus dem freigegebenen Code entstanden OpenWrt, DD-WRT, Tomato und eine ganze Generation quelloffener Router-Firmware. Millionen Geräte, die ihre Hersteller längst vergessen haben, werden bis heute von einer Community gepflegt. Lehre: Durchgesetztes Copyleft schafft nicht nur Pflichterfüllung — es kann ein ganzes Ökosystem entfesseln.

Reacts BSD-plus-Patents-Episode. Facebook veröffentlichte React 2013 zunächst unter Apache 2.0 und wechselte 2014 zu einer modifizierten BSD-Lizenz mit angebundenem Patentrider: Wer Facebook wegen Patentverletzung verklagt, verliert sofort seine Rechte an React. Im Juli 2017 stuften die Apache Software Foundation sowie Jenkins, WordPress und andere das als nicht tragfähig ein. Innerhalb weniger Wochen verlor React einen erheblichen Teil seines institutionellen Vertrauens. Im September 2017 kapitulierte Facebook und stellte React, Jest, GraphQL und Immutable.js auf reines MIT um. Lehre: Eine Lizenz, die asymmetrische Klauseln versteckt, kann ein ganzes Ökosystem gefährden.

HashiCorps Kehrtwendung. Im August 2023 gab HashiCorp bekannt, Terraform, Vault, Consul und weitere Projekte von MPL 2.0 auf die Business Source License (BSL) umzustellen — eine quelloffene Lizenz, die Wettbewerbern das Angebot konkurrenzfähiger Managed Services untersagt. Jahrelang hatten Nutzer und Contributoren die Projekte unter MPL vertraut. Die Community reagierte mit OpenTofu, einem Fork unter MPL, inzwischen gehütet durch die Linux Foundation. HashiCorp hat seinen Ruf als Open-Source-Vorreiter weitgehend verspielt.

Redis’ abrupte Wende. Im März 2024 änderte Redis Ltd. über Nacht die Lizenz seiner namensgebenden Datenbank von BSD 3-Clause auf ein Dual-License-Modell aus RSALv2 und SSPL. Beide gelten nicht mehr als Open Source im Sinne der OSI. Große Cloud-Anbieter — AWS, Google, Oracle, Snap — reagierten innerhalb von Tagen mit Valkey, einem Fork unter BSD 3-Clause, mittlerweile gehostet unter der Linux Foundation. Redis verlor binnen Wochen einen beträchtlichen Anteil seines Enterprise-Marktes.

MinIOs bewusster AGPL-Schritt. Anders als HashiCorp und Redis wählte MinIO, der S3-kompatible Objektspeicher, 2021 einen Weg, der innerhalb von Open Source blieb. Das Unternehmen wechselte vom permissiven Apache 2.0 auf AGPL v3 — eine echte, OSI-anerkannte Lizenz. Ziel: Cloud-Anbieter daran hindern, MinIO als Managed Service anzubieten, ohne Veränderungen offenzulegen. Die AGPL aktiviert genau dort, wo klassisches Copyleft wirkungslos bleibt: bei netzwerkbasierter Nutzung. Wer MinIO als Dienst betreibt und anpasst, muss seine Modifikationen unter AGPL freigeben. Der entscheidende Unterschied zu BSL oder SSPL: MinIO blieb quelloffen. Contributoren wurden nicht ausgesperrt, Forks blieben legitim, die Lizenz bleibt kompatibel mit dem breiten GPL-Ökosystem. Lehre: Wer sich vor kommerzieller Kannibalisierung schützen will, muss Open Source nicht verlassen — er muss die richtige Lizenz wählen.

CentOS und die Grenzen des Lizensierten. Die wohl berühmteste Geschichte spielt 2020/2023. Seit 2004 war CentOS ein Community-Rebuild von Red Hat Enterprise Linux — RHEL ohne Branding, kostenlos, binärkompatibel. 2014 übernahm Red Hat das Projekt, holte es ins Haus, bezahlte Maintainer. Alles schien in bester Ordnung. Im Dezember 2020 kam die Wende: Red Hat erklärte CentOS Linux 8 zum Jahresende 2021 für beendet und ersetzte es durch CentOS Stream — einen rollierenden Upstream-Kanal für RHEL statt einer stabilen Downstream-Distribution. Tausende Produktionssetups, die auf CentOS als kostenlosem RHEL-Substitut gebaut waren, standen vor dem Umzug. Die Community antwortete mit Rocky Linux (initiiert von Gregory Kurtzer, einem der ursprünglichen CentOS-Gründer) und AlmaLinux. Im Juni 2023 folgte der nächste Schlag: RHEL-Quellcode wurde nicht mehr als frei herunterladbare Tarballs veröffentlicht, sondern nur noch Kunden über das Red Hat Customer Portal zugänglich gemacht. Die GPL wurde nicht verletzt — der Code blieb für Bezugsberechtigte offen. Aber die Lücke, die Clone-Distributionen ermöglichte, war geschlossen. Lehre: Eine korrekte Lizenz allein schützt nicht vor strategischem Kurswechsel. Wer auf ein Projekt baut, muss neben der Lizenz auch die Governance, die Finanzierung und die Interessen des Stammhalters lesen.

Kannibalisierung unter dem Deckmantel des Schutzes

Diese Episoden sind keine Einzelfälle. Sie gehören zu einem Trend, der seit 2018 Fahrt aufnimmt: MongoDB (SSPL, Oktober 2018), Elastic (Elasticsearch und Kibana von Apache 2.0 auf SSPL, Januar 2021), Sentry, Cockroach Labs, Confluent — die Liste ließe sich fortsetzen. Gemeinsames Muster: Projekte bauen über Jahre eine Contributorschaft und Marke unter einer permissiven oder schwachen Copyleft-Lizenz auf. Sobald jedoch ein großer Cloud-Anbieter das lukrativere Managed-Service-Geschäft dominiert, tauscht der Stammhalter die Lizenz gegen ein Modell, das exakt dieses Geschäft abschirmt.

Manchmal ist das legitim. Maintainer haben ein Recht auf wirtschaftliche Nachhaltigkeit, und Open Source war nie gleichbedeutend mit unbezahlter Ausbeutung. Aber die Art der Umsetzung entscheidet: Wer Contributions unter der alten Lizenz annimmt und anschließend dieselben Contributoren mit der neuen Lizenz aussperrt, bricht einen impliziten Gesellschaftsvertrag. Das Resultat ist nicht mehr Open Source — und das Ökosystem lernt, dass solche Projekte jederzeit zum Risikofaktor werden können.

Für Beschaffer bedeutet das: Lizenzstabilität ist ein Auswahlkriterium geworden, kein Detail.

Was das für libcom.de bedeutet

Seit einem Vierteljahrhundert arbeite ich — Jochen Demmer, libcom.de — mit Open-Source-Produkten. Angefangen 2001, als Linux sich als Server-Betriebssystem etablierte. Mittlerweile trägt es globale Bankinfrastrukturen, Telekommunikationsnetze, Krankenhaus-IT und Industrieanlagen.

Aus dieser Erfahrung kommen Urteile, die kein Whitepaper lehrt: Welche Lizenzen sich in regulatorisch sensiblen Umfeldern bewähren, wo Copyleft tatsächlich haftet, wann AGPL eine Warnflagge statt einer Empfehlung ist, wie man Rug-Pull-Risiken frühzeitig erkennt, indem man Governance, Finanzierung und Contributor-Struktur liest — nicht nur die README. Wer eine Compliance-Strategie braucht, einen Stack auditiert, eine Ausschreibung formuliert oder eine Migrationsplanung begleitet — das sind Aufgaben, bei denen Lizenzkenntnis den Unterschied zwischen gelassener Mehrjahresplanung und überraschter Neuverhandlung macht.

Und ich sehe keinen Zukunftsweg mehr für rein proprietäre Lizenzen in der breiten IT-Infrastruktur. Die Gründe sind empirisch: Die wichtigsten Betriebssysteme, Datenbanken, Webserver, Container-Runtimes, Orchestratoren, Build-Systeme und Sprachcompiler sind Open Source. Selbst die größten proprietären Anbieter bauen heute auf Open Source — Apples Darwin-Wurzeln, Androids Linux-Kernel, Microsofts Visual-Studio-Code-Basis. Wer 2026 noch glaubt, Closed Source sei der sicherere Weg, übersieht, dass seine vermeintlich sichere Lieferkette längst aus Freier Software besteht. Proprietäre Lizenzen mögen in engen Hochspezialisierungen weiterexistieren. In der Breite sind sie nicht mehr zeitgemäß.

Open Source ist der neue De-facto-Standard. Nicht aus Ideologie. Aus Leistung, Transparenz, Prüfbarkeit und Langfristigkeit.

Wenn Sie sich fragen, ob Ihre IT-Stacks lizenztechnisch robust sind, ob eine bestimmte Abhängigkeit ein Risiko darstellt, oder wie eine Compliance-Strategie für Ihre Umgebung aussehen könnte: Schreiben Sie an contact@libcom.de. Wir machen eine ehrliche Bestandsaufnahme. Ohne Verkaufsdruck. Mit dem Blick auf das, was langfristig Bestand hat.

Freie Software ist nicht die Lösung für jedes Problem. Aber sie ist die einzige Lösungsgruppe, bei der die Spielregeln nachlesbar bleiben — auch in zwanzig Jahren.

Hinweis: Dieser Artikel bietet allgemeine Orientierung und ersetzt keine Rechtsberatung. Lizenzfragen können einzelfallabhängig sein; alle Angaben erfolgen ohne Gewähr.