KI- und Open-Source-Softwarelizenzen erklärt: MIT vs. Apache vs. GPL vs. AGPL vs. proprietär

Kurzfakten

• MIT ist die kürzeste und verbreitetste permissive Lizenz — rund 170 Wörter, keine Patentklausel.
• Apache-2.0 enthält eine explizite Patentgewährung, die MIT fehlt — deshalb bevorzugen viele Unternehmen sie für firmeneigene Projekte.
• GPL verlangt Quellcode-Offenlegung nur bei Verteilung der Software; AGPL-3.0 erweitert diese Pflicht auf den Betrieb als Netzwerkdienst.
• OSI-zertifizierte "Open Source" ist eine konkrete Zertifizierung der Open Source Initiative; "Source-Available" und "Fair-Code" sind Marketingbegriffe für Lizenzen, die diese Definition nicht erfüllen.
• KI-Modell-Lizenzen sind eine eigene Kategorie neben Codelizenzen. Der Code eines Tools kann Apache-2.0 sein, während die heruntergeladenen Modellgewichte völlig andere, restriktivere Bedingungen tragen.

Was sind permissive Lizenzen? MIT, Apache-2.0 und BSD

• Die MIT-Lizenz entstand am Massachusetts Institute of Technology als Möglichkeit, universitär entwickelte Software mit minimalen Einschränkungen freizugeben. Sie umfasst rund 170 Wörter, gewährt nahezu unbegrenzte Rechte und verlangt lediglich, dass der ursprüngliche Copyright- und Lizenztext bei jeder weitergegebenen Kopie oder wesentlichen Teilkopie erhalten bleibt.
• Die Apache License 2.0 stammt von der Apache Software Foundation, gegründet, um Unternehmen und Community-Mitwirkenden einen gemeinsamen rechtlichen Rahmen für große Gemeinschaftsprojekte zu geben. Anders als MIT enthält sie eine explizite Patentgewährung — Mitwirkende lizenzieren ihre den Code betreffenden Patentansprüche an Nutzer —, weshalb viele Unternehmen mit Patentportfolios sie bevorzugen.
• BSD-Lizenzen (2-Klausel und 3-Klausel) entstanden an der University of California, Berkeley, für das Betriebssystem Berkeley Software Distribution. Die 3-Klausel-Variante enthält zusätzlich eine Non-Endorsement-Klausel, die verbietet, die Namen der Originalautoren ohne Erlaubnis zur Bewerbung eines abgeleiteten Produkts zu nutzen.
• Praktische Auswirkung für Nutzer: Sie können ein permissiv lizenziertes Tool forken, verändern, einbetten und als Teil eines geschlossenen Produkts verkaufen, ohne je eigenen Quellcode zu veröffentlichen — das eigentliche Risiko besteht nur darin, den erforderlichen Copyright-/Lizenzhinweis bei der Weitergabe zu vergessen.
• Reale Beispiele aus den Reviews dieser Seite: Ollama und llama.cpp laufen beide unter MIT; vLLM unter Apache-2.0 — alle drei lassen sich ohne Offenlegungspflicht in ein kommerzielles Produkt einbetten.

Was ist Copyleft? Die GPL- und LGPL-Familie

• Die GNU General Public License (GPL) wurde von Richard Stallman und der Free Software Foundation als Lizenz für das GNU-Projekt geschrieben, basierend auf der Idee, dass Softwarefreiheit weitergegeben werden muss — wer eine veränderte Kopie erhält, soll dieselben Rechte haben wie der ursprüngliche Autor.
• GPL v2 und GPL v3 unterscheiden sich vor allem in Patentklauseln und Kompatibilitätsregeln; v3 fügte explizite Patent-Vergeltungs- und Anti-Tivoisierungsklauseln hinzu (die Hardware verhindern sollen, die Ihnen das Ausführen veränderter Software untersagt, obwohl Sie dazu rechtlich berechtigt sind).
• Die GNU Lesser General Public License (LGPL) lockert GPL speziell für Bibliotheken — Sie können eine LGPL-Bibliothek in eine proprietäre Anwendung einbinden, ohne die Anwendung selbst offenzulegen, solange die Bibliothekskomponente austauschbar bleibt und ihr eigener Quellcode verfügbar ist.
• Was die Pflicht tatsächlich auslöst: die Verteilung einer veränderten Kopie des GPL-Codes. Die bloße interne Nutzung unveränderter GPL-Software oder das Ausführen proprietärer Software auf einem GPL-lizenzierten Betriebssystem stellt Ihren eigenen Code nicht automatisch unter GPL.
• Wer vorsichtig sein sollte: Ein Startup, das ein GPL-Tool forken und als Kern eines kommerziellen Produkts verändern will, braucht einen Plan — entweder die Änderungen offenzulegen oder den Fork zu vermeiden; ein Unternehmen, das ein unverändertes GPL-Tool nur intern nutzt, hat diese Pflicht nicht.

Wie AGPL-3.0 die SaaS-Lücke schließt

• Die geschlossene Lücke: Unter reiner GPL gilt der Betrieb einer veränderten Version als gehosteter Webdienst nicht als "Verteilung" im rechtlichen Sinn, den die Lizenz auslöst — ein Unternehmen könnte GPL-Code nehmen, verändern, nur als SaaS-Produkt anbieten und müsste die Änderungen nie veröffentlichen. Das wurde informell als "ASP-Lücke" (Application Service Provider) oder "SaaS-Lücke" bekannt.
• AGPL-3.0 wurde gezielt geschrieben, um diese Lücke zu schließen, indem eine Netzwerk-Interaktionsklausel hinzukommt: Wer die Funktionalität der veränderten Software Nutzern über ein Netzwerk anbietet, löst dieselbe Offenlegungspflicht aus wie bei der Verteilung einer physischen Kopie.
• Warum das für Hosting und Weiterverkauf zählt: Eine Agentur oder ein Hosting-Anbieter, die ein AGPL-lizenziertes Tool nehmen, verändern und Kunden als gehosteten Dienst anbieten, müssen den veränderten Quellcode diesen Nutzern zugänglich machen — der unveränderte Betrieb löst diese Pflicht nicht aus.
• Reale Beispiele aus den Reviews dieser Seite: Jan, KoboldCpp, SillyTavern und text-generation-webui laufen unter AGPL-3.0 — für privates oder internes Self-Hosting unverändert unproblematisch; sobald Sie eines verändern und gehosteten Zugang weiterverkaufen, ändert sich die rechtliche Lage grundlegend.
• Dies ist eine allgemeine Erklärung des Lizenzmechanismus, keine Rechtsberatung — ob ein konkreter Einsatz als "Anbieten über ein Netzwerk" im genauen Wortlaut von AGPL-3.0 gilt, ist eine Frage für einen Anwalt, der Ihre spezifische Architektur prüft.

Was sind Source-Available- und "Fair-Code"-Lizenzen?

• Die Business Source License (BSL, auch BUSL genannt) gewährt zunächst Quellcode-Zugang und weitreichende Nutzungsrechte, mit einem festgelegten künftigen Datum, an dem die Lizenz in eine echte Open-Source-Lizenz übergeht (häufig Apache-2.0 oder eine ähnliche permissive Lizenz) — bis dahin gilt eine ausdrückliche Beschränkung der kommerziellen Nutzung, meist gegen ein konkurrierendes gehostetes Angebot gerichtet.
• Die Server Side Public License (SSPL), entwickelt von MongoDB, verlangt, dass jeder, der die Software als Dienst anbietet, den gesamten darum gebauten Dienst-Stack ebenfalls offenlegen muss — eine deutlich weitreichendere Pflicht als bei AGPL-3.0, bewusst darauf ausgelegt, kommerzielles Hosting für einen konkurrierenden Cloud-Anbieter unpraktikabel zu machen.
• Die Commons Clause ist eine Zusatzbeschränkung, die auf eine ansonsten permissive oder Copyleft-Basislizenz aufgesetzt wird und speziell den Verkauf der Software oder das Anbieten als kostenpflichtigen gehosteten Dienst verbietet, während freie Nutzung und Veränderung weiterhin erlaubt bleiben.
• Warum Projekte zu solchen Lizenzen wechseln: Ein Projekt, das unter einer vollständig offenen Lizenz startet und später zu einer Source-Available-Lizenz wechselt, reagiert typischerweise darauf, dass ein großer Cloud-Anbieter das Projekt als gehosteten Dienst anbietet, ohne zur Entwicklung beizutragen — der Wechsel zur Source-Available-Lizenz erhält die weitgehende Offenheit, blockiert aber diese spezifische konkurrierende Nutzung.
• Praktische Auswirkung für Nutzer: In der Regel dürfen Sie Source-Available-Software für interne Zwecke problemlos lesen, selbst hosten und verändern; die Beschränkung greift, sobald Sie versuchen, sie als gehostetes Produkt weiterzuverkaufen, das mit dem Angebot des Rechteinhabers konkurriert — lesen Sie die konkrete Klausel zur kommerziellen Nutzung, da die Formulierungen zwischen Projekten stark variieren.

Was bedeuten proprietäre und "kostenlose" Freemium-Lizenzen?

• "Kostenlos (geschlossen)" in einer Vergleichstabelle bedeutet kostenlose proprietäre Software. Sie dürfen die kompilierte Anwendung gemäß den Nutzungsbedingungen des Anbieters verwenden, haben aber keinen Zugang zum Quellcode und kein Recht, ihn zu verändern, zu prüfen oder zu forken.
• Der zentrale Kompromiss gegenüber Open-Source-Alternativen: Eine proprietäre kostenlose App ist oft ausgereifter und einfacher zu installieren, da ein einzelner Anbieter die gesamte Nutzererfahrung kontrolliert — Sie hängen aber vollständig von dessen fortgesetzter Bereitschaft ab, das Produkt kostenlos, sicher und gepflegt zu halten.
• Risiko der Anbieterbindung (Vendor Lock-in): Ohne Quellcode-Zugang können Sie keine veränderte Version selbst hosten, nicht genau prüfen, was die Anwendung mit Ihren Daten macht, und die Entwicklung nicht fortsetzen, falls der Anbieter die Pflege einstellt, das Preismodell ändert oder schließt.
• Wer besonders vorsichtig sein sollte: Wer einen Workflow oder Geschäftsprozess um ein proprietäres kostenloses Tool herum aufbaut, sollte einen dokumentierten Ausweichplan haben — dieselbe Sorgfalt, die Sie bei jeder Anbieterabhängigkeit anwenden würden, denn "kostenlos" bedeutet nicht "dauerhaft" oder "garantiert".
• Nicht dasselbe wie Source-Available: Source-Available-Lizenzen (BSL, SSPL) erlauben zumindest das Lesen und Prüfen des Codes, auch wenn die kommerzielle Nutzung eingeschränkt ist; ein vollständig proprietäres Tool bietet weder den Code noch diese Sicherheit.

Wie funktionieren KI-Modell-Lizenzen? Open Weights, RAIL und Nutzungsbeschränkungen

• Vollständig permissive Gewichte: Manche Modellfamilien veröffentlichen ihre Gewichte unter einer Standard-Softwarelizenz (meist Apache-2.0) und gewähren dieselben weitreichenden Nutzungsrechte, die diese Lizenz auch für Code gewährt — einschließlich kommerzieller Nutzung ohne Anwendungsbeschränkung.
• RAIL- und OpenRAIL-Lizenzen (Responsible AI License) entstanden mit BigSciences Veröffentlichung des Modells BLOOM und wurden gemeinsam mit Rechtsforschern entwickelt, um offenen Zugang mit einer konkreten Liste verbotener Nutzungen zu verbinden — üblicherweise das Erzeugen von Desinformation, diskriminierende Entscheidungsfindung oder rechtswidrige Inhalte, während kommerzielle Nutzung ansonsten breit erlaubt bleibt.
• Eigene "Community"- oder "Open-Weight"-Lizenzen: Mehrere große Modellanbieter veröffentlichen Gewichte unter einer maßgeschneiderten Lizenz, die wie eine offene Lizenz klingt, aber Anwendungsbedingungen hinzufügt. Das meistzitierte Beispiel ist die Community-Lizenz, die Meta an seine offen veröffentlichten Modellgewichte knüpft — sie erlaubt breite kostenlose Nutzung, fügt aber ab einer Nutzungsgrößenschwelle die Pflicht zu einer separaten kommerziellen Vereinbarung sowie Nutzungsbeschränkungen hinzu.
• Was konkret zu prüfen ist: ob kommerzielle Nutzung überhaupt erlaubt ist, ob eine Nutzungsgrößen- oder Umsatzschwelle die Bedingungen ändert, was die Acceptable-Use-Richtlinie verbietet, und ob die Lizenz einschränkt, mit den Modellausgaben ein konkurrierendes Modell zu trainieren — eine Einschränkung, die in mehreren modellspezifischen Lizenzen vorkommt und bei Standard-Softwarelizenzen kein Gegenstück hat.
• Dies ist keine Rechtsberatung — Modell-Lizenzbedingungen ändern sich zwischen Veröffentlichungen desselben Anbieters, prüfen Sie daher den genauen Lizenztext der konkreten Modellgewichte, die Sie einsetzen wollen, statt Kontinuität mit einer früheren Veröffentlichung derselben Organisation vorauszusetzen.

Wen betrifft welche Lizenz?

Checkliste vor der Tool-Auswahl: 7 Punkte vor dem Einsatz eines Tools

1. 1
   Die tatsächliche LICENSE-Datei im Repository lesen
   Why it matters: Eine "Open Source"-Aussage auf einer Landingpage kann Marketing sein, kein rechtlicher Fakt — die LICENSE- (oder NOTICE-/COPYING-)Datei im Quell-Repository ist das maßgebliche Dokument, kein Badge und keine Preisseite.
2. 2
   Prüfen, ob sich die Lizenz kürzlich geändert hat
   Why it matters: Manche Projekte wechseln nach kommerziellem Erfolg von einer permissiven oder Copyleft-Lizenz zu einer Source-Available-Lizenz — dieses Muster hat sich in der Softwarebranche wiederholt, seit Cloud-Anbieter beliebte Open-Source-Projekte hosten, ohne beizutragen. Prüfen Sie die Lizenzhistorie des Repositorys, nicht nur die aktuelle Datei.
3. 3
   Verifizieren, ob die Lizenz tatsächlich OSI-zertifiziert ist, falls das relevant ist
   Why it matters: Source-Available-Lizenzen wie BSL und SSPL werden oft als Open Source beworben, stehen aber nicht auf der Liste der von der Open Source Initiative anerkannten Lizenzen — wenn OSI-Zertifizierung für Ihren Anwendungsfall Pflicht ist, prüfen Sie die Liste direkt statt der Selbstbeschreibung eines Projekts zu vertrauen.
4. 4
   Klauseln zu kommerzieller Nutzung und Anwendungsbereich speziell bei KI-Modellen lesen
   Why it matters: Die Lizenz eines Modells kann kommerzielle Nutzung breit erlauben, ab einer Nutzungsgrößenschwelle einschränken oder bestimmte Anwendungen ganz verbieten — diese Klauseln liegen außerhalb der üblichen Softwarelizenz-Sprache und werden leicht übersehen, wenn nur die Codelizenz geprüft wird.
5. 5
   Klären, ob Self-Hosting oder SaaS-Hosting Ihre Pflichten ändert
   Why it matters: Unter AGPL-3.0 löst das Anbieten veränderter Software über ein Netzwerk dieselbe Offenlegungspflicht aus wie die Verteilung einer Kopie unter GPL — klären Sie, in welche Kategorie Ihr geplanter Einsatz fällt, bevor Sie den Code verändern.
6. 6
   Bei geplanten Beiträgen eine Contributor License Agreement (CLA) prüfen
   Why it matters: Eine CLA kann dem Projekt-Maintainer weitergehende Rechte an Ihrem Beitrag einräumen, als die Projektlizenz selbst Nutzern gewährt — relevant vor allem, wenn Sie Code an das Projekt zurückgeben wollen, nicht wenn Sie es nur nutzen.
7. 7
   Markenrechtliche Beschränkungen getrennt von der Codelizenz prüfen
   Why it matters: Eine permissive oder Copyleft-Codelizenz gewährt nicht automatisch Rechte am Namen oder Logo des Projekts — das Forken und Rebranding eines Tools kann durch Markenrecht blockiert sein, selbst wenn die Codelizenz den Fork sonst erlauben würde.

Häufige Fehler

• Der "Open Source"-Aussage einer Marketingseite vertrauen, statt die tatsächliche LICENSE-Datei im Repository zu lesen.
• Annehmen, AGPL-3.0 spiele nur eine Rolle bei der Verteilung einer Kopie — es gilt ebenso beim Anbieten veränderten Codes als gehosteten Dienst.
• Codelizenz und Modell-Gewichte-Lizenz eines KI-Modells als dasselbe Dokument behandeln — sie sind es häufig nicht.
• Ein Tool forken und umbenennen, ohne markenrechtliche Beschränkungen getrennt von der Codelizenz zu prüfen.
• Annehmen, eine anfangs permissive Lizenz gelte noch nach einer späteren Relizenzierung — die aktuelle Lizenz prüfen, nicht die erinnerte.
• Die Rechtsprüfung eines Copyleft- oder Source-Available-Tools überspringen, weil es "kostenlos" ist — kostenlos nutzbar und pflichtenfrei sind nicht dasselbe.

Quellen

• Open Source Initiative — The Open Source Definition — die formale Definition, die eine Lizenz erfüllen muss, um als OSI-zertifizierte Open Source zu gelten.
• GNU-Projekt — Free Software Licenses — die eigenen Erklärungen der Free Software Foundation zu GPL, LGPL und AGPL.
• Apache Software Foundation — Apache License 2.0 — vollständiger Lizenztext.
• MIT-Lizenztext (Open Source Initiative) — vollständiger Lizenztext.
• MongoDB — Server Side Public License — eigene Bedingungen und Begründung der SSPL.
• Business Source License FAQ — Erklärung, wie die BSL/BUSL-Umwandlung funktioniert, von einem prominenten Anwender der Lizenz.

Häufig gestellte Fragen

Weiterführende Artikel

• Das vollständige Local-LLM-Software-Verzeichnis — über 160 lokale LLM-Tools mit der jeweiligen Lizenz.
• Dify AI Workflow Builder Review — eine Review, die die Lizenz nennt; nutzen Sie diesen Leitfaden, um zu verstehen, was diese Lizenz für Ihren Einsatz bedeutet.
• KI-generierte Inhalte und IP-Risiko — die urheberrechtlichen Fragen, die neben der Lizenzierung stehen, wenn Sie KI-generierte Ausgaben kommerziell einsetzen.
• Agentic-AI-Sicherheit: Identität & Zugriff — Sicherheits- und Governance-Aspekte für selbst gehostete KI-Einsätze, ein Begleitthema zur Lizenz-Compliance.
• DSGVO-konformes lokales RAG für sensible Dokumente — Lizenzrisiko und Datenresidenz-/Compliance-Risiko sind getrennte Checklisten; dieser Leitfaden behandelt die Compliance-Seite.