💻 computer science

Detecting and Fixing Violations of Modification Terms in Open Source Licenses during Forking

Dieses Paper stellt LiVo vor, ein Werkzeug, das darauf ausgelegt ist, Verstöße gegen Modifikationsbedingungen in Open-Source-Lizenzen während des Forking-Prozesses automatisch zu erkennen und zu beheben, wobei eine bisher unerforschte Lücke in der Minderung rechtlicher Risiken durch die empirische Charakterisierung von 47 Lizenzen und eine erfolgreiche Validierung über gemergte Pull-Requests adressiert wird.

Ursprüngliche Autoren: Kaifeng Huang, Yingfeng Xia, Bihuan Chen, Zhuotong Zhou, Jin Guo, Xin Peng

Veröffentlicht 2026-06-23

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Kaifeng Huang, Yingfeng Xia, Bihuan Chen, Zhuotong Zhou, Jin Guo, Xin Peng

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich die Welt der Open-Source-Software wie eine riesige, belebte Bibliothek vor, in der jeder Bücher ausleihen, lesen und sogar Kapitel umschreiben kann, um seine eigenen neuen Geschichten zu erschaffen. Das ist großartig für die Kreativität, aber es gibt einen Haken: Fast jedes Buch in dieser Bibliothek kommt mit einem spezifischen Satz an Regeln (einer Lizenz), die vom ursprünglichen Autor verfasst wurden.

Die meisten Menschen kennen die großen Regeln, wie zum Beispiel „Sie müssen die Urheberschaft angeben“ oder „Sie müssen Ihre neue Version kostenlos zur Verfügung stellen“. Aber es gibt eine heimliche, oft übersehene Regel, die in vielen dieser Lizenzen versteckt ist: die Modifikationsklausel (Modification Term).

Die „Änderungsprotokoll“-Regel

Betrachten Sie die Modifikationsklausel als eine strenge Bibliothekarin-Regel: „Wenn Sie ein Buch aus unserer Bibliothek entnehmen, ein paar Seiten ändern und eine neue Version erstellen, müssen Sie einen Klebezettel schreiben, auf dem genau erklärt wird, was Sie geändert haben, wer es geändert hat und wann.“

Einige Lizenzen besagen, dass der Klebezettel auf jeder einzelnen Seite, die Sie berührt haben, stehen muss. Andere sagen, Sie können ihn in ein separates „Änderungen“-Notizbuch am Anfang des Buches legen. Wieder andere sagen einfach nur: „Stellen Sie sicher, dass jemand weiß, dass Sie es geändert haben.“

Das Problem? Die meisten Entwickler sind so sehr mit dem Schreiben von Code beschäftigt, dass sie vergessen, diese Klebezettel zu schreiben. Sie erstellen einen „Fork“ (eine Kopie des Projekts, das sie modifiziert haben), versäumen es aber, eine Spur dessen zu hinterlassen, was sie getan haben. Dies ist ein Rechtsverstoß, vergleichbar mit der Rückgabe eines Bibliotheksbuches mit zerrissenen Seiten, ohne eine Notiz darüber zu hinterlassen, warum dies geschah.

Das Problem: Die „stille“ Verletzung

Die Forscher der Fudan University erkannten, dass wir zwar Werkzeuge haben, um zu prüfen, ob man das richtige Buch benutzt, aber wir keine Werkzeuge haben, um zu prüfen, ob man vergessen hat, seinen Klebezettel zu schreiben. Sie fragten sich:

Was genau sagen diese Regeln aus?
Wie oft brechen Menschen sie?
Können wir einen Roboter bauen, um das zu beheben?

Die Lösung: Treffen Sie „LiVo“ (Den Bibliotheks-Wächter)

Um dies zu lösen, entwickelte das Team ein Werkzeug namens LiVo. Sie können sich LiVo als einen superintelligenten, automatisierten Bibliothekar vorstellen, der die „geforkten“ Bibliotheken kontrolliert.

So funktioniert LiVo, Schritt für Schritt:

Die Detektivarbeit (Die Änderungen finden): LiVo betrachtet das ursprüngliche Bibliotheksbuch und die neue, modifizierte Version. Es scannt durch jeden einzelnen „Commit“ (eine gespeicherte Änderung im Code), um zu sehen, welche Dateien tatsächlich berührt wurden. Es filtert die unwichtigen Dinge heraus, wie zum Beispiel, wenn jemand lediglich eine Seite aus dem Original kopiert hat, ohne sie zu verändern.
Die Suche (Nach dem Notizzettel suchen): Sobald LiVo weiß, welche Dateien geändert wurden, macht es sich auf die Suche nach dem „Klebezettel“. Es sucht an zwei Stellen:
- Innerhalb der modifizierten Dateien selbst.
- In einer separaten „Change Log“-Datei (wie einer CHANGELOG.md), die in Softwareprojekten üblich ist.
Der Abgleich (Haben sie es richtig gemacht?): LiVo vergleicht die „Commit-Nachricht“ (was der Entwickler beim Speichern der Änderung angegeben hat) mit dem „Change Log“ (dem Klebezettel).
- Wurde die Änderung erwähnt?
- Wurde das Datum angegeben?
- Wurde der Name angegeben?
  Wenn die Antwort auf eine dieser Fragen „Nein“ lautet, markiert LiVo dies als Verstoß.
Die Korrektur (Der Autopilot): Wenn LiVo einen fehlenden Notizzettel findet, schreit es nicht einfach nur, sondern versucht es zu beheben. Es schreibt automatisch den fehlenden Klebezettel basierend auf der ursprünglichen Commit-Nachricht des Entwicklers und schlägt vor, diesen dem Projekt hinzuzufügen.

Was sie herausfanden (Der Realitätscheck)

Das Team testete LiVo an 178 Paaren realer Softwareprojekte (ein Bassprojekt und dessen Fork). Die Ergebnisse waren augenöffnend:

Es ist ein häufiger Fehler: Etwa 51 % der modifizierten Projekte verstießen gegen diese Regeln. Sie hatten den Code geändert, aber vergessen, die erforderlichen Notizen zu schreiben.
Das Ausmaß: Sie fanden über 51.000 spezifische Instanzen, in denen Entwickler vergessen hatten, ihre Änderungen zu dokumentieren.
Der Quellcode ist der Übeltäter: Die meisten fehlenden Notizen betrafen Änderungen am eigentlichen „Quellcode“ (den Anweisungen, die das Programm ausführen), im Gegensatz zu Dokumentationen oder Skripten.

Hat es funktioniert?

LiVo ist nicht nur eine Theorie; sie haben es in der realen Welt getestet.

Sie schickten 91 „Pull Requests“ (offizielle Vorschläge zur Behebung des Codes) an die Projektbesitzer.
18 Entwickler reagierten positiv und sagten: „Oh, du hast recht! Das haben wir vergessen.“
8 dieser Korrekturen wurden tatsächlich in den Hauptcode übernommen (merged), was bedeutet, dass das rechtliche Risiko offiziell gelöst wurde.

Das Fazit

Dieses Paper ist das erste, das sagt: „Hey, wir müssen aufhören, die Regel über das Schreiben von Notizen zu ignorieren, wenn wir Open-Source-Code ändern.“ Sie haben kartografiert, wie genau diese Regeln über 47 verschiedene Lizenzen hinweg aussehen, und ein Werkzeug namens LiVo gebaut, das wie ein hilfreicher Bibliothekar fungiert, die fehlenden Notizen findet und sie für einen schreibt.

Es geht nicht darum, Menschen daran zu hindern, Code zu ändern; es geht darum, sicherzustellen, dass die „Papierspur“ existiert, damit jeder weiß, wer was geändert hat, um die rechtliche Bibliothek sicher und organisiert zu halten.

Technische Zusammenfassung: Erkennung und Behebung von Verstößen gegen Modifikationsbedingungen in Open-Source-Lizenzen während des Forking-Prozesses

Problemstellung
Die Entwicklung von Open-Source-Software (OSS) beruht maßgeblich auf dem Forking, bei dem Entwickler ein Basis-Repository kopieren, um eine neue, unabhängig modifizierte Version zu erstellen. Während dies die Innovation fördert, führt es zu erheblichen rechtlichen Risiken, wenn Entwickler versäumen, die Lizenzverpflichtungen einzuhalten. Die bestehende Forschung hat sich auf die Identifizierung von Lizenzen, die Erkennung von Inkompatibilitäten zwischen Abhängigkeiten und das Finden von Inkonsistenzen in der Lizenzierung von Dateien konzentriert. Eine kritische Lücke besteht jedoch hinsichtlich der Modifikationsbedingungen (Modification Terms, MTs). MTs sind spezifische Klauseln in OSS-Lizenzen, die die Bedingungen festlegen, unter denen Nutzer das Originalwerk modifizieren dürfen und welche Verpflichtungen sie bei einer solchen Modifikation erfüllen müssen. Ein prominentes Beispiel ist die Anforderung in Lizenzen wie Apache-2.0, „auffällige Hinweise“ (prominent notices) einzufügen, die besagen, dass Dateien geändert wurden. Nach Kenntnis der Autoren gibt es bisher keine Arbeit, die diese Bedingungen systematisch charakterisiert oder automatisierte Mechanismen zur Erkennung und Behebung von Verstößen gegen MTs während des Forking-Prozesses bereitstellt.

Methodik
Die Autoren schlagen einen zweiphasigen Ansatz vor: eine empirische Studie zur Charakterisierung von MTs, gefolgt von der Entwicklung eines automatisierten Tools namens LiVo.

1. Empirische Charakterisierung von Modifikationsbedingungen
Die Autoren führten eine empirische Studie an 107 Lizenzen durch, die von der Open Source Initiative (OSI) genehmigt wurden. Sie identifizierten 47 Lizenzen, die explizit MTs deklarieren, die eine bestimmte Form von „Hinweis“ (notice) erfordern, um Modifikationen zu beschreiben. Um diese Verpflichtungen zu modellieren, analysierten die Autoren die Lizenzen über drei Dimensionen hinweg:

Modifikationsumfang ( $S_g$ ): Die Arten von Dateien, die Modifikationsverpflichtungen unterliegen (z. B. Quellcode, Dokumentation, Konfigurationsdateien, Skripte). Diese wurden in acht Gruppen unterteilt, wobei festgestellt wurde, dass fast die Hälfte der Lizenzen (44,7 %) für jeden Dateityp gilt.
Inhalt des Hinweises ( $C_g$ ): Die erforderlichen Informationen im Hinweis. Dies wurde in vier Elemente unterteilt: Datum, Autor, kurze Erklärung (die besagt, dass Dateien geändert wurden) und informative Erklärung (die detailliert beschreibt, wie/warum). Lizenzen wurden basierend auf diesen Anforderungen in sechs Kategorien gruppiert.
Ort des Hinweises ( $L_g$ ): Wo der Hinweis platziert werden muss. Dies wurde in zwei Elemente unterteilt: ein separates Dokument (z. B. CHANGELOG) oder jede modifizierte Datei. Lizenzen wurden in vier Kategorien gruppiert.

Basierend auf diesen Dimensionen wurden die 47 Lizenzen als 2-Tupel $\langle lic, O \rangle$ modelliert, wobei $O$ ein 3-Tupel $\langle S_g, C_g, L_g \rangle$ darstellt, das die spezifische Verpflichtung repräsentiert.

2. Der LiVo-Ansatz
LiVo ist ein automatisiertes Tool, das darauf ausgelegt ist, MT-Verstöße während des Forking zu erkennen und zu beheben. Es nimmt ein Basis-Repository und ein Fork-Repository als Eingabe entgegen und arbeitet in drei Schritten:

Schritt 1: Erkennung verpflichtender Modifikationen
- Datei-Mapping: LiVo erstellt Zuordnungen zwischen Dateien in den Basis- und Fork-Repositories, um die Wiederverwendung zu identifizieren. Es behandelt Szenarien, in denen Dateien umbenannt, verschoben oder kopiert wurden (unter Verwendung von Werkzeugen wie JGit und Saga).
- Lizenzerkennung: Es verwendet Ninka, um die Lizenz jeder Datei im Basis-Repository zu erkennen.
- Verpflichtende Dateien & Commits: Es identifiziert „verpflichtende Dateien“ (Dateien, die in den Modifikationsumfang der erkannten Lizenz fallen) und „verpflichtende Commits“ im Fork-Repository, die diese Dateien modifizieren. Dabei werden Commits herausgefiltert, die aus dem Basis-Repository übernommen (da diese bereits konform sind) oder rückgängig gemacht (reverted) wurden.
Schritt 2: Extraktion des Hinweises
- LiVo lokalisiert potenzielle Hinweisdateien im Fork-Repository (z. B. CHANGELOG, RELEASE.txt).
- Es extrahiert „Änderungsprotokolle“ (change logs) aus diesen Dateien. Die Extraktionslogik verarbeitet semistrukturierte Texte und identifiziert Änderungsblöcke, die mit bestimmten Datumsbereichen und Autoren verknüpft sind.
- Jeder extrahierte Änderungsprotokoll-Eintrag wird als Tupel $\langle msg, d_s, d_e, a \rangle$ (Nachricht, Startdatum, Enddatum, Autor) modelliert.
Schritt 3: Erkennung und Behebung von Verstößen
- Abgleich (Matching): Für jeden verpflichtenden Commit versucht LiVo, eine Übereinstimmung mit einem Änderungsprotokoll aus dem extrahierten Satz herzustellen.
- Ähnlichkeitsprüfung: Es verwendet TF-IDF, um die semantische Ähnlichkeit zwischen der Commit-Nachricht und der Nachricht im Änderungsprotokoll zu messen. Wenn die Ähnlichkeit einen Schwellenwert (empirisch auf 0,3 gesetzt) überschreitet, gilt die Inhaltsanforderung als erfüllt.
- Attributverifizierung: Es prüft, ob das Commit-Datum innerhalb des Datumsbereichs des Änderungsprotokolls liegt und ob der Commit-Autor mit dem Autor des Änderungsprotokolls übereinstimmt.
- Klassifizierung: Commits werden klassifiziert als:
  - OB (Vollständig verpflichtet - Fully Obligated): Alle Anforderungen erfüllt.
  - VN (Verletzt - Fehlender Hinweis - Violated - Missing Notice): Kein passender Eintrag im Änderungsprotokoll gefunden.
  - VD (Verletzt - Fehlendes Datum - Violated - Missing Date): Datumsbereich weicht ab.
  - VA (Verletzt - Fehlender Autor - Violated - Missing Author): Autor stimmt nicht überein.
- Behebung: Bei Verstößen generiert LiVo eine Behebung, indem es einen Eintrag im Änderungsprotokoll erstellt oder aktualisiert, der die korrekte Nachricht, das korrekte Datum und den korrekten Autor enthält, und schreibt diesen in die entsprechende Hinweisdatei.

Wichtigste Ergebnisse
Die Autoren evaluierten LiVo anhand von 178 Paaren aus Basis- und Fork-Repositories (ausgewählt aus hoch bewerteten GitHub-Projekten).

Prävalenz: 21,9 % der analysierten Forked-Repositories erforderten MTs in ihren Lizenzen.
Schweregrad der Verstöße: 51,1 % der analysierten Forked-Repositories verstießen gegen MTs. Kritischer noch war, dass 95,3 % der verpflichtenden Commits (Commits, die geschützte Dateien modifizieren) gegen MTs verstießen. Der häufigste Verstoß war der fehlende Hinweis (VN), gefolgt vom fehlenden Datum (VD).
Genauigkeit: LiVo erreichte eine Makro-Präzision von 0,82 und eine Makro-Recall von 0,80 bei der Erkennung und Klassifizierung von Verstößen. Die Hauptfehlerquelle war die semantische Unwissenheit von TF-IDF beim Abgleich kurzer Commit-Nachrichten mit Änderungsprotokollen.
Effizienz: Das Tool benötigte im Durchschnitt 229,8 Sekunden pro Repository-Paar, wobei der Schritt der Modifikationserkennung etwa 92 % der Laufzeit beanspruchte.
Reale Auswirkungen: Die Autoren reichten 91 Pull Requests in den betroffenen Repositories ein. 18 erhielten positive Rückmeldungen und 8 wurden in die Hauptzweige gemergt. Einige Entwickler leisteten anfangs Widerstand, mit dem Argument, dass die Commit-Historie selbst als Hinweis diene oder sie die ursprünglichen Autoren seien, aber das Tool konnte die Mehrheit der Fälle erfolgreich identifizieren und Korrekturen vorschlagen.

Bedeutung und Ansprüche
Das Paper beansprucht, die erste Arbeit zu sein, die:

Modifikationsbedingungen über einen großen Satz von Open-Source-Lizenzen empirisch charakterisiert.
Einen automatisierten Ansatz (LiVo) zur Erkennung und Behebung von Verstößen gegen diese spezifischen Bedingungen während des Forkings vorschlägt.

Die Autoren betonen, dass während die Lizenzidentifizierung und die Erkennung von Inkompatibilitäten ausgereifte Felder sind, die spezifische Verpflichtung, eine „Benachrichtigung“ (notice) für Modifikationen bereitzustellen, übersehen wurde. Durch die Adressierung dieses Problems hilft LiVo, rechtliche Risiken wie Klagen und finanzielle Verluste aufgrund von Nichteinhaltung zu mindern. Das Paper schließt mit dem Schluss, dass MT-Verstöße in realen Szenarien schwerwiegend sind und dass eine automatisierte Erkennung und Behebung machbar und effektiv ist, wenngin Verbesserungen beim semantischen Matching (z. B. durch Deep Learning) notwendig sind, um die Anzahl der falsch-positiven und falsch-negativen Ergebnisse weiter zu reduzieren.