Su GitHub è comparso da poco un interessante tool open source di nome Netryx. Questo strumento, dato un qualsiasi scatto fotografico preso da una strada, restituisce le coordinate GPS del punto in cui è stato scattato, tutto in locale con un’accuratezza di sub-50 metri. Senza andare a guardare l’algoritmo, questo strumento offre lo spunto per una riflessione generale su AI coding e licenze open source.
Il tool è dotato di un’esaustiva pagina di descrizione dell’algoritmo. Fin troppo forse. Perché la cosa interessante, tool a parte, è la possibilità di clonarlo tramite AI-coding o vibe-coding (nda: io preferisco AI-coding): presa quella descrizione e passata a un assistente AI con buone capacità di coding, quello che si ottiene è un progetto Python funzionante che arriva in fretta a replicarne la pipeline centrale. Tre modelli di computer vision, la stessa logica di matching, un risultato abbastanza vicino da valerne la pena. Per erodere il valore di un progetto open source basta ormai descriverne bene il funzionamento.
Vale la pena annotare, a margine, che clonare un repository alla cieca non è privo di rischi propri anche sul piano della sicurezza: un caso recente ha mostrato come istruzioni malevole nascoste in una GitHub Issue possano essere lette silenziosamente da Copilot in modalità agente, portando all’esfiltrazione del token del repository senza alcuna interazione da parte dello sviluppatore. Casi analoghi sono accaduti per Claude e Codex. È un vettore diverso che rafforza l’idea che l’ecosistema dei repository pubblici vada trattato con cautela.
Indice degli argomenti
Il nocciolo del problema
La dottrina del copyright per il software, almeno negli ordinamenti anglosassoni, protegge l’espressione, non la funzionalità. Il test Abstraction-Filtration-Comparison stabilito nel 1992 dal caso Computer Associates v. Altai filtra gli elementi funzionalmente necessari e protegge solo le scelte creative residue. Un’implementazione generata ex novo da una descrizione naturale parte da zero sul piano formale, anche quando è funzionalmente equivalente. Il problema non è giuridico nel senso convenzionale, ma economico e strutturale.
Cosa proteggevano le licenze, e perché non basta più
Le licenze open source, MIT compresa, regolano il codice come artefatto: stabiliscono chi può copiarlo, distribuirlo, modificarlo. Presuppongono che tra l’opera e la sua ricostruzione esista una distanza reale, fatta di tempo, competenza e fatica. L’avvocata specializzata in open source Heather Meeker ha scritto nel marzo 2025 che l’AI può ora sostituire uno o entrambi i team nel tradizionale processo di “clean room development”, la pratica che permetteva di riscrivere un sistema legalmente attraverso due équipe isolate. Quel processo era costoso e lento; con l’AI coding diventa drasticamente più rapido ed economico. Finché capire il codice altrui richiedeva tutto questo, pubblicarlo in modo aperto restava un atto generoso ma sostenibile: si condivideva l’implementazione senza per questo annullare il vantaggio accumulato nel costruirla.
Con l’AI coding quella distanza si accorcia, e velocemente. La descrizione funzionale di un sistema riduce drasticamente il costo per ottenerne un’approssimazione operativa. La robustezza, la manutenzione implicita e gli edge case accumulati nel tempo richiedono ancora lavoro; però ciò che viene replicato è già sufficiente a comprimere sensibilmente il valore del codice preso isolatamente. Il caso di Netryx è istruttivo proprio perché la documentazione è ottima: più è chiara, più la soglia si abbassa.
Questo è diverso da quanto è accaduto con le immagini usate per addestrare modelli capaci di imitare uno stile grafico. Lì il conflitto riguardava l’assorbimento di opere all’interno di un modello; un tribunale tedesco ha stabilito nel novembre 2025, nel caso GEMA v. OpenAI, che la memorizzazione di contenuti nei pesi del modello costituisce riproduzione ai sensi del diritto d’autore. Qui il meccanismo è più diretto e, per certi versi, più difficile da aggredire legalmente: la descrizione naturale di un sistema software funziona sempre più spesso come una specifica ad alta comprimibilità, sufficiente in molti casi per farlo riemergere in un’altra forma, rapidamente, senza passare dal codice originale e senza lasciare tracce formali di derivazione.
Dove si sposta il valore
La licenza continua a governare la circolazione dell’artefatto, ma quell’artefatto ha smesso di contenere tutto il valore che sembrava custodire. Se una terza parte legge la descrizione del repository, si fa generare una replica funzionante e la itera per conto proprio, la domanda cambia registro: quanto del vantaggio competitivo era davvero nel codice, e quanto stava invece altrove?
La formula “ora si può rubare l’idea” spiega poco e protegge ancora meno, visto che le idee da sole sono sempre state difficili da difendere. Ciò che si restringe è la scarsità del codice come artefatto isolato. E quando perde scarsità, il valore difendibile si sposta nei dati, nelle suite di valutazione, nell’affidabilità costruita sul campo, nelle integrazioni, nella velocità di iterazione.
I repository AI-coded che proliferano su GitHub rendono la cosa ancora più visibile. Il codice pubblicato è sempre più spesso una superficie leggibile che contiene quasi tutte le informazioni necessarie ad un LLM per duplicare un servizio. Ovviamente non è una regola generale, perché al fianco del codice esistono i dati: saperli maneggiare ed usare (quali dati contano davvero, quali failure mode meritano attenzione, quali compromessi reggono fuori dalla demo). A tendere, però, questo vantaggio viene lentamente eroso.
I tentativi in corso
Pubblicare codice oggi significa sempre più spesso pubblicare anche una specifica da cui un’implementazione concorrente può essere rigenerata rapidamente. Le vecchie licenze restano necessarie, ma le categorie che usano per descrivere il valore e la sua perdita sono calibrate su un mondo in cui replicare richiedeva risorse che ora sono quasi azzerate.
Ci sono tentativi in corso. Le RAIL (Responsible AI Licenses), sviluppate dalla RAIL Initiative e adottato da Hugging Face, introducono clausole d’uso comportamentale che vanno oltre il semplice copyright: concedono accesso aperto ma restringono categorie specifiche di utilizzo, con obblighi che si propagano ai lavori derivati. Affrontano però più la responsabilità etica che la replicazione funzionale. L’addendum Commons Clause aggiunge alle licenze open source esistenti un divieto di vendita commerciale del software; è tecnicamente efficace, ma viene formalmente esclusa dall’Open Source Definition dell’OSI, creando ambiguità sul posizionamento dei progetti che la adottano.
La Functional Source License (FSL), usata tra gli altri da Sentry, ritarda la transizione ad open source, nel caso Sentry, di due anni: protezione temporale piuttosto che strutturale. Il progetto Post-Open di Bruce Perens, cofondatore dell’Open Source Initiative, che ha dichiarato che “le nostre licenze non funzionano più”, propone un modello contrattuale in cui le aziende sopra i cinque milioni di dollari di fatturato paghino l’1% dei ricavi ai maintainer, gestito come i diritti musicali con ASCAP: ancora una bozza, non pronta per l’uso. Seppure parzialmente fuori fuoco rispetto al tema, vale la pena citare anche l’iniziativa OpenMDW per modelli AI, aperta dalla Linux Foundation nel maggio 2025, e il Contextual Copyleft AI (CCAI), che estenderebbe il copyleft dai dati di addestramento ai modelli risultanti. Rimane però un problema di adozione critica: se solo una minoranza di sviluppatori la usa, chi sviluppa AI proprietaria aggira semplicemente i repository interessati.
Conclusioni
Nessuna di queste soluzioni tocca fino in fondo il punto strutturale. Cambiare il recinto giuridico non basta se il bene che si cerca di recintare ha smesso di coincidere con il file pubblicato. La questione richiede probabilmente un ripensamento delle categorie prima ancora che degli strumenti legali: cosa può essere considerato un’“opera” in un contesto in cui la descrizione funzionale e l’implementazione sono diventate quasi intercambiabili?
La domanda più scomoda, alla fine, rimane questa: quale parte del vantaggio competitivo resta davvero appropriabile dopo che il costo di ricostruire il codice partendo dalla sua descrizione è sceso quasi a zero? Netryx, involontariamente, ha reso la domanda concreta.
Riferimenti
Giurisprudenza e dottrina
- Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992) — test Abstraction-Filtration-Comparison per la protezione del software, https://law.justia.com/cases/federal/appellate-courts/F2/982/693/137252/
- GEMA v. OpenAI, Tribunale di Amburgo, novembre 2025 — memorizzazione nei pesi del modello come riproduzione ai sensi del diritto d’autore. https://www.rplt.it/gema-vs-openai-accertata-la-violazione-del-diritto-dautore-da-parte-di-openai/
- Meeker, H. (marzo 2025). AI Could Be Your Next Team for Clean Room Development. https://heathermeeker.com/2025/03/28/ai-could-be-your-next-team-for-clean-room-development/
Licenze e proposte
- RAIL Initiative. Responsible AI Licenses (RAIL). railinit.org
- Commons Clause. Commons Clause License Condition v1.0. commonsclause.com
- Crosby, E. & Dolan, J. Functional Source License (FSL). fsl.software — adottata da Sentry e altri.
- Perens, B. Post-Open Fonte: Bruce Perens’ Post-Open vision — proposta in bozza, modello ASCAP per il software.
- Linux Foundation. OpenMDW License, maggio 2025. linuxfoundation.org
- Proposte accademiche sulla Contextual Copyleft AI (CCAI) — circolanti in letteratura, non ancora adottate formalmente.
Strumento citato
sparkyniner. Netryx — Open Source Next-Gen Street-Level Geolocation. github.com/sparkyniner/Netryx-OpenSource-Next-Gen-Street-Level-Geolocation
