Open-Source-Lizenz-Compliance-Prüfung
Zweck
Diese Skill teilt mit, welche Lizenzen im Abhängigkeitsbaum enthalten sind, welche Pflichten diese Lizenzen angesichts des Einsatzmodells auslösen, und was für jede einzelne Abhängigkeit zu tun ist: Pflichten erfüllen, ersetzen, entfernen, anwaltliche Prüfung einholen oder kommerzielle Lizenz beschaffen.
Dies ist eine Erstklassifikation. Copyleft-Analysen hängen vom Einsatzmodell, der Einbindungstiefe, der Rechtsordnung und bisweilen von noch nicht gerichtlich geklärten Rechtsfragen ab (insbesondere AGPL-Netzwerktrigger, GPL-3.0-Patentklausel). Alles was als starkes Copyleft oder unklare Lizenz eingestuft wird, geht vor Auslieferung oder Veröffentlichung an einen Rechtsanwalt. Die Skill liefert den Befund; der Anwalt entscheidet.
Hinweis: Dieser Skill ersetzt keine anwaltliche Beratung im konkreten Einzelfall.
Eingaben
- Was wird geprüft?
- Abhängigkeitsliste (
package.json,requirements.txt,go.mod,Gemfile,Cargo.toml,pom.xml, SBOM nach SPDX / CycloneDX, Lockfile) - Einzelne Bibliothek — ein konkretes Paket, das hinzugefügt werden soll
- Eigener Code — Vorbereitung zur Open-Source-Veröffentlichung
- Einsatzmodell (vor Klassifikation der Pflichten zwingend festlegen):
- SaaS / gehosteter Dienst — Nutzer greifen über Netz zu; kein Code wird ausgeliefert
- Distribuiertes Programm — kompilierter Code wird ausgeliefert (Desktop-App, Mobile-App, On-Prem-Server, CLI)
- Nur intern — ausschließlich im Unternehmen genutzt, keine Auslieferung nach außen
- Eingebettet / Firmware — ausgeliefert in Hardware oder als Closed-System-Firmware
Rechtlicher Rahmen
Kernvorschriften
- § 69a ff. UrhG — Urheberrechtsschutz für Computerprogramme; § 69b UrhG Arbeitnehmerprogramme
- § 31 Abs. 1 UrhG — Einfaches und ausschließliches Nutzungsrecht; Copyleft-Lizenzen räumen einfache Nutzungsrechte unter Bedingungen ein
- § 31 Abs. 5 UrhG — Zweckübertragungslehre: Im Zweifel nur für Vertragszweck erforderliche Rechte; Copyleft-Bedingungen müssen explizit akzeptiert werden
- § 97 UrhG — Unterlassungs- und Schadensersatzanspruch bei Lizenzverletzung; Grundlage für GPL-Enforcement-Klagen
- §§ 14, 15 UrhG — Bearbeitungsrecht, Verwertungsrechte; Copyleft wirkt über das Bearbeitungsrecht
Leitentscheidungen
- Rechtsprechung live prüfen: Keine Entscheidung aus Modellwissen zitieren; vor Ausgabe über amtliche oder frei zugängliche Quelle mit Gericht, Entscheidungsform, Datum, Aktenzeichen und tragender Aussage verifizieren.
- Rechtsprechung: keine Entscheidung aus Modellwissen zitieren; vor Ausgabe über offizielle oder frei zugängliche Quelle mit Gericht, Entscheidungsform, Datum, Aktenzeichen und tragender Aussage verifizieren.
Kommentare
- Spindler, in: Schricker/Löwenheim, UrhG, 6. Aufl. 2020, § 69a Rn. 1 (Softwareschutz allgemein)
- Quellenregel: Literatur nur mit Nutzerquelle oder lizenziertem Live-Zugriff; keine Kommentar-, Handbuch- oder Aufsatzfundstellen aus Modellwissen.
- Dreier, in: Dreier/Schulze, UrhG, 7. Aufl. 2022, § 31 Rn. 60 (Nutzungsrechtseinräumung, Copyleft-Mechanismus)
- Metzger/Jaeger, Open Source Software und deutsches Urheberrecht, GRUR Int. 1999, 839 (847) — Grundlagenaufsatz zur Wirksamkeit der GPL nach deutschem Recht
Ablauf
Schritt 1: Prüfungsumfang klären
Aus dem Übergabematerial ableiten oder fragen:
- Abhängigkeitsliste → alle Einträge klassifizieren, Pflichten aufrollen
- Einzelbibliothek → ein Paket klassifizieren, transitive Abhängigkeiten soweit verfügbar
- Ausgehender Code → Was ist eingebettet (direkt und transitiv)? Ist die gewählte Ausgangslizenz mit allen eingebetteten Lizenzen kompatibel? Sind LICENSE/NOTICE-Dateien korrekt?
Schritt 2: Einsatzmodell festlegen
Das Einsatzmodell bestimmt, welche Copyleft-Pflichten ausgelöst werden:
| Einsatzmodell | Wesentliche Lizenzen | |---|---| | SaaS | AGPL-3.0 (Netzwerktrigger), Attribution bei Permissive in der UI, SSPL/BUSL/Elastic bei konkurrierendem Dienst | | Distribuiertes Programm | GPL-2.0, GPL-3.0, LGPL, MPL, EPL (alle greifen bei Distribution); Permissive Attribution | | Nur intern | Kein Copyleft-Auslöser bei interner Nutzung ohne Distribution. AGPL greift dennoch, wenn externe Nutzer über Netz zugreifen. Permissive Attribution gute Praxis. | | Embedded / Firmware | GPL besonders schwer erfüllbar (Quellcodeoffenlegung + reproduzierbarer Build + Installationsinfo); vor Auslieferung planen |
Einsatzmodell im Ausgabevermerk kennzeichnen.
Schritt 3: Jede Abhängigkeit klassifizieren
Nicht nur Metadaten lesen — tatsächlichen Lizenztext prüfen. LICENSE-Dateien können falsch sein; Package-Metadaten können veraltet sein.
Klassifikation:
| Kategorie | Beispiele | Wesentliche Pflichten | |---|---|---| | Permissiv | MIT, BSD-2-Clause, BSD-3-Clause, Apache-2.0, ISC | Attribution, Lizenztextbeibehaltung; Apache-2.0 ergänzend Patentlizenz + NOTICE-Pflicht | | Schwaches Copyleft | LGPL-2.1, LGPL-3.0, MPL-2.0, EPL-1.0, EPL-2.0, CDDL | Datei- oder bibliotheksweite Quellcodeoffenlegung; Verlinkungsregeln variieren | | Starkes Copyleft | GPL-2.0, GPL-3.0, AGPL-3.0, OSL, EUPL (je nach Version) | Breite Quellcodeoffenlegung; AGPL erstreckt sich auf Netzwerknutzung | | Public Domain / Widmung | CC0, Unlicense, WTFPL | Keine Pflichten; aber: Public-Domain-Widmung nicht in allen Rechtsordnungen anerkannt (in Deutschland fraglich, §§ 29, 64 UrhG) | | Nicht-OSI Source-Available | SSPL, BUSL, Commons Clause, Elastic License, Fair Source | Kein Open Source — schränken kommerzielle oder konkurrierende Nutzung ein; Lizenztext lesen | | Unbekannt / Proprietär | Vendor-spezifisch, fehlendes Lizenz-File, Widerspruch File vs. Headers | Stopp — nicht als Permissiv behandeln |
Besonders kennzeichnen:
- Dual-lizenzierte Pakete — welche Lizenz nutzen wir? Wahl kann Pflichten ändern.
- Veraltete Pakete — kein aktiver Maintainer; gibt es einen gepflegten Ersatz?
- Copyleft in transitiver Abhängigkeit — Toplevel-Lizenz ist permissiv, aber eine transitive Abhängigkeit ist Copyleft.
- Lizenswechsel bei bekannten Projekten — Redis, MongoDB, Elastic, HashiCorp haben relizenziert; angepinnte Version prüfen.
Schritt 4: Pflichten auf Einsatzmodell abbilden
Für jedes klassifizierte Paket:
### [Paket@Version] — [Lizenz]
**Klassifikation:** [Permissiv / Schwaches Copyleft / Starkes Copyleft / Public Domain / Nicht-OSI / Unbekannt]
**Pflichten für unser Einsatzmodell ([SaaS / Distribuiert / Intern / Embedded]):**
- [ ] [Konkrete Pflicht — z. B. "Attribution in NOTICES-Datei, die mit der App ausgeliefert wird"]
- [ ] [z. B. "Bei Modifikation und Distribution: Quellcode der Änderungen veröffentlichen"]
- [ ] [z. B. "AGPL-Netzwerktrigger — wenn Nutzer über Netz auf unsere modifizierte Version zugreifen, Quellcode anbieten"]
**Risiko:** 🔴 Kritisch | 🟠 Hoch | 🟡 Mittel | 🟢 Niedrig
**Empfehlung:** [Pflichten erfüllen | Ersetzen durch [Alternative] | Entfernen | Anwaltliche Prüfung vor Auslieferung | Kommerzielle Lizenz bei [Anbieter] beschaffen]Verlinkungsbeziehung bestimmt den Schweregrad:
- Statische Verlinkung / gemeinsame Kompilierung: Werke zu einem Binary vereint. Starkes Signal für Copyleft-Auslösung.
- Dynamische Verlinkung / Shared Library: Werke zur Laufzeit trennbar. LGPL explizit erlaubt (§ 6 LGPL — "work that uses the Library"). GPL-Position umstritten.
- Header-Einbindung / Inline-Funktionen: Kann abhängig von Einbindungstiefe ein abgeleitetes Werk begründen.
- Subprozess / IPC: Getrennte Prozesse über wohldefinierte Schnittstellen. Im Regelfall kein abgeleitetes Werk.
- Netzwerk-API-Aufruf: Für die meisten Lizenzen kein Auslöser. Für AGPL-3.0: Bereitstellung der Software über Netz gilt als Verbreitung — auch AGPL-Komponente hinter einer API triggert in einer Microservice-Architektur.
- Dateiweises Copyleft (MPL): Nur modifizierte Dateien tragen das Copyleft, nicht da