💻 computer science

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

Cet article présente LiVo, un outil conçu pour détecter et corriger automatiquement les violations des conditions de modification dans les licences open source lors du processus de fork, comblant ainsi une lacune jusqu'alors inexplorée en matière d'atténuation des risques juridiques grâce à la caractérisation empirique de 47 licences et une validation réussie via des pull requests fusionnées.

Auteurs originaux : Kaifeng Huang, Yingfeng Xia, Bihuan Chen, Zhuotong Zhou, Jin Guo, Xin Peng

Publié 2026-06-23

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Kaifeng Huang, Yingfeng Xia, Bihuan Chen, Zhuotong Zhou, Jin Guo, Xin Peng

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez le monde du logiciel libre comme une immense bibliothèque animée où n'importe qui peut emprunter des livres, les lire et même réécrire des chapitres pour créer ses propres histoires. C'est excellent pour la créativité, mais il y a un piège : chaque livre de cette bibliothèque vient avec un ensemble de règles spécifiques (une licence) écrites par l'auteur original.

La plupart des gens connaissent les règles majeures, comme « Vous devez citer l'auteur » ou « Vous devez partager votre nouvelle version gratuitement ». Mais il existe une règle sournoise, souvent négligée, cachée dans beaucoup de ces licences : la Clause de Modification.

La règle du « Journal des modifications »

Considérez la Clause de Modification comme la règle stricte d'un bibliothécaire : « Si vous prenez un livre dans notre bibliothèque, que vous modifiez quelques pages et que vous créez une nouvelle version, vous devez écrire un post-it expliquant exactement ce que vous avez changé, qui l'a changé et quand. »

Certaines licences disent que le post-it doit figurer sur chaque page que vous avez touchée. D'autres disent que vous pouvez le mettre dans un carnet de « Changements » séparé au début du livre. D'autres disent simplement : « Assurez-vous que quelqu'un sache que vous l'avez modifié. »

Le problème ? La plupart des développeurs sont tellement occupés à écrire du code qu'ils oublient d'écrire ces post-its. Ils créent un « fork » (une copie du projet qu'ils modifient) mais oublient de laisser une trace de ce qu'ils ont fait. C'est une violation légale, comme rendre un livre de bibliothèque avec des pages déchirées mais sans note pour expliquer pourquoi.

Le problème : la violation « silencieuse »

Les chercheurs de l'Université de Fudan ont réalisé que, bien que nous ayons des outils pour vérifier si vous utilisez le bon livre, nous n'avons aucun outil pour vérifier si vous avez oublié d'écrire votre post-it. Ils se sont posé les questions suivantes :

Que disent exactement ces règles ?
À quelle fréquence les gens les enfreignent-ils ?
Pouvons-nous construire un robot pour corriger cela ?

La solution : Rencontrez « LiVo » (Le Vigilante de la Bibliothèque)

Pour résoudre ce problème, l'équipe a construit un outil appelé LiVo. Vous pouvez considérer LiVo comme un bibliothécaire automatisé et super intelligent qui patrouille les bibliothèques « forkées ».

Voici comment fonctionne LiVo, étape par étape :

Le travail de détective (Trouver les changements) : LiVo examine le livre original de la bibliothèque et la nouvelle version modifiée. Il scanne chaque « commit » (une modification enregistrée dans le code) pour voir quels fichiers ont réellement été touchés. Il filtre les éléments sans importance, comme lorsqu'on se contente de copier une page de l'original sans la modifier.
La recherche (Chercher le post-it) : Une fois que LiVo sait quels fichiers ont été modifiés, il part à la chasse au « post-it ». Il cherche à deux endroits :
- À l'intérieur des fichiers modifiés eux-mêmes.
- Dans un fichier de « Journal des modifications » séparé (comme un CHANGELOG.md), ce qui est courant dans les projets logiciels.
La correspondance (Ont-ils réussi ?) : LiVo compare le « message de commit » (ce que le développeur a dit avoir fait lorsqu'il a enregistré la modification) avec le « journal des modifications » (le post-it).
- Ont-ils mentionné la modification ?
- Ont-ils inclus la date ?
- Ont-ils inclus leur nom ?
  Si la réponse est « Non » à l'une de ces questions, LiVo signale une violation.
La correction (Le pilote automatique) : Si LiVo trouve un post-it manquant, il ne se contente pas de crier ; il essaie de réparer. Il écrit automatiquement le post-it manquant en se basant sur le message de commit original du développeur et suggère de l'ajouter au projet.

Ce qu'ils ont découvert (Le test de réalité)

L'équipe a testé LiVo sur 178 paires de projets logiciels réels (un projet de base et son fork). Les résultats sont frappants :

C'est une erreur courante : Environ 51 % des projets modifiés enfreignaient ces règles. Ils avaient modifié le code mais avaient oublié de rédiger les notes requises.
L'ampleur : Ils ont trouvé plus de 51 000 instances spécifiques où des développeurs avaient oublié de documenter leurs changements.
Le code source est le coupable : La plupart des notes manquantes concernaient des modifications apportées au « code source » réel (les instructions qui font fonctionner le programme), plutôt qu'à la documentation ou aux scripts.

Cela a-t-il fonctionné ?

LiVo n'est pas seulement une théorie ; ils l'ont mis à l'épreuve dans le monde réel.

Ils ont envoyé 91 « Pull Requests » (suggestions officielles pour corriger le code) aux propriétaires de projets.
18 développeurs ont répondu positivement, en disant : « Oh, vous avez raison ! Nous avons oublié cela. »
8 de ces corrections ont été effectivement fusionnées dans le code principal, ce qui signifie que le risque juridique a été officiellement résolu.

L'essentiel à retenir

Cet article est le premier à dire : « Hé, nous devons arrêter d'ignorer la règle concernant l'écriture de notes lorsque nous modifions du code open-source. » Ils ont cartographié précisément ce que ces règles impliquent à travers 47 licences différentes et ont construit un outil, LiVo, qui agit comme un bibliothécaire utile, trouvant les post-its manquants et les écrivant pour vous.

Il ne s'agit pas d'empêcher les gens de modifier le code ; il s'agit de s'assurer que la « trace écrite » existe afin que tout le monde sache qui a changé quoi, gardant ainsi la bibliothèque juridique sûre et organisée.

Résumé Technique : Détection et Correction des Violations des Termes de Modification dans les Licences Open Source lors du Forking

Énoncé du Problème
Le développement de logiciels open source (OSS) repose largement sur le « forking » (création de forks), où les développeurs copient un dépôt de base pour créer une nouvelle version modifiée de manière indépendante. Bien que cela favorise l'innovation, cela introduit des risques juridiques importants lorsque les développeurs ne parviennent pas à respecter les obligations de la licence. La recherche existante s'est concentrée sur l'identification des licences, la détection d'incompatibilités entre les dépendances et la recherche d'incohérences dans la licence des fichiers. Cependant, une lacune critique subsiste concernant les Termes de Modification (TM). Les TM sont des clauses spécifiques des licences OSS qui dictent les conditions selon lesquelles les utilisateurs peuvent modifier l'œuvre originale et les obligations qu'ils doivent remplir en le faisant. Un exemple notable est l'exigence, dans des licences comme Apache-2.0, d'inclure des « avis proéminents » indiquant que les fichiers ont été modifiés. À la connaissance des auteurs, aucun travail antérieur n'a systématiquement caractérisé ces termes ou fourni de mécanismes automatisés pour détecter et corriger les violations des TM lors du processus de forking.

Méthodologie
Les auteurs proposent une approche en deux phases : une étude empirique pour caractériser les TM, suivie du développement d'un outil automatisé nommé LiVo.

1. Caractérisation Empirique des Termes de Modification
Les auteurs ont mené une étude empirique sur 107 licences approuvées par l'Open Source Initiative (OSI). Ils ont identifié 47 licences qui déclarent explicitement des TM exigeant des formes spécifiques d'« avis » pour décrire les modifications. Pour modéliser ces obligations, les auteurs ont analysé les licences selon trois dimensions :

Portée de la Modification ( $S_g$ ) : Les types de fichiers soumis aux obligations de modification (ex: code source, documentation, fichiers de configuration, scripts). Ils les ont classés en huit groupes, notant que près de la moitié des licences (44,7 %) s'appliquent à tout type de fichier.
Contenu de l'Avis ( $C_g$ ) : L'information requise dans l'avis. Cela a été classé en quatre éléments : Date, Auteur, Énoncé succinct (indiquant que les fichiers ont été modifiés) et Énoncé informatif (détaillant comment/pourquoi). Les licences ont été groupées en six catégories basées sur ces exigences.
Emplacement de l'Avis ( $L_g$ ) : Où l'avis doit être placé. Cela a été classé en deux éléments : un document séparé (ex: CHANGELOG) ou chaque fichier modifié. Les licences ont été groupées en quatre catégories.

Sur la base de ces dimensions, les 47 licences ont été modélisées sous forme de 2-uplets $\langle lic, O \rangle$ , où $O$ est un 3-uplet $\langle S_g, C_g, L_g \rangle$ représentant l'obligation spécifique.

2. L'Approche LiVo
LiVo est un outil automatisé conçu pour détecter et corriger les violations de TM lors du forking. Il prend en entrée un dépôt de base et un dépôt fork et opère en trois étapes :

Étape 1 : Détection de la Modification Obligatoire
- Cartographie des Fichiers : LiVo établit des correspondances entre les fichiers des dépôts de base et du fork pour identifier la réutilisation. Il gère les scénarios où les fichiers sont renommés, déplacés ou copiés (en utilisant des outils comme JGit et Saga).
- Détection de la Licence : Il utilise Ninka pour détecter la licence de chaque fichier dans le dépôt de base.
- Fichiers et Commits Obligatoires : Il identifie les « fichiers obligatoires » (ceux tombant dans le champ de la modification de la licence détectée) et les « commits obligatoires » dans le dépôt fork qui modifient ces fichiers. Il filtre les commits extraits du dépôt de base (qui sont déjà conformes) et les commits annulés (reverts).
Étape 2 : Extraction de l'Avis
- LiVo localise les fichiers d'avis potentiels dans le dépôt fork (ex: CHANGELOG, RELEASE.txt).
- Il extrait les « journaux de modifications » (change logs) de ces fichiers. La logique d'extraction gère le texte semi-structuré, identifiant les blocs de changements associés à des plages de dates et des auteurs spécifiques.
- Chaque journal de modification extrait est modélisé comme un tuple $\langle msg, d_s, d_e, a \rangle$ (message, date de début, date de fin, auteur).
Étape 3 : Détection et Correction des Violations
- Correspondance (Matching) : Pour chaque commit obligatoire, LiVo tente de le faire correspondre à un journal de modification dans l'ensemble extrait.
- Vérification de Similarité : Il utilise TF-IDF pour mesurer la similarité sémantique entre le message du commit et le message du journal de modification. Si la similarité dépasse un seuil (fixé empiriquement à 0,3), l'exigence de contenu est considérée comme remplie.
- Vérification des Attributs : Il vérifie si la date du commit tombe dans la plage de dates du journal et si l'auteur du commit correspond à l'auteur du journal.
- Classification : Les commits sont classés comme :
  - OB (Entièrement Obligé) : Toutes les exigences sont remplies.
  - VN (Violé - Avis Manquant) : Aucun journal de modification correspondant trouvé.
  - VD (Violé - Date Manquante) : Incohérence de la plage de dates.
  - VA (Violé - Auteur Manquant) : Incohérence de l'auteur.
- Correction (Fixing) : Pour les violations, LiVo génère une correction en créant ou en mettant à jour une entrée de journal avec le message, la date et l'auteur corrects, et l'écrit dans le fichier d'avis approprié.

Résultats Clés
Les auteurs ont évalué LiVo en utilisant 178 paires de dépôts de base et de fork (sélectionnées parmi des projets GitHub hautement étoilés).

Prévalence : 21,9 % des paires de dépôts analysées nécessitaient des TM dans leurs licences.
Gravité des Violations : 51,1 % des dépôts analysés violaient les TM. Plus critique encore, 95,3 % des commits obligatoires (commits modifiant des fichiers protégés) présentaient des violations de TM. La violation la plus courante était l'absence d'avis (VN), suivie de l'absence de date (VD).
Précision : LiVo a atteint une précision macro de 0,82 et un rappel macro de 0,80 pour la détection et la classification des violations. La principale source d'erreur était le manque de conscience sémantique de TF-IDF lors de la correspondance de messages de commit courts avec les journaux de modification.
Efficacité : L'outil a mis en moyenne 229,8 secondes par paire de dépôts, l'étape de détection de modification représentant environ 92 % du temps d'exécution.
Impact Réel : Les auteurs ont soumis 91 pull requests aux dépôts violés. 18 ont reçu des réponses positives, et 8 ont été fusionnées dans les branches principales. Certains développeurs ont initialement résisté, affirmant que l'historique des commits constituait en soi un avis ou prétendant être les auteurs originaux, mais l'outil a réussi à identifier et proposer des corrections pour la majorité des cas.

Signification et Revendications
L'article affirme être le premier travail à :

Caractériser empiriquement les termes de modification à travers un large ensemble de licences open source.
Proposer une approche automatisée (LiVo) pour détecter et corriger les violations de ces termes spécifiques lors du forking.

Les auteurs soulignent que, bien que l'identification des licences et la détection d'incompatibilité soient des domaines matures, l'obligation spécifique de fournir un « avis » pour les modifications a été négligée. En abordant cela, LiVo aide à atténuer les risques juridiques tels que les poursuites judiciaires et les pertes financières associées à la non-conformité. L'article conclut que les violations de TM sont graves dans les scénarios réels et que la détection et la correction automatisées sont réalisables et efficaces, bien que des améliorations de la correspondance sémantique (ex: utiliser le deep learning) soient nécessaires pour réduire davantage les faux positifs et les faux négatifs.