Einhaltung von Open-Source-Lizenzen: Ein praktischer Leitfaden für Softwareunternehmen

Die durchschnittliche kommerzielle Anwendung enthält 77 % Open-Source-Code, verteilt auf mehr als 500 Abhängigkeiten. Jede Abhängigkeit verfügt über eine eigene Lizenz mit spezifischen Verpflichtungen. Ein Verstoß gegen diese Verpflichtungen setzt Ihr Unternehmen dem Risiko von Klagen, erzwungener Code-Offenlegung und Reputationsschäden aus. Dennoch verfügen die meisten Unternehmen über kein Verfahren zur Nachverfolgung oder Einhaltung von Open-Source-Lizenzen.

Dieser Leitfaden bietet einen praktischen Rahmen für die Einhaltung von Open-Source-Lizenzen, von der Lizenzkategorisierung bis hin zum automatisierten Scannen und der SBOM-Generierung.

Wichtige Erkenntnisse

• Nicht alle Open-Source-Lizenzen sind gleich: Permissive Lizenzen erlauben fast alles, Copyleft-Lizenzen erfordern, dass Sie Änderungen teilen
• Eine Software-Bill of Materials (SBOM) wird zu einer gesetzlichen Anforderung im öffentlichen Beschaffungswesen (US Executive Order 14028) – Automatisiertes Lizenzscannen in CI/CD verhindert, dass nicht konforme Abhängigkeiten in Ihre Codebasis gelangen
• Das Risiko einer Copyleft-„Infektion“ ist real: Eine GPL-Abhängigkeit kann Sie dazu zwingen, Ihre gesamte Anwendung als Open Source bereitzustellen

---

Lizenzkategorien

Freizügige Lizenzen (geringes Risiko)

Sicher für die kommerzielle Nutzung. Fügen Sie Ihrer Verteilung den Lizenztext und den Copyright-Hinweis bei. Apache 2.0 erfordert zusätzlich die Kenntnisnahme aller Änderungen am Originalcode und beinhaltet eine Patentlizenz.

Schwaches Copyleft (mittleres Risiko)

Mit Vorsicht verwenden. Behalten Sie LGPL-Bibliotheken als gemeinsam genutzte (dynamische) Bibliotheken, nicht statisch verknüpft. Bewahren Sie MPL-lizenzierten Code in separaten Dateien von Ihrem proprietären Code auf.

Starkes Copyleft (hohes Risiko)

Höchstes Risiko für kommerzielle Software. Die Verwendung von GPL-Code in Ihrer Anwendung erfordert möglicherweise, dass Sie Ihre gesamte Anwendung unter der GPL veröffentlichen. AGPL erweitert dies auf serverseitige Software – selbst wenn Sie niemals Binärdateien verteilen, löst die Bereitstellung der Software als Webdienst die Copyleft-Pflicht aus.

---

Compliance-Workflow

Schritt 1: Generieren Sie eine SBOM

# For Node.js projects (using CycloneDX)
npx @cyclonedx/cyclonedx-npm --output-file sbom.json --spec-version 1.5

# For Python projects
pip install cyclonedx-bom
cyclonedx-py environment --output sbom.json

# For multi-language projects (using Syft)
syft . -o cyclonedx-json > sbom.json

Schritt 2: Auf Lizenzkonformität prüfen

# Using license-checker for Node.js
npx license-checker --production --json --out licenses.json

# Using scancode-toolkit (comprehensive, all languages)
scancode --license --copyright --output-json scan-results.json .

Schritt 3: Kategorisieren und genehmigen

Erstellen Sie eine Liste genehmigter Lizenzen:

{
  "approved": [
    "MIT", "BSD-2-Clause", "BSD-3-Clause", "Apache-2.0",
    "ISC", "0BSD", "Unlicense", "CC0-1.0"
  ],
  "conditional": [
    "LGPL-2.1", "LGPL-3.0", "MPL-2.0", "EPL-2.0"
  ],
  "prohibited": [
    "GPL-2.0", "GPL-3.0", "AGPL-3.0", "SSPL-1.0",
    "EUPL-1.2", "OSL-3.0"
  ]
}

Schritt 4: CI/CD-Integration

# .github/workflows/license-check.yml
name: License Compliance
on: [pull_request]

jobs:
  check-licenses:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: pnpm install --frozen-lockfile

      - name: Check licenses
        run: |
          npx license-checker --production --excludePackages "" \
            --failOn "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL-1.0" \
            --summary

---

SBOM (Software-Stückliste)

Warum SBOMs wichtig sind

• US Executive Order 14028 erfordert SBOMs für Software, die an die US-Regierung verkauft wird
• Der EU Cyber Resilience Act wird SBOMs für in der EU verkaufte Software erfordern
• Sicherheit der Lieferkette: SBOMs ermöglichen eine schnelle Reaktion auf Schwachstellen (wenn log4j auftritt, wissen Sie, ob Sie betroffen sind)
• Kundenvertrauen: Unternehmenseinkäufer fordern bei der Beschaffung zunehmend SBOMs

SBOM-Standards

Empfehlung: CycloneDX für die meisten Softwareunternehmen. Es ist einfacher, bietet eine bessere Werkzeugunterstützung und wird zum Branchenstandard.

---

Häufige Compliance-Szenarien

Szenario 1: Node.js-Webanwendung

Das typische node_modules-Verzeichnis enthält 500–2.000 Pakete. Die überwiegende Mehrheit nutzt MIT- oder ISC-Lizenzen. Häufige Probleme:

• Transitive Abhängigkeiten unter Verwendung der GPL (Sie haben sie nicht direkt hinzugefügt)
• UNKNOWN-Lizenzfelder, die eine manuelle Untersuchung erfordern
• Mehrere Lizenzen für ein einzelnes Paket (z. B. „MIT ODER Apache-2.0“)

Aktion: Führen Sie npx license-checker --production wöchentlich aus. Untersuchen Sie alle nicht zulässigen Lizenzen. Ersetzen Sie GPL-Abhängigkeiten durch freizügige Alternativen.

Szenario 2: Odoo-Modulentwicklung

Odoo Community Edition ist LGPL v3. Odoo Enterprise ist proprietär. Ihre individuellen Module:

• Community-Module: Muss LGPL v3 oder kompatibel sein (falls verteilt)
• Private interne Module: Nicht verteilt, daher gilt LGPL nicht
• Enterprise-Add-ons: Muss den Odoo Enterprise-Lizenzbedingungen entsprechen

Szenario 3: SaaS mit AGPL-Abhängigkeiten

Wenn Ihre SaaS-Anwendung AGPL-lizenzierten Code verwendet (z. B. MongoDB vor der Umstellung auf SSPL), müssen Sie entweder:

1. Geben Sie Ihren gesamten Anwendungsquellcode unter AGPL frei
2. Entfernen Sie die AGPL-Abhängigkeit und verwenden Sie eine Alternative
3. Besorgen Sie sich eine kommerzielle Lizenz vom AGPL-Projekt (falls verfügbar)

Die serverseitige Verwendung von AGPL-Code löst die Copyleft-Pflicht aus, auch wenn Sie niemals Binärdateien „verteilen“.

---

Häufig gestellte Fragen

Zwingt uns die Verwendung einer GPL-Bibliothek in unserer API dazu, unsere API als Open Source bereitzustellen?

Es hängt davon ab, wie Sie es verwenden. Wenn die GPL-Bibliothek mit Ihrer Anwendung verknüpft ist (statisch oder dynamisch), vertritt die FSF den Standpunkt, dass Ihre Anwendung ein „abgeleitetes Werk“ ist und unter der GPL lizenziert sein muss. Wenn Sie mit der GPL-Software über eine Netzwerk-API kommunizieren (z. B. mithilfe eines GPL-lizenzierten Datenbankservers), gilt dies im Allgemeinen nicht als abgeleitete Arbeit. Konsultieren Sie für Ihren konkreten Fall einen Anwalt.

Was passiert, wenn eine Abhängigkeit ihre Lizenz ändert?

Sie sind an die Lizenz gebunden, unter der Sie den Code erhalten haben, nicht an zukünftige Lizenzänderungen. Wenn Sie jedoch mit einer neuen Lizenz auf eine neue Version aktualisieren, gilt die neue Lizenz für diese Version. Aus diesem Grund sind SBOMs mit Versions-Pinning wichtig – sie dokumentieren genau, welche Version (und Lizenz) Sie verwenden.

Wie gehen wir mit Abhängigkeiten mit „UNBEKANNTEN“ Lizenzen um?

Suchen Sie im Repository des Pakets nach einer LICENSE-Datei. Wenn keine Lizenz angegeben ist, unterliegt der Code technisch gesehen vollem Urheberrechtsschutz – Sie haben kein Recht, ihn zu verwenden, zu ändern oder zu verbreiten. Suchen Sie entweder nach der Lizenz (sie befindet sich möglicherweise an einem nicht standardmäßigen Speicherort), fordern Sie den Autor auf, eine hinzuzufügen, oder ersetzen Sie die Abhängigkeit durch eine eindeutig lizenzierte Alternative.

Müssen wir für MIT-lizenzierte Pakete eine Quellenangabe angeben?

Ja. MIT und die meisten freizügigen Lizenzen erfordern, dass Sie bei der Verbreitung der Software den Urheberrechtshinweis und den Lizenztext angeben. Bei Webanwendungen bedeutet dies normalerweise, eine Datei „THIRD-PARTY-NOTICES“ ​​oder eine Seite einzuschließen, auf der alle Open-Source-Komponenten und deren Lizenzen aufgeführt sind.

---

Aufbau eines Compliance-Programms

Vierteljährliche Compliance-Überprüfung

1. SBOM neu generieren für alle Projekte
2. Nach neuen Abhängigkeiten suchen seit der letzten Überprüfung hinzugefügt
3. Überprüfen Sie die aktualisierten Pakete auf Lizenzänderungen
4. Überprüfen Sie alle angezeigten „UNBEKANNTEN“ Lizenzen
5. Aktualisieren Sie die Liste der genehmigten Lizenzen, wenn neue Lizenzen gefunden werden
6. Archivieren Sie SBOM-Snapshots für den Audit-Trail

Compliance-Rollen

Ein leichtgewichtiges Compliance-Programm nimmt für ein kleines Team zwei bis vier Stunden pro Quartal in Anspruch und vermeidet die viel höheren Kosten, die durch die Entdeckung eines Compliance-Problems nach der Produkteinführung oder während der Due Diligence entstehen.

---

Was als nächstes kommt

Die Einhaltung von Lizenzen ist ein Aspekt der Software-Governance. Kombinieren Sie es mit IP-Schutz für Ihren eigenen Code, SaaS-Vereinbarungsgrundlagen für Anbietersoftware und Cybersicherheitsvorschriften für die Einhaltung der Sicherheitsvorschriften.

Kontaktieren Sie ECOSIRE für Open-Source-Compliance-Audit- und SBOM-Generierungsdienste.

---

Herausgegeben von ECOSIRE – Unterstützung von Unternehmen bei der verantwortungsvollen Nutzung von Open Source.