Policy open source per codice assistito dall’IA

Cosa fare prima di inviare a monte codice assistito dall’IA

I progetti open source pubblicano sempre più spesso policy sul codice assistito dall’IA, ma queste policy non sono uniformi. La regola pratica è semplice: trova la policy prima di scrivere la patch e indica con precisione l’uso dell’IA quando la invii. Alla base di entrambe le indicazioni c’è una regola: non inviare mai una riga che non sai spiegare durante la revisione.

Una patch corretta può comunque essere chiusa se il progetto vieta il codice generato oppure se hai nascosto l’origine del codice. Il costo ricade sul tuo nome e resta associato a esso, perché un maintainer che scopre in seguito l’omissione non ha motivo di fidarsi del resto della tua cronologia. Prima servono alcune definizioni, perché le policy usano questi termini. Un LLM (large language model) è il modello alla base del tuo coding agent. Una PR (pull request) su GitHub corrisponde a una MR (merge request) su GitLab, e tutto ciò che segue si applica a entrambe. Il DCO (developer certificate of origin) è la riga di sign-off in fondo al messaggio di un commit e, come vedremo, è il punto centrale dell’intera discussione.

Dove sono arrivate le policy sull'AI per il codice open source

I progetti si sono ormai distribuiti in quattro gruppi. Ogni esempio riportato di seguito è datato, perché questi testi cambiano.

Vietato. Il consiglio di Gentoo ha votato il 14 aprile 2024 che è «espressamente vietato contribuire a Gentoo con contenuti creati con l'assistenza di strumenti di intelligenza artificiale per l'elaborazione del linguaggio naturale». Le linee guida per i commit di NetBSD definiscono l'output di un LLM «codice contaminato» che «non deve essere sottoposto a commit senza previa approvazione scritta da parte del core team». Il documento QEMU sulla provenienza del codice, aggiornato ad agosto 2026, afferma ancora che il progetto «RIFIUTERÀ qualsiasi contributo che si ritenga includere o derivare da contenuti generati dall'AI».

Solo analisi. La maggior parte dei divieti è più circoscritta di quanto suggerisca il titolo. Il documento QEMU afferma che la policy «non si applica ad altri usi dell'AI, come la ricerca di API o algoritmi, l'analisi statica o il debugging, purché il relativo output non venga incluso nei contributi». È possibile usare l'agente per leggere il codice. Non è possibile distribuire ciò che ha scritto. Questa distinzione rappresenta il limite operativo nei progetti più restrittivi ed è quella che viene più spesso trascurata.

Dichiarazione obbligatoria. Il consiglio di Fedora ha approvato una policy sui contributi assistiti dall'AI a ottobre 2025. La policy consente l'uso degli strumenti e attribuisce la responsabilità alla persona: il contributor è l'autore, risponde pienamente dell'intero contributo e deve dichiarare quando una parte significativa proviene da uno strumento senza modifiche. A dicembre 2025 il kernel Linux ha aggiunto una pagina sugli assistenti di programmazione alla documentazione del processo, con un trailer per registrare lo strumento e una regola vincolante su chi può dare l'approvazione finale.

Niente di scritto. Questo è ancora il caso più comune. Un preprint di maggio 2026 ha analizzato 1,000 repository GitHub popolari e ne ha trovati 118 con una policy sull'AI formalizzata in qualche documento. Il silenzio non equivale a un'autorizzazione. Chiedete una conferma in una sola frase nell'issue tracker prima di scrivere la patch: la risposta diventerà un record pubblico che potrete citare in seguito.

Perché i maintainer hanno scritto queste regole

Il primo motivo è il carico di revisione, e i rapporti sono chiaramente sbilanciati. Un agente produce in un minuto una merge request plausibile di 400 righe. Revisionare correttamente quella richiesta costa a un maintainer un pomeriggio, e la maggior parte dei maintainer lavora come volontario. Il costo dell'invio è sceso quasi a zero. Il costo della revisione non è cambiato.

curl mostra l'estremo opposto di questa dinamica. A metà del 2025 Daniel Stenberg ha riferito che circa un quinto dei security report ricevuti tramite il bug bounty del progetto erano quelli che lui definisce AI slop: report che indicano funzioni reali e percorsi di codice reali, descrivono un attacco plausibile e non contengono nulla di concreto. All'inizio del 2026 il progetto ha chiuso il bounty, invece di continuare a finanziare questo flusso. Si trattava di report, non di patch, ma il meccanismo è lo stesso: induce un maintainer ad aprire la tua PR quando è già stanco.

GNOME Calendar ha formalizzato il problema con un'etichetta. A giugno 2026 il progetto ha introdotto "Probabilistically Automated" per le merge request che mostrano "major or total reliance on artificial 'intelligence' to generate code", identificando con precisione il sintomo: "usually accompanied by a lack of proper testing, and finalizing patches based on theoretical intended behavior rather than correctness of code". Rileggi due volte l'ultima frase. Il codice sembra corretto. Nessuno ha verificato che lo sia davvero.

Il secondo motivo è la provenienza, cioè da dove proviene il codice e secondo quale licenza. QEMU descrive chiaramente il conflitto: il sign-off attesta che "fully understand the copyright and license status of content" che contribuisci, mentre lo status del copyright dell'output dei modelli non è definito. Il consiglio di Gentoo ha indicato lo stesso motivo, insieme a qualità ed etica. Non devi condividere questa interpretazione giuridica. Devi però riconoscere che la decisione spetta al maintainer, non a te.

Come individuare la policy AI di un progetto?

Cercatela nei seguenti punti, in quest'ordine.

• CONTRIBUTING.md nella root del repository, poi .github/CONTRIBUTING.md e infine qualsiasi file DCO accanto a esso.
• La documentazione per gli sviluppatori. QEMU definisce la propria regola in docs/devel/code-provenance.rst. Il kernel la definisce in Documentation/process/coding-assistants.rst.
• Il sito web o il wiki del progetto. La policy di Gentoo si trova nella pagina del wiki del council, mentre quella di NetBSD si trova nelle linee guida per i commit.
• Il sistema di gestione delle issue e l'archivio della mailing list. Una policy spesso resta disponibile in questi canali per mesi prima di essere inserita nel repository.

Dall'interno di un checkout, un comando grep copre la maggior parte dei casi:

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

Poi consultate la cronologia del progetto, perché la convenzione registrata nei commit prevale su qualsiasi sua sintesi:

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

Un conteggio accanto al valore di un trailer indica quale formato usa effettivamente il progetto. Un risultato vuoto significa che in questo progetto nessuno ha dichiarato informazioni in quel formato; anche questo è un dato utile. Se il progetto è ospitato su GitHub e il workflow è nuovo per voi, come funzionano pull request e fork su GitHub descrive i meccanismi presupposti da questa sezione.

Dichiaralo nel trailer del commit, non in un commento

Un trailer è una riga Key: value nell'ultimo paragrafo del messaggio di commit. Git usa già questo formato per Signed-off-by: e Co-authored-by:, e gli strumenti lo analizzano. È quindi l'unica dichiarazione che segue il codice nel repository.

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

Il kernel documenta questo formato come Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] e specifica chiaramente il limite della riga: "AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO)." Il nome dell'agente va in Assisted-by. Il tuo nome va in Signed-off-by. Non consentire mai a uno strumento di scrivere il secondo valore e non permettergli di inventare un indirizzo Co-authored-by che non appartiene a nessuno.

I nomi possono variare, quindi copia quello locale invece di inventarne uno. Una patch pubblicata sulla mailing list di QEMU nel maggio 2026 proponeva di allentare il divieto del progetto per modifiche meccaniche, test, documentazione e correzioni di bug di venti righe o meno, registrandole con un trailer come AI-used-for: tests, docs. Ad agosto 2026 si tratta ancora di una proposta pubblicata su una mailing list e il documento approvato continua a rifiutare i contenuti generati. Un progetto ha modificato due volte la propria posizione tra il 2023 e il 2026. Il prossimo cambiamento non aspetterà il tuo intervento. Per questo il metodo è più importante dell'elenco.

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

--trailer richiede Git 2.32 o versioni successive. Il secondo comando dovrebbe restituire direttamente il valore. Una riga vuota significa che git non ha analizzato il trailer. Nella maggior parte dei casi, questo accade perché nel blocco dei trailer, in fondo al messaggio, è presente una riga vuota o una frase ordinaria. Per una serie di commit già scritta, git rebase --signoff origin/main aggiunge il sign-off a ogni commit e git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt modifica un file di messaggio.

Conviene pianificare due casi di errore. Un'unione squash riscrive il messaggio di commit. In un progetto che usa lo squash, ripeti quindi la dichiarazione nella descrizione della PR, dove la leggerà il maintainer. Un commento nella revisione non è una registrazione affidabile, perché i commenti possono essere modificati e non entrano mai nella cronologia di git.

La precisione è importante in entrambe le direzioni. Assisted-by su un commit che hai scritto manualmente è rumore e riduce il valore delle tue dichiarazioni effettive. Ometterlo da un commit scritto dall'agente è ciò che interromperà la relazione.

Che cosa attesta realmente Signed-off-by?

Il DCO è un testo breve, alla versione 1.1, pubblicato su developercertificate.org e utilizzato dal kernel, da QEMU e da molti altri progetti. Aggiungere Signed-off-by: Your Name <you@example.com> significa dichiarare che lo si certifica. Leggete ciò che state certificando, perché la maggior parte delle persone lo firma senza averlo mai letto.

La clausola (a) stabilisce che il contributo «è stato creato interamente o in parte da me e ho il diritto di sottoporlo in base alla licenza open source indicata nel file». La clausola (b) riguarda il lavoro basato su codice open source precedente che avete il diritto di redistribuire con modifiche. La clausola (c) riguarda il codice che vi è stato fornito da qualcuno che ha certificato la stessa cosa. La clausola (d) stabilisce che comprendete che il contributo e le informazioni personali presenti nella vostra firma sono pubblici e vengono conservati a tempo indeterminato.

Notate ciò che manca. Il DCO non stabilisce mai che abbiate digitato ogni carattere. Stabilisce che avete il diritto di sottoporre il codice in base a questa licenza. Per questo il codice generato si colloca in una posizione poco chiara: la questione non è la paternità, ma la possibilità di ricostruirne l'origine. La maggior parte dei progetti che richiedono la firma richiede anche il nome reale, quindi uno pseudonimo non supera il controllo. Aggiungete la riga con git commit -s, che legge user.name e user.email dalla configurazione di git. Quando un bot DCO rifiuta la vostra PR e indica il commit privo della riga, git rebase --signoff origin/main e un force push al vostro branch risolvono il problema.

Firmare un commit non equivale ad apporre il sign-off

git commit -s aggiunge una riga di testo. git commit -S crea una firma crittografica sull'oggetto commit usando la chiave GPG o SSH. Rispondono a domande diverse. La firma attesta che questo commit proviene dal titolare della chiave e non è stato modificato da allora. Non indica nulla sull'origine del codice contenuto. Un commit firmato che contiene molto codice generato non dichiarato è quindi firmato, ma viola comunque la policy. Il sign-off è la dichiarazione sull'origine. La firma è la dichiarazione sull'identità. I progetti che richiedono entrambe le garanzie chiederanno entrambe.

Non inviare mai codice che non sai spiegare in revisione

Ecco il test, che non riguarda davvero l'onestà. Per ogni riga, chiediti: a cosa serve e cosa si rompe senza di essa? Se manca una delle due risposte, la patch non è pronta, perché arriverà il commento in revisione e la tua risposta richiederà un altro ciclo di generazione. I revisori se ne accorgono. È il momento in cui un contributore diventa un costo. Poni la stessa domanda anche per i casi limite, l'input vuoto, il percorso di errore e il secondo chiamante.

Esegui il codice. Compilalo, esegui la test suite del progetto e scrivi un riproduttore per il bug che dichiari di correggere. La documentazione del kernel indica chiaramente cosa fare in assenza di verifiche: "Se non è stato possibile compilare o testare la correzione, oppure non è stato possibile produrre un riproduttore, dichiaralo esplicitamente: i maintainer perdono attualmente troppo tempo ad analizzare segnalazioni non verificate e correzioni non testate." Scrivere "Non ho potuto testarlo su hardware reale" non ti costa nulla. Lasciare intendere il contrario danneggia il progetto.

Rispondi personalmente ai commenti della revisione, con parole tue e secondo i tuoi tempi. Una risposta pubblicata trenta secondi dopo il commento e che lo riformula in cinque paragrafi comunica esattamente al maintainer cosa è successo. Mantieni ridotto anche il diff. Quaranta righe che comprendi completamente valgono per un progetto più di un refactoring di quattrocento righe che hai soltanto supervisionato. Se il tuo agent continua a restituire più di quanto hai chiesto, una skill che lo vincola alla modifica minima funzionante è un modo per mantenere la patch abbastanza ridotta da poterla ancora difendere riga per riga.

Conservare le istruzioni dell'agent nel repository

Le istruzioni fornite all'agent fanno parte della toolchain, quindi vanno trattate come codice. Un file nella root del repository, in genere `AGENTS.md`, contiene il comando di build, il comando di test, il formato dei messaggi di commit, il requisito di sign-off e le regole di stile già documentate dal progetto. Il file è sottoposto a versionamento e può essere revisionato; inoltre resta invariato nel tempo. Le istruzioni riscritte a memoria a ogni sessione producono una patch diversa ogni volta, e non sarà possibile sapere quale sessione abbia prodotto la patch rifiutata. Scrivere un AGENTS.md leggibile sia da un agent sia da una persona illustra il file in dettaglio.

Una precisazione riguarda i repository di altre persone. Non fare del primo contributo una PR che aggiunge un file di istruzioni per l'agent a un progetto che non gestisci. Può sembrare un tentativo di imporre dall'esterno la policy del progetto sugli strumenti, e associa rapidamente il tuo account a ciò di cui i maintainer sono già stanchi. Conserva il file nel tuo fork finché qualcuno non te lo richiede.

Anche il luogo in cui esegui l'agent è importante per lo stesso motivo. Un agent che può eseguire la build del progetto e i relativi test all'interno di una sandbox sotto il tuo controllo produce una patch che hai verificato realmente. Questa è la differenza tra dichiarare di aver ricevuto assistenza e dichiarare qualcosa senza averlo verificato. Eseguire un coding agent sul proprio VPS descrive questa configurazione, mentre le differenze pratiche tra Claude Code, Cursor, Codex e Copilot spiega come questi strumenti differiscono nell'uso quotidiano.

Il metodo, quando la policy cambia

1. Individua la policy vigente prima di scrivere qualsiasi cosa: repository, documentazione per gli sviluppatori, sito web, tracker.
2. Se non esiste una policy, poni la domanda nell’issue con una sola frase e conserva la risposta.
3. Inserisci la dichiarazione nel formato usato dal progetto, nel trailer del commit, e ripetila nel corpo della PR se il progetto esegue lo squash.
4. Firma con il tuo nome reale, sapendo che quella riga dichiara il tuo diritto a presentare il codice.
5. Esamina la tua patch come se fosse stata scritta da un estraneo, perché lo è stata.

Ogni progetto citato in questa pagina sarà cambiato quando la leggerai. I cinque passaggi restano invariati.

FAQ

Devo dichiarare di aver usato un agente di coding basato sull'AI?

Controlla il progetto, perché la risposta dipende dalle regole locali. Fedora richiede la dichiarazione quando una parte significativa del contributo proviene da uno strumento e viene inviata senza modifiche. Il kernel Linux richiede un trailer Assisted-by. Gentoo e QEMU, ad agosto 2026, non accettano proprio il contributo. Se non è documentato nulla, dichiara comunque l'uso dello strumento in un trailer del commit. Se un maintainer lo scopre in seguito, reagisce all'omissione, non allo strumento, e questa reazione si riflette su tutto ciò che hai inviato.

Quali progetti open source vietano il codice generato dall'AI?

In base alla situazione di agosto 2026: Gentoo da aprile 2024, NetBSD, che considera l'output degli LLM codice contaminato e richiede l'approvazione del core team, QEMU, che rifiuta i contributi derivati da contenuti generati, e diverse applicazioni GNOME, tra cui Loupe e Calendar. Leggi il testo pubblicato da ciascun progetto invece di affidarti a questo elenco, perché diventerà obsoleto. Nota l'esenzione condivisa dalla maggior parte di questi progetti: usare un modello per studiare un'API, eseguire un'analisi statica o aiutarti nel debugging è di solito accettabile, purché il suo output non finisca nella patch.

Qual è la differenza tra Signed-off-by e un commit firmato?

Signed-off-by è una riga di testo semplice aggiunta da git commit -s. Certifica il Developer Certificate of Origin, cioè che hai il diritto di sottoporre questo codice in base alla licenza del progetto. Un commit firmato, creato con git commit -S, contiene una firma crittografica sull'oggetto commit, generata con la tua chiave GPG o SSH. Dimostra che il commit proviene dalla tua chiave e non è stato modificato. Origine e identità sono dichiarazioni separate, quindi un commit firmato può comunque violare una policy sull'AI.

Posso inserire la dichiarazione nella descrizione della pull request invece che nel messaggio del commit?

Inseriscila nel messaggio del commit, perché è il record che entra nella cronologia git e viaggia insieme al codice per chiunque cloni il repository in seguito. La descrizione di una pull request può essere modificata successivamente e risiede sulla piattaforma di hosting. Aggiungila anche nel corpo della PR quando il progetto esegue lo squash merge, perché lo squash riscrive il messaggio del commit e può eliminare il trailer.

La mia pull request è stata chiusa perché era generata dall'AI. Cosa devo fare?

Non contestare la policy nella discussione, perché la persona che ha chiuso la pull request non ha definito da sola la regola e la discussione non è il luogo in cui viene modificata. Leggi il testo della policy, quindi valuta se puoi rispettarla. Se il progetto vieta le patch generate, una segnalazione di bug chiara, con un riproduttore e senza patch, è comunque benvenuta e spesso rappresenta il contributo più utile. Se torni con del codice, proponi una modifica piccola che puoi difendere riga per riga.