Che cos’è la GPL? La GNU General Public License spiegata

GPL significa General Public License. Nel contesto delle licenze software, indica generalmente la GNU General Public License: una licenza di software libero che permette di eseguire, studiare, modificare e condividere un programma. Il suo elemento distintivo è il copyleft. Quando distribuisci un’opera coperta dalla licenza, devi preservare le libertà che questa concede ai destinatari e rispettare i requisiti relativi al codice sorgente.

La licenza GPL consente l’uso commerciale e la distribuzione a pagamento. Non impone di pubblicare online ogni modifica privata e non dà automaticamente accesso all’abbonamento di assistenza dello sviluppatore o a un account cloud. Queste distinzioni contano quando installi un plugin WordPress, sviluppi un’applicazione o condividi un programma modificato.

Che cosa significa la licenza GPL per la tua copia

La GNU GPL è pubblicata dalla Free Software Foundation. GNU identifica il progetto da cui nasce la licenza; GPL è il nome della licenza stessa. Le espressioni inglesi “GPL license” e “GPL licence” indicano lo stesso concetto, con grafie diverse. Le condizioni effettive dipendono dalla versione e dall’avviso di licenza associato al software.

Nel software libero, libero descrive le libertà dell’utente, non un prezzo necessariamente pari a zero. È possibile chiedere un compenso per un programma coperto dalla GPL. Quando ricevi una copia con questa licenza, averla pagata non elimina i diritti che la licenza ti concede. GNU chiarisce la distinzione nella sua definizione di software libero.

Questi diritti rendono possibili diverse attività comuni:

• Eseguire il software: usarlo per i tuoi scopi, anche in un’attività commerciale.
• Studiarlo: esaminare il sorgente per comprenderne il funzionamento.
• Modificarlo: adattare il codice alle tue esigenze.
• Condividerlo: ridistribuire le copie consentite, comprese le versioni modificate, rispettando le condizioni GPL applicabili.

Una piccola impresa, per esempio, può utilizzare un’applicazione GPL per gestire i propri dati interni. Uno sviluppatore può modificare una funzione per adattarla a un diverso flusso di lavoro. Un distributore può fornire copie insieme a un servizio di installazione. La licenza permette queste attività, ma gli obblighi cambiano in base a ciò che viene condiviso.

Leggere la licenza è quindi più utile che chiedere soltanto se un programma sia “gratis”. Verifica quali parti copre l’avviso, quale versione GPL si applica e se altri componenti prevedono condizioni separate.

Il copyleft mantiene i permessi insieme al software

Il codice coperto dalla GPL rimane protetto dal diritto d’autore. Gli autori concedono permessi soggetti a condizioni attraverso una licenza. Il software GPL è quindi diverso dal software messo nel pubblico dominio.

Il copyleft impedisce a chi distribuisce un’opera derivata coperta dalla licenza di negare ai destinatari le libertà GPL associate a quell’opera. Tutela la possibilità, anche per chi riceve la copia successiva, di lavorare sul programma. Non riserva questa possibilità soltanto al primo destinatario. La spiegazione del copyleft di GNU descrive il meccanismo.

Immagina un esempio: un’applicazione GPL per pianificare appuntamenti, della quale migliori la visualizzazione dei fusi orari. Puoi usare privatamente la tua copia modificata. Se distribuisci quell’applicazione modificata e coperta dalla licenza, devi rispettare i requisiti GPL pertinenti all’opera distribuita. Un avviso del tipo “puoi usarla, ma non puoi mai ridistribuirla” sarebbe in conflitto con i diritti che i destinatari devono ricevere.

Questo non significa che ogni file estraneo al programma presente sul tuo computer diventi coperto dalla GPL. Il fatto che un codice costituisca un’opera derivata o combinata coperta dipende dal suo rapporto con il programma GPL. La semplice condivisione di un dispositivo di archiviazione o di un server con un’altra applicazione non risolve la questione. Per integrare librerie o creare prodotti combinati, occorre esaminare l’architettura concreta e prendere una decisione sulle licenze.

Usare e distribuire software sono azioni diverse

La domanda più utile è: stai dando a qualcuno una copia del software coperto dalla licenza? L’eventuale pagamento è una questione separata.

La GPLv3 usa il termine convey, traducibile in questo contesto come trasferire o fornire copie, per le attività che permettono ad altri di creare o ricevere copie. Distingue esplicitamente queste attività dall’interazione attraverso una rete senza trasferimento di una copia. La GPLv2 usa il linguaggio della distribuzione. Le sezioni 0–2 del testo GPLv3 contengono queste definizioni e i permessi fondamentali.

Un programma di installazione, un archivio scaricabile o un pacchetto di codice eseguito sul dispositivo dell’utente possono cambiare l’analisi, perché l’utente potrebbe ricevere del software. Anche consegnare un pacchetto modificato a un’organizzazione distinta è diverso dal conservarlo sulla propria macchina. La tabella aiuta a orientarsi; non decide ogni possibile rapporto con collaboratori esterni, gruppi societari o configurazioni di distribuzione.

La GPL richiede di rendere pubblico il codice sorgente?

La GPL non impone un obbligo universale di caricare ogni modifica in un repository pubblico. Quando distribuisci software coperto, devi rispettare le regole di accesso al sorgente della versione applicabile e del metodo di distribuzione scelto.

C’è una precisazione importante: alcune modalità consentite basate su un’offerta scritta vanno oltre il compratore immediato. La sezione 3(b) della GPLv2, per esempio, descrive un’offerta di fornire il sorgente a qualsiasi terzo. Anche dire “il sorgente viene sempre fornito soltanto ai clienti” è quindi troppo categorico. Leggi le condizioni della modalità che usi nella sezione 3 del testo GPLv2.

Per un distributore, la domanda pratica migliore è questa: chi ha diritto al sorgente corrispondente può ottenere davvero il sorgente corretto per quella copia? Un riferimento generico al progetto originale è meno preciso di un sistema di consegna chiaro e coerente con la versione distribuita.

Che cos’è il sorgente corrispondente?

Il sorgente è la forma del lavoro che gli sviluppatori usano per modificarlo. Secondo GPLv3, il sorgente corrispondente comprende il materiale necessario per generare, installare, eseguire e modificare il codice oggetto coperto, fatte salve le esclusioni definite dalla licenza.

Consideriamo un distributore che modifica la logica di elaborazione di un’applicazione e invia ai clienti una versione compilata. Fornire soltanto il sorgente originale del progetto lascerebbe fuori la modifica ricevuta dai clienti. Il materiale sorgente deve corrispondere a quella versione compilata e includere il materiale pertinente per compilarla. L’esempio riguarda la coerenza tra la copia distribuita e il suo sorgente; le modalità precise di consegna dipendono comunque dalla licenza applicabile.

Conta anche preservare il testo della licenza e gli avvisi pertinenti. Una cartella di sorgenti leggibili non sostituisce questi requisiti. Gestisci sorgente, avvisi e metodo di distribuzione come parti di un’unica attività di rilascio.

GPLv2 e GPLv3: leggi l’avviso prima di scegliere

GPLv2 e GPLv3 sono versioni distinte della GNU GPL. La GPLv2 risale al 1991; la GPLv3 al 2007. Entrambe sono licenze copyleft, ma il loro testo e i loro requisiti non sono intercambiabili. Una licenza più recente non sostituisce automaticamente quella associata a un programma già esistente.

GPLv3 include disposizioni esplicite sui brevetti, disposizioni di compatibilità riviste e requisiti sulle informazioni di installazione in determinate circostanze riguardanti gli User Products, i prodotti per l’utente definiti dalla licenza. Questi cambiamenti affrontano situazioni che vanno oltre il semplice download del sorgente. La guida rapida GNU alla GPLv3 spiega le differenze.

I requisiti sulle informazioni di installazione si prestano facilmente a generalizzazioni errate. GPLv3 non impone a ogni venditore di software di consegnare tutte le password operative. La sua sezione 6 riguarda codice oggetto coperto fornito all’interno di, insieme a, oppure specificamente per l’uso in determinati User Products, secondo condizioni ed eccezioni precise. La distinzione conta per prodotti che potrebbero altrimenti impedire al destinatario di installare una versione modificata.

Per la maggior parte dei lettori, il primo passo è più semplice: trovare l’avviso di licenza del programma.

• Solo GPLv2: il permesso si limita a quella versione, salvo altri permessi applicabili.
• GPLv2 o successiva: l’avviso consente di scegliere GPLv2 o una versione successiva pubblicata dalla FSF.
• Solo GPLv3: il programma è distribuito con GPLv3, senza un’opzione generale per le versioni successive.

Codice “solo GPLv2” e codice GPLv3 non sono automaticamente compatibili per un’opera combinata. Un avviso “GPLv2 o successiva” può offrire la possibilità di usare GPLv3. L’elenco GNU sulla compatibilità delle licenze chiarisce questa differenza.

Non dedurre “o successiva” da un titolo sul sito che dice soltanto GPL. Se il pacchetto ha più dipendenze, controlla anche i loro avvisi. Il permesso di usare una versione successiva per un componente non riscrive la licenza di tutte le dipendenze.

GPL, LGPL, AGPL e MIT rispondono a esigenze diverse

Questi nomi descrivono accordi di licenza diversi. Conoscere la differenza fondamentale aiuta a trovare il testo giusto, senza considerare equivalenti tutte le licenze open source.

La Lesser General Public License è usata spesso per le librerie. Non permette di ignorarne le condizioni di licenza. La sezione 4 della LGPLv3, per esempio, include condizioni riguardanti le opere combinate, gli avvisi e la possibilità per l’utente di lavorare con una libreria modificata.

La Affero General Public License affronta più direttamente l’interazione a distanza. La sezione 13 della AGPLv3 richiede che una versione modificata offra in modo evidente il sorgente corrispondente agli utenti che interagiscono con essa a distanza attraverso una rete informatica. La normale GPLv3 non crea lo stesso obbligo per il solo fatto che un programma funzioni su un server.

La licenza MIT consente un ampio riutilizzo, imponendo di preservare il suo avviso di copyright e di autorizzazione. In generale, il codice con licenza MIT può essere incorporato in un progetto coperto dalla GPL se vengono rispettate queste condizioni. Questo non trasforma il codice già coperto dalla GPL in codice MIT e non elimina gli obblighi GPL dell’opera combinata.

Non esiste una licenza migliore in ogni situazione. Per l’autore, la scelta riflette come vuole che avvenga la condivisione successiva. Per chi usa un progetto esistente, i permessi disponibili dipendono anzitutto dalla licenza effettivamente concessa dai titolari del diritto d’autore.

Quando la GPL può vincolare un progetto

Il vincolo principale si presenta quando le condizioni di distribuzione che vuoi imporre sono in conflitto con il copyleft. Se vuoi fornire ai destinatari di un’opera combinata coperta soltanto il codice eseguibile, vietando di ridistribuirlo o di accedere al sorgente corrispondente, la GPL potrebbe non essere adatta a quel piano di rilascio. Anche preparare il sorgente e verificare la compatibilità delle dipendenze richiede tempo nel processo di rilascio.

La scelta pratica riguarda la tutela delle libertà dei destinatari rispetto al mantenimento di particolari restrizioni di distribuzione. Non impedisce di costruire un’attività commerciale intorno al software. Valuta questo equilibrio prima di incorporare un componente GPL in un prodotto che intendi consegnare, evitando di scoprire impegni incompatibili al momento del rilascio.

Che cosa significa GPL per WordPress, plugin e temi

WordPress dichiara che il proprio software è distribuito con GPLv2 o successiva. La sua pagina ufficiale sulla licenza spiega anche la posizione del progetto: plugin e temi sono opere derivate. La stessa pagina riconosce le zone grigie giuridiche nella definizione di opera derivata.

Per questo la GPL compare così spesso nelle discussioni sulle estensioni WordPress. Permette di condividere il software coperto nel rispetto delle proprie condizioni, anche attraverso la distribuzione commerciale. Tuttavia, il nome di un prodotto o l’etichetta di un marketplace non descrivono tutti gli aspetti di un pacchetto specifico.

Quando valuti un plugin, distingui tre elementi:

1. La licenza di diritto d’autore: quali permessi si applicano al codice coperto?
2. Il pacchetto consegnato: quali file e risorse con licenze separate sono effettivamente inclusi?
3. I servizi: chi fornisce download, aggiornamenti, assistenza ed eventuali funzioni ospitate su server esterni?

La chiave di un account dello sviluppatore può controllare l’accesso a un servizio o a un canale di aggiornamento. È una questione diversa dal permesso di diritto d’autore associato al codice che hai ricevuto. La GPL in sé non promette un account del fornitore, un servizio remoto a pagamento o assistenza futura.

Anche i requisiti delle directory WordPress hanno un ambito specifico. Le linee guida della Plugin Directory richiedono che codice, dati e immagini inviati usino licenze compatibili con la GPL. Si tratta di una regola della directory, non della prova che ogni archivio scaricabile altrove abbia contenuti o diritti identici.

Se vuoi capire concretamente che cosa include un download WordPress fornito da terzi, leggi la guida ai pacchetti di plugin WordPress con licenza GPL. Approfondisce la scelta del pacchetto e dei servizi. Questa spiegazione generale riguarda invece la licenza, senza confrontare venditori o singoli plugin.

Quattro esempi per capire meglio i confini

Gli scenari seguenti sono illustrativi. Mostrano quale fatto cambia la domanda da porsi; non descrivono test di prodotti.

Un negozio usa un’applicazione GPL al proprio interno

Un negozio installa uno strumento GPL per la gestione del magazzino e lo usa per tenere traccia delle scorte. Fa pagare ai clienti i prodotti fisici. Questa attività commerciale non distribuisce, di per sé, l’applicazione di magazzino. L’azione pertinente al software è l’esecuzione del programma, consentita dalla GPL anche per scopi commerciali.

Il negozio dovrebbe comunque conservare un registro del software installato e della sua licenza. Se in seguito fornisce l’applicazione a un’altra organizzazione, quella nuova azione richiede una verifica degli obblighi di distribuzione.

Uno sviluppatore condivide un’applicazione modificata con un cliente

Uno sviluppatore cambia il formato dei report di un’applicazione GPL e consegna l’applicazione modificata a un cliente. Il cliente riceve una copia del software: occorre quindi rispettare i requisiti di distribuzione applicabili. Il pagamento del lavoro di sviluppo non li elimina.

Prima della consegna, lo sviluppatore dovrebbe individuare le modifiche coperte, mantenere gli avvisi necessari e predisporre il sorgente corrispondente. Un contratto può descrivere il lavoro e l’assistenza, ma non dovrebbe promettere restrizioni in conflitto con i diritti GPL trasmessi al cliente.

Un sito usa software GPL sul server

Un’azienda modifica un programma GPLv3 per eseguire calcoli sul proprio server. I visitatori inviano dati e ricevono risultati senza ricevere una copia del programma. La sola interazione di rete non costituisce convey secondo GPLv3.

Cambiamo ora un fatto: il sito invia codice del programma coperto ai dispositivi dei visitatori. Torna la questione della distribuzione. Cambiamone un altro: il programma sul server usa AGPLv3 ed è stato modificato dall’azienda. Diventa pertinente la disposizione AGPL sul sorgente per gli utenti di rete. Dire soltanto “è un sito web” non basta quindi per identificare gli obblighi applicabili.

Un designer crea contenuti con uno strumento GPL

Un designer usa un’applicazione grafica GPL per realizzare un’illustrazione originale. La licenza GPL dell’applicazione non rende automaticamente GPL l’illustrazione. Conta il contenuto del risultato: GPLv3 copre l’output solo quando quell’output costituisce a sua volta un’opera coperta.

Il designer dovrebbe verificare separatamente i font, i modelli e le risorse usati nell’illustrazione. La licenza dello strumento di modifica e i permessi per questi elementi sono fatti diversi. GNU affronta il principio nelle sue FAQ sull’output dei programmi.

Come usare la GPL per il tuo software

Non ottieni la GPL acquistando una speciale chiave di attivazione. Se disponi dei necessari permessi di diritto d’autore, puoi distribuire il tuo software con questa licenza. La guida GNU all’applicazione delle licenze descrive il procedimento.

Inizia individuando il codice sul quale puoi decidere. Un progetto può includere contributi, lavori appartenenti al datore di lavoro, dipendenze e risorse con diritti diversi. Scegliere GPL per i tuoi file originali non ti autorizza a cambiare la licenza del materiale altrui.

Scegli poi la versione e decidi se il tuo avviso consentirà le versioni successive. Includi il testo completo della licenza e gli avvisi appropriati con il sorgente. Rendi visibile la scelta nella documentazione del progetto e prepara la modalità di accesso al sorgente prevista per la distribuzione prima di fornire versioni compilate.

Per una piccola utilità scritta interamente da un solo autore, il lavoro concreto può essere semplice: aggiungere un file di licenza, applicare gli avvisi pertinenti e pubblicare il sorgente con istruzioni di compilazione chiare. Un progetto più grande, con dipendenze, richiede una verifica componente per componente. Copiare l’etichetta GPL nel README non basta se il contenuto del pacchetto racconta una storia diversa.

Risposte brevi ad altre domande sulla GPL

Si può vendere software con licenza GPL?

Sì. La GPL consente la distribuzione a pagamento del software coperto quando vengono rispettate le sue condizioni. Gli acquirenti ricevono i diritti GPL applicabili, inclusi quelli di ridistribuzione. La guida GNU alla vendita di software libero spiega come il pagamento e la tutela delle libertà possano coesistere.

GPL e open source sono la stessa cosa?

La GPL è una licenza open source, ma l’open source comprende altre licenze con condizioni diverse. Una licenza permissiva come MIT e una licenza copyleft come GPL permettono entrambe la collaborazione sul sorgente, stabilendo però regole diverse per la distribuzione successiva.

La GPL permette di usare il marchio di un progetto?

I permessi relativi al diritto d’autore sul software non risolvono automaticamente la questione dei marchi. Ridistribuire il codice non autorizza necessariamente a dichiarare che lo sviluppatore originale approva la tua versione. WordPress, per esempio, ha una politica sui marchi separata.

Un’etichetta GPL dimostra che un download è sicuro?

No. Le condizioni di licenza descrivono permessi e obblighi. Non dimostrano l’origine, l’integrità o la manutenzione di un singolo archivio. Queste verifiche restano separate, sia per software GPL, sia per software con licenza permissiva o proprietaria.

Parti dalla copia e dall’azione

Per applicare questa spiegazione a un progetto reale, registra l’avviso di licenza del software, identifica ciò che intendi fare e determina se qualcuno riceverà codice coperto. Controlla poi le condizioni previste per quella versione e per il metodo di distribuzione.

Per un acquisto WordPress, aggiungi una verifica distinta del pacchetto e dei servizi necessari. Per un rilascio di software, controlla le dipendenze e il sorgente corrispondente. Questi fatti concreti ti diranno molto più della sola parola GPL.