MIT, Apache, GPL, EUPL – was Sie wirklich wissen müssen

Zwei Lizenzfamilien

Open-Source-Lizenzen lassen sich in zwei Kategorien einteilen: Permissive Lizenzen (MIT, Apache 2.0, BSD) erlauben die Nutzung in proprietärer Software ohne Offenlegungspflicht. Copyleft-Lizenzen (GPL, LGPL, EUPL) verlangen, dass abgeleitete Werke unter derselben oder einer kompatiblen Lizenz veröffentlicht werden.

Für interne Design Systeme ist diese Unterscheidung zentral: Ein permissiv lizenziertes System kann in beliebigen Produkten eingesetzt werden. Ein Copyleft-lizenziertes System kann die Offenlegungspflicht auf das gesamte Produkt ausdehnen – je nach Lizenz und Art der Einbindung.

Permissive Lizenzen fordern typischerweise nur die Beibehaltung des Copyright-Hinweises. Der Code darf modifiziert, kommerziell genutzt und ohne Offenlegung der eigenen Änderungen weiterverteilt werden. Das macht sie zur bevorzugten Wahl für Komponentenbibliotheken und Design-System-Infrastruktur.

Copyleft-Lizenzen gehen einen Schritt weiter: Sie verlangen, dass abgeleitete Werke unter derselben (oder kompatiblen) Lizenz veröffentlicht werden. Die Stärke des Copyleft variiert erheblich: Die GPL v3 (starkes Copyleft) kann sich auf das gesamte Programm ausdehnen. Die LGPL (schwaches Copyleft) beschränkt die Pflicht auf die Bibliothek selbst. Die EUPL bietet schwaches Copyleft mit einer expliziten Kompatibilitätsliste.

Die vier wichtigsten Lizenzen im Detail

MIT ist mit über 70 % Marktanteil im npm-Ökosystem die de-facto-Standardlizenz. Ihre Stärke ist die Einfachheit: 171 Wörter, keine Einschränkungen außer Attribution. Ihre Schwäche: keine Patentklausel, kein Markenrecht, kein Datenschutz. Für Unternehmen, die ihre Komponentenbibliothek intern halten, ist MIT unproblematisch.

Apache 2.0 ist die ausgereifte Alternative für regulierte Branchen. Sie enthält eine explizite Patentlizenz – wer Code unter Apache 2.0 veröffentlicht, gewährt automatisch eine Lizenz auf relevante Patente. Zusätzlich fordert sie die Dokumentation von Änderungen (NOTICE-Datei). Für Unternehmen, die in patentintensiven Branchen operieren, bietet Apache 2.0 deutlich besseren Schutz als MIT.

GPL v3 ist die bekannteste Copyleft-Lizenz. Jedes Programm, das GPL-lizenzierten Code einbindet, muss selbst unter GPL veröffentlicht werden – inklusive Quellcode. Für Frontend-Projekte ist das selten praktikabel: Eine GPL-lizenzierte UI-Bibliothek in einer kommerziellen Webanwendung würde die Offenlegung der gesamten Anwendung erfordern. Deshalb ist GPL im npm-Ökosystem selten, aber nicht inexistent.

EUPL v1.2 ist die einzige Open-Source-Lizenz unter EU-Recht. Sie bietet schwaches Copyleft mit einer expliziten Kompatibilitätsliste: Abgeleitete Werke dürfen auch unter GPL v2/v3, LGPL, MPL, CECILL oder Apache 2.0 verbreitet werden. Der Gerichtsstand ist das zuständige Gericht des EU-Mitgliedstaats des Lizenzgebers.

Kompatibilitätsprobleme

Das häufigste Problem in der Praxis ist nicht die Lizenz einer einzelnen Bibliothek, sondern die Kombination verschiedener Lizenzen in einem Projekt. GPL v2 und Apache 2.0 sind inkompatibel – Code unter diesen Lizenzen darf nicht in einem Werk kombiniert werden. In Monorepos mit hunderten Paketen können solche Konflikte leicht übersehen werden.

Typische Problemszenarien: Eine React-Komponente (MIT) bindet eine Utility-Library (Apache 2.0) ein, die wiederum ein Parsing-Modul (GPL v2) nutzt. Die transitiven Abhängigkeiten erzeugen einen Lizenzkonflikt, der ohne automatisierte Prüfung nicht erkennbar ist.

Automatisierte Prüfung

Tools wie FOSSA, license-checker (npm) oder Licensee (GitHub) scannen Dependency-Bäume und identifizieren Lizenzkonflikte. Für Organisationen, die Design Systeme als Produkt an Dritte weitergeben, ist eine regelmäßige, automatisierte Lizenzprüfung keine optionale Best Practice, sondern eine Compliance-Anforderung.

# Schneller Überblick über alle Lizenzen im Projekt
npx license-checker --summary

# Build brechen bei problematischen Lizenzen
npx license-checker --failOn "GPL-3.0;AGPL-3.0;SSPL-1.0"

In CI/CD-Pipelines eingebunden, verhindern diese Tools, dass Pakete mit problematischen Lizenzen unbemerkt in die Codebasis gelangen. Die regelmäßige Prüfung ist besonders wichtig, weil sich Lizenzen ändern können – das „MIT-to-BSL”-Pattern zeigt, dass heute permissive Projekte morgen restriktiv werden können.

Entscheidungsmatrix

Für die Wahl der richtigen Lizenz für eigene Design-System-Komponenten:

Internes Design System, nicht an Dritte weitergegeben: MIT ist unkompliziert und ausreichend. Apache 2.0, wenn Patentschutz relevant ist.

Design System als Open-Source-Projekt: EUPL für maximale europäische Rechtssicherheit. Apache 2.0 für maximale Adoption in der internationalen Community.

Komponenten in Kundenprojekten: Jede Lizenz im Dependency-Baum muss kompatibel mit dem Kundenprojekt sein. Automatisierte Prüfung ist Pflicht.

Kernpunkte

• Permissive Lizenzen erlauben proprietäre Nutzung, Copyleft-Lizenzen fordern Offenlegung abgeleiteter Werke.
• MIT ist Standard im npm-Ökosystem, bietet aber keinen Patentschutz – Apache 2.0 ist die bessere Wahl für regulierte Branchen.
• GPL-lizenzierter Code in transitiven Abhängigkeiten kann die Offenlegungspflicht auf das gesamte Projekt ausdehnen.
• Die EUPL ist die einzige Open-Source-Lizenz unter EU-Recht mit schwachem Copyleft und breiter Kompatibilität.
• Lizenzkombinationen in Monorepos können zu versteckten Konflikten führen – automatisierte Prüfung ist unverzichtbar.
• Lizenzen können sich ändern: Regelmäßige Prüfung schützt vor dem „MIT-to-BSL”-Risiko.