Die MIT-Lizenz: Freiheit mit Fußnoten

Was die MIT-Lizenz erlaubt – und was nicht

Die MIT-Lizenz besteht aus nur 171 Wörtern. Ihr Kernversprechen: Die Software darf ohne Einschränkung genutzt, kopiert, modifiziert, zusammengeführt, veröffentlicht, verteilt, unterlizenziert und verkauft werden. Die einzigen Bedingungen sind die Beibehaltung des Copyright-Hinweises und des Lizenztextes in allen Kopien oder wesentlichen Teilen der Software.

Der oft übersehene zweite Absatz enthält den Haftungsausschluss: Die Software wird „as is” bereitgestellt, ohne jegliche Gewährleistung. Der Lizenzgeber haftet nicht für Schäden – gleich welcher Art. Für Unternehmen bedeutet das: Es gibt keine rechtliche Handhabe, wenn eine MIT-lizenzierte Bibliothek einen Bug enthält, der einen Produktionsausfall verursacht.

Wo die MIT-Lizenz irreführend ist

Die Permissivität der MIT-Lizenz verleitet zu einer gefährlichen Annahme: „MIT = kein Risiko.” In der Praxis stimmt das aus mehreren Gründen nicht:

Lizenz ≠ Governance. Eine MIT-Lizenz sagt nichts darüber aus, wer das Projekt kontrolliert. React ist MIT-lizenziert, aber Meta bestimmt die Roadmap. Next.js ist MIT-lizenziert, aber Vercel kontrolliert die Entwicklungsrichtung. Die Lizenz garantiert das Recht zur Nutzung und zum Fork – aber nicht die Fähigkeit, das Projekt eigenständig weiterzuentwickeln. Ein Fork ohne die Expertise und Ressourcen des Originalprojekts ist oft wirtschaftlich nicht tragbar.

Supply-Chain-Risiko. Ein MIT-lizenziertes npm-Paket hat im Durchschnitt 5–15 transitive Abhängigkeiten. Jede dieser Abhängigkeiten kann eine andere Lizenz haben, kompromittiert werden (Supply-Chain-Attack) oder aufgegeben werden (Abandonware). Der Fall event-stream (2018), bei dem ein populäres Paket an einen Angreifer übergeben wurde, zeigt das Risiko: Die MIT-Lizenz verhindert weder Maintainer-Wechsel noch Schadcode-Injection.

Keine Patentrechte. Im Gegensatz zur Apache-2.0-Lizenz enthält die MIT-Lizenz keine explizite Patentlizenz. Ein Unternehmen, das ein MIT-lizenziertes Projekt nutzt, könnte theoretisch von den Urhebern wegen Patentverletzung verklagt werden – auch wenn die Software unter einer Open-Source-Lizenz steht. In der Praxis ist dieses Risiko gering, für regulierte Branchen aber relevant.

Die „MIT aber eigentlich proprietär”-Falle

Ein zunehmend verbreitetes Muster: Projekte starten unter MIT-Lizenz, um Adoption zu maximieren, und wechseln dann zu einer restriktiveren Lizenz, sobald sie Marktdominanz erreicht haben. Prominente Beispiele sind Redis (von BSD zu SSPL zu Dual License), Elastic (von Apache 2.0 zu SSPL), HashiCorp (von MPL zu BSL), und Sentry (von BSD zu BSL). Für Organisationen, die solche Tools in ihrer Infrastruktur einsetzen, ist der Lizenzwechsel ein konkretes Geschäftsrisiko: Die bestehende Version bleibt nutzbar, aber Updates und Sicherheitspatches erfordern die neue Lizenz.

Was das für Design Systeme bedeutet

In der Praxis sind die meisten Headless-UI-Bibliotheken (Radix UI, Bits UI, Headless UI), Build-Tools (Vite, esbuild, SWC) und Token-Tools (Style Dictionary) MIT-lizenziert. Die Lizenz selbst ist unproblematisch – das Risiko liegt in der Kombination aus Abhängigkeit und Governance:

Wer Radix UI in sein Design System einbaut, hat eine funktionale Abhängigkeit von der Radix-Roadmap, auch wenn die MIT-Lizenz jederzeit einen Fork erlaubt. Ein Fork ist rechtlich trivial, aber wirtschaftlich und technisch aufwändig.

Die souveräne Strategie: MIT-lizenzierte Bibliotheken als Fundament nutzen, aber die eigene Architektur so gestalten, dass ein Austausch der Bibliothek möglich ist, ohne das gesamte Design System neu zu bauen. Headless-Bibliotheken sind dafür ideal: Sie liefern Verhalten, nicht Aussehen – ein Wechsel von Radix zu Ark UI erfordert Anpassung der Behavior-Bindings, nicht der visuellen Ebene.

Automatisierte Lizenzprüfung

Für Organisationen mit einer npm-basierten Codebasis ist eine regelmäßige Lizenzprüfung unverzichtbar:

npx license-checker --summary --failOn "GPL-3.0;AGPL-3.0"

Tools wie FOSSA, Snyk und license-checker scannen den gesamten Dependency-Baum und identifizieren Lizenzinkompatibilitäten. In CI/CD-Pipelines eingebunden, verhindern sie, dass Pakete mit problematischen Lizenzen unbemerkt in die Codebasis gelangen.

Kernpunkte

• Die MIT-Lizenz erlaubt kommerziellen Einsatz ohne Offenlegungspflicht – die populärste Wahl im JavaScript-Ökosystem.
• „MIT = kein Risiko” ist eine gefährliche Vereinfachung: Governance, Supply-Chain-Risiken und fehlende Patentrechte bleiben.
• MIT enthält keine Patentlizenz – Apache 2.0 bietet hier besseren Schutz für regulierte Branchen.
• Die „MIT-to-BSL”-Falle: Projekte wechseln zu restriktiveren Lizenzen, nachdem sie Marktdominanz erreicht haben.
• Lizenz und Governance sind getrennte Risiken – ein Fork ist rechtlich einfach, aber wirtschaftlich oft nicht tragbar.
• Automatisierte Lizenzprüfung in der CI/CD-Pipeline verhindert unbemerkte Lizenzinkompatibilitäten.
• Souveräne Architektur bedeutet: MIT-Bibliotheken nutzen, aber die Austauschbarkeit sicherstellen.