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

Sintesi Tecnica: Rilevamento e Correzione delle Violazioni dei Termini di Modifica nelle Licenze Open Source durante il Forking

Enunciato del Problema
Lo sviluppo di software open source (OSS) si basa fortemente sul concetto di forking, in cui gli sviluppatori copiano un repository base per creare una nuova versione modificata in modo indipendente. Sebbene ciò favorisca l'innovazione, introduce rischi legali significativi quando gli sviluppatori non rispettano gli obblighi di licenza. La ricerca esistente si è concentrata sull'identificazione delle licenze, sul rilevamento delle incompatibilità tra le dipendenze e sulla ricerca di incongruenze nelle licenze dei file. Tuttavia, rimane un divario critico riguardante i Termini di Modifica (MT - Modification Terms). Gli MT sono clausole specifiche nelle licenze OSS che stabiliscono le condizioni sotto le quali gli utenti possono modificare l'opera originale e gli obblighi che devono adempiere in seguito alla modifica. Un esempio prominente è il requisito in licenze come Apache-2.0 di includere "avvisi evidenti" (prominent notices) che dichiarino che i file sono stati modificati. Per quanto ne sappiamo dagli autori, nessun lavoro precedente ha caratterizzato sistematicamente questi termini o fornito meccanismi automatizzati per rilevare e correggere le violazioni degli MT durante il processo di forking.

Metodologia
Gli autori propongono un approccio in due fasi: uno studio empirico per caratterizzare gli MT, seguito dallo sviluppo di uno strumento automatizzato chiamato LiVo.

1. Caratterizzazione Empirica dei Termini di Modifica
Gli autori hanno condotto uno studio empirico su 107 licenze approvate dall'Open Source Initiative (OSI). Hanno identificato 47 licenze che dichiarano esplicitamente gli MT richiedendo forme specifiche di "avviso" per descrivere le modifiche. Per modellare questi obblighi, gli autori hanno analizzato le licenze attraverso tre dimensioni:

• Ambito di Modifica ($S_g$): I tipi di file soggetti agli obblighi di modifica (es. codice sorgente, documentazione, file di configurazione, script). Li hanno categorizzati in otto gruppi, notando che quasi la metà delle licenze (44,7%) si applica a qualsiasi tipo di file.
• Contenuto dell'Avviso ($C_g$): Le informazioni richieste nell'avviso. Questo è stato categorizzato in quattro elementi: Data, Autore, Breve Dichiarazione (che dichiari che i file sono stati modificati) e Dichiarazione Informativa (che dettagli come/perché). Le licenze sono state raggruppate in sei categorie in base a questi requisiti.
• Posizione dell'Avviso ($L_g$): Dove deve essere inserito l'avviso. Questo è stato categorizzato in due elementi: un documento separato (es. CHANGELOG) o ogni singolo file modificato. Le licenze sono state raggruppate in quattro categorie.

Sulla base di queste dimensioni, i 47 licenze sono state modellate come 2-tuple $\langle lic, O \rangle$, dove $O$ è una 3-tupla $\langle S_g, C_g, L_g \rangle$ che rappresenta l'obbligo specifico.

2. L'Approccio LiVo
LiVo è uno strumento automatizzato progettato per rilevare e correggere le violazioni degli MT durante il forking. Prende in input un repository base e un repository fork e opera in tre fasi:

• Fase 1: Rilevamento della Modifica Obbligatoria

  • Mappatura dei File: LiVo stabilisce mappature tra i file nei repository base e fork per identificare il riutilizzo. Gestisce scenari in cui i file vengono rinominati, spostati o copiati (utilizzando strumenti come JGit e Saga).
  • Rilevamento della Licenza: Utilizza Ninka per rilevare la licenza di ogni file nel repository base.
  • File e Commit Obbliganti: Identifica i "file obbliganti" (quelli che rientrano nell'ambito di modifica della licenza rilevata) e i "commit obbliganti" nel repository fork che modificano tali file. Filtra i commit prelevati dal repository base (che sono già conformi) e i commit di ripristino (reverted commits).

• Fase 2: Estrazione dell'Avviso

  • LiVo individua potenziali file di avviso nel repository fork (es. CHANGELOG, RELEASE.txt).
  • Estrae i "log delle modifiche" da questi file. La logica di estrazione gestisce il testo semi-strutturato, identificando bloci di modifiche associati a specifici intervalli di date e autori.
  • Ogni log di modifica estratto è modellato come una tupla $\langle msg, d_s, d_e, a \rangle$ (messaggio, data di inizio, data di fine, autore).

• Fase 3: Rilevamento e Correzione delle Violazioni

  • Corrispondenza (Matching): Per ogni commit obbligante, LiVo tenta di abbinarlo a un log di modifica nell'insieme estratto.
  • Controllo di Similarità: Utilizza TF-IDF per misurare la similarità semantica tra il messaggio del commit e il messaggio del log di modifica. Se la similarità supera una soglia (impostata empiricamente a 0,3), il requisito di contenuto è considerato soddisfatto.
  • Verifica degli Attributi: Verifica se la data del commit rientra nell'intervallo di date del log e se l'autore del commit corrisponde all'autore del log.
  • Classificazione: I commit sono classificati come:
    • OB (Pienamente Obbligati - Fully Obligated): Tutti i requisiti soddisfatti.
    • VN (Violato - Avviso Mancante - Violated - Missing Notice): Nessun log di modifica corrispondente trovato.
    • VD (Violato - Data Mancante - Violated - Missing Date): Discrepanza nell'intervallo di date.
    • VA (Violato - Autore Mancante - Violated - Missing Author): Discrepanza dell'autore.
  • Correzione: In caso di violazioni, LiVo genera una correzione creando o aggiornando una voce nel log di modifica con il messaggio, la data e l'autore corretti, e la scrive nel file di avviso appropriato.

Risultati Chiave
Gli autori hanno valutato LiVo utilizzando 178 coppie di repository base e fork (selezionate da progetti GitHub con un alto numero di stelle).

• Prevalenza: Il 21,9% dei repository fork analizzati richiedeva gli MT nelle loro licenze.
• Gravità della Violazione: Il 51,1% dei repository fork violava gli MT. Ancora più critico, il 95,3% dei commit obbliganti (commit che modificano file protetti) è risultato violare gli MT. La violazione più comune è stata la mancanza di avviso (VN), seguita dalla mancanza di data (VD).
• Accuratezza: LiVo ha raggiunto una precisione macro di 0,82 e un richiamo macro di 0,80 nel rilevare e classificare le violazioni. La principale fonte di errore è stata la mancanza di consapevolezza semantica di TF-IDF nel far corrispondere brevi messaggi di commit ai log di modifica.
• Efficienza: Lo strumento ha impiegato in media 229,8 secondi per coppia di repository, con la fase di rilevamento della modifica che ha assorbito circa il 92% del tempo di esecuzione.
• Impatto nel Mondo Reale: Gli autori hanno inviato 91 pull request ai repository violati. 18 hanno ricevuto risposte positive e 8 sono state incorporate nei rami principali. Alcuni sviluppatori si sono inizialmente opposti, sostenendo che la cronologia dei commit stessa costituisse un avviso o affermando di essere gli autori originali, ma lo strumento è riuscito a identificare e proporre correzioni per la maggior parte dei casi.

Significatività e Rivendicazioni
Il documento sostiene di essere il primo lavoro che:

1. Caratterizza empiricamente i termini di modifica in un ampio set di licenze open source.
2. Propone un approccio automatizzato (LiVo) per rilevare e correggere le violazioni di questi termini specifici durante il forking.

Gli autori sottolineano che, mentre l'identificazione delle licenze e il rilevamento delle incompatibilità sono campi maturi, l'obbligo specifico di fornire un "avviso" per le modifiche è stato trascurato. Affrontando questo punto, LiVo aiuta a mitigare i rischi legali come cause legali e perdite finanziarie derivanti dalla mancata conformità. Il documento conclude che le violazioni degli MT sono gravi negli scenari reali e che il rilevamento e la correzione automatizzati sono fattibili ed efficaci, sebbene siano necessari miglioramenti nel matching semantico (es. l'uso del deep learning) per ridurre ulteriormente i falsi positivi e i falsi negativi.