La GPL ha un limite che con la diffusione delle applicazioni web è diventato evidente: i suoi obblighi scattano quando il software viene distribuito. Ma un'applicazione eseguita su un server e usata dagli utenti attraverso il browser non viene distribuita a nessuno. Chi la gestisce può modificarla quanto vuole, offrire il servizio a migliaia di persone e non condividere mai il codice. Questo fenomeno è spesso chiamato «scappatoia ASP» o «scappatoia SaaS». La GNU Affero General Public License, nella versione 3 pubblicata nel 2007, è nata per chiuderla.
Cosa aggiunge l'AGPL alla GPL
L'AGPLv3 è quasi identica alla GPLv3. La differenza sta nella sezione 13, intitolata all'interazione remota attraverso una rete. In sostanza dice: se modifichi il programma e la tua versione modificata permette agli utenti di interagire con essa da remoto attraverso una rete, devi offrire a quegli utenti la possibilità di ricevere il codice sorgente corrispondente della tua versione.
Tre elementi meritano attenzione:
- Serve una modifica. Chi esegue il programma originale, senza modificarlo, non ha obblighi aggiuntivi rispetto alla GPL: il sorgente è già disponibile a monte.
- Conta l'interazione degli utenti. L'obbligo riguarda chi usa il servizio, non chiunque nel mondo.
- L'offerta deve essere visibile. In genere si realizza con un collegamento nell'interfaccia, ad esempio nel piè di pagina, che porta a un archivio scaricabile o a un repository con il sorgente della versione in esecuzione.
Un esempio pratico
Un'associazione installa un software di gestione eventi sotto AGPL e lo usa per le iscrizioni dei propri soci. Finché lo usa così com'è, non deve fare nulla di particolare. Poi un volontario aggiunge un modulo per i pagamenti e personalizza le email di conferma. Da quel momento i soci che usano il sito interagiscono con una versione modificata: l'associazione deve offrire loro il sorgente completo di quelle modifiche, compreso il modulo dei pagamenti.
Le credenziali, le chiavi API e i dati del database non fanno parte del codice sorgente e non vanno pubblicati. Per questo è buona pratica tenere la configurazione separata dal codice, ad esempio in variabili d'ambiente.
Perché alcuni progetti scelgono l'AGPL
- Software pensato per girare su server: piattaforme di collaborazione, social network decentralizzati, sistemi di gestione documentale. Con la GPL classica il copyleft non avrebbe effetto nel loro uso tipico.
- Protezione da chi offre il progetto come servizio senza contribuire: un fornitore cloud che modifica il software deve condividere i miglioramenti.
- Modelli a doppia licenza: alcune aziende pubblicano il codice in AGPL e vendono una licenza commerciale a chi non vuole sottostare al copyleft di rete.
Perché alcune aziende la evitano
Molte organizzazioni hanno politiche interne che vietano o limitano l'uso di componenti AGPL. I motivi più frequenti sono:
- timore che una modifica anche piccola obblighi a pubblicare codice considerato riservato;
- incertezza su quali componenti costituiscano un'unica opera con il software AGPL;
- difficoltà nel garantire, a ogni rilascio, che il sorgente pubblicato corrisponda esattamente a quello in esecuzione.
Queste preoccupazioni sono comprensibili, ma spesso vengono gestite meglio con regole chiare che con divieti generalizzati.
Come gestirla in modo ordinato
Se un'organizzazione decide di usare un componente AGPL, alcune pratiche riducono quasi a zero il rischio di violazioni:
- Tenere un fork pubblico del componente, in cui confluiscono tutte le modifiche.
- Automatizzare la pubblicazione: la pipeline di rilascio pubblica il sorgente della versione che va in produzione, con lo stesso identificativo.
- Inserire il collegamento al sorgente nell'interfaccia, in un punto stabile.
- Isolare il componente dietro interfacce ben definite, come API di rete, invece di fonderlo con il codice proprietario. Se il proprio software comunica con il servizio AGPL senza esserne un'opera derivata, resta fuori dall'obbligo; i casi dubbi vanno però valutati con attenzione.
- Documentare la decisione, indicando chi è responsabile della conformità.
Confronto rapido
| Situazione | GPLv3 | AGPLv3 |
|---|---|---|
| Uso interno senza modifiche | nessun obbligo | nessun obbligo |
| Uso interno con modifiche, nessun utente esterno | nessun obbligo | nessun obbligo verso esterni |
| Servizio web modificato usato da utenti | nessun obbligo | offrire il sorgente agli utenti |
| Distribuzione del programma | sorgente ai destinatari | sorgente ai destinatari |
Compatibilità
La GPLv3 e l'AGPLv3 contengono clausole reciproche che permettono di combinare codice dell'una e dell'altra in un'unica opera: ciascuna parte resta sotto la propria licenza, e l'insieme è soggetto anche al requisito di rete dell'AGPL. La GPLv2 da sola, invece, non è compatibile con l'AGPLv3.
In sintesi
- L'AGPLv3 estende il copyleft della GPLv3 al software usato attraverso una rete.
- L'obbligo nasce quando si modifica il programma e gli utenti interagiscono da remoto con la versione modificata.
- Va offerto agli utenti il sorgente della versione in esecuzione, non i dati né le credenziali.
- Un fork pubblico e la pubblicazione automatica a ogni rilascio rendono la conformità semplice.
- GPLv3 e AGPLv3 sono combinabili; la GPLv2 da sola non lo è con l'AGPL.
