Lizenzkonformitätsprüfung mittels Abhängigkeitsanalyse

Die Anfrage zur Due-Diligence-Prüfung im Rahmen der Fusion oder Übernahme trifft am Dienstagmorgen ein: ein vollständiger Bericht zur Einhaltung der Open-Source-Lizenzbestimmungen für die gesamte Software, fällig am Freitag. Das Rechtsteam hat drei Tage Zeit, um ein Verzeichnis aller Open-Source-Komponenten im gesamten Quellcode, aller anwendbaren Lizenzen und aller Verpflichtungen zu erstellen, die vor der rechtlichen Prüfung durch den Käufer erfüllt werden müssen. Für Unternehmen, die die Einhaltung der Lizenzbestimmungen als regelmäßige manuelle Überprüfung behandeln, beginnt an diesem Dienstagmorgen eine der teuersten Krisensituationen in der Unternehmens-Softwareentwicklung. Für Unternehmen mit einer ausgereiften Infrastruktur zur Abhängigkeitsanalyse beginnt sie mit der Erstellung eines Berichts.

Software wird größtenteils zusammengestellt, nicht geschrieben. Der Black Duck 2026 OSSRA-Bericht ergab, dass 98 % der kommerziellen Codebasen Open-Source-Komponenten enthalten, 87 % mindestens eine bekannte Sicherheitslücke aufweisen und sich die durchschnittliche Anzahl der Sicherheitslücken pro Codebasis im Vergleich zum Vorjahr mehr als verdoppelt hat. Die Prüfung der Lizenzkonformität beantwortet eine andere, aber verwandte Frage: nicht nur, welche Komponenten Sicherheitslücken enthalten, sondern auch, welche Komponenten rechtliche Verpflichtungen hinsichtlich der Verbreitung, Modifizierung oder Kommerzialisierung der Software mit sich bringen. Eine fehlende GPL-2.0-Abhängigkeit in einem proprietären kommerziellen Produkt ist kein Sicherheitsvorfall, sondern ein Lizenzverstoß, der die Offenlegung des Quellcodes, eine außergerichtliche Einigung oder die Rücknahme des Produkts zur Folge haben kann.

Grundlage der Lizenzkonformitätsprüfung ist die Abhängigkeitsanalyse. Dabei wird systematisch jede Softwarekomponente identifiziert, von der eine Codebasis direkt oder indirekt abhängt, und die jeweilige Lizenz vollständig angegeben. Die Abhängigkeitsanalyse beschränkt sich nicht auf das Scannen des Paketmanifests. Sie ist eine umfassende strukturelle Untersuchung dessen, was die Software zur Kompilier- und Laufzeit tatsächlich enthält, unabhängig davon, ob diese Einbindungen deklariert, transitiv, durch den Anbieter bereitgestellt oder implizit sind.

Warum die Abhängigkeitsanalyse die Grundlage bildet

Die Einhaltung von Lizenzbestimmungen ist zunächst ein Abhängigkeitsproblem und erst dann ein rechtliches. Man kann die Lizenzverpflichtungen eines Softwareprodukts nicht beurteilen, ohne vorher dessen Zusammensetzung, jede Komponente, jede Bibliothek und jeden kopierten Codeabschnitt zu kennen. Die Lizenzanalyse folgt der Ermittlung der Abhängigkeiten. Ist die Ermittlung der Abhängigkeiten fehlerhaft, basiert die Lizenzanalyse auf einem unvollständigen Bild.

Drei Fragen, die die Abhängigkeitsanalyse im Hinblick auf die Lizenzkonformität beantworten muss:

Welche Komponenten sind im Lieferumfang enthalten? Nicht nur die direkt deklarierten Abhängigkeiten in package.json or pom.xmlAber jede transitive Abhängigkeit, die sie mit sich bringen, jede in den Quellcodebaum kopierte externe Bibliothek, jede statisch gelinkte Komponente, die in die Binärdatei kompiliert wird, und jedes dynamisch geladene Modul, das zur Laufzeit aufgerufen wird, wird analysiert. Eine gute SCA-Engine gleicht diese Komponenten mit Schwachstellendatenbanken wie dem NVD ab, prüft Lizenzmetadaten und kennzeichnet bekannte Exploits oder rechtliche Risiken, bevor diese Ihre Auslieferungskette beeinträchtigen. Dieselbe Engine muss auch auf Inventarebene – also auf der Ebene dessen, was tatsächlich in der Software enthalten ist – präzise sein, damit die Lizenzanalyse verlässlich ist.

Unter welchen Lizenzen unterliegen sie? Eine Komponente kann eine einzelne deklarierte Lizenz, eine Dual-Lizenz mit Optionen, mehrere Lizenzen für verschiedene Dateien oder eine Lizenz, die sich im Laufe der Versionen geändert hat, besitzen. Die Lizenzerkennungs-Engine von FOSSA erzielt eine Genauigkeit von 99.8 %, was wichtig ist, wenn Ihre Rechtsabteilung neben dem Sicherheitsinventar auch die Open-Source-Verpflichtungen überprüfen muss. Die Lizenzidentifizierung auf Komponentenebene ist zwar notwendig, aber nicht ausreichend. Für Komponenten, bei denen verschiedene Dateien unterschiedliche Lizenzen tragen, ist die Identifizierung auf Datei- oder Snippet-Ebene erforderlich.

Welche Verpflichtungen bringen diese Lizenzen mit sich? Eine freizügige Lizenz (MIT, Apache 2.0) verlangt Namensnennung. Eine schwache Copyleft-Lizenz (LGPL) stellt unterschiedliche Verpflichtungen, je nachdem, ob die Komponente dynamisch oder statisch eingebunden wird. Eine strenge Copyleft-Lizenz (GPL 2.0, GPL 3.0) kann die Verbreitung des Quellcodes des gesamten Werks erfordern. Um die Verpflichtungen zu verstehen, muss man die Lizenzbedingungen und nicht nur die Lizenzkennung kennen.

Die vier Arten von Abhängigkeiten, die ein Lizenzrisiko darstellen

Nicht alle Abhängigkeiten sind gleichermaßen sichtbar oder werden von den vorhandenen Werkzeugen gleichermaßen verwaltet. Die Lizenzverfügbarkeit ergibt sich aus vier verschiedenen Abhängigkeitstypen, die jeweils unterschiedliche Ermittlungsmethoden erfordern:

1. Paketmanager-Abhängigkeiten (deklariert und transitiv)

Die sichtbarste Ebene: Abhängigkeiten, die in Manifestdateien deklariert sind (package.json, pom.xml, requirements.txt, go.mod, Cargo.tomlund die transitiven Abhängigkeiten, die sie zur Build-Zeit auflösen. Paketmanager-Abhängigkeiten sind die am besten abgedeckte Kategorie; SCA-Tools durchsuchen Manifeste, Sperrdateien und Build-Artefakte, um sie aufzulisten.

Der entscheidende Unterschied liegt in der Unterscheidung zwischen direkten und transitiven Abhängigkeiten. Eine direkte Abhängigkeit ist die vom Entwickler gewählte. Eine transitive Abhängigkeit ist das, was die direkte Abhängigkeit erfordert. Ein Entwickler, der eine einzelne Abhängigkeit hinzufügt, … react-data-grid Ein Paket in einem Node.js-Projekt kann Dutzende transitiver Abhängigkeiten importieren, von denen jede ihre eigene Lizenz hat. Der Entwickler hat diese Lizenzen nicht ausgewählt. Sie sind trotzdem im Abhängigkeitsbaum vorhanden.

JSON

// package.json: 1 direct dependency declared
{
  "dependencies": {
    "react-data-grid": "^7.0.0"
  }
}

// npm lockfile resolves to 47 transitive dependencies, including:
// - react@18.2.0 (MIT)
// - clsx@1.2.1 (MIT)
// - scheduler@0.23.0 (MIT)
// - tslib@2.6.0 (0BSD)
// - ...43 more, each with its own license
// The developer declared 1 license obligation; they shipped 47.

Die Falle transitiver Lizenzen: Das Lizenzrisiko liegt nicht in Ihren Deklarationen, sondern in den Deklarationen Ihrer Abhängigkeiten und deren Abhängigkeiten. Ein übersichtlicher direkter Abhängigkeitsbaum mit freizügigen Lizenzen kann eine GPL-lizenzierte transitive Abhängigkeit drei Ebenen tief verbergen, die Copyleft-Verpflichtungen für die gesamte Distribution nach sich zieht.

2. Zugekaufter und kopierter Quellcode

Quellcode aus externen Projekten wird direkt in das Repository kopiert – ein gängiges Muster bei C/C++-Projekten, Go-Projekten ohne Module und älteren Codebasen. Der eingebundene Code erscheint nicht in den Manifesten des Paketmanagers, da er per Copy-Paste und nicht über einen Abhängigkeitsmanager hinzugefügt wurde.

Die Snippet-basierte Suche von SCANOSS geht weit über die Manifest-basierte Erkennung hinaus und gleicht Quellcodefragmente mit über 100 Millionen Open-Source-Dateien in der OSSKB ab. Diese Suche ist erforderlich, um eingebundenen Code und kopierte Funktionen zu identifizieren – Ansätze, die zwar keine Manifest-Abhängigkeit deklarieren, aber dennoch die vollen Lizenzverpflichtungen mit sich bringen, als wäre die Komponente explizit eingebunden worden.

Eine aus einer Stack Overflow-Antwort kopierte Hilfsfunktion, die ursprünglich aus GPL-lizenziertem Code stammt, unterliegt der gleichen Copyleft-Verpflichtung wie eine direkte GPL-Abhängigkeit, erscheint aber nirgends im Paketmanifest, in der Sperrdatei oder bei einem automatisierten Scan, der nur deklarierte Abhängigkeiten liest.

3. Statisch verknüpfte Bibliotheken

Bibliotheken werden zur Build-Zeit direkt in die Anwendungsdatei kompiliert. Im Gegensatz zu dynamisch verknüpften Bibliotheken, die zur Laufzeit als separate Dateien vorliegen, sind statisch verknüpfte Bibliotheken in die ausführbare Datei eingebettet. Sie sind nicht in den Manifesten des Paketmanagers sichtbar, sondern erscheinen in den Build-Konfigurationen (Makefile, CMakeLists.txt, Linker-Skripte) und in der kompilierten Binärdatei selbst.

Insbesondere bei unter der LGPL lizenzierten Bibliotheken bestimmt die Unterscheidung zwischen statischer und dynamischer Verknüpfung die Lizenzpflicht. Die LGPL erlaubt dynamische Verknüpfung ohne Copyleft-Weitergabe; statische Verknüpfung kann Copyleft-Anforderungen für das resultierende Werk auslösen. Um statisch verknüpfte Komponenten und deren Lizenzen zu identifizieren, ist ein Binäranalysetool erforderlich, das das kompilierte Artefakt und nicht nur das Quellmanifest untersucht.

4. Zur Laufzeit geladene Abhängigkeiten

Bibliotheken, die dynamisch zur Laufzeit über Plugin-Architekturen, späte Bindung oder Skript-Engine-Integrationen geladen werden, können Abhängigkeiten aufweisen, die sich möglicherweise nicht allein durch Quellcodeanalyse auflösen lassen, da sie von der Laufzeitumgebung, der Konfiguration und dem Ausführungspfad abhängen. Datenbanktreiber, die per Reflektion geladen werden, Parser-Plugins, die über Service-Loader-Mechanismen gefunden werden, und Skript-Erweiterungen, die beim Start aus Dateisystempfaden geladen werden, sind allesamt Laufzeitabhängigkeiten mit potenziellen Lizenzfolgen.

Lizenzrisikokategorien und ihre Verpflichtungen

Open-Source-Lizenzen lassen sich auf einem Spektrum von permissiv bis restriktiv einordnen. Das Verständnis der jeweiligen Position der Lizenz auf diesem Spektrum bestimmt die damit verbundenen Compliance-Verpflichtungen:

Freizügige Lizenzen (MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC)

Verpflichtung: Namensnennung, Lizenztext und Copyright-Hinweis müssen in den Verbreitungsmaterialien enthalten sein. Offenlegung des Quellcodes ist nicht erforderlich. Kommerzielle Nutzung ist uneingeschränkt gestattet. Integration in proprietäre Produkte ist zulässig.

Risikoniveau für kommerzielle Software: Niedrig. Die Zuordnung kann problemlos automatisch erfolgen.

Schwache Copyleft-Lizenzen (LGPL-2.0, LGPL-2.1, LGPL-3.0, MPL-2.0, EUPL-1.2)

Verpflichtung: Namensnennung und Änderungen an der lizenzierten Komponente müssen weitergegeben werden. Speziell für die LGPL gilt: Dynamisches Verlinken erfüllt die Lizenzbedingungen in der Regel, ohne dass Copyleft für den aufrufenden Code ausgelöst wird; statisches Verlinken hingegen möglicherweise nicht.

Risikostufe für kommerzielle Software: Mittel. Abhängig von der Verlinkungsmethode. Dynamische Verlinkung ist in der Regel sicher; statische Verlinkung erfordert eine sorgfältige rechtliche Prüfung.

Starke Copyleft-Lizenzen (GPL-2.0, GPL-3.0, AGPL-3.0)

Verpflichtung: Die Urheberschaft sowie das gesamte Werk, einschließlich der GPL-Komponente, müssen unter den GPL-Bedingungen (Offenlegung des Quellcodes) verfügbar gemacht werden. AGPL erweitert dies auf Software, auf die über ein Netzwerk zugegriffen wird.

Risiko für kommerzielle Software: Hoch. Eine unter der GPL lizenzierte Komponente, die statisch in ein proprietäres kommerzielles Produkt eingebunden oder davon abgeleitet ist, kann die Offenlegung des proprietären Quellcodes erfordern. Dieses Lizenzrisiko führt zu den höchsten Entschädigungszahlungen in Rechtsstreitigkeiten.

Netzwerk-Copyleft (AGPL-3.0)

Verpflichtung: Alle Verpflichtungen der GPL-3.0, plus: Benutzer, die über ein Netzwerk mit der Software interagieren, gelten als Empfänger der Software, wodurch die Verpflichtung zur Offenlegung des Quellcodes auch bei SaaS-Produkten ausgelöst wird, die niemals Binärdateien verteilen.

Risiko für SaaS-Produkte: Sehr hoch. Die AGPL wurde speziell entwickelt, um die „SaaS-Lücke“ in der GPL zu schließen. Ein kommerzielles SaaS-Produkt, das eine AGPL-Komponente enthält, muss seinen Quellcode jedem Benutzer offenlegen, der über ein Netzwerk damit interagiert.

Eigentums- und Handelslizenzen

Verpflichtung: Die im Lizenzvertrag definierte Verpflichtung variiert von „keine Weiterverbreitung“ über „Lizenzgebühr pro Einheit“ bis hin zu „Unternehmenslizenz“. Diese Komponenten sind nicht Open Source, erscheinen aber in Abhängigkeitsbäumen, wenn kommerzielle Komponenten verwendet werden.

Risikograd: Variiert je nach Vertragsbedingungen. Wird häufig im Rahmen der Due-Diligence-Prüfung bei Fusionen und Übernahmen festgestellt, wenn die Lizenzgebührenverpflichtungen für erworbene Produkte aufgeführt werden.

Lizenzkompatibilität: Die entscheidende Matrix

Werden Komponenten mit unterschiedlichen Lizenzen in einem Softwareprodukt kombiniert, müssen die Lizenzen kompatibel sein. Inkompatible Lizenzkombinationen bergen ein rechtliches Risiko, das sich nicht allein durch die Zuordnung der Lizenzen beheben lässt; die Kombination selbst kann gegen eine oder beide Lizenzen verstoßen.

Kombiniert mit	MIT	Apache-2.0	LGPL-2.1	GPL-2.0	GPL-3.0	PLFA-3.0
MIT	Kompatibel	Kompatibel	Kompatibel	Kompatibel	Kompatibel	Kompatibel
Apache-2.0	Kompatibel	Kompatibel	Kompatibel	Unvereinbar	Kompatibel	Kompatibel
LGPL-2.1	Kompatibel	Kompatibel	Kompatibel	Kompatibel	Unvereinbar	Unvereinbar
GPL-2.0	Kompatibel	Unvereinbar	Kompatibel	Kompatibel	Unvereinbar	Unvereinbar
GPL-3.0	Kompatibel	Kompatibel	Unvereinbar	Unvereinbar	Kompatibel	Kompatibel
Proprietäre	Kompatibel	Kompatibel	Kaution	Unvereinbar	Unvereinbar	Unvereinbar

Die folgenreichste Inkompatibilität für kommerzielle Software: Apache-2.0 und GPL-2.0 sind nicht kompatibel. Eine unter Apache-2.0 lizenzierte Bibliothek kann nicht mit einer unter GPL-2.0 lizenzierten Komponente im selben Projekt kombiniert werden. Da viele grundlegende Open-Source-Komponenten (Linux-Kernelmodule, einige ältere Java-Bibliotheken) unter GPL-2.0 und nicht unter GPL-3.0 stehen, birgt diese Inkompatibilität ein erhebliches Compliance-Risiko bei gemischten Abhängigkeitsstrukturen.

Die AGPL-3.0-Klausel ist für SaaS am restriktivsten: Im Grunde lässt sich nichts nahtlos mit der AGPL-3.0 in einem kommerziellen Produkt kombinieren, ohne die Verpflichtung zum Copyleft-Netzwerk auszulösen.

Durchsetzung der Lizenzrichtlinien in CI/CD

Die Einhaltung der Lizenzbestimmungen, die auf regelmäßigen Audits beruht, scheitert bereits bei der Einführung: Eine GPL-Abhängigkeit, die jemand im letzten Sprint hinzugefügt hat, ist drei Wochen lang produktiv im Einsatz, bevor sie beim vierteljährlichen Audit entdeckt wird. Nur die kontinuierliche Überprüfung beim Merge-Vorgang verhindert, dass nicht-konforme Abhängigkeiten in den Quellcode gelangen.

YAML

# GitHub Actions: license compliance gate on every PR
name: License Compliance Check

on:
  pull_request:

jobs:
  license-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install license checker
        run: npm install -g license-checker fossa-cli

      - name: Scan dependency licenses
        run: |
          license-checker --summary --excludePrivatePackages \
            --out license-report.json

      - name: Enforce license policy
        run: |
          # Block GPL-2.0, GPL-3.0, AGPL-3.0, SSPL in commercial product
          FORBIDDEN=$(license-checker --failOn \
            "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL" \
            --excludePrivatePackages 2>&1 || true)

          if echo "$FORBIDDEN" | grep -q "FAIL"; then
            echo "Forbidden license detected in dependencies"
            echo "$FORBIDDEN"
            exit 1
          fi

      - name: Generate SBOM artifact
        run: |
          # Generate CycloneDX SBOM for audit trail
          npx @cyclonedx/cyclonedx-npm \
            --output-file sbom-$(date +%Y%m%d).json

      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom-*.json

Achtung: Lizenzrichtlinien sind organisationsspezifisch. Die Liste der verbotenen Lizenzen im obigen Beispiel spiegelt eine gängige Unternehmensrichtlinie wider. Ihre Rechtsabteilung muss jedoch festlegen, welche Lizenzen für Ihren spezifischen Produkttyp, Ihr Vertriebsmodell und Ihre Kundenvereinbarungen zulässig, zur Überprüfung vorgemerkt oder verboten sind. Eine in einem internen Tool zulässige Bibliothek kann in einem an Kunden vertriebenen Produkt verboten sein.

SBOM-Generierung und Formatstandards

Eine Software-Stückliste (SBOM) ist das strukturierte Dokument, das die Überprüfung der Lizenzkonformität ermöglicht und die Weitergabe sowie maschinelle Verifizierung erlaubt. Compliance-Teams können Lizenzverpflichtungen ohne manuelle Prüfungen bestätigen, wenn eine SBOM diese Daten bereitstellt. Zwei Formate dominieren den Markt:

CycloneDX wurde von OWASP entwickelt und ist für Sicherheits- und Lieferkettenanwendungen konzipiert. Es unterstützt Stücklisten für Komponenten, Dienste, Schwachstellen (VEX), Formeln und Modelle für maschinelles Lernen. Es ist das bevorzugte Format für sicherheitsorientierte SBOMs und wird von den meisten modernen SCA-Tool-Integrationen benötigt.

SPDX, gepflegt von der Linux Foundation, dem ISO/IEC-Standard (ISO 5962:2021). Erforderlich für einige staatliche Beschaffungsstandards, einschließlich Aspekte der Executive Order 14028. Mehr auf Lizenzkonformität als auf Sicherheit ausgerichtet, mit einer differenzierteren Lizenzausdruckssprache (SPDX-Ausdrücke können komplexe Szenarien mit mehreren Lizenzen abbilden). GPL-2.0-only AND MIT OR Apache-2.0).

Die Executive Order 14028 schließt Anbieter ohne SBOM-Zertifizierung bereits von Bundesaufträgen aus, die CRA führt ab September 2026 die Meldepflicht für Sicherheitslücken ein, und PCI DSS 4.0 befindet sich bereits in der Prüfungsphase. Entweder Sie liefern SBOM-konforme Software oder Sie verlieren Aufträge.

Bei Unternehmenssoftwareprodukten entstehen durch die Erstellung beider Formate außer der Generierung aus derselben Abhängigkeitsanalyse kaum zusätzliche Kosten. Die Zielgruppen unterscheiden sich: Sicherheitsteams und Workflows für das Schwachstellenmanagement nutzen CycloneDX; Rechtsabteilungen, Beschaffung und Workflows zur Einhaltung gesetzlicher Bestimmungen bevorzugen in der Regel SPDX.

Das Problem mit der Legacy-Codebasis: Kein Paketmanager, kein Manifest

Die oben beschriebenen Tools zur Abhängigkeitsanalyse – SCA-Scanner, Lockfile-Parser und SBOM-Generatoren – basieren auf der Annahme, dass Softwareabhängigkeiten über Paketmanager verwaltet und in Manifestdateien deklariert werden. Diese Annahme trifft auf moderne Java-, JavaScript-, Python-, Go- und Rust-Projekte zu. Sie gilt jedoch nicht für ältere Unternehmensumgebungen, die auf COBOL, JCL und Mainframe-Plattformen basieren.

In einer Mainframe-Umgebung manifestiert sich die Abhängigkeit von Drittanbietersoftware auf drei Arten, die Standard-SCA-Tools nicht erkennen können:

Lizenzierte Sortier- und Verbrauchsmaterialien. JCL-Jobstreams rufen Hilfsprogramme, Sortierprodukte (DFSORT, SyncSort/Syncsort, jetzt Precisely, CA Sort), Berichtsgeneratoren (SAS, EASYTRIEVE) und Datenkonvertierungstools auf. Diese sind kommerzielle Lizenzsoftware mit eigenen Lizenzbedingungen, Wartungsverträgen und Compliance-Anforderungen. Sie erscheinen in JCL als PGM=SORT, PGM=IEBGENER, PGM=ICETOOLProgrammnamen, nicht Paketbezeichner. Kein SCA-Tool, das diese liest. package.json or pom.xml wird sie finden.

Vom Anbieter bereitgestellte COBOL-Copybooks. Drittanbieter von Software liefern COBOL-Copybooks, die lizenzierte Software darstellen. Ein Fintech-Softwareanbieter, der COBOL-Programme für die Zahlungsabwicklung bereitstellt, kann Copybooks liefern, die seine proprietären Datenstrukturen definieren. Jedes COBOL-Programm, das diese Copybooks verwendet, nutzt lizenzierte Software. Die Lizenzverpflichtungen sind real; der entsprechende Eintrag im Paketmanager existiert nicht.

Eingebettete Algorithmen aus lizenzierten Quellen. Finanzinstitute, die COBOL-Systeme betreiben, haben möglicherweise lizenzierte Algorithmen, versicherungsmathematische Berechnungsroutinen, kryptografische Implementierungen und Bibliotheken für numerische Analysen direkt in den COBOL-Quellcode integriert. Diese stammen möglicherweise aus lizenziertem Quellcode, der in die Codebasis kompiliert wurde und nicht über Paketmanager identifiziert werden kann.

Die Erkennung dieser Komponenten erfolgt durch Quellcodeanalyse: Dabei werden CALL-Anweisungen verfolgt, um aufgerufene Programme zu identifizieren, COPY-Anweisungen untersucht, um eingebundene Elemente zu ermitteln, und die Programmnamen mit einer Datenbank bekannter Drittanbieterkomponenten abgeglichen. Die Ergebnisse fließen in denselben Workflow zur Lizenzkonformität ein, erfordern jedoch ein Tool, das die Semantik von COBOL und JCL versteht und nicht nur moderne Paketmanifestformate.

Erstellung des auditfähigen Compliance-Pakets

Wenn die Rechtsabteilung, die Compliance-Abteilung oder ein externer Prüfer einen Nachweis über die Einhaltung der Lizenzbestimmungen anfordert, ist ein Scanbericht zwar notwendig, aber nicht ausreichend. Das prüfungsfertige Compliance-Paket enthält:

• Vollständiges AbhängigkeitsinventarAlle Komponenten, Versionen und Lizenzen, einschließlich transitiver Abhängigkeiten, geordnet nach Produkt und Version
• LizenzverpflichtungsmatrixFür jede vorhandene Lizenzkategorie die spezifischen Verpflichtungen (Namensnennung, Offenlegung der Quelle, Änderungsmitteilung) und wie diese erfüllt werden
• Datei mit Urhebervermerken, hat rechtliche Hinweise für alle Komponenten zusammengestellt, die eine Namensnennung erfordern, und zwar in dem von der jeweiligen Lizenz geforderten Format (NOTICE-Datei für Apache-2.0, LICENSE-Datei für MIT usw.).
• InkompatibilitätsanalyseDokumentation, dass im kombinierten Produkt keine inkompatiblen Lizenzkombinationen vorhanden sind, mit rechtlicher Begründung für etwaige Grenzfälle
• SBOM-Artefakt, aktuelle CycloneDX- oder SPDX-Datei, signiert und mit Zeitstempel versehen, die alle Komponenten im Geltungsbereich abdeckt
• Richtliniendokumentation, die schriftliche Open-Source-Lizenzrichtlinie der Organisation, einschließlich des Genehmigungsprozesses für neue Lizenzen
• Genehmigungsunterlagen, für jede Lizenz, die vor ihrer Aufnahme einer rechtlichen Prüfung bedarf, die dokumentierte Genehmigung und die geschäftliche Begründung
• SanierungshistorieDokumentation aller zuvor festgestellten Verstöße und der zu deren Behebung ergriffenen Maßnahmen.

Speziell für die Due-Diligence-Prüfung bei Fusionen und Übernahmen: Erwerber fordern dieses Paket zunehmend als Teil der technischen Due-Diligence-Prüfung an. Ein vollständiges Compliance-Paket ohne ungelöste Verstöße beschleunigt den Due-Diligence-Prozess. Ein Paket, das ungelöste Verstöße gegen die Produktlizenzbestimmungen (GPL) in einem geschützten Produkt aufdeckt, führt in der Regel zu Preisanpassungen, Hinterlegungspflichten oder der Behebung von Mängeln als Abschlussbedingung. All dies ist kostspieliger als ein Compliance-Programm, das diese Verstöße verhindert hätte.

Wie SMART TS XL Unterstützt die Einhaltung von Lizenzbestimmungen in Unternehmenscodebasen

SMART TS XL Zuordnung von Anwendungsabhängigkeiten bietet die strukturelle Abhängigkeitsanalyseschicht für Unternehmenscodebasen, insbesondere in Legacy-Umgebungen, wo Standard-SCA-Tools an ihre Grenzen stoßen.

In Mainframe-Umgebungen identifiziert die Abhängigkeitskarte jedes von jedem anderen Programm aufgerufene Programm (einschließlich in JCL und COBOL eingebetteter Drittanbieter-Dienstprogramme), jedes von jedem Programm eingebundene Copybook (einschließlich herstellerseitiger Copybook-Abhängigkeiten) und jeden von jedem Programm verwendeten Datensatz (einschließlich Abhängigkeiten der Datenschicht von lizenzierten Datenbankprodukten). Diese Analyse erzeugt das Komponenteninventar, das Voraussetzung für die Lizenzkonformitätsprüfung in Umgebungen ohne Paketmanager ist.

Die statische Codeanalyse identifiziert Codemuster, die mit spezifischen Drittanbieterkomponenten verknüpft sind: proprietäre API-Aufrufsignaturen, herstellerspezifische Datenstrukturkonventionen und lizenzierte Algorithmenimplementierungen, die in benutzerdefinierten COBOL-Quellcode eingebettet sind. Diese Ergebnisse ergänzen die manifestbasierte Bestandsaufnahme um Codeabhängigkeiten, die durch die Manifestanalyse nicht erfasst werden können.

Die Auswirkungsanalyse ermöglicht es, Lizenzrichtlinienänderungen gezielt umzusetzen: Ändert sich die Lizenz einer Komponente, beispielsweise durch eine Lizenzänderung von MIT auf AGPL-3.0 oder durch eine Änderung der Nutzungsbedingungen eines Anbieters, identifiziert die Auswirkungsanalyse alle Programme im Portfolio, die direkt oder indirekt von dieser Komponente abhängen. Dadurch wird ein Lizenzänderungsereignis von einem unbekannten Risiko in einen klar definierten Handlungsspielraum für Abhilfemaßnahmen umgewandelt.

Die unternehmensweite Suchfunktion ermöglicht die Abfrage des Abhängigkeitsinventars für Compliance-Zwecke: Innerhalb von Sekunden findet sich im gesamten bestehenden Portfolio jedes Programm, das ein bestimmtes Hilfsprogramm aufruft, jedes Copybook, das ein bestimmtes vom Anbieter bereitgestelltes Element enthält, und jedes Programm, das von einer bestimmten lizenzierten Komponente abhängt. Diese Suchfunktion ist das ideale Werkzeug für die anstehende M&A-Prüfung am Dienstagmorgen: eine einfache Abfrage statt einer manuellen Überprüfung.

Für Organisationen, die eine umfassende SBOM-Abdeckung aufbauen, die sowohl moderne als auch ältere Systeme umfasst, SMART TS XL Es bietet das Legacy-Komponenteninventar, das Standard-SBOM-Generatoren nicht erstellen können, und ergänzt damit Tools wie Syft, FOSSA und Dependency-Track für den modernen Stack.

Die Prüfung, die niemals eine Überraschung sein sollte

Die Prüfung der Lizenzkonformität gehört zu den wenigen regulatorischen Disziplinen, in denen die Folgen von Verstößen häufig nicht von einer Aufsichtsbehörde, sondern von einem Geschäftspartner, einem Erwerber, der Rechtsabteilung eines Kunden oder einem Vertriebspartner aufgedeckt werden, der die Lizenzbedingungen liest und einen Nachweis über die Einhaltung verlangt. Die Kosten dieser Aufdeckung reichen von unangenehm bis existenzbedrohend, je nach Schwere des Verstoßes und Phase der Transaktion.

Das Abhängigkeitsanalyseprogramm, das solche unerwarteten Entdeckungen verhindert, ist im Verhältnis zum minimierten Risiko nicht teuer. Es erfordert Kenntnisse über die gesamte Software, jede Komponente, jede transitive Abhängigkeit, jedes externe Code-Snippet und jedes Legacy-Dienstprogramm. Jedes dieser Elemente muss kontinuierlich, nicht nur periodisch, mit den Lizenzrichtlinien des Unternehmens abgeglichen werden. Die Tools, Standards (SBOM, SPDX, CycloneDX) und regulatorischen Vorgaben (EO 14028, CRA, PCI-DSS 4.0) sind vorhanden. Was den meisten Unternehmen fehlt, ist die Disziplin, die Abhängigkeitsanalyse als Teil der Infrastruktur und nicht nur als Prüfungsmaßnahme zu behandeln.

Der Dienstagmorgen, der mit einem Bericht statt mit einer Feueralarmübung beginnt, ist der Dienstagmorgen, den die Infrastruktur für Abhängigkeitsanalysen ermöglicht hat.