Open-Source-Lizenz-Compliance mit Knowledge Graphs: So macht ABIS Lizenzrisiken sichtbar und auditfähig

Kurzantwort: Open-Source-Lizenz-Compliance scheitert selten an der Erkennung einzelner Lizenzen, sondern am fehlenden Kontext. Ein Knowledge Graph verbindet Dateien, Komponenten, Lizenzen und Scan-Ergebnisse zu einem abfragbaren Modell. Im hier dokumentierten Use Case (Notepad++-Projekt, modelliert in ABIS) wurden so 469 fehlende Lizenzangaben zugeordnet, 291 unklare Review-Fälle per Git-Recherche geklärt und nur 4 echte Lizenzverstöße als reales Risiko isoliert – mit lückenloser Nachvollziehbarkeit für Audit und Due Diligence.

Auf einen Blick: Die wichtigsten Ergebnisse

Definition: Open-Source-Lizenz-Compliance bezeichnet den Nachweis, dass alle in einer Software verwendeten Open-Source-Komponenten korrekt lizenziert und ihre Lizenzbedingungen erfüllt sind – einschließlich Weitergabe-, Attributions- und Kompatibilitätspflichten.

Warum reicht ein klassischer Lizenz-Scan nicht aus?

Open-Source-Compliance wird in vielen Unternehmen noch immer vor allem als Scan-Ergebnis verstanden: Ein Tool läuft über den Code, erkennt Lizenzen, markiert Auffälligkeiten und erzeugt eine lange Liste von Findings.

Das Problem: In realen Softwareprojekten reicht diese Sicht oft nicht aus. Open-Source-Lizenz-Compliance ist selten nur eine Frage einzelner Dateien. Entscheidend ist der Kontext:

• Welche Datei gehört zu welcher Komponente?

• Welche Komponente bringt welche wirksame Lizenz mit?

• Welche Warnung ist ein echtes rechtliches Risiko – und welche entsteht nur, weil ein Scanner einen Lizenzverweis nicht korrekt interpretieren konnte?

Genau hier setzt der Einsatz von Knowledge Graphs an. In diesem Use Case wurde das Notepad++-Projekt mit ABIS als Wissensgraph modelliert und auf Open-Source-Lizenz-Compliance analysiert. Das Ziel: nachweisen, dass die verwendeten Komponenten korrekt lizenziert sind, echte Risikofälle identifizieren und eine nachvollziehbare Grundlage für Audit, Due Diligence und Remediation schaffen.

Was ist ein Knowledge Graph für Open-Source-Compliance?

In großen Codebasen liegen Lizenzinformationen nicht an einer einzigen Stelle. Sie verteilen sich über einzelne Quelldateien, Komponenten und Unterkomponenten, externe Lizenzdateien, historische Projektstrukturen, eingebettete Drittanbieter-Bibliotheken sowie Scanner-Verdicts wie compatible , missing , review oder violation .

Ein klassischer Scan erkennt zwar viele Muster, verliert aber schnell den Zusammenhang. So entstehen lange Warnlisten, die Compliance-Teams manuell einordnen müssen.

Definition: Ein Knowledge Graph (Wissensgraph) bildet Dateien, Komponenten, Lizenzen, Scan-Ergebnisse und Rechercheerkenntnisse als vernetztes Modell aus Knoten und Beziehungen ab. Statt isolierter Findings entsteht eine navigierbare, abfragbare und erklärbare Compliance-Landkarte.

Was wurde im Graphen modelliert?

Das Notepad++-Projekt wurde in ABIS vollständig als Knowledge Graph abgebildet.

Beziehungen wie „Datei gehört zu Komponente" oder „Komponente steht unter Lizenz" machen sichtbar, wie Lizenzinformationen tatsächlich durch das Projekt wirken. Dadurch lassen sich zentrale Compliance-Fragen direkt im Graphen beantworten: Welche Lizenzen sind im Produkt enthalten? Welche Dateien hängen an welchen Lizenzen? Wo liegen echte unvereinbare Lizenzen? Welche Findings sind auditrelevant?

Wie identifiziert man kritische Lizenzverstöße? (Schritt 1)

Zunächst wurden die bereits vorhandenen Compliance-Urteile je Datei ausgewertet. Der Graph zeigte, dass nur vier Dateien echte Verstöße enthielten. Diese Dateien waren rechtlich kritisch, weil sie nicht ohne Weiteres weitergegeben werden dürfen.

Diese Fälle wurden im Graphen hervorgehoben und als Bookmark gespeichert: 🚨 License Violations (fine risk) .

Der entscheidende Punkt: Der Graph half nicht nur dabei, viele Findings zu erzeugen, sondern die wenigen wirklich kritischen Fälle präzise zu isolieren.

Wie ordnet man Dateien mit fehlender Lizenz zu? (Schritt 2)

Insgesamt waren 469 Dateien als missing markiert. Isoliert betrachtet klingt das nach erheblichem Risiko. Im Graphen konnte jedoch nachvollzogen werden, zu welcher Komponente diese Dateien gehören – und welche wirksame Lizenz diese Komponente trägt.

Die Kernaussage: 238 Dateien waren Notepad++-eigener Code und konnten der Projektlizenz GPL-3.0 zugeordnet werden. Die übrigen 231 Dateien waren Drittanbieter-Code und erbten die jeweilige Upstream-Lizenz ihrer Komponente. Aus einer scheinbar großen Menge fehlender Lizenzangaben wurde damit ein nachvollziehbares, strukturiertes Bild.

Wie reichert man den Graphen mit Compliance-Erkenntnissen an? (Schritt 3)

Nach der Zuordnung wurden die Erkenntnisse als Enrichment im Graphen ergänzt. Wichtig ist dabei die Unterscheidung zwischen zwei Konzepten:

Das Enrichment ergänzte je Sammelknoten die wirksame Lizenz, die Begründung, den Vertrauensgrad und die empfohlene Handlung. Der ursprüngliche Scanner-Befund blieb erhalten.

Das ist besonders wichtig für Audits: Es bleibt nachvollziehbar, was der Scanner ursprünglich erkannt hat und welche fachliche Entscheidung anschließend getroffen wurde.

Warum war die Projektion zunächst nicht sichtbar? (Schritt 4)

Im Use Case zeigte sich ein typisches Modellierungsproblem: Die Projektionsebene war aktiv, aber im Graphen zunächst nicht sichtbar. Der Grund: Enrichment allein erzeugt keine neuen sichtbaren Beziehungen. Deshalb wurde eine echte Projektion modelliert – mit drei geplanten Lizenzknoten und acht geplanten Verbindungen.

Damit konnten die zuvor „toten" Knoten visuell in der Projektion als gelöst dargestellt werden.

Welche simulierten Werte zeigt die Projektion? (Schritt 5)

Die Projektion zeigte, auf welche realen Lizenzen die ursprünglich fehlenden Lizenzangaben umgeleitet würden.

Zusammengefasst wurden 469 Dateien auf drei Lizenzknoten umgeleitet: GPL-3.0-or-later (244), Scintilla-Lizenz / HPND (220) und BSL-1.0 (5). Diese Werte wurden zunächst als vorgemerkte Projektion behandelt – ein fachlich begründeter Vorschlag, der nach Freigabe festgeschrieben werden kann.

Wie klärt man unklare Lizenzfälle per Git-Recherche? (Schritt 6)

Ein großer Teil der verbleibenden Review-Fälle betraf Lexilla und Scintilla. Der Scanner hatte viele Dateien als unknown-license-reference markiert. Die direkte Recherche im Git-Repository zeigte jedoch: Die Dateiköpfe verwiesen auf eine externe License.txt . Diese trug den Titel „License for Lexilla, Scintilla, and SciTE" und enthielt eine permissive Nutzungserlaubnis.

Definition: Die HPND-Lizenz (Historical Permission Notice and Disclaimer) ist eine permissive, GPLv3-kompatible Open-Source-Lizenz. Code unter HPND darf frei genutzt, verändert und weitergegeben werden.

Der entscheidende Befund: Keine dieser Dateien musste entfernt werden. Die unbekannten Markierungen waren kein reales Lizenzrisiko, sondern Scanner-Rauschen, das durch Recherche und Graph-Kontext aufgelöst werden konnte.

Endergebnis: Vom Scan-Ergebnis zur auditfähigen Entscheidung

Nach der Analyse ergab sich folgende Statusübersicht über alle 2.394 Dateien:

Damit änderte sich die Perspektive grundlegend: Nicht die Anzahl der Warnungen war entscheidend, sondern deren tatsächliche Bedeutung. Nur vier echte Verstöße waren unmittelbar risikorelevant, während 469 fehlende Lizenzangaben und 291 Review-Fälle nachvollziehbar geklärt werden konnten.

Verbleibende Restfälle

Bookmarks für Review und Nachverfolgung

Diese Bookmarks machen die Analyse operativ nutzbar. Teams können gezielt zwischen echten Risiken, Review-Fällen und bereits geklärten Dateien wechseln.

Empfehlungen und nächste Schritte

Warum der Graph-Ansatz für Open-Source-Lizenz-Compliance so wertvoll ist

Der Mehrwert liegt nicht nur darin, Findings sichtbar zu machen. Der eigentliche Wert entsteht durch Kontext. Ein Knowledge Graph kann zeigen, warum eine Datei als kritisch gilt, welche Komponente betroffen ist, welche Lizenz tatsächlich wirkt, welche Fälle durch Recherche geklärt wurden und welche Punkte noch offen sind.

Damit entsteht eine belastbare Entscheidungsgrundlage für Legal, Security, Engineering und Management. Gerade für Open-Source-Lizenz-Compliance ist das entscheidend: Unternehmen müssen nicht nur Risiken erkennen, sondern auch erklären können, wie sie zu ihren Bewertungen gekommen sind.

Fazit

Dieser Use Case zeigt, wie sich Open-Source-Lizenz-Compliance von einer statischen Scan-Liste zu einem erklärbaren, graphbasierten Entscheidungsprozess entwickeln kann:

• 469 fehlende Lizenzangaben wurden wirksam zugeordnet.

• 291 unklare Dateien wurden durch Git-Recherche geklärt.

• Nur 4 Dateien blieben als echte Lizenzverstöße übrig.

• Rund 15 unkritische Restfälle benötigen noch manuelle Bestätigung.

Für Compliance-Teams bedeutet das: weniger Rauschen, mehr Nachvollziehbarkeit und ein klarer Weg zum Audit-Nachweis. Die Zukunft der Software-Compliance liegt nicht in noch größeren Tabellen, sondern in vernetztem, erklärbarem und überprüfbarem Wissen.

Häufige Fragen (FAQ)

Was bedeutet Open-Source-Lizenz-Compliance?

Open-Source-Lizenz-Compliance bedeutet, nachzuweisen, dass alle verwendeten Open-Source-Komponenten korrekt lizenziert sind und ihre Lizenzpflichten (Weitergabe, Attribution, Kompatibilität) erfüllt werden. Wird nicht lizenzierter oder unvereinbar lizenzierter Code ausgeliefert, drohen rechtliche Risiken und Bußgelder.

Wie hilft ein Knowledge Graph bei der Lizenz-Compliance?

Ein Knowledge Graph verbindet Dateien, Komponenten und Lizenzen zu einem abfragbaren Modell. Dadurch lässt sich für jede Warnung der Kontext bewerten: Welche Komponente ist betroffen, welche Lizenz wirkt tatsächlich, und ist ein Finding ein echtes Risiko oder nur Scanner-Rauschen.

Sind fehlende Lizenzangaben automatisch ein Compliance-Risiko?

Nein. Im Use Case waren 469 Dateien als „missing" markiert, ließen sich aber über ihre Komponente einer wirksamen Lizenz zuordnen – 238 davon zur GPL-3.0-Projektlizenz. Fehlende Angaben sind oft Kennzeichnungslücken, kein rechtliches Risiko.

Was ist die HPND-Lizenz und ist sie GPLv3-kompatibel?

HPND (Historical Permission Notice and Disclaimer) ist eine permissive Open-Source-Lizenz und GPLv3-kompatibel. Im Use Case waren 272 als „unknown" markierte Lexilla-/Scintilla-Dateien tatsächlich HPND-lizenziert und damit unbedenklich weitergebbar.

Worin unterscheiden sich Enrichment und Projektion im Graphen?

Enrichment ergänzt Informationen auf bestehenden Knoten, ohne das Original-Scan-Ergebnis zu überschreiben. Eine Projektion ist eine Was-wäre-wenn-Überlagerung mit geplanten Knoten und Beziehungen, die eine mögliche Auflösung visuell simuliert.