💻 computer science

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

Dit artikel introduceert LiVo, een tool die is ontworpen om automatisch schendingen van wijzigingsvoorwaarden in open-sourcelicenties tijdens het forken te detecteren en te herstellen, waarmee een voorheen onverkend gat in de mitigatie van juridische risico's wordt geadresseerd door middel van een empirische karakterisering van 47 licenties en succesvolle validatie via samengevoegde pull requests.

Oorspronkelijke auteurs: Kaifeng Huang, Yingfeng Xia, Bihuan Chen, Zhuotong Zhou, Jin Guo, Xin Peng

Gepubliceerd 2026-06-23

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Kaifeng Huang, Yingfeng Xia, Bihuan Chen, Zhuotong Zhou, Jin Guo, Xin Peng

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je de wereld van open-source software voor als een enorme, bruisende bibliotheek waar iedereen boeken kan lenen, ze kan lezen en zelfs hoofdstukken kan herschrijven om hun eigen nieuwe verhalen te creëren. Dit is geweldig voor de creativiteit, maar er is een addertje onder het gras: elk boek in deze bibliotheek komt met een specifieke set regels (een licentie) geschreven door de oorspronkelijke auteur.

De meeste mensen kennen de grote regels, zoals "Je moet credit geven" of "Je moet je nieuwe versie gratis delen." Maar er is een sluipende, vaak over het hoofd geziene regel die in veel van deze licenties verborgen zit, genaamd de Modification Term (Wijzigingsterm).

De "Change Log"-regel

Beschouw de Modification Term als een strikte regel van een bibliothecaris: "Als je een boek uit onze bibliotheek neemt, een paar pagina's verandert en een nieuwe versie maakt, moet je een briefje plakken waarin je precies uitlegt wat je hebt veranderd, wie het heeft veranderd en wanneer."

Sommige licenties zeggen dat het briefje op elke pagina die je hebt aangeraakt moet staan. Anderen zeggen dat je het in een apart "Changes"-notitieboekje aan het begin van het boek kunt zetten. Sommige zeggen gewoon: "Zorg ervoor dat iemand weet dat je het hebt veranderd."

Het probleem? De meeste ontwikkelaars zijn zo druk bezig met het schrijven van code dat ze vergeten deze briefjes te schrijven. Ze maken een "fork" (een kopie van het project dat ze aanpassen) maar laten geen spoor achter van wat ze hebben gedaan. Dit is een juridische overtreding, alsoverst een bibliotheekboek terugbrengt met gescheurde pagina's zonder een briefje toe te voegen dat uitlegt waarom.

Het Probleem: De "Stille" Overtreding

De onderzoekers van de Fudan Universiteit realiseerden zich dat, hoewel we tools hebben om te controleren of je het juiste boek gebruikt, we geen tools hebben om te controleren of je bent vergeten je briefje te schrijven. Ze vroegen zich af:

Wat zeggen deze regels precies?
Hoe vaak overtreden mensen ze?
Kunnen we een robot bouwen om dit te repareren?

De Oplossing: Maak kennis met "LiVo" (De Bibliotheek-Wachter)

Om dit op te lossen, bouwde het team een tool genaamd LiVo. Je kunt LiVo zien als een super-slimme, geautomatiseerde bibliothecaris die de "geforkte" bibliotheken controleert.

Zo werkt LiVo, stap voor stap:

Het Detectiewerk (De wijzigingen vinden): LiVo bekijkt het originele bibliotheekboek en de nieuwe, gewijzigde versie. Het scant door elke enkele "commit" (een opgeslagen wijziging in de code) om te zien welke bestanden daadwerkelijk zijn aangeraakt. Het filtert de saaie zaken eruit, zoals wanneer iemand gewoon een pagina uit het origineel heeft gekopieerd zonder deze te veranderen.
De Zoektocht (Op zoek naar het briefje): Zodra LiVo weet welke bestanden zijn gewijzigd, gaat het op jacht naar het "briefje". Het zoekt op twee plaatsen:
- Binnen de gewijzigde bestanden zelf.
- In een apart "Change Log"-bestand (zoals een CHANGELOG.md), wat gebruikelijk is bij softwareprojecten.
De Match-up (Hebben ze het goed gedaan?): LiVo vergelijkt de "commit message" (wat de ontwikkelaar zei dat hij deed toen hij de wijziging opsloeg) met de "change log" (het briefje).
- Hebben ze de wijziging vermeld?
- Hebben ze de datum opgenomen?
- Hebben ze hun naam opgenomen?
  Als het antwoord op een van deze vragen "Nee" is, markeert LiVo dit als een overtreding.
De Fix (De Autopiloot): Als LiVo een ontbrekend briefje vindt, roept het niet alleen dat het fout is; het probeert het ook te herstellen. Het schrijft automatisch het ontbrekende briefje op basis van de oorspronkelijke commit message van de ontwikkelaar en stelt voor om dit aan het project toe te voegen.

Wat ze vonden (De Realiteitscheck)

Het team testte LiVo op 178 paren van echte softwareprojecten (een basisproject en de bijbehorende fork). De resultaten waren oogopenend:

Het is een veelvoorkomende fout: Ongeveer 51% van de gewijzigde projecten overtrad deze regels. Ze hadden de code gewijzigd maar vergaten de vereiste aantekeningen te schrijven.
De Schaal: Ze vonden meer dan 51.000 specifieke gevallen waarin ontwikkelaars vergaten hun wijzigingen te documenteren.
De Broncode is de Boosdoener: De meeste ontbrekende aantekeningen gingen over wijzigingen in de eigenlijke "source code" (de instructies die het programma laten draaien), in plaats van documentatie of scripts.

Werkte het?

LiVo is niet alleen een theorie; ze hebben het in de echte wereld getest.

Ze stuurden 91 "Pull Requests" (officiële suggesties om de code te herstellen) naar de eigenaren van de projecten.
18 ontwikkelaars reageerden positief, met de tekst: "Oh, je hebt gelijk! Dat zijn we vergeten."
8 van die fixes werden daadwerkelijk toegevoegd aan de hoofdcode, wat betekent dat het juridische risico officieel is opgelost.

De Kern van het Verhaal

Dit paper is het eerste dat zegt: "Hé, we moeten stoppen met het negeren van de regel over het schrijven van aantekeningen wanneer we open-source code wijzigen." Ze brachten exact in kaart hoe deze regels eruitzien over 47 verschillende licenties en bouwden een tool, LiVo, die fungeert als een behulpzame bibliothecaris die de ontbrekende briefjes vindt en ze voor je schrijft.

Het gaat er niet om mensen te stoppen met het wijzigen van code; het gaat erom ervoor te zorgen dat de "paper trail" bestaat, zodat iedereen weet wie wat heeft veranderd, waardoor de juridische bibliotheek veilig en georganiseerd blijft.

Technische Samenvatting: Detectie en Herstel van Schendingen van Wijzigingsvoorwaarden in Open Source Licenties tijdens het Forken

Probleemstelling
De ontwikkeling van open source software (OSS) leunt zwaar op het forken, waarbij ontwikkelaars een kopie van een basisrepository maken om een nieuwe, onafhankelijk gewijzigde versie te creëren. Hoewel dit innovatie bevordert, introduceert het aanzienlijke juridische risico's wanneer ontwikkelaars nalaat om aan licentieplichten te voldoen. Bestaand onderzoek heeft zich gericht op het identificeren van licenties, het detecteren van incompatibiliteiten tussen afhankelijkheden en het vinden van inconsistenties in de licentiering van bestanden. Echter, er blijft een kritieke kloof bestaan met betrekking tot Wijzigingsvoorwaarden (Modification Terms, MTs). MT's zijn specifieke clausules in OSS-licenties die de voorwaarden bepalen waaronder gebruikers het originele werk mogen wijzigen en de verplichtingen die zij moeten nakomen bij het doen daarvan. Een prominent voorbeeld is de vereiste in licenties zoals Apache-2.0 om "opvallende mededelingen" (prominent notices) op te nemen waarin staat dat bestanden zijn gewijzigd. Naar weten van de auteurs is er geen eerder werk dat deze voorwaarden systematisch heeft gekarakteriseerd of geautomatiseerde mechanismen heeft geboden voor het detecteren en herstellen van schendingen van MT's tijdens het forking-proces.

Methodologie
De auteurs stellen een tweefasige aanpak voor: een empirische studie om MT's te karakteriseren, gevolgd door de ontwikkeling van een geautomatiseerde tool genaamd LiVo.

1. Empirische Karakterisering van Wijzigingsvoorwaarden
De auteurs voerden een empirische studie uit op 107 door de Open Source Initiative (OSI) goedgekeurde licenties. Zij identificeerden 47 licenties die expliciet MT's verklaren die specifieke vormen van "mededeling" (notice) vereisen om wijzigingen te beschrijven. Om deze verplichtingen te modelleren, analyseerden de auteurs de licenties over drie dimensies:

Wijzigingsomvang ( $S_g$ ): De typen bestanden die onderhevig zijn aan wijzigingsverplichtingen (bijv. broncode, documentatie, configuratiebestanden, scripts). Zij categoriseerden deze in acht groepen, waarbij zij opmerkten dat bijna de helft van de licenties (44,7%) van toepassing is op elk type bestand.
Inhoud van de Mededeling ( $C_g$ ): De vereiste informatie in de mededeling. Dit werd gecategoriseerd in vier elementen: Datum, Auteur, Beknopte Verklaring (stating dat bestanden zijn gewijzigd) en Informatieve Verklaring (details over hoe/waarom). Licenties werden gegroepeerd in zes categorieën op basis van deze vereisten.
Locatie van de Mededeling ( $L_g$ ): Waar de mededeling geplaatst moet worden. Dit werd gecategoriseerd in twee elementen: een apart document (bijv. CHANGELOG) of elk gewijzigd bestand. Licenties werden gegroepeerd in vier categorieën.

Op basis van deze dimensies werden de 47 licenties gemodelleerd als 2-tuples $\langle lic, O \rangle$ , waarbij $O$ een 3-tuple $\langle S_g, C_g, L_g \rangle$ is die de specifieke verplichting vertegenwoordigt.

2. De LiVo-aanpak
LiVo is een geautomatiseerde tool ontworpen om MT-schendingen te detecteren en te herstellen tijdens het forken. Het neemt een basisrepository en een fork-repository als input en werkt in drie stappen:

Stap 1: Detectie van Verplichtende Wijzigingen
- Bestandsmapping: LiVo stelt mappingen vast tussen bestanden in de basis- en de fork-repository om hergebruik te identificeren. Het gaat om met scenario's waarin bestanden zijn hernoemd, verplaatst of gekopieerd (met behulp van tools zoals JGit en Saga).
- Licentiedetectie: Het gebruikt Ninka om de licentie van elk bestand in de basisrepository te detecteren.
- Verplichtende Bestanden & Commits: Het identificeert "verplichtende bestanden" (bestanden die binnen de wijzigingsomvang van de gedetecteerde licentie vallen) en "verplichtende commits" in de fork-repository die deze bestanden wijzigen. Het filtert commits die uit de basisrepository zijn gepikt (die al compliant zijn) en ongedane (reverted) commits eruit.
Stap 2: Extractie van Mededelingen
- LiVo lokaliseert potentiële mededelingsbestanden in de fork-repository (bijv. CHANGELOG, RELEASE.txt).
- Het extraheert "change logs" uit deze bestanden. De extractielogica verwerkt semi-gestructureerde tekst en identificeert blokken wijzigingen die geassocieerd zijn met specifieke datums en auteurs.
- Elke geëxtraheerde change log wordt gemodelleerd als een tuple $\langle msg, d_s, d_e, a \rangle$ (bericht, startdatum, einddatum, auteur).
Stap 3: Detectie en Herstel van Schendingen
- Matching: Voor elke verplichtende commit probeert LiVo deze te matchen met een change log in de geëxtraheerde set.
- Gelijkheidstoets: Het gebruikt TF-IDF om de semantische gelijkenis te meten tussen de commit-boodschap en de change log-bereding. Als de gelijkenis een drempelwaarde overschrijdt (empirisch ingesteld op 0,3), wordt de inhoudelijke vereiste als voldaan beschouwd.
- Attribuutverificatie: Het verifieert of de commitdatum binnen de datumrange van de change log valt en of de commit-auteur overeenkomt met de auteur van de change log.
- Classificatie: Commits worden geclassificeerd als:
  - OB (Volledig Verplicht): Alle vereisten voldaan.
  - VN (Geschend - Ontbrekende Mededeling): Geen overeenkomende change log gevonden.
  - VD (Geschend - Ontbrekende Datum): Datumrange komt niet overeen.
  - VA (Geschend - Ontbrekende Auteur): Auteur komt niet overeen.
- Herstel: Voor schendingen genereert LiVo een herstel door een change log-entry aan te maken of bij te werken met de juiste boodschap, datum en auteur, en schrijft dit naar het passende mededelingsbestand.

Belangrijkste Resultaten
De auteurs evalueerden LiVo met behulp van 178 paren basis- en fork-repositories (geselecteerd uit zeer populaire GitHub-projecten).

Prevalentie: 21,9% van de geanalyseerde geforkte repositories vereiste MT's in hun licenties.
Ernst van de Schending: 51,1% van de geforkte repositories schond MT's. Nog kritieker is dat 95,3% van de verplichtende commits (commits die beschermde bestanden wijzigen) MT's overtrad. De meest voorkomende schending was de ontbrekende mededeling (VN), gevolgd door de ontbrekende datum (VD).
Nauwkeurigheid: LiVo behaalde een macro-precisie van 0,82 en een macro-recall van 0,80 bij het detecteren en classificeren van schendingen. De primaire bron van fouten was het gebrek aan semantisch bewustzijn van TF-IDF bij het matchen van korte commit-berichten aan change logs.
Efficiëntie: De tool nam gemiddeld 229,8 seconden in beslag per paar repositories, waarbij de stap van modificatiedetectie ongeveer 92% van de runtime besloeg.
Impact in de Praktijk: De auteurs dienden 91 pull requests in bij de geschendde repositories. 18 ontvingen positieve reacties, en 8 werden gemerged in de main branches. Sommige ontwikkelaars boden aanvankelijk weerstand, met het argument dat de commitgeschiedenis zelf als mededeling diende of door te claimen dat zij de oorspronkelijke auteurs waren, maar de tool identificeerde en stelde succesvol herstel voor in de meeste gevallen.

Betekenis en Claims
Het artikel beweert het eerste werk te zijn dat:

Empirisch de wijzigingsvoorwaarden over een grote set open source licenties heeft gekarakteriseerd.
Een geautomatiseerde aanpak (LiVo) voorstelt om schendingen van deze specifieke voorwaarden tijdens het forken te detecteren en te herstellen.

De auteurs benadrukken dat hoewel licentie-identificatie en incompatibiliteitsdetectie volwassen velden zijn, de specifieke verplichting om wijzigingen te "melden" (notice) over het hoofd is gezien. Door dit aan te pakken, helpt LiVo bij het verminderen van juridische risico's zoals rechtszaken en financiële verliezen als gevolg van non-compliance. Het artikel concludeert dat MT-schendingen ernstig zijn in real-world scenario's en dat geautomatiseerde detectie en herstel haalbaar en effectief zijn, hoewel verbeteringen in semantische matching (bijv. via deep learning) nodig zijn om verdere fout-positieven en fout-negatieven te verminderen.