Thomas de Grivel ha pubblicato sulla mailing list openbsd-tech un’implementazione di ext4 per OpenBSD, scritta interamente con ChatGPT e Claude. Zero righe di codice sorgente Linux lette. Il driver sembrava funzionare nel perimetro dichiarato: forniva accesso in lettura e scrittura, passava e2fsck, ma non supportava journaling. Abbastanza per essere interessante. Non abbastanza per superare il problema che OpenBSD vedeva davvero: la provenienza.

Pochi giorni dopo, Theo de Raadt ha chiuso la discussione con una frase secca: “the chances of us accepting such new code with such a suspicious Copyright situation is zero.”

De Raadt stava prendendo posizione sul punto che l’industria continua a evitare: cosa succede quando il vibe coding incontra codice GPL, copyright e licenze open source? La qualità del driver era secondaria. Il problema era dimostrare da dove veniva davvero quel codice.

Il caso ext4 per OpenBSD

De Grivel era esplicito nel suo blog post: “It’s pure AI (ChatGPT and Claude-code) with careful code reviews and error checking and building kernel and rebooting/testing. No Linux source files were ever read.”

Quella frase prova a stabilire una catena di innocenza: nessun file Linux letto, solo AI, review manuale, test su kernel reale. Ma per OpenBSD non bastava. Il punto non era cosa avesse letto De Grivel. Era cosa avessero assorbito gli strumenti che stava usando.

Entrambi i modelli usati, ChatGPT e Claude, sono stati addestrati su enormi corpus di codice sorgente, tra cui, con ogni probabilità, anche codice e documentazione relativi a ext4 nel kernel Linux: materiale GPL v2. Quando un LLM genera un’implementazione di ext4, non sta necessariamente reinventando il filesystem da zero. Sta producendo codice attraverso pattern appresi da una massa enorme di esempi precedenti.

La domanda che nessun tribunale ha ancora risolto è questa: quando quella ricostruzione diventa abbastanza vicina al materiale di training da poter essere considerata un’opera derivata?

Il team di OpenBSD non aveva risposta. E quella mancanza di risposta era già sufficiente per rifiutare il codice. Bryan Miller ha sintetizzato la posizione con chiarezza: “We don’t know. The law hasn’t caught up to the technology yet and we can’t take the risk.”

La difesa standard del vibe coding corre su questo binario: non ho letto il codice GPL, quindi non posso averne prodotto un derivato. Questo ragionamento regge abbastanza bene per uno sviluppatore umano che impara dalla documentazione, comprende il dominio e scrive codice originale. Non è chiaro che regga nello stesso modo per un modello addestrato su miliardi di token di codice licenziato.

Brian Kernighan potrebbe scrivere un’implementazione di ext4 senza aver mai letto il codice di Linux, e nessuno avrebbe dubbi seri sulla provenienza: lui capisce i filesystem, applica conoscenza propria, prende decisioni progettuali autonome. Un LLM non porta in dote esperienza personale sui filesystem. Porta una distribuzione statistica costruita su esempi, documentazione, codice e pattern visti in addestramento. È proprio questo che rende il confine legale difficile da tracciare.

De Grivel stesso ha usato una formula che rende evidente quanto il linguaggio intorno al vibe coding sia ancora acerbo: “We can freely steal each other in a new original way without copyright infringement.” Il verbo steal in quel contesto pesa. Non perché dimostri qualcosa da solo, ma perché descrive bene l’ambiguità culturale del momento: stiamo chiamando originalità qualcosa che potrebbe essere ricombinazione, e stiamo chiamando ricombinazione qualcosa che potrebbe avere ancora una provenienza giuridicamente rilevante.

Implicazioni pratiche per chi sviluppa

Se stai usando AI per scrivere codice rilasciato con licenza BSD, MIT o Apache, questo caso ti riguarda direttamente. Non come problema astratto: come rischio concreto e difficile da quantificare sulla tua codebase.

La questione del copyright sul codice AI non è nuova. Già nel 2025 era chiaro che i contributi generati da AI al kernel Linux sollevavano problemi di sicurezza legati alla qualità del codice generato, ma il copyright aggiunge una dimensione che i code review non intercettano. Una patch può essere corretta, passare tutti i test e contenere un problema di provenienza che nessuno rileverà finché non arriva un avvocato.

Le conseguenze pratiche per chi gestisce un progetto open source sono immediate.

Ogni progetto BSD-licensed che accetta contributi AI-generated senza una policy di provenienza si espone a un rischio legale difficile da quantificare. Le organizzazioni con requisiti di compliance rigorosa — governi, aziende quotate, software embedded in contesti regolamentati — non possono trattare “l’AI l’ha scritto” come risposta sufficiente a una domanda di licensing.

Il provider del modello può offrire indennizzi contrattuali, ma non elimina automaticamente il problema di provenienza del codice. Microsoft, per esempio, ha introdotto il Copilot Copyright Commitment per alcuni servizi commerciali e a determinate condizioni. È una copertura contrattuale, non una sentenza sulla natura giuridica di ogni output generato.

Il take di TechMonk

Theo de Raadt ha ragione. La posizione di OpenBSD non è paranoia: è l’unica risposta coerente dato lo stato attuale del diritto. L’intera proposta di valore di OpenBSD dipende dalla chiarezza delle licenze; accettare codice con provenienza ambigua significherebbe indebolire quella garanzia in cambio di un driver utile, ma non abbastanza prezioso da giustificare una crepa nella catena di provenienza del progetto.

La GPL potrebbe essere il primo vero test legale del codice AI

La copyleft virale è stata progettata per propagarsi: ogni opera derivata da GPL deve essere GPL. Questo è il meccanismo, ed è deliberato. La FSF non aveva previsto i modelli linguistici nel 1989, ma il principio non cambia.

Se un LLM ha assorbito codice e documentazione relativi all’implementazione ext4 del kernel per costruire una distribuzione di probabilità sul codice, e quella distribuzione genera un driver ext4 funzionale, la domanda sulla derivazione somiglia a quella che la GPL pone da decenni: quanto deve essere trasformativo un lavoro per non essere considerato derivato?

Nessun tribunale ha ancora risposto in modo definitivo. Ma la logica dice che la GPL potrebbe diventare uno degli strumenti attraverso cui verrà ridefinito il modo in cui le aziende AI possono usare l’open source. Non perché qualcuno l’abbia scritta appositamente per questo, ma perché il meccanismo esiste già.

La FSF non ha costruito una trappola per gli LLM. Ha costruito una licenza che rende difficile rimuovere la reciprocità dal codice libero. Se un tribunale dovesse riconoscere certi output AI come derivati da codice GPL, quella vecchia architettura legale diventerebbe improvvisamente il primo vero test per l’industria dei modelli.

La vera bomba sono le licenze permissive

Tutti si focalizzano sulla GPL. Il rischio più insidioso riguarda MIT e Apache.

Quelle licenze permettono uso commerciale libero, ma richiedono attribuzione. I modelli di linguaggio hanno assorbito miliardi di righe di codice MIT, BSD e Apache senza mantenere una catena leggibile delle fonti. Quando il modello riproduce pattern da quel codice, l’attribuzione non compare da nessuna parte: non nel commit, non nella documentazione, non nella risposta dell’API.

Il caso tipico non è per forza il modello che copia un intero file MIT riga per riga. È più sottile: una funzione di parsing, un algoritmo di checksum, una routine di compatibilità, un pattern di test. Abbastanza simile da creare un dubbio, troppo frammentato per essere attribuito correttamente.

La GPL protegge i contributor imponendo che il lavoro derivato rimanga aperto. MIT e BSD provano a proteggere i contributor soprattutto attraverso attribuzione e notice. Ma se l’intermediario è un modello statistico che non tiene traccia delle fonti, l’attribuzione sparisce nel processo e nessuno la chiede.

Gli autori di codice GPL almeno hanno la viralità come meccanismo di difesa. Gli autori di codice MIT hanno un diritto formale all’attribuzione, ma un meccanismo molto più debole per farlo emergere quando il passaggio avviene attraverso un modello che non conserva la catena delle fonti.

Il caso OpenBSD è la punta visibile di un problema che si misura in miliardi di righe di contributi che nessuno ha mai attribuito davvero nel passaggio attraverso i modelli.

Il primo caso legale non sarà casuale

Questa ambiguità non si risolverà con una causa qualunque. È improbabile che il primo caso davvero decisivo emerga in modo neutro. Più probabilmente sarà un caso selezionato, finanziato e raccontato con attenzione: da un provider di modelli che cerca un precedente favorevole, o da una fondazione open source che vuole fissare un limite prima che lo fissino altri.

L’industria non sta aspettando passivamente. Sta aspettando il caso più vantaggioso. I provider di modelli hanno team legali che monitorano ogni causa rilevante. Le fondazioni open source stanno raccogliendo documentazione. Il developer che oggi usa AI per scrivere codice rilasciato con licenza permissiva rischia di diventare, inconsapevolmente, un potenziale convenuto nella strategia legale di qualcun altro.

“L’AI l’ha scritto” non è una difesa. È un buco nella catena di custodia.

Conclusione

Il kernel Linux ha impiegato trent’anni a costruire un processo di revisione abbastanza solido da resistere a contributi buggy, malevoli e ambigui dal punto di vista legale. Il vibe coding aggira quel processo, non per malevolenza, ma per una fiducia mal riposta nel fatto che “l’AI l’ha scritto” sia una dichiarazione di provenienza invece che una zona grigia.

La domanda che resta aperta è quante codebase BSD, MIT e Apache contengano già oggi codice che, sotto esame legale, potrebbe rivelarsi un derivato non dichiarato di GPL o di codice permissivo mai attribuito. Nessuno sta facendo audit sistematici su questo. Non ancora.

Ma quando il primo caso arriverà in tribunale, l’industria scoprirà che il problema non era teorico. Era solo difficile da vedere, perché era nascosto nel punto esatto in cui abbiamo smesso di guardare: la provenienza del codice.