Der Entwickler lädt eine Library von GitHub herunter, integriert sie ins Produkt. Niemand schaut auf die Lizenz. Dann kommt eine Rechtsfrage oder eine Compliance-Audit auf den Tisch, und plötzlich stellt sich heraus: Das Produkt steht unter GPL-Bindung oder hat Apache-2.0-Verpflichtungen, die nie erfüllt wurden. Open-Source-Lizenzen klingen akademisch, bis sie praktisch werden. Dann kosten sie Zeit, Geld oder im schlimmsten Fall die Kontrolle über das eigene Produkt.
Die vier Lizenzen, die in der Praxis zählen
Es gibt Hunderte von Open-Source-Lizenzen, aber vier dominieren in kommerziellen Softwareprojekten. Jede mit anderen Freiheiten und Verpflichtungen.
MIT - Maximale Freiheit mit Mindesthaftung
Die MIT-Lizenz ist die Freiheitsticket der Open-Source-Welt. Sie erlaubt fast alles: kopieren, ändern, verteilen, kommerziell nutzen. Einzige Bedingung: Der ursprüngliche Copyright-Vermerk und die Lizenzbedingungen müssen mitgeliefert werden. Das war’s.
React, Express.js, Node.js und Lodash stehen unter MIT. Das ist kein Zufall. diese Projekte wollten maximale Adoption und minimale Hürden.
Aus Unternehmenssicht: MIT ist grün. Sie können damit fast ungehindert arbeiten, solange Sie die Lizenzhinweise in Ihrer Dokumentation aufnehmen. Keine versteckten Verpflichtungen, kein Code-Disclosure-Zwang.
Apache 2.0 - Freiheit mit explizitem Patentschutz
Apache 2.0 ist wie MIT, aber mit einem Zusatz: Der Lizenzvergeber räumt den Nutzern auch Patentrechte ein. Das ist für Enterprise besonders wertvoll. Wenn der Original-Autor ein Patent auf die Technologie hat, haft er die Nutzer für Patentverletzungen frei.
Kubernetes, Terraform, Apache Spark, Airflow: Bei großen Infrastructure-Projekten ist Apache 2.0 der Standard.
Besonderheit: Apache 2.0 verbietet ausdrücklich, die Lizenz zu verklagen. Das ist eher rechtliche Gründlichkeit als praktisches Problem, aber es zeigt: Apache 2.0 ist gedacht für Projekte, die von Konzernen abhängig sind.
Aus Unternehmenssicht: Apache 2.0 ist auch grün, oft sogar besser als MIT, weil der Patentschutz rechtliche Ruhe bringt.
GPL - Die Viral-Lizenz mit Konsequenzen
GPL. GNU General Public License. ist völlig anders. GPL sagt: Wenn du diesen Code nutzt, muss auch dein Code unter GPL stehen. Das nennt sich “Copyleft”. die Freiheit ist ansteckend, und der Zweck ist explizit: Proprietäre Software soll davon absehen, GPL-Code zu verwenden, ohne ihn auch freizugeben.
Linux, WordPress, GIMP: Die großen GPL-Projekte sind stabil und bewährt. Aber die Lizenz ist eine Einbahnstraße.
GPL hat mehrere Versionen (GPLv2, GPLv3), und v3 ist noch restriktiver. etwa beim Verbot von DRM-Umgehung. Kleine, aber wichtige Unterschiede.
Aus Unternehmenssicht: GPL ist rot für kommerzielle Softwareprodukte. Wenn ihr Produkt GPL-Code enthält und Sie es nicht open-source machen, brauchen Sie eine kommerzielle Lizenz vom Urheber (falls es den gibt) oder müssen die GPL-Code-Anteile komplett refaktorieren.
Die Grauzone liegt in der Nutzungsweise: GPL bindet normalerweise nur Code, den Sie als Ganzes oder verbunden nutzen. Wenn Sie GPL-Software nur als Dienst anbieten (z.B. WordPress-Hosting), nicht aber verbunden mit proprietärem Code, fallen Sie nicht unter die Copyleft-Verpflichtung. Das hat juristische Grenzen, die im Einzelfall schwer zu ziehen sind.
AGPL - GPL für die Cloud-Ära
AGPL ist wie GPL, aber mit einem entscheidenden Zusatz: Auch wenn Sie den Code nicht verteilen, sondern nur über ein Netzwerk (z.B. SaaS) anbieten, müssen Sie den quelloffenen Code zur Verfügung stellen.
Das ist das GPL-Loch für Cloud-Zeiten. GPL brauchte Sie nur zur Freigabe zu verpflichten, wenn Sie die Software verteilten. MongoDB Community, Grafana (unter AGPL bis v7), Mattermost. diese SaaS-freundlichen Projekte nutzen AGPL genau dafür: Um zu verhindern, dass Konkurrenten ihr Produkt verkaufen, ohne zurückzugeben.
Aus Unternehmenssicht: AGPL ist dunkelrot für SaaS-Produkte. Wenn Sie einen Dienst mit AGPL-Code betreiben und den Dienst Kunden anbieten (auch kostenlos), müssen Sie den gesamten Code offenlegen. Das ist praktisch ein Verbot für kommerzielle SaaS.
LGPL - Ein Kompromiss
LGPL (Lesser General Public License) versucht einen Mittelweg: Der LGPL-Code muss offenbleiben, aber Code, der damit verlinkt wird, nicht. Das ist hilfreich für Bibliotheken.
Qt ist ein Beispiel. unter LGPL können Sie ein GUI-Framework nutzen und Ihren Code proprietär halten, solange Sie Qt dynamisch linken.
Aus Unternehmenssicht: LGPL ist gelb bis grün, je nachdem, wie gut Sie “dynamic linking” kontrollieren.
Die praktischen Lizenzfallen
Vier konkrete Szenarien, wo Lizenzen Probleme verursachen:
Szenario 1: GPL-Code in Ihrem Backend
Sie entwickeln ein SaaS-Produkt und nutzen eine bewährte GPL-Bibliothek für Image-Verarbeitung. Der Code wird kompiliert und läuft auf Ihren Servern, Kunden sehen ihn nicht. Trotzdem müssen Sie dem Kunden auf Anfrage den gesamten Source-Code zur Verfügung stellen. inklusive Ihrer proprietären Geschäftslogik.
Lösungsoptionen: Refaktorieren Sie die GPL-Abhängigkeit (Zeit, Kosten), kaufen Sie eine kommerzielle Lizenz vom Autor (falls verfügbar), oder machen Sie Ihr Produkt open-source (Geschäftsmodell-Änderung).
Szenario 2: AGPL in der Cloud
Ähnlich: Sie integrieren eine AGPL-Bibliothek in Ihre SaaS-Plattform. Beim Rechnungsprüfungs-Audit stellt sich heraus: Sie müssen AGPL-Quellcode offenlegen, weil Sie ihn über ein Netzwerk anbieten. Noch schlimmer: AGPL ist ambivalent, was “Netzwerk-Angebot” bedeutet. Manche interpretieren es so eng, dass auch interne APIs reichen. Rechtssicherheit = Null.
Lösungsoptionen: Ersetzen Sie AGPL-Code durch Apache-2.0 oder MIT, dokumentieren Sie die Anforderung in der Entwickler-Richtlinie, oder setzen Sie einen SBOM-Prozess auf (siehe unten).
Szenario 3: Abhängigkeits-Lotto
Sie importieren Package A unter MIT. Package A hat eine Abhängigkeit zu Package B unter Apache 2.0. Package B hängt von Package C unter GPL ab. Ihr Produkt ist jetzt transitiv GPL-gebunden, obwohl Sie Package C nie direkt verwendet haben.
Das passiert häufiger, als Entwickler denken. npm, PyPI, Maven Central. alle sind voll von indirekten Abhängigkeiten, und niemand schaut auf Lizenzen.
Lösungsoptionen: SBOM-Tools (Software Bill of Materials) wie Trivy, CycloneDX, oder SPDX scannen automatisch transitive Abhängigkeiten.
Szenario 4: Dual-Licensing-Verschwinden
Sie nutzen eine Library unter einer großzügigen Lizenz. Der Autor wird von einem Konzern aufgekauft, und die nächste Major-Version hat eine restriktivere Lizenz. Ihre alten Versionen sind noch legal nutzbar (da lizenziert), aber Sie sind quasi eingefroren. Upgrades sind riskant, langfristig wird der alte Code zum Sicherheitsrisiko.
Das ist kein Bug, sondern Feature der Lizenzlandschaft: Viele Projekte wechseln zu Dual-Licensing oder Subscription-Modellen (Terraform, HashiCorp BSL).
Lizenz-Transparenz mit SBOM
Das wichtigste Kontroll-Instrument ist eine Software Bill of Materials (SBOM). Das ist ein maschinenlesbares Verzeichnis aller direkten und transitiven Abhängigkeiten mit ihren Lizenzen.
Ein SBOM sieht aus wie:
{
"bomFormat": "CycloneDX",
"specVersion": "1.3",
"components": [
{
"type": "library",
"name": "react",
"version": "18.2.0",
"license": "MIT"
},
{
"type": "library",
"name": "kubernetes",
"version": "1.28.0",
"license": "Apache-2.0"
}
]
}Tools wie Trivy (kostenlos, open-source) generieren SBOMs automatisch für Container, Dependencies und Binaries. CycloneDX ist der Standard-Format.
Prozess:
- Generieren Sie beim Build einen SBOM.
- Scannen Sie nach Policies. z.B. “Keine GPL in Produktivcode” oder “Nur MIT und Apache-2.0”.
- Dokumentieren Sie Ausnahmen explizit.
- Teilen Sie den SBOM mit Kunden auf Anfrage (wird zunehmend zur Compliance-Anforderung).
Praktische Entscheider-Richtlinien
Drei Handlungsempfehlungen für den produktiven Betrieb:
1. Lizenz-Policy definieren Legen Sie fest, welche Lizenzen in welchen Kontexten erlaubt sind. Beispiel:
- Produktive Services: Nur MIT, Apache 2.0, ISC
- Entwickler-Tools (interne Nutzung): MIT, Apache 2.0, Apache 2.0, GPL v2/v3, BSD
- Strikte Ausnahmen für AGPL, proprietäre Lizenzen
2. SBOM in den CI/CD-Prozess einbauen Trivy beim Build laufen lassen, SBOM generieren, Policy prüfen. Wenn eine nicht genehmigte Lizenz auftaucht, sollte der Build fehlschlagen (konfigurierbar).
3. Abhängigkeits-Reihe regelmäßig prüfen Lizenzen ändern. Entwickler updaten Dependencies. Ein jährlicher Audit (oder pro Major-Release) fängt Drift früh.
Fazit
Open-Source-Lizenzen sind keine akademische Übung. GPL zwingt Sie entweder zur Offenlegung oder zur Refaktorierung. AGPL macht SaaS-Produkte unmöglich, ohne zu offenbaren. Apache 2.0 und MIT geben Ihnen Freiheit, aber erfordern Dokumentation. Und transitive Abhängigkeiten verstecken Risiken tief in der Dependency Tree.
Die Antwort ist: Bauen Sie einen SBOM-Prozess auf. Generieren Sie beim Build automatisch, prüfen Sie gegen Policy, dokumentieren Sie Ausnahmen. Das ist weniger eine Recht-Problem als ein Transparenz-Problem. und das ist lösbar.
Wenn Sie unsicher sind, welche Lizenzen Ihre Software hat oder wie Sie ein Compliance-Programm aufbauen: Kontaktieren Sie uns für eine Beratung. Wir helfen Ihnen, die Abhängigkeiten zu klären und einen Prozess einzuführen, der Lizenzen von Anfang an im Griff behält.
Mehr zum Thema Software Supply Chain Security erfahren Sie in unserem Leitfaden zu technischen Schulden systematisch abbauen, unserem Artikel zu Supply Chain Angriffen mit Trivy und in unserem Beitrag zu Open Source für KMU. Praktisches DevSecOps-Wissen finden Sie auch in unserem Artikel zu DevSecOps vs DevOps.
Häufige Fragen
Welche Open-Source-Lizenz ist am sichersten für kommerzielle Produkte?
Apache 2.0 ist oft die beste Wahl. sie gewährt Freiheiten wie MIT, bietet aber zusätzlich Patentschutz. MIT ist auch sicher, hat aber weniger explizite Rechtssicherheit. Vermeiden Sie GPL und AGPL in Ihrem Produktivcode.
Kann ein Projekt mehrere Lizenzen haben?
Ja, “Dual Licensing” ist häufig. Ein Projekt kann unter open-source und kommerzieller Lizenz verfügbar sein. Die Lizenzen sind in der Regel nicht austauschbar. Sie müssen sich für eine entscheiden.
Wie oft sollte ich ein Lizenz-Audit durchführen?
Ein jährliches Audit oder bei jedem Major-Release ist das Minimum. Noch besser: Automatisieren Sie die Prüfung in Ihrer CI/CD-Pipeline mit SBOM-Tools und Policy-Checks. Das kostet keine zusätzliche Zeit, fängt neue Lizenzrisiken sofort beim Build auf.
Was passiert, wenn ich eine GPL-Abhängigkeit übersehe?
Im schlimmsten Fall könnte Sie der Copyright-Inhaber zur Freigabe zwingen oder auf Schadensersatz klagen. In der Praxis ist das selten. die meisten GPL-Projekte sind pragmatisch. Aber das Risiko ist real und nicht versichert.
Brauche ich einen Anwalt für Open-Source-Compliance?
Nicht für die Grundlagen. Viele Projekte haben klare, einfache Lizenzen. Für komplexe Fälle (GPL-Code in proprietären Produkten, SBOM mit hundert Dependencies, Dual-Licensing) macht ein IP-Spezialist Sinn.
