Leak di Claude Code: il DMCA ha funzionato. È questo il problema.

Ad aprile 2026, Anthropic ha mandato una serie di richieste DMCA a GitHub per contenere la diffusione del codice sorgente di Claude Code, finito online dopo un leak. Come riportato da TechCrunch, alcuni dei repository colpiti non contenevano il codice leakato. Contenevano fork con codice scritto dai loro autori. GitHub li ha rimossi comunque. Anthropic si è scusata. La notizia è durata un giorno.

Il takedown DMCA che sembrava un errore operativo

La prima reazione, la mia compresa, è stata: errore operativo. Succede. Un'azienda si trova il codice proprietario sparso su GitHub, reagisce in fretta, il raggio d'azione è troppo ampio, qualche progetto legittimo finisce in mezzo. Poi arrivano le segnalazioni, l'azienda corregge, i repository vengono ripristinati. Il sistema ha funzionato.

È una lettura che regge. Anthropic ha agito in buona fede, ha riconosciuto l'errore, ha collaborato al ripristino. Non c'è un cattivo in questa storia, non c'è dolo, non c'è negligenza grave. Se ti fermi qui, la conclusione è rassicurante: i meccanismi di ricorso esistono e funzionano.

Perché la lettura dell'errore non regge

Il problema con questa lettura è che scambia il ripristino per la prova che il sistema funziona. Ma il ripristino è arrivato dopo. Prima è successo qualcos'altro: GitHub ha rimosso i repository automaticamente, senza verifica di merito, perché il DMCA glielo impone.

Non è una scelta di GitHub. È la struttura della legge. Il DMCA, la legge federale statunitense del 1998 che governa il copyright digitale e la responsabilità delle piattaforme online, al paragrafo 512(c) funziona così: il titolare dei diritti dichiara la violazione, la piattaforma rimuove il contenuto per mantenere il proprio safe harbor, il soggetto colpito può fare counter-notice. Il default è la rimozione. La verifica viene dopo.

In un contesto dove i contenuti sono file statici (un film, una canzone, una foto), questa logica ha una sua brutalità accettabile. Rimuovi, verifichi, ripristini. Il danno nel frattempo è contenuto: il file non c'è per qualche giorno, poi torna.

Ma il software non funziona così.

Perché il DMCA non distingue copia da derivazione

Quando rimuovi un repository, non sparisce un file. Si rompe una catena di dipendenze: le CI/CD pipeline di chi lo importa iniziano a fallire, i fork perdono il riferimento upstream, le pull request aperte puntano al vuoto.

E qui arrivo alla cosa su cui ho dovuto cambiare idea. Inizialmente pensavo che il problema fosse la velocità: Anthropic ha agito troppo in fretta, con un raggio troppo ampio. Ma non è un problema di velocità. È un problema di categorie.

Il DMCA opera su una distinzione binaria: c'è un proprietario e c'è chi ha copiato. Questa distinzione funziona per le copie. Un film piratato è una copia. Un album su un sito di streaming illegale è una copia. La relazione tra l'originale e la copia è semplice: uno è legittimo, l'altro no.

Un fork non è una copia. Un fork è un atto di costruzione che parte da una base condivisa. Un fork attivo contiene stratificazioni di codice: quello dell'autore originale, quello di altri contributori, quello di chi ha fatto il fork e ha iniziato a modificarlo. Le linee di proprietà non sono binarie, sono un continuum. Il DMCA non ha una categoria per questo. Ha "proprietario" e "non proprietario". Quando lo applichi a un ecosistema dove ogni progetto è una derivazione di altri progetti, il danno collaterale non è un bug. È il funzionamento normale di uno strumento che usa le categorie sbagliate.

I 10 giorni della counter-notice e il costo sul software

Ho dubitato, e continuo a dubitare, che sia giusto prendersela con il meccanismo legale. Chi subisce un leak reale ha bisogno di strumenti rapidi. Il codice di Claude Code era effettivamente online e ogni ora che restava disponibile era un'ora in cui poteva essere copiato, analizzato, usato. La velocità del DMCA, in quel caso, serviva a qualcosa di legittimo.

Non esiste un sistema che sia contemporaneamente immediato e chirurgico. Chi chiede rapidità deve accettare imprecisione. Chi chiede precisione deve accettare lentezza.

Ma ecco il dato che mi ha fatto ragionare: il DMCA stesso, al paragrafo 512(g)(2)(C), prevede che dopo una counter-notice la piattaforma ripristini il contenuto non prima di 10 e non oltre 14 giorni lavorativi, salvo che chi ha presentato il reclamo non abbia nel frattempo aperto un'azione legale. Non è una scelta di GitHub: la legge fissa al reclamante una finestra garantita di due settimane in cui il contenuto resta giù, anche se non viola niente. In un ecosistema dove i rilasci sono continui e le dipendenze si rompono in ore, due settimane di non-esistenza non sono un inconveniente. Per un progetto piccolo o emergente sono il tempo sufficiente perché chi dipende da te trovi un'alternativa, aggiorni le proprie dipendenze, vada avanti. Quando torni, il posto è già occupato.

Nel caso Anthropic il ripristino è stato rapido perché l'azienda ha ritrattato volontariamente dopo 48 ore. Ma quella è l'eccezione. Nel caso normale chi ha inviato il DMCA non ritratta, e la finestra di 10-14 giorni scatta per intero. Anthropic è stato l'incidente che ha reso visibile il meccanismo, non il meccanismo stesso.

Il conto della delega

Il punto è questo: anche quando chi lo usa agisce in buona fede, come Anthropic, il DMCA resta uno strumento strutturalmente sbilanciato. Funziona come un sequestro preventivo dove chi reclama non deve dimostrare i confini della proprietà, basta che dichiari. Applica questa logica a un ecosistema che funziona come un fiume: il codice scorre, si biforca, confluisce, si mescola. Finché lo strumento legale non riconosce la differenza tra copia e derivazione, ogni fork su una piattaforma centralizzata esiste per gentile concessione di chi ha più avvocati.

Non mi aspetto che la legge distingua in fretta tra copia e derivazione. Le categorie legali si muovono più lente degli ecosistemi che dovrebbero regolare e una riforma del DMCA non è all'orizzonte. Il lavoro ricade sul singolo.

Il costo di questa consapevolezza è concreto: se costruisci su GitHub, su npm, su qualsiasi registry centralizzato, accetti che un'email automatica possa far sparire il tuo lavoro per due settimane. Non è un'eccezione, è un pattern: lo strumento legacy colpisce i bersagli che sa colpire, quelli innocenti e centralizzati, e manca quelli che dovrebbe colpire. È il funzionamento ordinario. Delegare infrastruttura critica vuol dire accettare che il conto, quando arriva, lo paghi tu.

Spostare il terreno: forge self-hosted in uno Stato UE

Il passo coerente con questa diagnosi non è un palliativo, è uno spostamento di terreno: un'istanza self-hosted del tuo forge. GitLab Community Edition, Gitea e Forgejo sono open source, girano su una VPS da venti euro al mese. Non è zero lavoro: backup, sicurezza, uptime restano in carico, il provider può sempre sospenderti per violazione dei termini. Ma le leve decisionali tornano in casa. La scelta tecnica è libera. La scelta geografica no: la VPS va presa in Unione Europea, presso un provider soggetto alla giurisdizione di uno Stato membro UE.

Qui il quadro cambia davvero. Il DMCA è una legge federale statunitense, non si applica a un hoster tedesco o italiano. Le piattaforme europee rispondono al regime di responsabilità degli intermediari codificato oggi dal Digital Services Act (Regolamento UE 2022/2065), che ha superato gli articoli 12-15 della precedente Direttiva 2000/31/CE sul commercio elettronico. Il safe harbor europeo non dipende dalla velocità di rimozione ma dalla qualità della notifica: l'art. 16 del DSA formalizza una procedura strutturata, non basta un modulo PDF automatico. E il provider europeo, a differenza di GitHub, non ha l'incentivo strutturale a rimuovere al primo dubbio per proteggere un safe harbor.

Non è immunità. Un'ordinanza da un tribunale di uno Stato UE arriva comunque, se il caso regge in aula. E un claimant con risorse legali può sempre aggirare l'hoster premendo sul registrar del dominio o sul provider upstream. Ma è un cambio di regime: dal default rimuovi subito, verifica dopo, al default valuta prima, rimuovi se c'è motivo. In mezzo ci sono le due settimane che per l'ecosistema software fanno la differenza. Open source sul software che usi e giurisdizione di uno Stato UE sull'infrastruttura che gestisci non sono una preferenza ideologica: alzano il costo di enforcement di una legge che usa categorie sbagliate. Il DMCA è una legge territoriale, non una forza di gravità.

Fonti

TechCrunch, Anthropic took down thousands of GitHub repos trying to yank its leaked source code, aprile 2026.

Notifica di ritrattazione DMCA di Anthropic, repository github/dmca (1 aprile 2026): documento primario che elenca il repository residuo e i 96 fork ancora oggetto del takedown.

17 U.S.C. § 512, Digital Millennium Copyright Act, paragrafo (g)(2)(C): termine di ripristino dopo counter-notice (10-14 giorni lavorativi).

Regolamento (UE) 2022/2065 (Digital Services Act), art. 16: meccanismo di notice and action per i prestatori di servizi di hosting nella UE.