La GNU General Public License è la licenza copyleft più conosciuta, ma in pratica non esiste «la» GPL: esistono soprattutto due versioni in uso, la 2 del 1991 e la 3 del 2007. Hanno lo stesso spirito, cioè garantire che chi riceve il programma riceva anche le libertà di studiarlo, modificarlo e condividerlo, ma differiscono su punti che oggi hanno grande peso pratico. Molti progetti indicano «GPL» senza specificare la versione, e questa ambiguità genera dubbi proprio quando servirebbe chiarezza.
Il nucleo comune
In entrambe le versioni valgono le stesse regole di base:
- chi distribuisce il programma, originale o modificato, deve offrire il codice sorgente corrispondente;
- le opere derivate distribuite devono restare sotto la stessa licenza;
- non si possono aggiungere restrizioni ulteriori ai diritti dei destinatari;
- l'uso privato e interno non comporta obblighi di pubblicazione.
Le differenze nascono da problemi emersi nei sedici anni tra le due versioni.
Le novità principali della GPLv3
1. Protezione contro la «tivoizzazione»
Il termine viene da un caso noto: un dispositivo che usava software GPL e ne rendeva disponibile il sorgente, ma impediva tramite firme crittografiche di eseguire versioni modificate sull'hardware. Formalmente la GPLv2 era rispettata, ma la libertà di modificare il software restava sulla carta.
La GPLv3 introduce le Installation Information: per i «prodotti per l'utente», cioè dispositivi destinati al consumo privato, chi distribuisce il software deve fornire anche le chiavi o le istruzioni necessarie per installare versioni modificate. L'obbligo non vale per apparati destinati esclusivamente a uso professionale o industriale, e non obbliga a continuare a fornire assistenza a chi modifica il dispositivo.
2. Brevetti esplicitamente regolati
La GPLv2 trattava i brevetti in modo indiretto. La GPLv3 contiene una licenza esplicita sui brevetti: ogni contributore concede ai destinatari i diritti sui propri brevetti necessari per usare il suo contributo. Inoltre affronta gli accordi in cui un distributore ottiene protezione brevettuale solo per alcuni dei propri clienti, rendendo tale protezione estesa a tutti i destinatari.
3. Misure tecnologiche e leggi anti-elusione
La GPLv3 stabilisce che il software sotto questa licenza non costituisce una «misura tecnologica efficace» ai fini delle leggi che vietano di aggirare i sistemi di protezione. In pratica chi distribuisce codice GPLv3 rinuncia a usare quelle leggi contro chi modifica il software.
4. Risoluzione delle violazioni più morbida
Con la GPLv2 una violazione faceva cessare automaticamente i diritti. La GPLv3 prevede un meccanismo di ripristino: se il violatore rimedia, i diritti vengono ristabiliti, in via provvisoria e poi definitiva se il titolare non contesta entro un certo periodo; e chi rimedia entro trenta giorni dalla prima notifica ricevuta, per la prima violazione, riottiene i diritti. È un approccio pensato per favorire la conformità più che la punizione.
5. Compatibilità con altre licenze
La GPLv3 è compatibile con la licenza Apache 2.0, che invece è incompatibile con la GPLv2. Permette anche alcuni «permessi aggiuntivi» e un numero limitato di condizioni supplementari elencate nel testo, il che facilita la combinazione con altre licenze.
6. Linguaggio meno legato agli Stati Uniti
La GPLv3 usa termini come «propagare» e «trasmettere» invece di «distribuire», per ridurre la dipendenza da concetti propri di un singolo ordinamento.
Il nodo della clausola «o successive»
Molti progetti indicano «GPL versione 2 o, a tua scelta, qualsiasi versione successiva». Questa formula permette a chi riceve il codice di usarlo alle condizioni della GPLv3. Altri progetti scelgono «solo GPLv2»: il caso più noto è il kernel Linux, rimasto sotto GPLv2 senza la clausola delle versioni successive.
| Indicazione | Combinabile con codice GPLv3? |
|---|---|
| GPLv2 o successive | sì, l'insieme diventa GPLv3 |
| Solo GPLv2 | no |
| Solo GPLv3 | sì |
| GPLv3 o successive | sì |
La conseguenza è importante: codice «solo GPLv2» e codice GPLv3 non possono essere uniti in un'unica opera derivata. Prima di integrare due componenti conviene leggere l'intestazione dei file, non solo il nome della licenza nel README.
Quale scegliere per un nuovo progetto
Non esiste una risposta valida per tutti, ma alcuni criteri aiutano:
- Software per dispositivi (firmware, sistemi embedded per consumatori): la GPLv3 protegge davvero la possibilità di modifica.
- Progetti che vogliono combinarsi con codice Apache 2.0: la GPLv3 evita incompatibilità.
- Progetti con contributori aziendali preoccupati dai brevetti: la licenza esplicita della GPLv3 chiarisce le regole, anche se alcune aziende la vivono come un vincolo.
- Progetti che devono integrarsi con un ecosistema «solo GPLv2»: restare sulla v2 può essere obbligato.
Nel mio lavoro, quando un cliente chiede un parere tecnico, la prima domanda è sempre: con quali altri componenti dovrà convivere questo codice? Spesso è la compatibilità a decidere, prima ancora delle preferenze.
Come dichiararla correttamente
Una dichiarazione chiara elimina gran parte dei dubbi:
SPDX-License-Identifier: GPL-2.0-only
SPDX-License-Identifier: GPL-2.0-or-later
SPDX-License-Identifier: GPL-3.0-or-later
Questi identificatori standard, inseriti all'inizio di ogni file sorgente, dicono senza ambiguità quale variante si applica.
In sintesi
- GPLv2 e GPLv3 condividono il copyleft forte, ma la v3 affronta tivoizzazione, brevetti e misure anti-elusione.
- La GPLv3 è compatibile con Apache 2.0; la GPLv2 no.
- La clausola «o successive» decide se codice GPLv2 può confluire in un progetto GPLv3.
- Il kernel Linux è «solo GPLv2»: un esempio di come la versione esatta conti.
- Usare identificatori SPDX precisi evita ambiguità sulla versione.
