Un LLM ha riscritto chardet da LGPL a MIT, è legale?

Il 4 marzo 2026 Dan Blanchard, maintainer di lunga data di chardet, la libreria Python di rilevamento delle codifiche dei caratteri che vive come dipendenza in una quantità sterminata di progetti, ha pubblicato la versione 7.0.0. Le note di rilascio raccontavano una riscrittura completa, prestazioni dichiarate fino a 41 volte superiori, e un dettaglio in fondo alla pagina che valeva più di tutto il resto: la licenza non era più la LGPL 2.1 che accompagnava il progetto fin dalle origini, ma MIT. La riscrittura era stata condotta in larga parte con Claude, il modello di Anthropic, e la tesi dei maintainer era lineare: la versione 7 è un'opera nuova e indipendente, e un'opera indipendente si licenzia come si vuole. La risposta di Mark Pilgrim, l'autore originale della libreria, è arrivata pubblica e senza sfumature: i maintainer non hanno alcun diritto di rilicenziare il progetto, la riscrittura non cambia niente perché è avvenuta con piena esposizione al codice originale, e il cambio di licenza è una violazione esplicita della LGPL da ripristinare. In mezzo ai due, una domanda che nessuna corte ha ancora deciso e che riguarda chiunque usi modelli linguistici sul codice, cioè ormai quasi tutti noi: se faccio riscrivere a un LLM una codebase copyleft, l'output è un'opera nuova o un'opera derivata con il numero di serie limato? Questo articolo ricostruisce il caso com'è documentato, pesa gli argomenti veri di entrambe le parti, e ne tira fuori le regole operative che applico nelle mie pipeline e che consiglio a ogni azienda che mette un LLM a contatto con codice altrui.

La cronaca, prima delle opinioni

I fatti documentati stanno in poche righe. Chardet nasce oltre vent'anni fa dal lavoro di Mark Pilgrim, sotto LGPL 2.1; la manutenzione passa negli anni a Dan Blanchard. Il problema della licenza non è nuovo: la LGPL è considerata incompatibile con l'inclusione nella libreria standard di Python, un traguardo di cui per chardet si era parlato concretamente, e Blanchard aveva dichiarato in passato che, potendo, avrebbe rilicenziato. Il 4 marzo 2026 arriva la 7.0.0: riscrittura totale, condotta con Claude, licenza MIT. Nel giro di quarantotto ore il caso esplode: Pilgrim interviene chiedendo il ripristino della LGPL, la discussione sul repository si allunga per centinaia di commenti, e Simon Willison pubblica l'analisi che mette a fuoco il punto tecnico decisivo: dai log del lavoro risulta che il modello ha avuto accesso al sorgente LGPL durante il processo, e il maintainer stesso ha dentro di sé più di un decennio di esposizione a quel codice. LWN dedica al caso l'approfondimento più completo in circolazione, e la questione supera in fretta il perimetro di una singola libreria: se questo schema è lecito, chiunque può dare in pasto a un modello un progetto GPL e ripubblicarne la funzionalità sotto licenza permissiva, e l'intero edificio del copyleft ha una porta sul retro spalancata. Non a caso, fra i primi a segnalare il precedente come pericoloso ci sono state voci dalla manutenzione del kernel Linux.

Vale la pena fissare anche gli argomenti della difesa, perché non sono di paglia. Blanchard sostiene che la 7.0.0 sia un'implementazione indipendente della stessa funzione, non una traduzione del vecchio codice; richiama la sentenza Oracle contro Google, dove la Corte Suprema americana ha qualificato come fair use la replica di un'API; e osserva che la motivazione non è commerciale ma di ecosistema, sbloccare un'adozione che la LGPL impediva. C'è infine l'argomento più curioso del mazzo, sollevato da terzi: se l'output di un LLM non è proteggibile da copyright, come la giurisprudenza americana sull'autorialità delle macchine suggerisce, la 7.0.0 potrebbe non essere licenziabile affatto, né MIT né altro. Un'opera che voleva liberarsi del copyleft e rischia di scoprirsi senza copyright: il 2026 in una frase.

Se vuoi vedere come imposto le pipeline LLM di produzione con la provenienza del codice tracciata e i confini di licenza trattati come vincoli architetturali, non come dettagli legali da rimandare, nel mio hub sull'AI per lo sviluppo software trovi la metodologia e il perimetro dichiarati.

Si può davvero rilicenziare un progetto facendolo riscrivere a un LLM?

La risposta onesta: nessuno lo sa con certezza, perché non esiste ancora giurisprudenza sul punto, ma la tesi della riscrittura pulita ha, in questo caso specifico, problemi seri e visibili a occhio nudo. Il diritto d'autore del software distingue da sempre fra l'idea (l'algoritmo, la funzione: liberi) e l'espressione (il codice concreto: protetto), e l'industria ha sviluppato decenni fa lo strumento per stare dal lato giusto della linea: la clean room. In una clean room vera, un gruppo studia l'originale e produce una specifica funzionale; un gruppo diverso, che l'originale non l'ha mai visto, implementa dalla specifica; la separazione è documentata e difendibile in giudizio. Il caso di scuola è la riscrittura del BIOS IBM negli anni Ottanta, quella che aprì la strada ai PC compatibili: Compaq e poi Phoenix investirono in muri organizzativi veri, ingegneri "contaminati" che scrivevano specifiche e ingegneri "vergini" che implementavano, proprio perché sapevano che la difendibilità stava tutta nella procedura documentata. È una procedura, non un aggettivo. Ed è esattamente ciò che qui non è avvenuto: il modello ha visto il sorgente, il supervisore umano lo conosce a memoria, e la suite di test dell'originale ha guidato la convergenza. Chiamarla clean room significa usare il nome di una procedura per descrivere il suo contrario.

Un LLM non è una lavatrice per licenze. Se il modello ha letto il codice originale durante il lavoro, la catena di derivazione non si è spezzata: si è solo resa più difficile da vedere. E le catene difficili da vedere sono il terreno preferito dei contenziosi.

Il precedente Oracle contro Google, invocato dalla difesa, copre meno di quanto sembri: quella sentenza riguarda la replica di un'interfaccia, non la riscrittura assistita di un'implementazione con accesso all'originale. E l'argomento "il modello avrebbe potuto scriverlo comunque, ha visto mille rilevatori di codifiche in addestramento" prova troppo: se valesse, nessun output di LLM potrebbe mai essere derivato di niente, che è precisamente la tesi che i tribunali di mezzo mondo stanno vagliando nei contenziosi sull'addestramento, con esiti tutt'altro che scontati. Chi costruisce oggi processi aziendali su quella scommessa sta facendo gestione del rischio con il paraocchi.

Il caso ha anche un fratello concettuale che vale la pena nominare: negli incidenti che studio per lavoro c'è già il precedente dell'agente che ha attaccato pubblicamente un maintainer di matplotlib dopo un rifiuto di pull request. Sono le due facce dello stesso anno: là l'agente contro il custode del progetto, qui il custode che usa l'agente per scavalcare la licenza del progetto. In entrambi i casi la tecnologia non ha creato il conflitto: ha abbattuto il costo di azioni che prima richiedevano troppo lavoro per essere tentate. Il copyleft, in particolare, si reggeva su un'assunzione economica implicita che nessuno aveva mai avuto bisogno di scrivere: riscrivere da zero una libreria matura costa mesi di lavoro qualificato, quindi la tentazione di aggirare la licenza riscrivendo restava teorica. Quando la riscrittura costa un fine settimana e un abbonamento, l'assunzione cade, e ciò che la sostituisce non può più essere l'attrito: devono essere le procedure, i log di provenienza e, prima o poi, le sentenze.

Cosa significa per chi USA le librerie, non solo per chi le scrive

Qui il caso smette di essere una disputa fra sviluppatori e diventa un tema di gestione del rischio per qualunque azienda. Se la rilicenza della 7.0.0 fosse giudicata invalida, il codice resterebbe LGPL a dispetto dell'etichetta MIT, e chi nel frattempo l'ha integrato confidando nell'etichetta si troverebbe in casa obblighi LGPL che non ha mai valutato. Per la LGPL su una libreria Python le conseguenze pratiche sono gestibili, ma il punto è il metodo: l'etichetta di licenza di una dipendenza è un'affermazione, non un fatto, e quando l'affermazione è contestata pubblicamente dall'autore originale, l'azienda prudente lo tratta come un rischio aperto. Operativamente: chi ha chardet nel proprio albero di dipendenze può restare sulla serie 6.x, l'ultima con genealogia di licenza non contestata, finché la disputa non si assesta; e chi ha policy di compliance sulle licenze dovrebbe aggiungere ai propri controlli una domanda nuova, se una dipendenza abbia cambiato licenza di recente e su quali basi.

C'è un punto cieco strumentale che questo caso illumina e che vale per qualunque stack: gli scanner di licenze leggono le etichette, non le genealogie. Gli strumenti che generano l'inventario delle licenze di un progetto, dai tool a riga di comando alle piattaforme di software composition analysis, riportano la licenza dichiarata nei metadati del pacchetto: per chardet 7 leggono MIT e passano oltre, verdi come semafori. Una rilicenza contestata è invisibile a tutta la filiera automatica, SBOM comprese, ed emerge solo se qualcuno legge le notizie del proprio ecosistema. La conseguenza per chi fa compliance seriamente è scomoda ma onesta: l'automazione copre il censimento, non il giudizio, e le dipendenze critiche meritano una revisione umana periodica che nessun report sostituisce. Il censimento stesso, peraltro, è il prerequisito che in molte aziende ancora manca: se non sai elencare in un minuto quali pacchetti con quali licenze entrano nel tuo prodotto, il problema è a monte della disputa di turno. È lo stesso principio di diffidenza verso le etichette che applico alla catena di fornitura del codice in generale, dal typosquatting e la dependency confusion su Composer in su: la fiducia si dà ai processi verificabili, mai alle dichiarazioni.

E c'è la lezione per chi, come me, usa gli LLM sul codice ogni giorno. Nelle mie pipeline di automazione la regola è scritta ed è brutale nella sua semplicità: la provenienza si traccia, la licenza si eredita. Se un modello lavora su codice di terzi, l'output resta nel perimetro di licenza di quel codice, punto; l'idea di usare la generazione per "ripulire" una licenza scomoda è vietata non perché un tribunale l'abbia già bocciata, ma perché scommettere il patrimonio di codice aziendale su una questione giuridica aperta è cattiva ingegneria del rischio. È la stessa conclusione a cui è arrivata, per la via del processo invece che della scommessa, la comunità di Debian con la sua risoluzione sull'IA generativa: gli strumenti non cambiano le regole, e chi contribuisce resta responsabile della conformità legale di ciò che firma, come ho raccontato analizzando la GR 2026-002. Se nella tua azienda gli LLM toccano il codice, la policy minima ha tre righe: si registra su quale base di codice il modello ha lavorato, si eredita la licenza più restrittiva coinvolta, e le eccezioni le approva un umano che risponde con il proprio nome. La prima riga è quella che nessuno implementa e che il caso chardet rende preziosa: la registrazione della provenienza significa conservare, per ogni lavorazione significativa, quali repository e file il modello aveva in contesto, ed è un log che costa pochissimo produrre durante il lavoro e moltissimo ricostruire dopo, quando serve per difendersi. Vale anche una nota sulle manleve: alcuni vendor di strumenti di generazione offrono impegni di indennizzo sul copyright dell'output, e sono clausole che vale la pena leggere per intero prima di contarci, perché tipicamente coprono l'uso conforme dello strumento, non la scelta deliberata di dargli in pasto codice altrui per rilicenziarlo. Nessuna manleva firma al posto tuo.

La vicenda chardet finirà come finiscono queste cose: con un assestamento, un fork che riparte dalla serie con la genealogia pulita, forse una retromarcia negoziata, forse un giorno una sentenza che farà da faro per tutte le dispute gemelle già in coda. Ma il segnale che lascia è già chiaro e non tornerà indietro: la generazione automatica ha reso la riscrittura di intere codebase un'operazione da un fine settimana, e questo mette sotto pressione ogni costruzione giuridica che presumeva la riscrittura costosa, il copyleft per primo. Le aziende che attraverseranno bene questa fase sono quelle che trattano la questione per ciò che è, gestione del rischio su una frontiera giuridica in movimento, senza scorciatoie entusiaste né paralisi. Il tema si intreccia, per chi costruisce in casa, con l'altra faccia della sovranità sul codice di cui ho scritto parlando dei costi reali del self-hosting dei modelli: controllare dove gira il modello e controllare cosa è lecito fargli produrre sono due metà dello stesso mestiere. E se hai un progetto concreto in cui l'automazione del codice incontra vincoli di licenza o di compliance, il modulo di preventivo gratuito ti dice in due minuti se rientra nel mio perimetro di intervento: sette domande, nessun impegno.