Codice generato da LLM: può essere “vibe code” libero?

La Free Software Foundation Europe (FSFE) ha pubblicato un’analisi tecnica-giuridica sulla copyrightability del codice generato da grandi modelli linguistici (LLM) e sulle implicazioni per le licenze libere.

Punti chiave:

• Si discute se il codice prodotto da LLM possa essere considerato opera originale tutelabile da copyright o se ricada in una zona grigia (“vibe code”) dove la titolarità è incerta.

• La FSFE ribadisce il criterio fondamentale: una licenza è Free Software license se garantisce le quattro libertà essenziali (uso, studio, modifica, condivisione), indipendentemente da come il codice è stato prodotto.

• L’articolo esamina scenari in cui:

  • l’output è quasi identico a codice esistente (rischio di violazione di licenze copyleft);

  • l’output è fortemente trasformativo (più facile difendere una nuova paternità);

  • l’output è banale o generico (difficile sostenere un copyright forte).

Per chi integra LLM nei flussi di sviluppo, il messaggio tecnico è: serve una policy chiara su provenienza dei dati di training, tracciabilità degli snippet e scelta di licenze compatibili con le quattro libertà.

California: Linux esentato dalla verifica dell’età grazie alle licenze libere

In California è stato approvato un emendamento al Digital Age Assurance Act che esenta esplicitamente i sistemi e le applicazioni distribuiti con licenze libere/open source dall’obbligo di verificare l’età dell’utente durante l’installazione o il primo avvio.

Aspetti tecnici rilevanti:

• La norma definisce come “provider esenti” chi distribuisce software con licenze che consentono al destinatario di copiare, redistribuire e modificare il codice.

• Vengono citati esplicitamente i modelli di licenza GPL, MIT, BSD e Apache come esempi che rientrano in questa definizione.

• Di fatto, distribuzioni come Debian, Fedora, Ubuntu, Arch Linux e vari sistemi BSD non dovranno implementare meccanismi di age-gating, a differenza di molti prodotti proprietari.

Questa è una delle prime volte in cui una legge lega esplicitamente obblighi regolamentari alla natura della licenza software, riconoscendo un trattamento differenziato per il software libero.

Euro-Office, AGPLv3 e controversie su marchi e attribuzione

Un caso pratico molto tecnico riguarda Euro-Office, un progetto europeo basato su ONLYOFFICE, finito al centro di una disputa su AGPLv3, attribuzione e uso dei marchi.

Punti salienti:

• ONLYOFFICE accusa i promotori di Euro-Office di aver violato condizioni della licenza AGPLv3, in particolare su:

  • corretta attribuzione del software originale;

  • rispetto delle clausole di ridistribuzione del codice modificato;

  • uso dei marchi commerciali in modo da non creare confusione con il prodotto upstream.

• La controversia tocca temi centrali per chi fa fork o rebranding di progetti AGPL:

  • quanto si può modificare prima di dover cambiare nome/marchio;

  • come gestire la documentazione e gli avvisi di copyright;

  • quali modifiche devono essere rese pubbliche sotto AGPL quando il software è offerto come servizio.

Il caso è utile come studio pratico su come le clausole di copyleft forte (AGPL) interagiscono con strategie di “sovranità digitale” e branding istituzionale.

Rune IDE: GPLv3 e diritti dei contributori

Un esempio più “leggero” ma tecnicamente interessante è Rune, un IDE scritto in Go che è passato a licenza GPLv3, dichiarando esplicitamente che i contributori mantengono i diritti sul proprio lavoro.

Questo approccio:

• evita clausole di cessione totale del copyright (tipiche di alcuni progetti corporate);

• mantiene il progetto sotto copyleft forte, garantendo che i derivati restino liberi;

• lascia ai singoli sviluppatori la possibilità di riutilizzare i propri snippet in altri contesti, purché compatibili con GPLv3.

È un modello di governance della licenza sempre più discusso nella comunità, soprattutto per progetti che vogliono bilanciare protezione copyleft e autonomia dei contributori.