Licenze e codice generato dall’IA: cosa puoi pubblicare e cosa rischi
Vuoi mettere su GitHub o vendere un progetto scritto con l’IA? Diritti sul codice, termini dei servizi e licenze altrui: i controlli da fare prima.
Il progetto funziona, l’hai costruito con ChatGPT, Claude o Cursor e adesso vuoi metterlo su GitHub, regalarlo a un’associazione o venderlo a un cliente. GitHub ti chiede quale licenza scegliere e ti accorgi di non sapere nemmeno se quel codice è «tuo». Nella guida ai rischi del vibe coding mi concentro sulla sicurezza; qui affronto il lato che molti scoprono tardi. Prima di pubblicare codice generato con l’IA devi controllare tre cose separate: quanto contributo tuo c’è, cosa dicono i termini del servizio che hai usato e se nel codice sono finiti pezzi coperti da licenze altrui.
⚠️ Attenzione — Non è una consulenza legale: io non sono un avvocato. Qui trovi le norme e i documenti ufficiali che ho letto, più una procedura pratica di controllo. Se vendi software, firmi un contratto con un cliente o hai un dubbio concreto su un frammento di codice, la decisione va presa con un professionista.
La risposta breve: per un progetto personale o open source, nella maggior parte dei casi puoi pubblicare, a patto di aver rivisto e modificato il codice, di aver controllato che non contenga frammenti riconoscibili di progetti con licenza incompatibile e di rispettare le licenze delle dipendenze. Il resto dell’articolo spiega perché e ti dà i comandi per farlo.
Tre domande diverse che spesso vengono confuse
Quando si parla di «licenza del codice IA» si mescolano tre questioni che hanno risposte diverse.
1. Esiste un diritto d’autore sul codice generato? In Italia la legge sul diritto d’autore (L. 633/1941) protegge i programmi per elaboratore come opere letterarie. Dal 10 ottobre 2025, con la legge 132/2025, l’articolo 1 parla di «opere dell’ingegno umano» e precisa che sono protette anche quelle create con l’ausilio di strumenti di intelligenza artificiale, «purché costituenti risultato del lavoro intellettuale dell’autore». In pratica: il contributo creativo umano conta. Negli Stati Uniti il Copyright Office, nel rapporto di gennaio 2025, arriva a una conclusione simile: il solo prompt non basta, mentre selezione, organizzazione e modifiche creative dell’autore possono essere protette.
2. Cosa dicono i termini del servizio? Questo riguarda il rapporto tra te e il fornitore. I termini d’uso di OpenAI, per esempio, dicono che l’output è tuo e che OpenAI ti cede gli eventuali diritti che ha su di esso, «nella misura consentita dalla legge»; aggiungono che altri utenti possono ricevere output simili. Una cessione contrattuale non crea un diritto d’autore dove la legge non lo riconosce: sposta solo quello che c’è.
3. Il codice contiene pezzi di terzi? È la domanda più concreta. Un assistente può riprodurre frammenti simili a codice pubblico esistente. Se quel codice era sotto GPL, per esempio, distribuirlo dentro un progetto chiuso può violarne la licenza, indipendentemente da chi «possiede» l’output.
Per chi pubblica un progetto, le domande 2 e 3 sono quelle su cui puoi agire subito. La 1 dipende soprattutto da quanto lavoro tuo c’è: più rivedi, riorganizzi e riscrivi, più il risultato è anche tuo.
Passo 1 — Ricostruisci cosa ha scritto l’IA e cosa hai scritto tu
Non serve un registro notarile, serve sapere dove guardare. Se usi Git, la cronologia è già un buon punto di partenza:
Windows (PowerShell o Prompt dei comandi) e macOS / Linux, stesso comando:
git log --stat --reverse
L’opzione --stat mostra per ogni commit quali file sono cambiati e quante righe; --reverse parte dal commit più vecchio. Scorri e annota i file nati interi da un’unica risposta dell’IA: sono quelli da controllare per primi al Passo 2.
Da qui in avanti prendi un’abitudine semplice: quando incolli un blocco generato, scrivilo nel messaggio di commit (per esempio feat: parser CSV (bozza generata con IA, rivista)). Tra sei mesi saprai quali parti hai riscritto e quali no.
Passo 2 — Cerca nel codice tracce di licenze altrui
Un frammento copiato da un progetto pubblico a volte porta con sé indizi: intestazioni di copyright, identificatori SPDX (SPDX-License-Identifier: GPL-3.0), nomi di autori, commenti in un’altra lingua che non c’entrano con il resto. Cercali in tutto il progetto.
Windows (Prompt dei comandi, dalla cartella del progetto):
findstr /S /I /N "copyright spdx gpl lgpl agpl license" *.py *.js *.ts *.html
/Scerca anche nelle sottocartelle./Iignora maiuscole e minuscole./Nmostra il numero di riga.- Le parole tra virgolette sono alternative: basta che una compaia.
macOS / Linux (Terminale):
grep -rniE "copyright|spdx|gpl|lgpl|agpl|license" --include="*.py" --include="*.js" --include="*.ts" --include="*.html" .
-rricorsivo,-nnumero di riga,-isenza distinzione tra maiuscole e minuscole,-Eespressioni regolari estese (per usare|).--includelimita la ricerca ai tipi di file indicati; aggiungine altri se il progetto usa altri linguaggi.
Escludi dal controllo la cartella del venv (.venv) e node_modules: lì le licenze sono normali e le controlli al Passo 3. Se trovi un’intestazione di copyright dentro un tuo file, cerca su GitHub una riga distintiva di quel blocco tra virgolette: se esce un progetto con licenza incompatibile, riscrivi la parte o rispetta quella licenza.
Se usi GitHub Copilot, sfrutta anche lo strumento ufficiale. Secondo la documentazione GitHub sulle impostazioni di Copilot, nelle impostazioni personali trovi la voce Suggestions matching public code: con Block i suggerimenti che coincidono (o quasi) con codice pubblico su GitHub non vengono mostrati; con Allow vengono mostrati insieme a un riferimento al repository e alla licenza rilevata. Nei piani aziendali l’impostazione la decide l’organizzazione. Altri assistenti hanno funzioni diverse o nessuna: controlla la documentazione del tuo.
Passo 3 — Controlla le licenze delle dipendenze
Le librerie che l’IA ti ha fatto installare hanno licenze proprie, e quelle valgono a prescindere da come hai scritto il tuo codice. Per un progetto Python, attiva il venv e salva questo script come licenze.py nella cartella del progetto: usa solo la libreria standard.
from importlib.metadata import distributions
for dist in sorted(distributions(), key=lambda d: d.metadata["Name"].lower()):
meta = dist.metadata
licenza = meta.get("License-Expression") or meta.get("License") or ""
if licenza.strip().upper() in ("", "UNKNOWN") or len(licenza) > 60:
classificatori = [c.split(" :: ")[-1] for c in meta.get_all("Classifier") or [] if c.startswith("License ::")]
licenza = ", ".join(classificatori) or "NON DICHIARATA"
print(f"{meta['Name']:<25} {dist.version:<12} {licenza}")
Windows:
.venv\Scripts\activate
python licenze.py
macOS / Linux:
source .venv/bin/activate
python3 licenze.py
Output reale, venv con il solo pacchetto requests installato con python3 -m pip install requests (22 ottobre 2026; le versioni cambiano nel tempo). Su macOS 15.7.7 con Python 3.14.7:
certifi 2026.10.19 MPL-2.0
charset-normalizer 3.5.2 MIT
idna 3.20 BSD-3-Clause
pip 26.2.1 MIT
requests 2.34.2 Apache-2.0
urllib3 2.8.0 MIT
Su Linux (Debian 13) con Python 3.13.5 l’elenco è identico, tranne pip alla versione 25.1.1, quella inclusa nel venv di quel Python. Su Windows non ho potuto eseguirlo in questa prova: lo script usa solo la libreria standard e nessun percorso di sistema, quindi su Windows ti aspetti un elenco con la stessa struttura (le versioni, soprattutto di pip, possono essere diverse).
Lo script legge i metadati che ogni pacchetto dichiara (il campo moderno License-Expression, poi il vecchio License, poi i classificatori). I pacchetti più vecchi a volte scrivono UNKNOWN nel campo License: lo script lo tratta come vuoto e passa ai classificatori. Il campo, però, è testo libero: nelle mie prove python-dateutil 3.0.0 dichiara solo Dual License, che non dice quali due licenze. In casi così leggi il file LICENSE del pacchetto. Se compare NON DICHIARATA, apri la pagina del pacchetto su PyPI o il suo repository e cerca il file LICENSE. Se il venv non è attivo vedrai i pacchetti di sistema: è il primo errore da escludere.
Come leggere il risultato:
| Licenza della dipendenza | Compatibile con un progetto chiuso? | Cosa devi fare |
|---|---|---|
| MIT, BSD, ISCPermissive | Sì | Conserva l’avviso di copyright e il testo della licenza se distribuisci la libreria. |
| Apache-2.0Permissiva con clausola brevetti | Sì | Come sopra, più l’eventuale file NOTICE e l’indicazione delle modifiche. |
| MPL-2.0, LGPLCopyleft debole | Dipende | Di solito puoi usarle come librerie; le modifiche ai loro file vanno condivise. |
| GPL, AGPLCopyleft forte | Di norma no | Se distribuisci il programma (o, con AGPL, lo offri in rete), il tuo codice combinato segue quella licenza. |
Per un progetto JavaScript il ragionamento è identico: le licenze stanno nel campo license di ogni package.json dentro node_modules.
Passo 4 — Scegli la tua licenza e dichiara l’uso dell’IA
Se il progetto è open source, scegli una licenza compatibile con le dipendenze che hai trovato: MIT o Apache-2.0 sono le scelte più semplici per un progetto senza dipendenze GPL. Su GitHub, crea un file LICENSE dalla pagina del repository (Add file → Create new file, nome LICENSE): l’interfaccia propone i modelli delle licenze più comuni.
Nel README aggiungi due righe oneste, per esempio:
Parti di questo progetto sono state scritte con l'aiuto di assistenti IA
e poi riviste, modificate e testate da me. Le dipendenze e le loro licenze
sono elencate in THIRD_PARTY_LICENSES.txt.
Per il file delle terze parti puoi salvare l’output del Passo 3:
Windows:
python licenze.py > THIRD_PARTY_LICENSES.txt
macOS / Linux:
python3 licenze.py > THIRD_PARTY_LICENSES.txt
La dichiarazione non è un obbligo generale che io abbia trovato nelle norme citate sopra, ma è trasparenza utile: chi usa il tuo progetto sa come è nato. Alcuni progetti open source hanno regole proprie sui contributi generati con l’IA: se proponi codice a un progetto altrui, leggi prima il suo file CONTRIBUTING.
Errori tipici
- «L’ha scritto l’IA, quindi è di pubblico dominio» → confonde la domanda 1 con la 3 → anche se il tuo contributo fosse minimo, un frammento copiato da un progetto GPL resta sotto GPL.
- «Il fornitore dice che l’output è mio, quindi sono a posto» → i termini regolano il rapporto con il fornitore, non i diritti di terzi → fai comunque il Passo 2.
- Licenza MIT su un progetto che include una libreria GPL → incompatibilità se distribuisci il tutto → sostituisci la libreria o adotta una licenza compatibile.
- Controllo delle licenze fatto con il venv spento → l’elenco mostra i pacchetti di sistema → attiva il venv e rilancia.
- Codice del cliente incollato in un assistente → problema di riservatezza prima ancora che di licenza → controlla il contratto con il cliente prima di farlo.
Domande Frequenti (FAQ)
Posso vendere un’app scritta con ChatGPT?
Per quanto ho letto, i termini di OpenAI non lo vietano e ti attribuiscono l’output. Restano due condizioni: il codice non deve violare licenze di terzi e le dipendenze devono permettere l’uso commerciale. Per una vendita vera, con contratto e garanzie al cliente, fai valutare il caso a un professionista.
Il codice generato dall’IA è protetto dal diritto d’autore in Italia?
Dopo la modifica dell’articolo 1 della legge 633/1941, sono protette le opere dell’ingegno umano create anche con l’ausilio dell’IA, purché siano il risultato del lavoro intellettuale dell’autore. Un output preso così com’è difficilmente lo è; codice che hai progettato, selezionato e modificato in modo creativo ha argomenti migliori. Il confine preciso lo stabiliranno i casi concreti.
Devo scrivere nel README che ho usato l’IA?
Nelle norme che ho citato non ho trovato un obbligo generale per chi pubblica un progetto personale. Alcuni progetti open source e alcuni clienti, però, hanno regole proprie. Una riga trasparente nel README costa poco e risponde in anticipo alla domanda.
Che licenza conviene per un progetto vibe coded?
Se le dipendenze sono permissive, MIT è la più semplice da capire; Apache-2.0 aggiunge una clausola esplicita sui brevetti. Se vuoi che chi modifica il tuo codice condivida le modifiche, valuta la GPL. La scelta deve sempre essere compatibile con le licenze delle librerie che usi.
Come faccio a sapere se l’IA ha copiato codice da GitHub?
Non esiste un controllo completo alla portata di tutti. Puoi cercare intestazioni di copyright e identificatori SPDX nel progetto, verificare su GitHub le righe più distintive e, se usi Copilot, attivare il blocco o i riferimenti al codice pubblico. Sono controlli che riducono il rischio, non lo azzerano.
Se riscrivo il codice con parole mie il problema sparisce?
Se riscrivi davvero la logica, il risultato è in buona parte tuo. Cambiare solo i nomi delle variabili in un blocco copiato non basta a renderlo un’opera diversa. Nel dubbio, sostituisci quel frammento con una libreria dalla licenza chiara.
Prima di premere «Pubblica»
Il controllo completo richiede mezz’ora: cronologia, ricerca delle intestazioni, elenco delle licenze, file LICENSE e due righe nel README. È lo stesso spirito della code review umana in 15 minuti, applicato ai diritti invece che alle falle. Se il progetto dipende da pacchetti suggeriti dall’IA, verifica anche che esistano davvero e siano quelli giusti, come spiego nella guida su quando usare pip install. Per il quadro generale su cosa può andare storto quando costruisci con l’IA, torna all’articolo madre sui rischi del vibe coding che non vedi.