GPL, MIT o Apache: cosa cambia per chi distribuisce codice

GPL, MIT e Apache: cosa richiede ciascuna licenza

GPL, MIT e Apache 2.0 rispondono alla stessa domanda in modi diversi: che cosa devi agli altri quando distribuisci il software? MIT richiede un avviso di copyright e nient'altro. Apache 2.0 richiede lo stesso avviso, oltre a un accordo sui brevetti con tutti coloro che contribuiscono al codice. GPL richiede di pubblicare il codice sorgente di ciò che hai realizzato sopra il software, con la stessa licenza con cui lo hai ricevuto.

Sembra una questione per avvocati, fino al giorno in cui un progetto che gestisci cambia licenza e si divide in due. Da quel momento diventa una questione operativa. Devi scegliere tra due repository di pacchetti e gestire librerie client che non comunicano più tra loro. Questa guida tratta le licenze e i relativi meccanismi, non il movimento che le ha prodotte. Per questo ogni sezione si conclude con le conseguenze per te: la persona che deve eseguire l'aggiornamento.

Perché esiste la GPL: una stampante che nessuno poteva riparare

Intorno al 1980, il MIT Artificial Intelligence Lab ricevette una stampante laser Xerox 9700. Il laboratorio aveva modificato il software di una stampante precedente, in modo che segnalasse quando un processo di stampa si bloccava. Per il nuovo modello non era disponibile il codice sorgente e la richiesta di ottenerlo fu respinta a causa di un accordo di riservatezza. Richard Stallman, allora programmatore del laboratorio, considerò quel rifiuto un problema generale e non un semplice episodio sfortunato, quindi annunciò il progetto GNU il 27 settembre 1983.

Il copyleft si basa sulla normativa sul copyright, non la elude. Per impostazione predefinita, non si ha alcun diritto di copiare il codice di altri. La GPL concede questo diritto a una condizione: se si distribuisce il programma a qualcun altro, è necessario fornire anche il codice sorgente, secondo gli stessi termini, affinché possa fare ciò che il laboratorio non aveva potuto fare. La condizione è applicabile perché, senza la licenza, non si disponeva inizialmente di alcuna autorizzazione.

Stallman scrisse prima una licenza per GNU Emacs, poi la generalizzò nella GPL version 1 il 25 febbraio 1989. La GPL version 2 seguì nel giugno 1991 ed è ancora la licenza della maggior parte del software di sistema eseguito. La Lesser GPL fu introdotta per le librerie, così una libreria copyleft poteva essere collegata da un programma soggetto a qualsiasi licenza senza assoggettare quel programma alla GPL.

Un dettaglio determina il modo in cui la GPL incide su chi gestisce servizi self-hosted. L'obbligo scatta con la distribuzione, non con l'uso. È possibile modificare un programma GPL, eseguirlo sul proprio server e usarlo per fornire un servizio al pubblico senza dover fornire nulla a nessuno, perché non si è mai distribuita una copia. Questa lacuna è il motivo per cui esiste la AGPL.

La tradizione permissiva: BSD, poi MIT

Berkeley seguì una strada diversa. Il Computer Systems Research Group distribuì il proprio lavoro su Unix con una licenza che richiedeva di conservare l'avviso di copyright e declinava ogni garanzia. La versione originale conteneva quattro clausole. La terza, la clausola pubblicitaria, richiedeva di citare l'Università in ogni materiale pubblicitario che menzionasse funzionalità del software. Questo approccio non è scalabile. Stallman contò 75 citazioni separate in una versione di NetBSD del 1997. UC Berkeley ritirò la clausola il 22 July 1999, con una lettera di William Hoskins del suo Office of Technology Licensing.

Rimangono la licenza BSD a 3 clausole, che conserva il divieto originale di usare i nomi dei contributori per promuovere il proprio prodotto, e la versione a 2 clausole, che elimina anche questo divieto. Il testo della licenza MIT nacque al MIT negli anni 1980, dove disciplinava X Window System, e in pratica svolge la stessa funzione della BSD a 2 clausole.

Le motivazioni erano diverse. Un'università finanziata con denaro pubblico voleva che il proprio lavoro fosse usato ovunque, anche dalle aziende. Il progetto GNU voleva creare un bene comune che non potesse essere reso proprietario. Entrambe le posizioni sono legittime, ed entrambe hanno un punto debole. Il codice permissivo può diventare proprietario e non si riceve nulla in cambio. Il codice copyleft viene rifiutato dalle aziende i cui legali non accettano questa condizione.

Da Berkeley si ricava una seconda lezione, ed è quella a cui questo articolo ritorna continuamente. AT&T's Unix System Laboratories fece causa a Berkeley Software Design nel 1992 per il codice BSD, e il procedimento si concluse con un accordo all'inizio del 1994. Per due anni nessuno poteva essere certo che fosse sicuro basarsi su BSD, e l'adozione si arrestò mentre Linux cresceva. L'incertezza legale blocca l'adozione più rapidamente di una funzionalità mancante.

Perché Apache 2.0 ha aggiunto una concessione di brevetto

La prima licenza dell'Apache Group era una derivazione della BSD a 4 clausole con lo stesso problema relativo alla pubblicità. La versione 1.1, del 2000, ha rimosso quella clausola. La versione 2.0, pubblicata nel gennaio 2004, era una riscrittura e non una semplice modifica.

L'aggiunta importante riguarda i brevetti. Le licenze MIT e BSD non stabiliscono nulla al riguardo. Un contributore può concedere un'autorizzazione chiara sul copyright del proprio codice e detenere comunque un brevetto applicabile a ciò che il codice esegue, per poi citare in giudizio chi lo utilizza. Apache 2.0 elimina questa lacuna: ogni contributore concede una licenza sui brevetti relativa al proprio contributo e chiunque faccia causa sostenendo che l'opera viola i propri brevetti perde la licenza sui brevetti concessa per quell'opera. La tutela è reciproca, quindi nella pratica nessuno avvia un contenzioso.

Il resto della versione 2.0 riguarda gli aspetti amministrativi, ed è per questo che piace alle aziende. È definito un file NOTICE, quindi le informazioni sull'attribuzione hanno un unico punto di riferimento invece di essere distribuite nell'albero dei sorgenti. La licenza può essere applicata tramite un riferimento, invece di essere incollata in ogni file sorgente. I contributi sono disciplinati da condizioni esplicite. I marchi sono esclusi. Una revisione legale di una dipendenza Apache 2.0 trova già nel testo una risposta a ogni domanda prevista, quindi l'approvazione diventa una procedura ordinaria: è questo, in gran parte, il significato di "impostazione predefinita aziendale".

Cosa ha cambiato la GPLv3 e perché Linux è rimasto alla GPLv2

TiVo ha distribuito un videoregistratore che eseguiva Linux e ha pubblicato il codice sorgente del kernel, esattamente come richiede la GPLv2. All'avvio, però, l'hardware verificava una firma crittografica e rifiutava di eseguire un kernel che non riconosceva. Era possibile leggere il codice sorgente, modificarlo e compilarlo. Non era possibile eseguirlo sul dispositivo da cui proveniva. La licenza era rispettata alla lettera, ma il suo scopo veniva vanificato. Questa pratica ha assunto il nome di tivoisation.

La versione 3 della GPL, pubblicata il 29 June 2007, risponde direttamente a questo problema. Quando distribuisci il binario all'interno di un dispositivo destinato ai consumatori, devi fornire anche le "Installation Information": le chiavi o le istruzioni necessarie per installare una versione modificata e farla eseguire. La versione 3 ha inoltre introdotto una concessione esplicita di brevetto, clausole formulate in risposta all'accordo sui brevetti tra Microsoft e Novell del November 2006 e la compatibilità unidirezionale con Apache 2.0.

Linux non ha seguito questo percorso. Il kernel è disponibile esclusivamente con GPL version 2, senza la clausola di estensione "or any later version", e il suo file COPYING lo specifica. Linus Torvalds si è opposto pubblicamente alle clausole anti-tivoisation per l'hardware con verifica della firma. L'ostacolo pratico è più ampio del disaccordo: il kernel ha migliaia di titolari del copyright, quindi nessuno potrebbe raccogliere le autorizzazioni necessarie per cambiare licenza, anche se tutti fossero d'accordo. Questo singolo fatto è la protezione più forte che un progetto possa avere. Vale la pena ricordarlo quando si valuta un progetto controllato da una sola azienda.

L'altra licenza del 2007 ha conseguenze più dirette per te. La GNU Affero GPL version 3, pubblicata a November dello stesso anno, estende l'obbligo di fornire il codice sorgente alle persone che interagiscono con il programma attraverso una rete. Se esegui per il pubblico un servizio AGPL modificato, devi fornire il codice sorgente a quegli utenti. Per questo molto software web self-hosted usa la licenza AGPL. Nextcloud è un esempio. Se stai confrontando le alternative self-hosted a Nextcloud, la riga relativa alla licenza nel repository di ciascun candidato ti dice più sui suoi prossimi cinque anni di quanto faccia l'elenco delle funzionalità.

Quali licenze si possono effettivamente combinare?

La compatibilità funziona in una sola direzione: dalle licenze permissive verso quelle copyleft.

• Il codice MIT e BSD può essere incluso in qualsiasi progetto, compreso un prodotto proprietario.
• Il codice Apache 2.0 può essere incluso in un progetto GPLv3; l'opera risultante è soggetta alla GPLv3.
• Il codice Apache 2.0 non può essere incluso in un progetto soggetto esclusivamente alla GPLv2. Le clausole relative alla cessazione dei diritti sui brevetti e all'indennizzo costituiscono condizioni aggiuntive che la GPLv2 non consente di aggiungere. Sia la FSF sia la ASF pubblicano questa conclusione.
• Non puoi trasferire il codice GPL a una licenza permissiva. Solo i titolari del copyright possono farlo; si torna quindi alla domanda su chi siano.

L’era della relicenza: SSPL, BUSL e ciò che non sono

La causa scatenante era commerciale. Un’azienda detiene il copyright su un prodotto, un cloud provider lo vende su larga scala come servizio gestito e restituisce poco al progetto, quindi l’azienda modifica la licenza per impedirlo. Redis Labs ha compiuto la prima mossa visibile nell’agosto 2018, aggiungendo la Commons Clause alla licenza Apache 2.0 per diversi moduli. MongoDB ha seguito l’esempio il 16 ottobre 2018, passando da AGPLv3 alla Server Side Public License.

La SSPL è la AGPL con una sezione riscritta. Se offri il programma a terzi come servizio, devi pubblicare il codice sorgente di tutto ciò che usi per offrirlo, compresi il software di gestione e quello di orchestrazione che lo circondano. Il perimetro di questo obbligo non è definito con chiarezza e nessun tribunale lo ha ancora verificato. L’OSI non ha mai approvato la licenza e MongoDB ha ritirato la propria richiesta nel marzo 2019. Debian aveva già dichiarato nel dicembre 2018 che il software SSPL non doveva entrare nel proprio archivio, mentre Fedora ha stabilito nel gennaio 2019 che la licenza non è libera. In seguito, Red Hat ha rimosso MongoDB da Fedora e da Red Hat Enterprise Linux. Questo è l’effetto pratico di una relicenza: la distribuzione smette di impacchettare il software, quindi gli aggiornamenti arrivano da un repository del fornitore, secondo le tempistiche stabilite dal fornitore.

La Business Source License è uno strumento diverso. È nata dai fondatori di MariaDB e la versione 1.1 risale al 2017. Non è una licenza copyleft e non è open source. Il codice sorgente è pubblico e l’uso non produttivo è gratuito. L’uso in produzione è consentito solo nei limiti dell’Additional Use Grant del fornitore, che normalmente vieta l’esecuzione di un servizio hosted concorrente. Ogni release passa automaticamente a una vera licenza open source in una data di conversione non oltre quattro anni dalla release. La licenza di destinazione deve essere la GPL versione 2.0 o una versione successiva, oppure una licenza compatibile con una di esse. HashiCorp ha trasferito Terraform e gli altri suoi prodotti a BUSL 1.1 il 10 agosto 2023. La usa anche Outline, un aspetto utile da conoscere se stai scegliendo tra le alternative self-hosted a Notion: eseguirlo per il proprio team è consentito, mentre costruirci sopra un servizio non lo è.

Nessuna delle due licenze è ingannevole. Entrambe dichiarano chiaramente di rendere disponibile il codice sorgente. Nessuna è open source secondo la definizione dell’OSI e la differenza ricade su di te, non sul cloud provider a cui erano rivolte.

OpenSearch: quanto costa all’operatore un fork dovuto al cambio di licenza

Il 14 gennaio 2021 Elastic ha annunciato che Elasticsearch e Kibana avrebbero abbandonato Apache 2.0 per adottare SSPL oppure Elastic License, a partire dalla release 7.11. La versione 7.10.2 è stata l’ultima release con licenza Apache 2.0. Circa una settimana dopo, AWS ha dichiarato che avrebbe creato e mantenuto un fork con licenza Apache 2.0 di entrambi i progetti. Il 12 aprile 2021 il fork ha ricevuto il nome OpenSearch e Kibana è stato rinominato OpenSearch Dashboards. OpenSearch 1.0 è diventato disponibile a tutti il 12 luglio 2021, a partire da Elasticsearch 7.10.2 e Kibana 7.10.2.

Consideriamo il costo sostenuto da chi gestiva i cluster. Sono cambiati i nomi dei pacchetti e dei repository. Ogni riferimento a Kibana presente nelle procedure operative è diventato un riferimento a OpenSearch Dashboards. Sono cambiati anche i nomi dei plugin. Poi la separazione ha raggiunto il codice applicativo: dalla versione 7.13 delle librerie client ufficiali di Elastic, il client verifica a quale prodotto si è connesso e rifiuta di proseguire se il prodotto non è Elasticsearch, segnalando che il server è un prodotto sconosciuto. Una decisione sulla licenza presa da un'azienda per cui non lavorate si è trasformata in una chiamata non riuscita all'interno della vostra applicazione.

La storia ha poi cambiato direzione altre due volte. Il 29 agosto 2024 Elastic ha annunciato l'aggiunta di AGPLv3 come terza opzione di licenza. La FAQ sulle licenze indica settembre 2024 come momento dell'aggiunta. Elasticsearch attuale è quindi nuovamente open source con approvazione OSI. Il 16 settembre 2024 AWS ha trasferito OpenSearch alla OpenSearch Software Foundation, ospitata dalla Linux Foundation. Il fork ha così ottenuto una struttura di governance che non dipende da una singola azienda. A cinque anni dalla separazione, entrambi i progetti sono open source e mantenuti. A ottobre 2026 OpenSearch è nella serie 3.x.

La conclusione è l'insegnamento principale. La licenza è tornata, ma il fork è rimasto. Quando un ecosistema ha due componenti per ogni elemento, correggere i documenti non li riunisce.

Il numero che determina l'impatto di un cambio di licenza è l'intervallo tra l'annuncio e una versione stabile del fork che si possa realmente distribuire.

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

Ogni intervallo è calcolato dall'annuncio pubblico del fornitore alla prima release stabile del fork, usando le date riportate di seguito. OpenSearch 1.0 ha richiesto 179 giorni, perché il fork ha dovuto essere rinominato e ricostruito senza poter copiare da un fork precedente. OpenTofu ha richiesto 153 giorni. Valkey ha richiesto 27 giorni, perché è stato derivato da Redis 7.2.4 mantenendo identici il protocollo e il formato su disco. Il dato utile è la direzione: oggi un fork credibile arriva in poche settimane, con una fondazione e maintainer retribuiti fin dal primo giorno.

Valkey e OpenTofu: lo stesso schema, più velocemente

Redis Ltd ha cambiato la licenza di Redis dalla BSD a 3 clausole alla scelta tra RSALv2 e SSPLv1 il 20 marzo 2024. Otto giorni dopo, la Linux Foundation ha annunciato Valkey, un fork di Redis 7.2.4 che mantiene la licenza BSD a 3 clausole. Valkey 7.2.5 è arrivato il 16 aprile 2024 con lo stesso protocollo e gli stessi file di dati; per la maggior parte degli amministratori, quindi, la migrazione consisteva nel cambiare il nome del pacchetto. A maggio 2025 Redis ha aggiunto AGPLv3 come terza opzione in Redis 8. In base alla definizione dell'OSI, Redis è quindi nuovamente open source, mentre Valkey continua a essere gestito secondo il proprio modello di governance. Lo schema è molto simile a quello di Elasticsearch.

Terraform ha seguito lo stesso percorso, con un capitolo aggiuntivo. OpenTofu è nato come fork dell'ultima release con licenza Mozilla Public License 2.0, è entrato nella Linux Foundation a settembre 2023 e ha pubblicato la versione 1.6.0 il 10 gennaio 2024. Il 3 aprile 2024, gli avvocati di HashiCorp hanno inviato al progetto una lettera di diffida, sostenendo che nel fork fosse stato copiato codice proveniente da una release di Terraform con licenza BUSL. OpenTofu ha pubblicato una risposta dettagliata l'11 aprile 2024, negando l'accusa e ricondicendo il codice contestato alla cronologia con licenza MPL condivisa da entrambi i progetti. Non ci sono stati ulteriori sviluppi pubblici. Il rischio concreto da ricordare è questo: una semplice accusa può bloccare l'adozione per un trimestre, con lo stesso effetto prodotto dalla causa legale di Berkeley trent'anni prima.

Non tutti i fork nascono da una questione di licenza. Forgejo è nato come fork di Gitea nel 2022, dopo che lo sviluppo di Gitea è passato sotto il controllo di un'azienda. Si è trattato di una disputa sulla governance, non sulla licenza. Forgejo ha mantenuto la licenza MIT per tutta la serie 8, quindi dalla versione 9.0 del 2024 è passato alla licenza GPLv3 o successiva, per impedire che il suo lavoro venisse reintegrato in un prodotto soggetto al controllo commerciale. Se stai valutando le opzioni per un server Git self-hosted, questa coppia è l'esempio attuale più chiaro di una base di codice e due filosofie.

Il test da eseguire prima di adottare una soluzione

Quattro domande da porsi prima della prima installazione, non dopo.

1. Chi detiene il copyright? Per cambiare licenza serve l'autorizzazione di ogni titolare del copyright, quindi un progetto con centinaia di contributori indipendenti e senza cessione dei diritti non può realisticamente cambiare licenza. Un progetto interamente posseduto da una sola azienda può cambiare licenza durante una riunione del consiglio di amministrazione.
2. Esiste una CLA e che cosa concede? Un contributor licence agreement che consente all'azienda di cambiare a propria discrezione la licenza del contributo è il meccanismo esatto alla base di ogni cambio di licenza descritto sopra. Un DCO (developer certificate of origin), cioè la riga di sign-off adottata dal kernel Linux nel 2004, non trasferisce alcun diritto. Una CLA detenuta da una fondazione è più sicura di una detenuta da un'azienda, perché un'azienda può essere venduta.
3. Chi detiene il marchio? Elastic ha mantenuto il nome Elasticsearch, quindi il fork ha dovuto cambiare nome e riscrivere ogni runbook che menzionava Kibana.
4. Quanto ti costerebbe concretamente cambiare licenza? Considera il formato dei dati, le librerie client, la configurazione da riscrivere e l'eventuale esistenza di un fork compatibile.

Due comandi forniscono una risposta parziale in pochi secondi.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

Ogni pacchetto Debian e Ubuntu include un file in /usr/share/doc/<package>/copyright, che registra la licenza della versione installata, non quella utilizzata oggi dal progetto. Per bash su Ubuntu 24.04, quel file indica la GNU General Public License versione 3. Esegui il secondo comando all'interno di un checkout del codice sorgente per ottenere la cronologia del file della licenza. Un commit degli ultimi due anni merita di essere letto prima di basare qualsiasi soluzione sul progetto. Se il comando non produce output, il repository usa un altro nome per il file della licenza: elenca quindi la directory principale e verifica.

Nessuna licenza ti protegge da ogni possibile esito, e scegliere per ideologia è il modo più semplice per ritrovarsi impreparati. Preferisci progetti il cui copyright sia distribuito tra molti titolari o detenuto da una fondazione, e conserva i dati in un formato che puoi esportare. Individua poi il fork a cui passeresti e annotane il nome prima di averne bisogno. Applicare questo controllo a ogni candidato richiede meno di un'ora e, quando decidi che cosa ospitare autonomamente nel 2026, è ciò che distingue un aggiornamento da una migrazione.

FAQ

La licenza MIT è uguale alla licenza BSD?

Di fatto, la licenza MIT corrisponde alla licenza BSD a 2 clausole: è necessario mantenere l'avviso sul copyright e la clausola di esclusione della garanzia, poi si può fare ciò che si vuole, incluso creare un prodotto proprietario. La licenza BSD a 3 clausole aggiunge una sola condizione: vieta di usare i nomi dei collaboratori per approvare o promuovere il prodotto senza autorizzazione. La versione precedente a 4 clausole richiedeva inoltre un riconoscimento nei materiali pubblicitari. UC Berkeley ha rimosso questa clausola il 22 July 1999, quindi oggi quasi nessun progetto la include ancora.

Posso inserire codice Apache 2.0 in un progetto GPLv2?

No. Apache 2.0 aggiunge condizioni che GPLv2 non consente di aggiungere, soprattutto la clausola di cessazione dei diritti sui brevetti. Di conseguenza, un'opera combinata non può soddisfare contemporaneamente entrambe le licenze. Sia FSF sia ASF pubblicano questa conclusione. La direzione opposta è possibile: il codice Apache 2.0 può essere incluso in un progetto GPLv3, e il risultato è GPLv3. Per lo stesso motivo, il codice Apache 2.0 non può essere integrato nel kernel Linux, che è solo GPL version 2.

SSPL è una licenza open source?

No, e la risposta ha conseguenze pratiche. OSI non l'ha mai approvata e MongoDB ha ritirato la propria richiesta nel March 2019. Debian ha dichiarato nel December 2018 che il software SSPL non doveva essere incluso nel proprio archivio. Fedora ha stabilito nel January 2019 che la licenza non è libera; in seguito Red Hat ha rimosso MongoDB da Fedora e Red Hat Enterprise Linux. Questo significa che un pacchetto precedentemente gestito dalla distribuzione proviene ora da un repository del fornitore, secondo i tempi di supporto stabiliti dal fornitore. Anche la Business Source License rende disponibile il codice sorgente, ma non è open source, sebbene ogni release venga convertita in una licenza open source entro quattro anni.

Una modifica della licenza si applica alla versione che sto già utilizzando?

No. Una licenza concessa con una release non può essere ritirata dalle copie già pubblicate. È esattamente per questo che sono possibili i fork. OpenSearch è stato creato a partire da Elasticsearch 7.10.2, l'ultima release pubblicata da Elastic con licenza Apache 2.0. Ciò che si perde è il futuro, perché la correzione di sicurezza successiva viene rilasciata secondo i nuovi termini. Fissare l'ultima versione con licenza permissiva può offrire qualche mese di tempo, ma non costituisce un piano.