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

GPL vs MIT vs Apache: cosa richiede ciascuna licenza

GPL, MIT e Apache 2.0 rispondono alla stessa domanda in modi diversi: quali obblighi hai nei confronti degli altri quando distribuisci il software? MIT richiede un avviso di copyright e nient'altro. Apache 2.0 richiede lo stesso avviso e aggiunge un accordo sui brevetti tra tutti coloro che modificano o distribuiscono il codice. La GPL richiede di pubblicare il codice sorgente di ciò che hai costruito sopra il software, secondo 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. A quel punto diventa una questione operativa. Devi scegliere tra due repository di pacchetti e gestire librerie client che smettono di comunicare tra loro. Questa guida tratta le licenze e il loro funzionamento, non il movimento che le ha create. Per questo, ogni sezione arriva fino alle conseguenze pratiche per te: la persona che deve eseguire l'upgrade.

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ì un percorso diverso. 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 aveva quattro clausole. La quarta, detta clausola pubblicitaria, richiedeva di citare l'Università in tutto il materiale pubblicitario che menzionasse funzionalità del software. Questo approccio non è scalabile. Stallman contò 75 citazioni separate in una versione del 1997 di NetBSD. UC Berkeley ritirò la clausola il 22 July 1999, in una lettera di William Hoskins dell'Office of Technology Licensing.

Ciò che resta è la licenza BSD a 3 clausole, che aggiunge il divieto di usare i nomi dei contributori per sostenere 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 nella 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 un patrimonio comune che non potesse essere reso proprietario. Entrambe le posizioni sono legittime e entrambe presentano un punto debole. Il codice con licenza permissiva 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 deriva una seconda lezione, ed è quella a cui questo articolo torna continuamente. Nel 1992 AT&T's Unix System Laboratories citò in giudizio Berkeley Software Design per il codice BSD e il caso si concluse con un accordo all'inizio del 1994. Per 2 anni nessuno poteva essere certo che fosse sicuro basarsi su BSD e l'adozione si bloccò mentre Linux cresceva. L'incertezza giuridica 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 delle nuove licenze: SSPL, BUSL e ciò che non sono

L’impulso era commerciale. Un’azienda detiene il copyright di un prodotto, un cloud provider lo vende su larga scala come servizio gestito e restituisce pochi contributi; l’azienda modifica quindi la licenza per impedirlo. Redis Labs ha compiuto il primo passo 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 i software di gestione e orchestrazione che lo circondano. L’ambito di questo obbligo non ha confini chiari e nessun tribunale lo ha ancora esaminato. 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 essere incluso nel proprio archivio. 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 è il risultato operativo di una modifica della licenza: la distribuzione smette di pacchettizzare il software e gli aggiornamenti arrivano dal repository del fornitore, secondo i tempi stabiliti dal fornitore.

La Business Source License è uno strumento diverso. È stata ideata 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 è gratuito, salvo l’uso escluso dal fornitore, che normalmente consiste nell’esecuzione di un servizio hosted concorrente. Ogni release passa automaticamente a una vera licenza open source in una data prestabilita, non oltre quattro anni dalla release. La licenza di conversione deve essere compatibile con GPLv2. 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: eseguirla 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 della licenza

Il 14 January 2021 Elastic ha annunciato che Elasticsearch e Kibana sarebbero passati da Apache 2.0 a una scelta tra SSPL ed 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 Apache 2.0 di entrambi i progetti. Il fork è stato denominato OpenSearch il 12 April 2021, mentre Kibana è stato rinominato OpenSearch Dashboards. OpenSearch 1.0 è diventato generalmente disponibile il 12 July 2021, a partire da Elasticsearch 7.10.2 e Kibana 7.10.2.

Consideriamo il costo per chi gestiva i cluster. Sono cambiati i nomi dei pacchetti e i repository. Ogni riferimento a Kibana nei runbook è 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 server non è Elasticsearch, segnalando che il prodotto del server è sconosciuto. Una decisione sulla licenza presa da un'azienda per cui non lavorate è diventata una chiamata non riuscita nella vostra applicazione.

La situazione è cambiata altre due volte. Il 29 August 2024 Elastic ha aggiunto AGPLv3 come terza opzione di licenza, quindi Elasticsearch attuale è di nuovo open source approvato da OSI. Il 16 September 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. Cinque anni dopo la separazione, entrambi i progetti sono open source, entrambi sono mantenuti e, ad August 2026, OpenSearch è nella serie 3.x.

La conclusione è l'insegnamento principale. La licenza è tornata, ma il fork è rimasto. Quando un ecosistema ha due versioni di ogni componente, correggere la documentazione legale non li riunisce.

Il numero che determina quanto pesa un cambio di licenza è l'intervallo tra l'annuncio e un fork stabile effettivamente distribuibile.

[
  {
    "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 vendor alla prima release stabile del fork, usando le date elencate di seguito. OpenSearch 1.0 ha richiesto 179 giorni, perché il fork doveva essere rinominato e ricostruito senza un fork precedente da cui partire. 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. L'aspetto importante è 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.