Open-Source-Lizenzen: Was Start-ups und Unternehmen über GPL, MIT & Co. wissen müssen
Moderne Software besteht zu großen Teilen aus Open-Source-Komponenten – npm-Pakete, Frameworks, Bibliotheken. „Kostenlos“ heißt aber nicht „bedingungslos“: Jede Komponente kommt mit einer Lizenz, und deren Verletzung ist eine Urheberrechtsverletzung mit Unterlassungs- und Schadensersatzfolgen.
Besonders heikel ist das Copyleft der GPL: Unter bestimmten Voraussetzungen muss der eigene Code offengelegt werden. Dieser Ratgeber erklärt die Lizenzfamilien, die typischen Fallstricke – und warum Investoren bei der Due Diligence zuerst nach Ihrer Lizenz-Bilanz fragen.
1. Die drei Lizenzfamilien im Überblick
| Familie | Beispiele | Kernpflichten | Risiko |
|---|---|---|---|
| Permissiv | MIT, BSD, Apache 2.0 | Lizenztext und Copyright-Hinweis beilegen; Apache: Patentklausel, Änderungsvermerke | gering |
| Schwaches Copyleft | LGPL, MPL, EPL | Änderungen an der Komponente selbst offenlegen; eigener Code bleibt bei sauberer Trennung geschützt | mittel |
| Starkes Copyleft | GPL v2/v3, AGPL | Abgeleitete Werke müssen bei Weitergabe vollständig unter derselben Lizenz offengelegt werden | hoch |
Die AGPL verdient besondere Aufmerksamkeit: Ihr Copyleft greift schon beim Betrieb als Netzwerkdienst (SaaS) – nicht erst bei der Weitergabe von Software. Für SaaS-Anbieter ist der ungeprüfte Einsatz von AGPL-Komponenten deshalb besonders riskant.
2. Wann „infiziert“ die GPL Ihren Code?
Das Copyleft greift, wenn Ihr Code ein abgeleitetes Werk der GPL-Komponente ist und Sie die Software weitergeben. Die Abgrenzung ist technisch-juristische Detailarbeit: Statisches Linken spricht eher für ein abgeleitetes Werk, die Kommunikation über Prozessgrenzen (separate Programme, APIs) eher dagegen – viele Konstellationen sind ungeklärt. Praktisch gilt: Architekturentscheidungen sind Lizenzentscheidungen. Wer GPL-Komponenten sauber kapselt oder auf permissive Alternativen ausweicht, vermeidet das Risiko von vornherein.
Verstöße werden verfolgt: GPL-Rechtsdurchsetzung ist in Deutschland etabliert – von spezialisierten Einzelentwicklern bis zu organisierten Enforcement-Initiativen. Die Folgen: Unterlassung, Auskunft, Schadensersatz und im schlimmsten Fall der Verlust der Lizenzrechte an der Komponente, auf der Ihr Produkt aufbaut.
3. Compliance in der Praxis: Die vier Grundpflichten
Das Pflichtenprogramm für jede Auslieferung
- Inventarisieren: Software Bill of Materials (SBOM) – welche Komponenten in welcher Version mit welcher Lizenz?
- Lizenztexte mitliefern: Copyright-Hinweise und Lizenztexte aller Komponenten beifügen (auch bei MIT!)
- Quellcode-Angebote erfüllen: Bei Copyleft-Komponenten den korrespondierenden Quellcode zugänglich machen
- Kompatibilität prüfen: Nicht jede Lizenz verträgt sich mit jeder – GPL-v2-only und Apache 2.0 etwa sind inkompatibel
4. Open Source in der Due Diligence
Spätestens bei Finanzierungsrunde, Exit oder Enterprise-Kunden wird Ihre Lizenz-Bilanz geprüft. Investoren lassen Codebasen automatisiert scannen; ungeklärte GPL-Abhängigkeiten in proprietärem Kerncode sind ein klassischer Deal-Breaker oder Preisdrücker. Umgekehrt ist eine gepflegte SBOM samt Open-Source-Richtlinie ein Professionalitätssignal, das Verhandlungen beschleunigt. Wie Sie auch die übrige IP-Kette sauber halten, lesen Sie im Ratgeber Rechte am Quellcode.
5. Die Open-Source-Richtlinie: Klein anfangen, konsequent leben
Schon eine einseitige Richtlinie verhindert die meisten Probleme: Erlaubte Lizenzfamilien (Whitelist), Freigabeprozess für Copyleft-Komponenten, Pflicht zur SBOM-Pflege im Build-Prozess und ein Verantwortlicher für Lizenzfragen. Ergänzt um automatisierte Scans in der CI/CD-Pipeline wird Compliance vom Projekt zum Nebeneffekt. Wir erstellen solche Richtlinien als kompaktes Paket – abgestimmt auf Ihren Stack und Ihr Geschäftsmodell.
Das Wichtigste in Kürze
Open Source ist kostenlos, aber nicht bedingungslos: Permissive Lizenzen verlangen Hinweise, Copyleft-Lizenzen können die Offenlegung des eigenen Codes erzwingen – die AGPL sogar im SaaS-Betrieb. Wer SBOM, Lizenztexte und eine schlanke Richtlinie etabliert, ist compliant und due-diligence-fest. Bei GPL-Abmahnungen gilt wie immer: nicht vorschnell unterschreiben, sondern Ansprüche und Abhilfemöglichkeiten prüfen lassen.
GPL-Abmahnung oder Due Diligence in Sicht?
Wir klären Ihre Lizenzlage, verteidigen gegen Enforcement-Forderungen und machen Ihre Codebasis transaktionsfest.
Beratung anfragen →6. Häufige Fragen (FAQ)
Darf ich MIT-lizenzierten Code einfach kommerziell nutzen?
Ja – die MIT-Lizenz erlaubt praktisch jede Nutzung. Aber auch sie hat eine Pflicht: Lizenztext und Copyright-Vermerk müssen bei der Weitergabe erhalten bleiben. Selbst dieser Minimalverstoß ist formal eine Urheberrechtsverletzung.
Muss ich meinen Code offenlegen, wenn ich GPL-Komponenten nutze?
Nur wenn Ihr Code ein abgeleitetes Werk ist und Sie die Software weitergeben. Interne Nutzung löst das Copyleft nicht aus; bei der AGPL genügt allerdings schon der Betrieb als Online-Dienst. Die Abgrenzung im Einzelfall gehört in fachkundige Hände.
Was ist eine SBOM und brauche ich sie?
Die Software Bill of Materials listet alle Komponenten, Versionen und Lizenzen Ihrer Software. Sie ist die Grundlage jeder Compliance, wird von Enterprise-Kunden zunehmend vertraglich verlangt und spielt auch in Cybersicherheits-Regulierung eine wachsende Rolle.
Ich habe eine GPL-Abmahnung erhalten – was nun?
Ruhe bewahren, nichts unterschreiben, Sachverhalt technisch aufklären: Welche Komponente, welche Version, welcher Verstoß? Oft lässt sich der Verstoß schnell abstellen und die Auseinandersetzung auf dieser Basis beilegen. Vorformulierte Unterlassungserklärungen sind auch hier regelmäßig zu weit.
Sind Open-Source-Komponenten in KI-generiertem Code ein Problem?
Ja, potenziell: KI-Assistenten können lizenzpflichtige Codefragmente reproduzieren, ohne die Lizenz auszuweisen. Wer KI-generierten Code produktiv einsetzt, sollte Scans auf Lizenz-Übereinstimmungen in den Entwicklungsprozess integrieren.
Was kostet ein Open-Source-Audit?
Das hängt von Codebasis und Tiefe ab – vom kompakten Richtlinien-Paket bis zum vollständigen Audit vor einer Transaktion. Nach einer kostenlosen Ersteinschätzung erhalten Sie von uns ein Festpreisangebot.
7. Ihre Kanzlei für Open-Source-Compliance-Beratung in Essen und ganz NRW
Die Kanzlei MANDATI in Essen berät Unternehmen, Start-ups und Verbraucher im IT-Recht – von der DSGVO-Compliance über IT-Verträge bis zur Abwehr von Abmahnungen. Persönlich in Essen oder vollständig digital, bundesweit.
MANDATI Rechtsanwälte – Ihr Anwalt für Open-Source-Compliance-Beratung in Essen und dem gesamten Ruhrgebiet. Persönliche Beratung vor Ort oder mandatsbezogen bundesweit.
Hindenburgstr. 23, 45127 Essen, Nordrhein-Westfalen
Telefon: 0201 – 890 722 40 · E-Mail: [email protected]
Öffnungszeiten: Mo–Fr 9–18 Uhr
Einzugsgebiete / „in der Nähe":
- Essen
- Bochum
- Dortmund
- Düsseldorf
- Duisburg
- Mülheim a. d. Ruhr
- Oberhausen
- Gelsenkirchen
- Köln
Kanzlei MANDATI
Hindenburgstr. 23
45127 Essen
Nordrhein-Westfalen
Telefon: 0201 – 890 722 40
E-Mail: [email protected]
Beratung im IT-Recht: vor Ort in Essen · bundesweit digital per Video und Telefon
Open-Source-Richtlinie zum Festpreis
Whitelist, Prozesse, SBOM-Integration: Kanzlei MANDATI bringt Ihre Open-Source-Nutzung in geordnete Bahnen.
Beratung anfragen →