Storia del software open source: dalle origini alla SSPL

Che cos’è il software open source e da dove proviene

La storia del software open source è soprattutto la storia delle sue licenze, perché una licenza è l’unico elemento che stabilisce che cosa si può fare con il codice scritto da altri. Il codice veniva condiviso liberamente molto prima che qualcuno mettesse per iscritto quelle licenze. Ha smesso di essere condiviso quando è diventato un prodotto, e le licenze sono state redatte per tutelare la condivisione anche in tribunale.

Questa è la versione breve. Quella completa è importante perché il software che oggi esegui su un server porta ancora i segni di quelle decisioni. Alcune risalgono al 1983. Altre sono state prese l’anno scorso e spiegano perché alcune applicazioni nelle nostre guide al self-hosting sono ora disponibili in due versioni con nomi diversi.

Il software veniva condiviso prima di essere venduto

Negli anni 1950 e 1960, il software veniva fornito insieme alla macchina. IBM distribuiva il codice sorgente con i propri sistemi e gruppi di utenti come SHARE, fondato nel 1955, si scambiavano programmi su nastro. Due eventi posero fine a questa pratica. Nel 1969 IBM annunciò che avrebbe applicato un prezzo separato al software e all'hardware, creando un mercato autonomo per il software. Poi anche la legislazione si adeguò. Il Computer Software Copyright Act del 1980 stabilì negli Stati Uniti che i programmi sono opere protette dal copyright. Dopo il 1980, il codice non scritto da chi lo utilizzava era considerato proprietario per impostazione predefinita; per condividerlo era quindi necessaria un'autorizzazione scritta dell'autore.

Il Homebrew Computer Club e la Lettera aperta agli hobbisti

Il Homebrew Computer Club tenne la sua prima riunione nel marzo 1975, in un garage a Menlo Park, in California. I membri portavano hardware e nastri perforati; la copia faceva parte della riunione. Altair BASIC, scritto da Bill Gates e Paul Allen, passava da una persona all’altra su nastri copiati. Nel febbraio 1976 Gates rispose nella newsletter del club con «An Open Letter to Hobbyists».

Come la maggior parte degli hobbisti dovrebbe sapere, la maggior parte di voi ruba il software.

Scrisse che meno di un proprietario di Altair su dieci aveva pagato BASIC e che il tempo di elaborazione usato per scriverlo valeva più di 40,000 dollari. L’intera discussione moderna è già contenuta in quella lettera. Copiare il software non costa nulla e aiuta tutti quelli che lo copiano. Scriverlo è comunque costato a qualcuno un anno della propria vita. Ogni licenza descritta di seguito tenta di rispondere contemporaneamente a entrambi questi fatti.

GNU nel 1983 e la GPL come innovazione giuridica

Richard Stallman annunciò GNU nel settembre 1983 su Usenet, la rete di newsgroup utilizzata prima del web. GNU è l'acronimo di "GNU's Not Unix". Il progetto prevedeva un sistema completo compatibile con Unix, che chiunque potesse copiare e modificare.

Free Unix! Starting this Thanksgiving I am going to write a complete Unix-compatible software system called GNU (for Gnu's Not Unix), and give it away free to everyone who can use it.

La Free Software Foundation (FSF) nacque nel 1985. La sua Free Software Definition elenca quattro libertà, numerate a partire da zero: eseguire il programma per qualsiasi scopo, studiarlo e modificarlo, ridistribuire copie e distribuire le proprie versioni modificate. La libertà 1 richiede il codice sorgente, perché nessuno può studiare un binario in modo concretamente praticabile. In questo contesto, "free" indica la libertà, non il prezzo. La formula usata dalla FSF è free as in free speech, not free beer.

Il manifesto non fu l'innovazione. Lo fu la licenza. La GNU General Public License (GPL) usa il copyright per imporre la condivisione invece di impedirla. Si ricevono le quattro libertà a una condizione: chiunque riceva il software da voi deve riceverle a sua volta, insieme al codice sorgente. Stallman chiamò questo principio copyleft. Fu distribuito per la prima volta con GNU Emacs nel 1985, divenne la GPL version 1 nel 1989 e la version 2 nel giugno 1991.

La GPL funziona perché si basa sul diritto d'autore, non lo contrasta. Senza una licenza, non si ha alcun diritto di distribuire il codice di altri. La GPL concede questo diritto e vi associa determinate condizioni. Di conseguenza, un vendor che distribuisce codice GPL modificato all'interno di un router e rifiuta di fornire il codice sorgente non sta semplicemente violando una promessa. Sta violando il copyright, e il titolare del copyright può portare il caso in tribunale. Per questo è possibile far rispettare la licenza, dai casi di gpl-violations.org promossi da Harald Welte negli anni 2000 fino alla causa intentata dalla Software Freedom Conservancy contro Vizio nel 2021, secondo cui anche chi ha acquistato il televisore può richiedere il codice sorgente.

Linux completa il sistema

Nel 1991 il progetto GNU disponeva del compilatore, della libreria C, della shell e della maggior parte degli strumenti. Non disponeva di un kernel funzionante, perché il kernel sviluppato dal progetto GNU, Hurd, richiedeva molto più tempo del previsto. Nell'agosto 1991 uno studente di Helsinki scrisse nel newsgroup comp.os.minix:

Sto sviluppando un sistema operativo (gratuito), solo per hobby: non sarà grande e professionale come GNU, per cloni AT 386(486).

Linux 0.01 fu pubblicato nel settembre 1991 con una licenza scritta dallo stesso Linus Torvalds, che ne vietava la vendita. All'inizio del 1992 Torvalds la sostituì con GPLv2 e in seguito ha dichiarato che fu una delle sue decisioni migliori. La licenza rese sicuro il contributo delle aziende: un'azienda poteva assegnare ingegneri allo sviluppo del kernel sapendo che un concorrente non avrebbe potuto rendere proprietarie quelle migliorie.

A Berkeley esisteva già un Unix libero. Il motivo per cui Linux, e non BSD (Berkeley Software Distribution), divenne lo Unix libero predefinito dipende in parte da una causa legale. Unix System Laboratories fece causa a Berkeley Software Design nel 1992 e il procedimento proseguì fino all'inizio del 1994. Per quei due anni i sistemi BSD comportavano un rischio legale, mentre Linux non ne comportava alcuno. Fu allora che arrivarono gli utenti. La FSF chiede di chiamare il sistema combinato GNU/Linux, perché Linux è il kernel e la maggior parte degli strumenti circostanti proviene da GNU. La maggior parte delle persone dice Linux. Entrambi i nomi indicano la stessa raccolta di software.

1998: il rebranding open source e la divisione mai ricomposta

Nel gennaio 1998 Netscape annunciò che avrebbe pubblicato il codice sorgente del proprio browser. Era l'azienda più grande ad averlo fatto fino a quel momento e la decisione mise in evidenza un problema pratico. In inglese, l'espressione "free software" viene interpretata come "software che non costa nulla", ed era esattamente questo il significato colto dai dirigenti. Nel febbraio 1998, un gruppo si riunì a Palo Alto per individuare un termine migliore e Christine Peterson propose "open source". Nel giro di poche settimane, Eric Raymond e Bruce Perens fondarono la Open Source Initiative (OSI). L'organizzazione adottò la Open Source Definition, adattata dalle Debian Free Software Guidelines che Perens aveva redatto nel 1997.

La Open Source Definition contiene dieci criteri. Due determinano la maggior parte delle discussioni attuali: il codice sorgente deve essere disponibile e la licenza non deve limitare chi può usare il programma né lo scopo per cui può usarlo. Una licenza che stabilisce "non è possibile offrire questo programma come servizio commerciale" non supera il test, indipendentemente da ciò che autorizza sotto altri aspetti. È importante ricordare questa frase. È il limite oltre il quale si spingono le licenze source-available attuali.

La divisione iniziata nel 1998 riguarda le motivazioni, non quali licenze siano accettabili. La posizione della FSF è etica: un utente che non può modificare il programma non ha il controllo del proprio computer. La posizione dell'OSI, sostenuta nei confronti delle aziende dal saggio di Raymond "The Cathedral and the Bazaar", è pratica: lo sviluppo aperto produce software migliore e un'azienda può basarsi su questo principio. La risposta di Stallman, "Why Open Source Misses the Point of Free Software", è ancora pubblicata su gnu.org e Stallman non ha mai accettato il termine più recente. Perens, che aveva contribuito a crearlo, si dimise dal consiglio dell'OSI nel 1999, affermando che il movimento si era allontanato dal free software.

È utile essere precisi su quanto sia ridotta la differenza pratica. L'elenco delle licenze free della FSF e quello delle licenze approvate dall'OSI coincidono quasi completamente, includendo GPL, MIT, Apache 2.0 e BSD. Gli autori che devono indicare contemporaneamente entrambi i significati usano FOSS (free and open source software) oppure FLOSS (free/libre and open source software).

Come le aziende hanno imparato a distribuire il codice

La quotazione di Red Hat in borsa nel 1999 ha dimostrato che il valore economico risiedeva nell'assistenza e nella distribuzione dei pacchetti, non nella vendita delle copie. Nel 2001 IBM ha destinato un miliardo di dollari a Linux. Nello stesso anno, l'amministratore delegato di Microsoft ha definito Linux «un cancro». Nel 2016 la stessa azienda è entrata nella Linux Foundation come membro platinum, quindi nel 2018 ha acquistato GitHub per 7.5 miliardi di dollari in azioni. Nel 2019 IBM ha acquistato Red Hat per 34 miliardi di dollari. Nulla di tutto questo rappresentava un ripensamento sulle licenze. Era cambiato il punto in cui si concentrava il valore economico. Quando un sistema operativo è un costo condiviso, mantenere il proprio sistema è costoso e ogni fornitore preferisce competere sul livello superiore.

La proprietà aziendale può produrre anche l'effetto opposto. Quando Oracle ha acquistato Sun nel 2010, ha ereditato MySQL e OpenOffice.org, ma entrambe le comunità hanno abbandonato il progetto. MariaDB è nata da MySQL e LibreOffice è stata creata come fork di OpenOffice.org nel settembre 2010. Un fork è l'unico strumento di voto realmente disponibile per una comunità di utenti, e la licenza è ciò che rende possibile questo voto.

Perché alcune applicazioni che gestisci in self-hosting ora hanno dei fork

Dal 2018 in poi, alcuni gruppi aziendali hanno modificato i termini di licenza del software già rilasciato. Ogni volta la situazione era simile. Un'azienda impiegava quasi tutti gli sviluppatori, un provider cloud molto più grande vendeva lo stesso software come servizio gestito e l'azienda più piccola decideva che la licenza fosse il motivo per cui non riusciva a competere.

• MongoDB ha adottato la Server Side Public License (SSPL) nell'ottobre 2018. La SSPL stabilisce che, se offri il software ad altri come servizio, devi pubblicare il codice sorgente di tutto ciò che usi per fornire quel servizio. L'OSI non l'ha accettata come licenza open source e MongoDB l'ha ritirata dalla valutazione nel 2019.
• Redis ha introdotto restrizioni d'uso per alcuni moduli nel 2018 e nel 2019, quindi ha trasferito il server principale a termini dual source-available con la versione 7.4 nel marzo 2024. Pochi giorni dopo è comparso un fork dell'ultima release con licenza BSD, chiamato Valkey, sotto la Linux Foundation e sostenuto, tra gli altri, da Amazon, Google e Oracle. Nel maggio 2025 Redis ha aggiunto la Affero General Public License version 3 (AGPLv3), approvata dall'OSI, come terza opzione per Redis 8.
• Elastic ha rimosso Elasticsearch e Kibana dalla licenza Apache 2.0 nel gennaio 2021, adottando una combinazione delle condizioni SSPL ed Elastic License. Amazon ha creato il fork OpenSearch. Elastic ha aggiunto AGPLv3 come terza opzione nell'agosto 2024 e OpenSearch è stato trasferito alla Linux Foundation nel settembre 2024, come OpenSearch Software Foundation.
• HashiCorp ha trasferito Terraform e gli altri strumenti alla Business Source License (BUSL) nell'agosto 2023. La BUSL non è una licenza open source mentre è in vigore, perché vieta l'uso in produzione per competere. Ogni release viene convertita in una licenza open source a una data fissa, quattro anni dopo nel caso di Terraform. OpenTofu è nato come fork nel giro di poche settimane e ora è anch'esso sotto la Linux Foundation.

Entrambe le parti hanno argomenti validi e nessuna delle due agisce in malafede. Un'azienda che paga cinquanta stipendi mentre un'impresa molto più grande rivende il suo lavoro si trova davanti a un problema che la buona volontà non può risolvere. Anche un utente che ha costruito la propria soluzione sulla base dei termini Apache 2.0 e si è ritrovato, dopo un aggiornamento, soggetto a nuovi termini ha un problema, e nessuno gli ha chiesto prima il suo consenso. Osserva cosa è successo dopo in due di questi casi. Dopo che i fork si sono affermati, sia Elastic sia Redis hanno reintrodotto il copyleft forte. Il copyleft ha risposto alla contestazione originale, perché AGPLv3 impone al provider di un servizio di pubblicare le modifiche che esegue. Ad agosto 2026 entrambi i progetti e i relativi fork sono ancora attivi: è proprio il risultato che queste licenze sono state progettate per consentire.

Chi è autorizzato a modificare una licenza

Un progetto può essere distribuito con una nuova licenza solo se un unico soggetto controlla il copyright sull’intero progetto. Le aziende ottengono questo controllo in uno di due modi. La cessione del copyright trasferisce all’azienda la titolarità di ogni contributo. Un contributor licence agreement (CLA) lascia la titolarità al contributore, ma concede all’azienda diritti sufficientemente ampi per distribuire il lavoro con una nuova licenza. Di solito, il contributore firma uno dei due accordi facendo clic su un link che un bot pubblica nella prima pull request.

Linux non usa un CLA. I contributi arrivano con GPLv2 e un Developer Certificate of Origin, mentre il copyright è distribuito tra migliaia di persone e aziende. Nessuno può distribuire Linux con una nuova licenza, perché nessuno potrebbe raccogliere tutte quelle firme. La stessa protezione si applica a qualsiasi progetto con molti titolari indipendenti del copyright. È una protezione più solida di una promessa, perché dipende da un fatto concreto: chi possiede cosa.

La domanda da porsi sul software da cui si prevede di dipendere non è quindi se oggi sia open source. Bisogna chiedersi chi potrebbe modificare la licenza e se potrebbe farlo autonomamente.

Cosa offre realmente una fondazione

Una fondazione detiene gli asset e stabilisce le regole per il processo decisionale. Apache Software Foundation, Linux Foundation, Cloud Native Computing Foundation al suo interno e Software Freedom Conservancy svolgono ciascuna una versione di questo compito. Una fondazione non è neutrale per magia. I membri pagano per i propri posti e la maggior parte delle persone che lavorano a tempo pieno a un grande progetto della fondazione è retribuita da aziende associate. Ciò che si ottiene è più limitato, ma comunque molto importante: il marchio e il processo di rilascio non appartengono a un solo fornitore, quindi nessuna azienda può rendere il progetto proprietario.

Il marchio è l'elemento che spesso viene trascurato. Il codice è distribuito con una licenza. Un nome è un marchio, e un marchio non è disciplinato dalla licenza del codice. È sempre possibile creare un fork del codice. Di norma non è possibile mantenere lo stesso nome. Per questo i fork descritti in questa storia si chiamano Valkey, OpenSearch, OpenTofu e Forgejo.

Il problema dei maintainer

L’infrastruttura moderna si basa su progetti gestiti da uno o due maintainer non retribuiti, e sono gli incidenti a rendere evidente questa situazione. Nel 2014 il bug Heartbleed in OpenSSL ha colpito una libreria che gestiva una quota significativa del traffico web cifrato ed era mantenuta da poche persone con risorse economiche quasi nulle. Nel dicembre 2021 Log4Shell ha fatto confluire la risposta agli incidenti di tutto il mondo su un piccolo team di volontari del progetto Apache Log4j.

La backdoor di XZ Utils, scoperta nel marzo 2024, è l’esempio più evidente perché l’attacco ha preso di mira il maintainer, non il codice. Un account ha trascorso circa due anni a fornire contributi realmente utili a una libreria di compressione usata in numerose distribuzioni Linux. Altri account hanno fatto pressione sull’unico maintainer, ormai esausto, perché accettasse aiuto. Il nuovo co-maintainer ha quindi inserito una backdoor negli archivi delle release, destinata ai sistemi in cui il demone SSH (secure shell) è collegato a liblzma. Un developer l’ha individuata mentre cercava di capire perché gli accessi richiedessero circa mezzo secondo in più del previsto. È stata una coincidenza, e tutte le persone coinvolte lo hanno dichiarato pubblicamente.

I finanziamenti hanno iniziato ad arrivare: GitHub Sponsors dal 2019, Open Collective, il Sovereign Tech Fund tedesco dal 2022 e il progetto Alpha-Omega di OpenSSF. Arrivano in modo disomogeneo e tendono a raggiungere i progetti già famosi. Anche la regolamentazione sta avanzando. Il Cyber Resilience Act dell’Unione europea è entrato in vigore nel dicembre 2024 e la maggior parte dei relativi obblighi si applicherà a partire dal dicembre 2027. Le prime bozze avrebbero attribuito la responsabilità del produttore a volontari non retribuiti; il testo finale introduce quindi una categoria meno onerosa, chiamata "open source software steward", dopo una lunga attività di lobbying da parte di fondazioni e distribuzioni.

Cosa significa la storia dell'open source per il software sul tuo VPS

Ogni applicazione nelle nostre guide al self-hosting dipende da queste decisioni. Nextcloud esiste grazie a un fork: nel 2016 il fondatore di ownCloud e gran parte del team lasciarono il progetto e lo riavviarono con licenza AGPLv3. Da allora i due prodotti sono sviluppati in parallelo. Questa storia fa da contesto a le alternative a Nextcloud da valutare e alle alternative self-hosted a Dropbox che competono con entrambi.

Lo stesso schema si ritrova nell'hosting Git. Gitea è nato nel 2016 come fork di Gogs. Alla fine del 2022 il marchio e i domini del progetto sono passati a un'azienda; Codeberg ha creato il fork Forgejo nel dicembre dello stesso anno, e nel 2024 Forgejo è passato dalla licenza MIT alla GPLv3 con la versione 9. Entrambi sono trattati nelle opzioni per server Git self-hosted, e la differenza di licenza è una delle ragioni principali per cui continuano a divergere. Nel frattempo, la maggior parte del software libero viene sviluppata su GitHub, una piattaforma proprietaria di Microsoft. È un dibattito aperto da tempo, con argomenti validi da entrambe le parti: vedi che cos'è davvero GitHub.

Prima di assegnare un server a un progetto, vale la pena dedicare dieci minuti a quattro verifiche.

• Leggi il file LICENSE nel repository, non la pagina di presentazione. Le pagine continuano a usare l'espressione "open source" anche quando il file non la supporta più.
• Verifica la presenza di una CLA o di una cessione del copyright. Se esiste, un singolo titolare può modificare i termini delle versioni future.
• Scopri chi detiene il copyright: una sola azienda, molti contributori o una fondazione.
• Conta i maintainer attivi. Un progetto con un solo maintainer rappresenta un rischio per quella persona tanto quanto per te.

Niente di tutto questo implica che tu debba evitare il software di un singolo fornitore. Molti di questi prodotti sono eccellenti, e il fatto che siano finanziati è spesso il motivo per cui vengono mantenuti. Queste verifiche indicano a cosa ti esponi. Quando decidi che cosa vale la pena eseguire in self-hosting, inserisci la licenza nella tabella di confronto accanto al requisito di memoria.

Puoi leggere una parte di questa storia direttamente sulla macchina che hai davanti. Ogni pacchetto in un sistema Debian o Ubuntu include i propri termini di licenza:

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

Il primo numero indica quanti pacchetti installati contengono un file di copyright, in genere alcune centinaia su un VPS di piccole dimensioni. Il secondo comando stampa l'inizio del file relativo a bash, che indica la GNU General Public License versione 3. Un file mancante significa che il pacchetto non è stato compilato secondo la policy Debian. È un caso raro e merita una seconda verifica prima di considerare il pacchetto affidabile.

FAQ

Qual è la differenza tra free software e open source?

Coprono quasi lo stesso insieme di licenze, ma differiscono sul motivo per cui tali licenze sono importanti. «Free software» è il termine più antico, introdotto dalla Free Software Foundation nel 1985, e il suo argomento è etico: un utente che non può modificare il programma non controlla il computer. «Open source» è stato coniato nel febbraio 1998 per rendere le stesse licenze più facili da spiegare alle aziende, con un approccio pratico. Le licenze GPL, MIT, BSD e Apache 2.0 compaiono in entrambi gli elenchi ufficiali. Chi vuole indicare entrambi i concetti usa FOSS o FLOSS.

Il software source-available è la stessa cosa dell’open source?

No. Source-available significa che è possibile leggere il codice. Open source, secondo la Open Source Definition, significa anche che la licenza non può limitare chi utilizza il software o lo scopo per cui lo utilizza. Le licenze SSPL e Business Source License limitano l’uso commerciale da parte dei concorrenti. Secondo questa definizione, quindi, nessuna delle due è open source, anche se entrambe pubblicano il codice sorgente. Se si esegue il software soltanto per uso personale, la limitazione potrebbe non riguardare mai il proprio caso. Se si vuole sviluppare un prodotto basato su quel software, è necessario leggere prima con attenzione il testo della licenza.

Un’azienda può revocare una licenza open source che ha già concesso?

Non per il codice già rilasciato. Quella versione resta soggetta alla licenza con cui è stata rilasciata. È proprio per questo che fork come Valkey e OpenTofu hanno potuto partire dall’ultimo commit distribuito con una licenza permissiva. Un’azienda può invece applicare condizioni diverse alle versioni future, ma solo se detiene il copyright sull’intero progetto tramite cessione dei diritti o un contributor licence agreement. I progetti con molti titolari indipendenti del copyright, incluso Linux, non possono essere relicenziati da un singolo soggetto.

Quale licenza dovrei cercare nel software self-hosted?

Per il software eseguito autonomamente e non rivenduto, qualsiasi licenza approvata da OSI, come GPL, AGPL, MIT o Apache 2.0, offre tutto ciò che serve. È più importante verificare chi detiene il copyright, perché da questo dipende la possibilità che le condizioni cambino in futuro senza il consenso degli utenti. Un progetto detenuto da una fondazione o da molti contributori indipendenti non può essere relicenziato a svantaggio degli utenti. Un progetto gestito da un singolo fornitore con un contributor licence agreement può invece esserlo. Entrambi possono essere software validi. Solo uno dei due può modificare autonomamente le regole.