KI-Projekte bestehen selten aus „nur eigenem Code“. Typisch sind Frameworks, Bibliotheken, Container, vortrainierte Modelle, Build-Tools und manchmal Datenpakete. Jede Komponente bringt Lizenzbedingungen mit – und die gelten unabhängig davon, ob du „nur schnell etwas ausprobierst“ oder ein Produkt auslieferst.
Eine Software-Lizenz sagt dir, was du mit Software machen darfst und was du dabei tun musst. Ohne Lizenz (oder ohne Rechte) gilt grundsätzlich: du darfst Software nicht einfach kopieren, verändern oder verteilen.
Stell dir vor, du kaufst ein Buch. Du darfst es lesen. Du darfst es aber nicht ohne Erlaubnis kopieren und verkaufen. Bei Software ist es ähnlich – die Lizenz ist die Erlaubnis + Regeln.
Lizenzpflichten hängen oft an Triggern wie Verteilung (Distribution), Modifikation, Linkage/Integration und bei AGPL zusätzlich Network Use.
Sehr flexibel. Du darfst sie meist problemlos in kommerziellen Produkten nutzen – solange du die Hinweise mitlieferst.
„Teilen, wenn du verteilst“: Wenn du ein abgeleitetes Werk auslieferst, musst du Quellcode und Rechte weitergeben. AGPL erweitert das häufig auf Online-Nutzung über ein Netzwerk.
Diese Lizenzen sind „selektiv“. Pflichten greifen oft nur für bestimmte Teile (z. B. geänderte Dateien, Bibliotheks-Komponente) oder je nach Art der Verknüpfung. Das ist in der Praxis oft gut, wenn du Offenheit willst, aber nicht „alles anstecken“ möchtest.
Die Tabelle ist eine praxisnahe Orientierung. Details hängen immer vom konkreten Einsatz ab.
| Lizenz | Typ | Kommerziell nutzbar? | Typische Mindest-Pflichten | Wann kann Source fällig werden? |
|---|---|---|---|---|
| MIT / BSD | Permissiv | Ja | Lizenztext + Copyright-Hinweise | Meist nie (keine Copyleft-Pflicht) |
| Apache-2.0 | Permissiv | Ja | Lizenztext + NOTICE beachten, Änderungen kennzeichnen | Meist nie, aber Patent/NOTICE-Regeln einhalten |
| MPL-2.0 | Selektives Copyleft | Meist ja | Lizenz/Notices; MPL-Dateien bei Änderungen offenlegen | Bei Verteilung geänderter MPL-Dateien |
| LGPL | Schwaches Copyleft | Oft ja | Lizenz/Notices; Bedingungen rund um Linkage erfüllen | Für LGPL-Komponente (und je nach Integrationsart) |
| GPL | Copyleft | Eingeschränkt | Bei Verteilung: Source + gleiche Lizenz fürs abgeleitete Werk | Wenn du ein abgeleitetes Werk auslieferst |
| AGPL | Copyleft + Network | Eingeschränkt | Wie GPL + Netzwerk-Nutzung kann Source-Pflichten auslösen | Oft schon beim Angebot als Online-Service |
In Releases ist das meist eine THIRD_PARTY_NOTICES oder ein Ordner licenses/. Wichtig: Nicht nur „irgendwo“, sondern dort, wo Nutzer/ Kunden es real finden (Installer, About-Dialog, Paketverzeichnis).
Copyright-Hinweise im Code/Repository dürfen oft nicht entfernt werden. In der Praxis: beim Minify/Bundle-Prozess sicherstellen, dass relevante Hinweise erhalten bleiben.
Manche Lizenzen erwarten, dass geänderte Dateien als geändert erkennbar sind (z. B. über Kommentar, Changelog, NOTICE).
Der wichtigste Schritt: Wenn du Copyleft nutzt, kläre sauber, ob du verteilst, ob es ein abgeleitetes Werk ist, und ob bei AGPL Netzwerk-Nutzung relevant ist.
KI-Projekte unterscheiden sich von „normaler Software“ vor allem dadurch, dass du neben Code oft Modelle (Weights), Tokenizer, Prompts/Policies und Datasets verwendest. Diese Teile können eigene Lizenzmodelle haben, die nicht identisch mit klassischen OSS-Lizenzen sind.
Viele Modell-Lizenzen regeln Nutzung, Redistribution, Fine-Tuning, kommerzielle Nutzung und manchmal sogar „Use-Cases“ (z. B. keine bestimmten Anwendungen). Das ist oft strenger als MIT/Apache.
Neben Lizenz (z. B. CC) spielen häufig Rechte an Inhalten (Urheberrecht), Datenschutz, Nutzungsbedingungen der Quelle und Dokumentation (Provenance) eine Rolle.
Ob KI-Ausgaben (Texte, Bilder, Code) lizenzrechtlich „abgeleitet“ sind, hängt stark von Kontext, Trainingsdaten, Prompting, Modell-Lizenz und Rechtsprechung ab. Für robuste Projekte gilt:
Du verteilst Software. Das heißt: Lizenztexte/Notices müssen in den Installer oder das Installationsverzeichnis. Wenn Copyleft-Komponenten drin sind, musst du prüfen, ob Source-Pflichten entstehen.
Viele Pflichten sind identisch (Notices). Der Unterschied: AGPL kann auch ohne klassische „Auslieferung“ greifen. Deshalb: AGPL-Komponenten sehr bewusst einsetzen – oder architektonisch entkoppeln (separater Service) und rechtlich prüfen.
Ein Container ist praktisch eine Auslieferung eines kompletten Software-Stacks. Du brauchst eine saubere Komponentenliste (SBOM), Notices und ggf. Source-Angebote – nicht nur für deinen Code, sondern auch für Basis-Images/Packages.
Hier kommen Audits fast immer. Typisch ist die Frage: „Welche Open-Source-Komponenten sind drin, welche Lizenzen, welche Pflichten, welche CVEs?“ Ohne SBOM/Notices wird das teuer.
„Compliance“ klingt groß, ist aber in der Praxis ein einfacher, wiederholbarer Prozess. Ziel: jederzeit nachweisen können, was im Release steckt und welche Pflichten erfüllt wurden.
Eine SBOM ist eine Stückliste (Dependencies + Versionen). Sie hilft gleich doppelt: Lizenzen & Security (CVE-Tracking). Du kannst SBOMs pro Build erzeugen und zusammen mit dem Release ablegen.
release/ app/ # dein Produkt licenses/ # Lizenztexte der Komponenten THIRD_PARTY_NOTICES.txt # kompakte Übersicht + Copyright SBOM.json # Stückliste (Komponenten + Versionen) README-LICENSE.txt # wo findet man was (für Kunden/Audits)Bei eigenen Projekten (wenn du selbst veröffentlichst) entscheidet die Lizenz über Adoption, Beitragspflichten und kommerzielle Optionen. Bei Nutzung fremder Komponenten entscheidet sie über Risiko, Pflichten und Architektur.
| Ziel | Typischer Fit | Warum | Worauf achten? |
|---|---|---|---|
| Maximale Verbreitung / geringe Hürden | MIT / BSD / Apache-2.0 | Einfach für Nutzer, gut für Ecosystem | NOTICE/Patente (Apache), Marken |
| Teilweise Offenheit sichern | MPL / LGPL | Selektives Copyleft, weniger „Ansteckung“ | Datei-/Linkage-Regeln |
| Alles abgeleitete soll offen bleiben | GPL | Starkes Copyleft bei Distribution | Kompatibilität, Quellcode-Pflichten |
| Auch SaaS soll offenlegen | AGPL | Copyleft auch bei Netzwerk-Nutzung | Service-Betrieb, Codebereitstellung |
Nein. Open Source beschreibt Rechte am Quellcode. Kostenlos kann sein, muss aber nicht. Entscheidend sind Lizenz und Angebot (Support/Enterprise/Hosting).
In der Regel ja. Du musst typischerweise Lizenztexte und Copyright-Hinweise beilegen. Bei Apache-2.0 zusätzlich NOTICE- und Patent-Themen beachten.
Wenn du ein abgeleitetes Werk verteilst/auslieferst und die GPL-Pflichten dadurch auf dein Produkt übergehen. Ob „abgeleitet“ vorliegt, hängt stark vom Integrationsmodell ab.
AGPL ist genau für Netzwerk-Nutzung gebaut. Wenn du AGPL-Software als Service anbietest, kann Quellcode-Bereitstellung erforderlich sein. Plane das bewusst ein oder nutze Alternativen.
Behandle sie wie eigene Compliance-Objekte: Lizenztexte sichern, Quellen dokumentieren, Version/Hash festhalten, und klare Regeln für Nutzung/Redistribution definieren.
SBOM ist ein starker Baustein, aber du brauchst zusätzlich die tatsächliche Erfüllung der Pflichten: Notices/Lizenzen beilegen, Copyleft-Trigger klären und dokumentieren.