Open-Source-Lizenz-Compliance

Diese Seite enthält allgemeine Informationen und keine Rechtsberatung. Für Entscheidungen zu einem bestimmten Produkt sprechen Sie mit einem Anwalt.

Arten von Open-Source-Lizenzen

Art	Beispiele	Was sie meist verlangt
Permissiv	MIT, BSD, Apache-2.0	Copyright- und Lizenzhinweise beibehalten. Apache-2.0 enthält außerdem Patentbedingungen.
Schwaches Copyleft	LGPL, MPL-2.0	Änderungen an der lizenzierten Komponente selbst teilen
Starkes Copyleft	GPL-2.0, GPL-3.0	Software, die damit verbreitet wird, muss unter denselben Bedingungen und mit Quellcode angeboten werden
Netzwerk-Copyleft	AGPL-3.0	Wie starkes Copyleft, gilt aber auch, wenn Nutzer über ein Netzwerk mit der Software interagieren
Source-Available	BUSL, SSPL	Kein Open Source: Der Quellcode ist einsehbar, die Nutzung aber eingeschränkt

Was ist eine Copyleft-Lizenz?

Eine Copyleft-Lizenz erlaubt Ihnen, Software zu nutzen, zu ändern und weiterzugeben, unter der Bedingung, dass das, was Sie verbreiten, unter denselben Bedingungen bleibt. So bleibt Open Source offen. Das Risiko für ein kommerzielles Produkt: Eine Komponente mit starkem Copyleft, die in Ihren Code gelinkt wird, kann die Frage aufwerfen, ob auch Ihr eigener Code veröffentlicht werden muss.

Ob das zutrifft, hängt davon ab, wie die Komponente genutzt und wie das Produkt bereitgestellt wird. Software, die Sie an Kunden verbreiten, ist stärker betroffen als ein internes Tool, und ein SaaS-Produkt entgeht meist den Verbreitungsbedingungen der GPL, aber nicht denen der AGPL.

Häufige Compliance-Risiken

• Transitive Lizenzen. Ein permissives Paket kann von einem Copyleft-Paket abhängen. Wer nur direkte Abhängigkeiten prüft, übersieht das.
• Fehlende Hinweise. Die meisten Lizenzen verlangen, die Attribution beizubehalten, und eine vergessene Hinweisdatei ist der häufigste Fehler.
• Geänderte Lizenzen. Ein Projekt kann in einer neuen Version die Lizenz wechseln, ein Upgrade kann also Ihre Bedingungen ändern.
• Deklariert vs. tatsächlich. Die Metadaten eines Pakets können falsch oder unvollständig sein, und eingebetteter Code kann eine eigene Lizenz mitbringen.
• Due Diligence. Käufer und Großkunden verlangen ein Lizenzinventar, meist kurzfristig.

So bleiben Sie konform

1. Schreiben Sie eine Policy. Legen Sie je nach Produktart fest, welche Lizenzen erlaubt sind, welche eine Prüfung brauchen und welche verboten sind.
2. Erstellen Sie ein Inventar. Eine SBOM führt jede Komponente mit ihrer Lizenz auf, einschließlich transitiver Abhängigkeiten.
3. Prüfen Sie automatisch. Setzen Sie die Policy im CI durch, damit eine neue Abhängigkeit in dem Moment scheitert, in dem sie hinzugefügt wird, und nicht erst in einem Audit.
4. Erfüllen Sie die Pflichten. Erzeugen Sie Hinweisdateien und stellen Sie Quellcode bereit, wo eine Lizenz das verlangt.
5. Bewahren Sie die Aufzeichnungen auf. Speichern Sie das Inventar pro Release, denn die Frage betrifft meist eine Version, die Sie bereits ausgeliefert haben.

Was Lizenz-Compliance-Software leistet

Lizenz-Compliance ist ein fester Bestandteil der Software Composition Analysis. Die Tools identifizieren Komponenten, melden ihre Lizenzen und markieren Verstöße gegen Ihre Policy. Sie unterscheiden sich in der Tiefe:

• Deklarierte Lizenzen: Die meisten Tools lesen, was jedes Paket in seinen Metadaten deklariert. Das geht schnell und deckt den Normalfall ab.
• Tiefes Lizenz-Scanning: FOSSA und Black Duck analysieren zusätzlich Lizenztexte im Code und helfen bei Attributionsberichten und der rechtlichen Prüfung. Siehe CRACI vs. FOSSA und CRACI vs. Black Duck.
• Kostenlose Tools: Viele SBOM-Generatoren und SCA-Scanner melden deklarierte Lizenzen kostenlos. Siehe die besten SCA-Tools.

Wo CRACI ansetzt

CRACI behandelt deklarierte Lizenzen im Build. Als Ihr GitHub-Actions-Runner zeichnet es jedes Paket auf, das ein Job lädt, und jedes davon trägt seine deklarierte Lizenz, sodass Copyleft-Lizenzen erkannt werden, bevor sie im Produkt landen. Regeln für die Lizenz-Policy können einen Build wegen einer Lizenz blockieren, und SBOM-Exporte in CycloneDX und SPDX enthalten die deklarierte Lizenz jeder Komponente. CRACI arbeitet mit dem, was Pakete deklarieren. Wenn Sie also Workflows für die rechtliche Prüfung oder Lizenztextanalyse brauchen, nutzen Sie daneben ein Spezialtool.

Open-Source-Lizenz-Compliance: häufig gestellte Fragen

Was ist Open-Source-Lizenz-Compliance?

Sie bedeutet zu wissen, welche Open-Source-Lizenzen für die von Ihnen genutzte Software gelten, und deren Bedingungen zu erfüllen, etwa Hinweise beizubehalten oder Quellcode zu teilen.

Was ist eine Copyleft-Lizenz?

Eine Lizenz, die Ihnen erlaubt, Software zu nutzen und zu ändern, unter der Bedingung, dass das, was Sie verbreiten, unter denselben Bedingungen bleibt. Die GPL ist das bekannteste Beispiel.

Dürfen Sie GPL-Code in kommerzieller Software verwenden?

Ja, aber wenn Sie Software verbreiten, die ihn enthält, müssen Sie den Quellcode dieser Software möglicherweise unter der GPL anbieten. Es kommt darauf an, wie der Code kombiniert wird. Holen Sie für Ihren Fall daher Rechtsberatung ein.

Gilt Copyleft auch für SaaS?

Die Bedingungen der GPL greifen in der Regel bei der Verbreitung, die SaaS meist vermeidet. Die AGPL schließt diese Lücke, indem sie die Bedingungen auf Nutzer ausweitet, die über ein Netzwerk mit der Software interagieren.

Was ist die sicherste Open-Source-Lizenz für die kommerzielle Nutzung?

Permissive Lizenzen wie MIT, BSD und Apache-2.0 verlangen am wenigsten. Ihre Hinweise müssen Sie dennoch beibehalten.

Wie prüfen Sie die Lizenzen Ihrer Abhängigkeiten?

Erzeugen Sie eine SBOM, die transitive Abhängigkeiten und deklarierte Lizenzen enthält, oder nutzen Sie ein SCA-Tool. Setzen Sie Ihre Policy im CI durch, damit neue Verstöße den Build fehlschlagen lassen.