Il ragù di nonna Pina e la GPL: storia del software libero e licenze spiegate in cucina

Giovedì sera, quasi mezzanotte. Hai appena finito ricettario, il tuo primo progetto davvero tuo: un'app che digitalizza il quaderno di nonna Pina, quello con la copertina unta e le dosi scritte in «un bicchiere», «q.b.» e «finché non è pronto». Ci hai messo tre mesi di weekend. Il parser che trasforma «un pugno di farina» in grammi è la cosa di cui vai più fiero in tutta la tua carriera.

Crei il repository su GitHub, e prima di fare il push ti compare un menu a tendina: Choose a license. MIT, Apache 2.0, GPLv3, e una ventina di altre sigle. Sotto, una frase gentile e inutile: «Una licenza dice agli altri cosa possono e non possono fare con il tuo codice.»

Il cursore lampeggia. Ieri sera hai letto la storia del maintainer di gnocco, quello con 11 dollari al mese di sponsor, e adesso quel menu ti sembra molto meno innocente. In quel momento ti scrive proprio nonna Pina, che a 84 anni usa WhatsApp meglio di te: «Allora, chi la può usare la mia ricetta del ragù?»

Bella domanda, nonna. Per rispondere bisogna fare un viaggio. Prima tappa: una stampante inceppata.

1980: la stampante

Immagina di lavorare all'Artificial Intelligence Lab del MIT, nel 1980. Il laboratorio ha appena ricevuto in regalo da Xerox una stampante laser, una 9700: enorme, velocissima, e sistemata in un'altra stanza. Si inceppa spesso. Con la stampante precedente il problema era risolto da tempo: un programmatore del laboratorio, Richard Stallman, aveva modificato il software in modo che avvisasse gli utenti quando la carta si bloccava, e che dicesse a chi aspettava una stampa quando era pronta. Una piccola modifica, fatta in un pomeriggio, che faceva risparmiare a tutti molte camminate a vuoto.

Con la stampante nuova non si può fare. Xerox ha fornito solo i binari, niente sorgenti. Stallman scopre che un ricercatore della Carnegie Mellon ha una copia del codice, va a chiederla, e se la vede rifiutare: quel ricercatore aveva firmato un accordo di riservatezza con Xerox. Non poteva condividere il codice nemmeno con un collega che voleva solo sistemare un inceppamento.

Per te, oggi, è normale. Per un hacker di quel laboratorio era un tradimento: fino ad allora il software girava tra università e centri di ricerca come girano le ricette tra vicine di casa. Chi migliorava qualcosa lo passava agli altri. Ora qualcuno ti dava il piatto, ma ti vietava di sapere com'era fatto, e soprattutto ti vietava di aggiustarlo.

Il 27 settembre 1983 (tra due settimane fanno 42 anni) Stallman annuncia su Usenet il progetto GNU: un sistema operativo compatibile con Unix, completamente libero. Nel 1985 nasce la Free Software Foundation. E il software libero viene definito con quattro libertà, numerate da zero come si conviene a dei programmatori:

• Libertà 0: usare il programma per qualunque scopo.
• Libertà 1: studiare come funziona e modificarlo. Per questo servono i sorgenti.
• Libertà 2: ridistribuirne copie.
• Libertà 3: distribuire le proprie versioni modificate, così che tutti ne beneficino.

Attenzione alla parola. In inglese free vuol dire sia «libero» sia «gratis», e Stallman ha passato quarant'anni a ripetere «free as in free speech, not as in free beer». In italiano siamo fortunati: abbiamo due parole. Il software libero si può vendere. La libertà riguarda cosa puoi fare con il codice, non quanto lo paghi.

Il trucco del copyleft

Restava un problema. Se regali la tua ricetta senza condizioni, chiunque può prenderla, migliorarla, chiuderla in cassaforte e venderla come segreto industriale. È esattamente quello che era successo con la stampante. Serviva un modo per regalare il codice e, allo stesso tempo, impedire che qualcuno lo richiudesse.

La soluzione è un trucco legale geniale: usare il copyright, cioè lo strumento che serve a limitare la copia, per garantirla. L'autore resta titolare dei diritti e concede una licenza che dice, in sostanza: «Puoi fare tutto, a una condizione: se distribuisci questo programma o una sua versione modificata, devi farlo alle stesse condizioni, sorgenti compresi.» Lo hanno chiamato copyleft, gioco di parole su copyright. Nel 1989 diventa la GNU General Public License, la GPL. Nel 1991 arriva la versione 2, quella che conoscerai meglio tra poco.

Il copyleft è una ricetta con una clausola ereditaria. Chi la usa per cucinare qualcosa e poi regala o vende quel piatto, deve dare anche la ricetta, comprese le sue modifiche, e con la stessa clausola. Chi lo critica la chiama «virale». Chi la ama dice che è l'unico modo per far restare libero ciò che nasce libero.

1991: un kernel «per hobby»

A fine anni Ottanta GNU aveva quasi tutto: compilatore (GCC), editor (Emacs), shell, librerie, utility. Mancava il pezzo più difficile, il kernel. Ad agosto 1991 Linus Torvalds, che studia informatica all'Università di Helsinki, annuncia su Usenet che sta scrivendo un sistema operativo, «just a hobby, won't be big and professional like gnu».

La prima licenza di Linux era sua, e vietava l'uso commerciale. A gennaio 1992, nelle note di rilascio della versione 0.12, Torvalds annuncia il passaggio alla GPL, valido dal 1° febbraio. Sarà una scelta decisiva, e il motivo è proprio il copyleft: un'azienda che migliora Linux e distribuisce il risultato deve restituire le modifiche. Le aziende hanno contribuito per convenienza, non per bontà, e il kernel è diventato il più grande progetto collaborativo della storia del software.

Oggi, 11 settembre 2025, l'ultima versione stabile è la 6.16, e la 6.17 è alla quinta release candidate. Quasi ogni file del kernel comincia con una riga che dichiara la licenza in formato SPDX, leggibile anche da una macchina. Se hai i sorgenti a portata di mano, prova:

$ git clone --depth 1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd linux
$ grep -rhoE "SPDX-License-Identifier: .*" --include="*.[ch]" . \
    | sed 's/ \*\/$//' | sort | uniq -c | sort -rn | head -5

In cima troverai GPL-2.0 e GPL-2.0-only, e poco sotto una curiosità: GPL-2.0 WITH Linux-syscall-note. È l'eccezione che rende possibile tutto il resto. Dice che un programma che usa il kernel solo tramite le normali chiamate di sistema non è un'opera derivata. Senza quella nota, ogni programma che gira su Linux rischierebbe di dover essere GPL, e nessuno lo userebbe.

Nota anche quell'-only. Molti progetti GNU scrivono «GPL versione 2 o successive», e così sono passati automaticamente alla GPLv3 nel 2007. Linux no: Torvalds non ha mai voluto la v3, e cambiare licenza oggi richiederebbe il consenso di migliaia di autori, alcuni dei quali non sono più tra noi. Il kernel resterà GPLv2 per sempre.

2003: il router che non voleva essere libero

Facciamo un salto. È il 2003 e hai appena comprato un Linksys WRT54G, il router Wi-Fi blu e nero che hanno tutti. Quello che non sai è che dentro gira Linux. Lo scopre a giugno uno sviluppatore, Andrew Miklas, che lo segnala sulla mailing list del kernel: il firmware contiene codice GPL, ma Linksys (appena comprata da Cisco) non ha pubblicato i sorgenti.

La GPL qui fa il suo lavoro. Distribuire un router con Linux dentro significa distribuire Linux, e chi distribuisce codice GPL deve rendere disponibili i sorgenti. Dopo qualche settimana di pressioni, a luglio, Linksys li pubblica (all'inizio incompleti: servirà un secondo giro di segnalazioni sulla stessa mailing list). Da quei sorgenti, nel 2004, nasce OpenWrt, e con lui DD-WRT e Tomato: firmware alternativi che trasformano un router da sessanta dollari in una macchina da rete professionale, con VPN, QoS, firewall configurabile.

La parte più bella arriva dopo. Nel 2005 Linksys passa il WRT54G a un altro sistema operativo, VxWorks, con meno memoria. La comunità protesta, e Linksys mette in vendita un modello apposta, il WRT54GL. La «L» sta per Linux. Resterà in commercio per anni, tra i router più venduti di sempre, comprato proprio da chi voleva installarci sopra il firmware libero. Se il tuo router di casa oggi ha un'interfaccia che si chiama LuCI, o se il tuo provider usa un firmware basato su OpenWrt, stai usando un discendente di quella storia. E non è un caso isolato: negli anni successivi la Software Freedom Conservancy ha portato in tribunale diversi produttori che distribuivano BusyBox (GPL) senza sorgenti, ottenendo la pubblicazione del codice.

Oggi, nella tua tasca e sulla tua scrivania

Prendi il telefono. Se è Android, sotto c'è il kernel Linux, GPLv2. Ma guarda come Google ha organizzato la cucina: il kernel è GPL perché non poteva essere altrimenti, mentre quasi tutto il resto del sistema, lo userspace, è sotto Apache 2.0. Al posto della libreria C di GNU (glibc, LGPL) Android usa Bionic, scritta apposta con licenza BSD. La regola interna era chiara: niente GPL sopra il kernel. Così i produttori di telefoni possono modificare Android e tenersi le modifiche, e le app non devono preoccuparsi di nessun copyleft. È una scelta di licenze precisa quanto una scelta architetturale, e ha funzionato: Android gira su miliardi di dispositivi.

Ora apri il terminale di un Mac e scrivi:

$ /bin/bash --version
GNU bash, version 3.2.57(1)-release (arm64-apple-darwin24)

Bash 3.2: una versione del 2006, ferma lì da quasi vent'anni. Non è pigrizia. Da bash 4.0 la licenza è diventata GPLv3, e la v3 ha clausole sui brevetti e sui dispositivi bloccati che Apple non ha voluto accettare. Così ha tenuto l'ultima bash GPLv2, e dal 2019, con macOS Catalina, ha cambiato la shell predefinita in zsh, che ha una licenza permissiva. Per lo stesso motivo, tra gli altri, Apple ha investito in LLVM e Clang invece di restare su GCC, che è passato alla GPLv3 nel 2007. Due licenze diverse hanno spostato milioni di sviluppatori da una shell e da un compilatore all'altro.

E poi c'è tutto il resto. Dal novembre 2017 il 100% dei 500 supercomputer più potenti al mondo usa Linux, e la classifica di giugno 2025 lo conferma. Quasi tutto il cloud gira su Linux. Il server web che ti ha servito questa pagina è open source. Il software libero ha vinto così bene che ormai nessuno se ne accorge più.

1998: quando «free» diventò «open»

Manca un pezzo, ed è quello che spiega perché il menu di GitHub dice «open source» e non «software libero». A gennaio 1998 Netscape annuncia che pubblicherà il codice del suo browser (diventerà Mozilla, e poi Firefox). Un gruppo di sviluppatori capisce che è il momento di parlare alle aziende, e che la parola free, con la sua ambiguità e il suo sapore politico, le spaventa. A febbraio, in una riunione, Christine Peterson propone un'alternativa: open source. Pochi giorni dopo Eric Raymond e Bruce Perens fondano la Open Source Initiative.

Le due etichette indicano quasi sempre lo stesso software, ma con motivazioni diverse. Per il software libero è una questione etica: gli utenti hanno diritto a controllare i programmi che usano. Per l'open source è una questione pratica: sviluppare in modo aperto produce software migliore. Stallman non ha mai accettato il secondo termine. Da qui la sigla neutrale che usa chi non vuole scegliere: FOSS, Free and Open Source Software.

La cucina delle licenze

Torniamo a nonna Pina, che sta ancora aspettando una risposta. Immagina che la sua ricetta del ragù sia codice, e che tu debba decidere come regalarla. Ogni licenza è un modo diverso di farlo.

Pubblico dominio (CC0, Unlicense). Lasci la ricetta su un foglio, sul sedile del tram. Chiunque può farne qualunque cosa, anche firmarla col proprio nome. Semplice, ma in alcuni paesi, Italia compresa, rinunciare del tutto ai diritti d'autore non è nemmeno possibile, e per questo CC0 include una licenza di riserva.

MIT. Regali la ricetta con un bigliettino attaccato: «Ricetta di nonna Pina». Chi la usa può fare tutto, anche aprire un ristorante stellato e vendere un ragù rivisitato, tenendo segrete le sue modifiche. L'unico obbligo è lasciare il bigliettino, cioè la nota di copyright e il testo della licenza. In fondo al biglietto c'è anche scritto: «Se ti viene il mal di pancia, la nonna non c'entra.» È la clausola «AS IS», senza garanzia, che trovi in tutte le licenze. È la licenza più usata su GitHub: React, Node.js, Ruby on Rails.

BSD. Come la MIT, più una postilla: «Non scrivere sul menu "approvato da nonna Pina" senza chiederglielo.» Cioè non usare il nome degli autori per promuovere il tuo prodotto. La versione originale aveva anche una clausola che obbligava a citare l'università di Berkeley in ogni pubblicità, ed è stata tolta nel 1999 perché le pubblicità diventavano elenchi di ringraziamenti. FreeBSD e nginx usano licenze BSD. Il sistema operativo della PlayStation è basato su FreeBSD, e Sony non è tenuta a pubblicare niente.

Apache 2.0. La MIT con il notaio. Oltre al bigliettino, chi modifica la ricetta deve segnare cosa ha cambiato («aggiunto peperoncino»). E c'è una clausola sui brevetti: se la nonna avesse brevettato il suo soffritto in tre tempi, con questa licenza ti concede anche il permesso di usare il brevetto. Ma se tu le fai causa sostenendo che il soffritto viola un tuo brevetto, perdi la licenza. Le aziende la adorano proprio per questo. Kubernetes, Swift e lo userspace di Android sono Apache 2.0. (Nel 2017 React aveva una licenza BSD con una clausola brevettuale scritta da Facebook, che revocava i diritti a chi faceva causa a Facebook per qualunque brevetto. La Apache Software Foundation la vietò nei suoi progetti, la comunità protestò, e a settembre Facebook passò React alla MIT.)

MPL 2.0. Il copyleft a barattolo. Se modifichi il sugo dentro il barattolo, devi condividere la ricetta del sugo. La lasagna che ci costruisci intorno, però, resta tua. In termini tecnici il copyleft vale file per file: i file con licenza MPL che modifichi restano MPL, i tuoi file nuovi possono avere qualunque licenza. È la licenza di Firefox.

LGPL. Il sugo come ingrediente. Puoi vendere la tua lasagna segreta usando il sugo della nonna, ma se modifichi il sugo devi condividere le modifiche, e il cliente deve poter sostituire il sugo con un altro, anche con una versione modificata da lui. Nel software, questo vuol dire che puoi usare una libreria LGPL in un programma chiuso, di solito con il linking dinamico: la libreria sta in un file separato (.so, .dll) che l'utente può rimpiazzare. Con il linking statico si può fare lo stesso, ma devi fornire i file oggetto per ricollegare il programma. glibc è LGPL, e FFmpeg lo è nella configurazione predefinita.

GPL. La regola d'oro: chi assaggia ha diritto alla ricetta. Puoi usare il ragù della nonna come vuoi, modificarlo e anche venderlo. Ma se dai a qualcuno il piatto, cioè distribuisci il programma o un'opera derivata, chi lo riceve ha diritto alla ricetta completa, comprese le tue modifiche, e con la stessa licenza. Due dettagli che molti ignorano. Il primo: se cucini solo per casa tua, cioè usi il programma internamente senza distribuirlo, non devi dare niente a nessuno. Il secondo: «opera derivata» non riguarda solo chi modifica i file, ma anche chi combina il codice GPL nel proprio programma. Per la Free Software Foundation anche il linking, statico o dinamico, crea un'opera unica. È per questo che le aziende ci stanno così attente.

GPLv3. La GPLv2 più un paio di regole nuove, nate da storie vere. La più famosa: niente lucchetti sulla teglia. TiVo, un videoregistratore digitale, usava Linux e pubblicava regolarmente i sorgenti, ma l'hardware accettava solo software firmato da TiVo: potevi leggere e modificare il codice, ma non installarlo. La GPLv3 lo vieta nei prodotti di consumo: se dai il piatto chiuso in una teglia con il lucchetto, devi dare anche la chiave (le «installation information»). In più ha clausole esplicite sui brevetti. Bash, GCC e Samba sono GPLv3.

AGPL. La GPL al ristorante. Con la GPL, se servi il ragù nel tuo ristorante invece di venderlo da asporto, non stai «distribuendo» niente, e quindi non devi dare la ricetta. È la cosiddetta SaaS loophole: un'azienda può prendere software GPL, modificarlo e offrirlo come servizio web senza mai pubblicare una riga. L'AGPL la chiude: se gli utenti interagiscono con il programma tramite rete, hanno diritto ai sorgenti della versione che stanno usando. Mastodon e Grafana sono AGPL.

Le finte ricette libere (SSPL, BSL). «Ricetta gratis per tutti, tranne per chi apre una trattoria che serve ragù.» Sono le licenze source-available che hai incontrato ieri tra i cambi di licenza di MongoDB, Elastic, Redis e HashiCorp. Puoi leggere il codice, ma non sono open source: la definizione della Open Source Initiative vieta di discriminare chi usa il software o per quale attività. Un sorgente consultabile non basta.

Proprietario. La formula della Coca-Cola: in cassaforte. Compri la bevanda, non la ricetta.

Le licenze in tavola

Un'ultima cosa che in cucina sanno tutti: non tutte le ricette si possono mescolare. Il codice permissivo può entrare in un piatto GPL (MIT dentro GPL va benissimo), ma non il contrario. E alcune licenze copyleft non sono compatibili tra loro: Apache 2.0 si può combinare con la GPLv3 ma non con la GPLv2-only, ed è per questo che ZFS, sotto licenza CDDL, non può entrare nel kernel Linux. Prima di aggiungere una dipendenza, guarda cosa c'è nella dispensa:

# riepilogo delle licenze delle dipendenze di un progetto Node
$ npx license-checker --summary

# il tuo progetto dichiara correttamente le licenze di ogni file?
$ pipx run reuse lint

Mezzanotte e un quarto

Torni al menu a tendina, e adesso le sigle hanno un significato. Ti fai tre domande. Vuoi che ricettario lo usi più gente possibile, aziende comprese, senza nessun attrito? MIT, o Apache 2.0 se vuoi anche la protezione sui brevetti. Vuoi che chi lo migliora e lo distribuisce restituisca le modifiche? GPL, o LGPL e MPL se stai scrivendo una libreria da usare dentro altri programmi. Temi che qualcuno lo trasformi in un servizio a pagamento senza restituire niente? AGPL.

Pensi a gnocco, ai suoi 11 dollari, alle aziende che ricevono il piatto e non chiedono mai la ricetta. E scegli. Aggiungi in cima a ogni file la riga SPDX-License-Identifier, fai il commit e il push.

Poi rispondi alla nonna: «Tutti, nonna. Chiunque la può usare, cambiare, anche venderla. Ma chi la serve agli altri deve dare anche la ricetta.»

La risposta arriva dopo un minuto, con tre emoji di cuori: «Giusto. Così si è sempre fatto.»