Lizenz-Compliance (GPL, MIT, Apache, AGPL)
Die Pflichten der gängigen Open-Source-Lizenzen verstehen und sauber einhalten — von permissiv bis strong copyleft.
Open-Source-Software steckt heute in nahezu jedem Produkt — und mit ihr ihre Lizenzpflichten. Ich sorge dafür, dass Sie FOSS rechtssicher nutzen, einbinden und veröffentlichen: von der Lizenz-Compliance über Code-Audits bis zur eigenen Open-Source-Strategie.
Die Pflichten der gängigen Open-Source-Lizenzen verstehen und sauber einhalten — von permissiv bis strong copyleft.
Wann GPL/AGPL den eigenen Code „anstecken": Quelltextpflichten, Netzwerk-Copyleft und die kritischen Kombinationsfragen.
FOSS sicher in proprietäre Software und SaaS einbinden, ohne den eigenen Code ungewollt offenlegen zu müssen.
Software-Stückliste (SBOM), Lizenz-Scans und FOSS-Audits — entscheidend bei M&A, Finanzierungsrunden und Auslieferung.
Contributor License Agreements (CLA/DCO), eigene Open-Source-Releases und eine tragfähige Projekt-Governance.
Projektnamen und Marken, die Haftungs- und Gewährleistungsausschlüsse der Lizenzen und ihre Grenzen im Einsatz.
Open Source berührt viele Felder: von Container- und Cloud-Native-Stacks über Dual-Licensing-Modelle und SaaS-Copyleft (AGPL) bis zu Patent- und Markenfragen. Schildern Sie mir Ihre Konstellation — gemeinsam klären wir, wie ich Sie unterstützen kann.
Eine einzelne GPL-Komponente an der falschen Stelle — und plötzlich steht die Frage im Raum, ob der gesamte proprietäre Code offengelegt werden muss. Solche Fragen tauchen erfahrungsgemäß im ungünstigsten Moment auf: in der Due Diligence vor einer Finanzierungsrunde oder einem Verkauf.
Ob Copyleft tatsächlich „ansteckt", hängt von Lizenz, Einbindungsart und Distribution ab — und ist seltener eindeutig, als beide Seiten behaupten. Entscheidend sind eine saubere Software-Stückliste und die frühzeitige Trennung kritischer Komponenten. Wer das vor dem Audit klärt, verhandelt aus einer ganz anderen Position.
Open Source ist nicht „kostenlos und egal", sondern „frei unter Bedingungen". Wer die Bedingungen kennt und dokumentiert, nutzt FOSS als Vorteil statt als Risiko.
Sechs Punkte, die über Compliance oder Risiko entscheiden — ob Sie FOSS einsetzen, ausliefern oder selbst veröffentlichen.
Jede FOSS-Komponente bringt Pflichten mit. Wer Lizenzen nur „wegklickt", riskiert Compliance-Verstöße, die erst im Audit oder beim Verkauf schmerzhaft auffallen.
Permissiv (MIT, Apache) oder Copyleft (GPL, AGPL)? Die Lizenzklasse entscheidet, ob und wann eigener Code offengelegt werden muss — das gehört vor den ersten Import geklärt.
Nur wer weiß, welche Komponenten in welcher Version verbaut sind, kann Lizenzen und Schwachstellen managen. Eine SBOM ist die Grundlage jeder Compliance.
Nicht jede Lizenz verträgt sich mit jeder anderen. Inkompatible Kombinationen können die Auslieferung eines Produkts vollständig blockieren.
Lizenztexte, Copyright-Vermerke und — wo gefordert — der Quelltext müssen vollständig und an der richtigen Stelle bereitgestellt werden. Halbe Erfüllung ist keine.
Wer Mitarbeitende beitragen lässt oder selbst Open Source veröffentlicht, braucht klare CLA/DCO-Vereinbarungen und Governance — sonst gehört der Code am Ende niemandem richtig.
Open-Source-Richtlinie, Freigabeprozesse und eine Lizenz-Whitelist aufsetzen — bevor der erste fremde Code in das eigene Produkt wandert.
Code-Basis scannen, SBOM erstellen, Lizenzpflichten und Kompatibilität prüfen, Risiken priorisieren und abstellen — auditfest dokumentiert.
Bei Compliance-Vorwürfen, Copyleft-Forderungen oder Streit um Beiträge: Sachlage einordnen, verhandeln und tragfähig lösen.
Nicht generell. Eine Offenlegungspflicht trifft Sie vor allem unter Copyleft-Lizenzen (insbesondere GPL/AGPL) und auch dort nur unter bestimmten Bedingungen — etwa bei der Distribution oder, bei der AGPL, bereits beim Bereitstellen über ein Netzwerk. Permissive Lizenzen wie MIT, BSD oder Apache verlangen das nicht. Entscheidend sind die konkrete Lizenz, die Art der Einbindung und ob Sie die Software verbreiten.
Permissive Lizenzen (MIT, BSD, Apache) erlauben Nutzung, Änderung und Verbreitung mit minimalen Pflichten — typischerweise dem Erhalt von Lizenz- und Copyright-Hinweisen. Copyleft-Lizenzen (GPL, LGPL, AGPL) verlangen, dass abgeleitete Werke unter derselben Lizenz stehen, und können eine Quelltextpflicht auslösen; die AGPL erstreckt diese sogar auf die Bereitstellung als Online-Dienst.
Eine Software Bill of Materials ist die vollständige Liste aller eingesetzten Komponenten samt Version und Lizenz. Sie ist die Grundlage, um Lizenzpflichten und Sicherheitslücken überhaupt steuern zu können — und wird durch Regelwerke wie den Cyber Resilience Act sowie bei jeder ernsthaften Due Diligence faktisch vorausgesetzt.
Wählen Sie bewusst eine passende Lizenz, klären Sie die Rechte der Beitragenden (über CLA oder DCO), schützen Sie Projektname und Marke und definieren Sie eine Governance. Wichtig ist auch ein wirksamer Haftungs- und Gewährleistungsausschluss — und Klarheit darüber, welche Rechte Sie sich für eine spätere kommerzielle Verwertung vorbehalten.
Das ist riskant. Ein Verstoß führt bei vielen Lizenzen automatisch zum Erlöschen der Nutzungsrechte — Sie nutzen die Software dann unlizenziert, was eine Urheberrechtsverletzung mit Unterlassungs- und Schadensersatzansprüchen darstellt. Spätestens in einem Audit oder bei einer Transaktion fällt das auf und kann ganze Deals gefährden.
Ob Lizenzprüfung, FOSS-Audit vor einer Transaktion oder eine eigene Open-Source-Strategie — schildern Sie Ihr Anliegen, ich melde mich innerhalb von 24 Stunden.
Dr. Sebastian Volk ist angestellter Rechtsanwalt der JUN Legal GmbH. Mandatsverhältnisse kommen ausschließlich mit der JUN Legal GmbH (Würzburg) zustande, nicht mit Dr. Sebastian Volk persönlich.