GNU compie 43 anni: il progetto che ha costruito Linux prima di Linux

Il 27 settembre 1983 Richard Stallman pubblicò sui newsgroup net.unix-wizards e net.usoft un messaggio con un oggetto quasi dimesso, “new Unix implementation”. Dentro c’era però l’annuncio di un progetto destinato a lasciare un’impronta profonda sulla storia dell’informatica: la costruzione di GNU (GNU’s Not Unix), un sistema operativo completo, compatibile con Unix ma distribuibile e modificabile liberamente. Il 27 settembre 2026 GNU ha quindi compiuto 43 anni. L’anniversario offre l’occasione per capire quanto software nato da quell’idea continui a trovarsi, spesso senza farsi notare, dentro sistemi Linux, ambienti di sviluppo, server e infrastrutture moderne.

L’annuncio originale del progetto GNU risale effettivamente al 27 settembre 1983 ma il lavoro vero e proprio partì nel gennaio 1984.

Nel piano iniziale, Stallman immaginava un kernel accompagnato dagli strumenti necessari per sviluppare ed eseguire programmi C: editor, shell, compilatore, linker, assembler e altre utility. L’obiettivo era enorme per una ragione semplice: non si trattava di creare un singolo programma alternativo, bensì di ricostruire una piattaforma Unix compatibile senza dipendere dal software proprietario che ne limitava copia e modifica.

GNU significa GNU’s Not Unix: perché imitare Unix senza copiarlo

Il nome GNU nasce come acronimo ricorsivo di GNU’s Not Unix. La battuta tecnica nasconde una scelta progettuale precisa: Stallman non voleva inventare da zero un modello di sistema operativo completamente diverso. Unix aveva già dimostrato la validità di concetti come programmi relativamente piccoli, strumenti componibili, shell, gerarchie di file e un ambiente di sviluppo fortemente legato al linguaggio C. Rendere GNU compatibile con Unix avrebbe inoltre permesso agli utenti di trasferire più facilmente programmi e competenze.

Compatibile, però, non significava derivato dal codice proprietario di Unix. Il progetto puntava a realizzare componenti sostitutivi distribuibili con sorgenti disponibili e libertà di modifica. È una distinzione importante anche oggi: compatibilità Unix e identità del codice sono due aspetti completamente differenti.

Per comprendere meglio da dove arrivassero Unix, GNU e successivamente Linux, vale la pena affiancare la ricostruzione al nostro approfondimento sulla vera storia di Linux: il percorso parte da Unix e dalla cultura hacker dei laboratori universitari, passa attraverso Minix e arriva al progetto personale avviato da Linus Torvalds nel 1991.

GNU occupa una posizione centrale in quella sequenza storica, perché quando Linux comparve erano già disponibili molti degli strumenti necessari a costruire un sistema operativo realmente utilizzabile.

L’annuncio del 1983 mostra inoltre quanto il progetto fosse concreto fin dall’origine. Stallman cita esplicitamente editor, shell, compilatore C, linker, assembler, formatter di testo, documentazione e persino applicazioni. Aveva già individuato un problema che chiunque costruisca oggi una piattaforma software conosce bene: un kernel da solo serve a poco. Per ottenere un ambiente realmente utilizzabile occorrono librerie, toolchain, strumenti di base, interfacce e programmi.

Prima GNU Emacs, poi GCC: i pezzi iniziano a diventare utili da soli

Stallman iniziò a lavorare a GNU Emacs, uno degli editor tradizionali più conosciuti, nel settembre 1984 e nei primi mesi del 1985 l’editor aveva già raggiunto uno stato sufficientemente maturo da attirare utenti. Fu un passaggio decisivo: i componenti GNU potevano essere eseguiti sopra sistemi Unix esistenti, quindi non era necessario aspettare il completamento dell’intero sistema operativo per utilizzarli.

La caratteristica accelerò enormemente la diffusione degli strumenti GNU: gli utenti iniziarono a portarli sulle differenti varianti Unix, a correggerli e ad aggiungere funzionalità.

C’era però un effetto collaterale: più un programma diventava popolare, più tempo richiedevano manutenzione, portabilità e nuove funzioni. Nella ricostruzione storica pubblicata dal progetto GNU, Stallman osserva come il successo dei singoli programmi abbia finito anche per assorbire risorse che avrebbero potuto contribuire al completamento dell’intero sistema.

Uno dei risultati più importanti arrivò con GCC: la prima beta dello GNU C Compiler risale al 22 marzo 1987 e GCC 1.0 al 23 maggio dello stesso anno, come documenta la cronologia ufficiale delle release GCC. La disponibilità di un compilatore libero e portabile aveva un’importanza particolare: per costruire un sistema operativo libero serviva prima di tutto la capacità di compilare liberamente il suo software.

GCC si sarebbe trasformato successivamente nella GNU Compiler Collection, aggiungendo supporto per altri linguaggi e numerose architetture hardware. GCC resta una delle toolchain fondamentali nello sviluppo di kernel, distribuzioni Linux, software embedded e numerosi progetti multipiattaforma.

La Free Software Foundation e il significato tecnico del copyleft

Nel 1985 nacque la Free Software Foundation (FSF), inizialmente anche con l’obiettivo di raccogliere risorse per sostenere lo sviluppo di GNU. Nello stesso periodo si consolidò una distinzione che ancora oggi genera qualche equivoco: “free software” non significa necessariamente software gratuito. Il termine “free” riguarda le libertà concesse all’utente.

Nel modello promosso da GNU, l’utente deve poter eseguire il programma, studiarne il funzionamento attraverso il codice sorgente, modificarlo e redistribuire copie originali o modificate. Le quattro libertà fondamentali del software libero formalizzano il concetto.

Vendere il software non le contraddice: lo dimostra un episodio dei primi anni di GNU. Stallman distribuiva GNU Emacs anche su nastro chiedendo 150 dollari a chi non poteva scaricarlo via FTP. Il software rimaneva libero nonostante il supporto fisico avesse un prezzo.

Un altro tassello fondamentale arrivò nel febbraio 1989 con la prima versione della GNU General Public License. La GPL 1.0 originale applicò in maniera formale il principio del copyleft: chi redistribuisce versioni modificate di software coperto dalla licenza deve preservare per i destinatari le libertà previste dalla GPL e rispettarne le condizioni, compresa la disponibilità del corrispondente codice sorgente nei casi previsti.

GNU non coincide con “open source” e la GPL non rappresenta semplicemente un modo per pubblicare codice su Internet. Il movimento del software libero pone al centro le libertà dell’utente; il termine “open source” arrivò molto più tardi, alla fine degli anni ’90, e nacque con una diversa impostazione comunicativa. Molti programmi soddisfano entrambe le definizioni, ma i due termini non sono sinonimi.

Il grande pezzo mancante: GNU aveva quasi tutto tranne il kernel

Intorno al 1990 GNU disponeva ormai della maggior parte dei componenti fondamentali previsti per un sistema operativo. Mancava però proprio il pezzo che lavora più vicino all’hardware: il kernel.

Dopo aver vagliato varie possibilità, il progetto puntò su GNU Hurd. L’architettura scelta differiva dal tradizionale kernel Unix monolitico: Hurd consiste in una collezione di server che operano sopra il microkernel Mach e implementano servizi quali file system, controllo degli accessi e altre funzioni normalmente collocate all’interno di un kernel Unix.

L’idea era tecnicamente ambiziosa: un microkernel mantiene nel nucleo privilegiato un insieme più limitato di funzioni, mentre diversi servizi possono operare come processi separati comunicando tramite IPC, cioè meccanismi di comunicazione interprocesso. GNU Hurd utilizza GNU Mach come base e affida a server distinti varie responsabilità che un kernel monolitico tende invece a mantenere al proprio interno.

Sulla carta il modello offriva possibilità interessanti in termini di modularità e sperimentazione. Nella pratica, lo sviluppo si rivelò molto più difficile del previsto.

Il progetto ha prodotto versioni funzionanti, GNU Mach e distribuzioni sperimentali; Debian mantiene da tempo anche un port Debian GNU/Hurd. Rimane però lontano dalla diffusione e dalla compatibilità hardware raggiunte dal kernel Linux. Ancora oggi proprio Hurd rappresenta uno degli aspetti più affascinanti e, allo stesso tempo, problematici della storia GNU.

Poi arrivò Linux e i pezzi si incastrarono

Nel 1991 Linus Torvalds iniziò lo sviluppo di Linux. La situazione era quasi complementare: GNU possedeva compilatori, librerie, shell, debugger, editor e molte utility, ma faticava a completare il proprio kernel; Linux offriva invece un kernel Unix-like che poteva essere combinato con gran parte degli strumenti già sviluppati dal progetto GNU.

La storia di quel passaggio merita di essere letta anche dalla prospettiva opposta, cioè partendo da Torvalds. Nel nostro articolo Linux: la vera storia del sistema operativo che ha cambiato il mondo abbiamo ricostruito il percorso che da Minix portò all’annuncio del 25 agosto 1991 sul newsgroup comp.os.minix, alla release 0.01 e alla successiva crescita del progetto grazie ai contributi di sviluppatori sparsi in tutto il mondo.

Nel 1992 Linux adottò la GPL: da quel momento la combinazione fra kernel Linux e componenti GNU rese disponibile un sistema operativo libero praticamente completo. È da qui che nasce la nota discussione terminologica fra “Linux” e GNU/Linux: GNU sostiene che chiamare l’intero sistema semplicemente Linux nasconda il contributo del progetto e confonda il kernel con l’insieme di programmi che costruiscono l’ambiente utilizzabile dall’utente.

Abbiamo affrontato espressamente la questione nell’approfondimento GNU/Linux: cos’è e ha davvero senso fare polemica?. Al di là della disputa sul nome, il dato tecnico resta difficilmente contestabile: Linux identifica il kernel, mentre ciò che normalmente chiamiamo “distribuzione Linux” comprende una quantità di componenti provenienti da progetti differenti, molti dei quali storicamente sviluppati proprio sotto l’ombrello GNU.

Quanto GNU c’è ancora in un sistema Linux moderno

Una tipica distribuzione GNU/Linux continua a utilizzare glibc come implementazione della libreria C, Bash come shell e numerosi altri componenti GNU: GCC per la compilazione, GDB per il debugging, Binutils per assembler, linker e strumenti sui file oggetto, GNU Make, grep, sed, tar e parecchi altri pacchetti.

Una parte dello userland Linux, tuttavia, sta attraversando una trasformazione interessante: alcuni programmi storicamente forniti da GNU possono mantenere lo stesso nome e quasi la stessa interfaccia, pur non contenendo più il codice GNU originale.

Ubuntu sostituisce le GNU Coreutils con Rust

Ubuntu rappresenta il caso più evidente. Come abbiamo raccontato nell’articolo Ubuntu abbandona GNU/Linux: rivoluzione agghiacciante e affascinante allo stesso tempo, Canonical ha avviato una progressiva sostituzione delle tradizionali GNU Coreutils con uutils coreutils, una reimplementazione in Rust che punta a comportarsi come l’originale senza riutilizzarne il codice.

Il cambiamento è diventato concreto con Ubuntu 25.10: comandi fondamentali come ls, cat, chmod, date, du e molti altri hanno iniziato a provenire dal pacchetto rust-coreutils. Nello stesso rilascio Canonical ha reso sudo-rs l’implementazione predefinita di sudo. Per l’utente la differenza può risultare praticamente invisibile: si continua a scrivere ls o sudo, ma dietro quel comando può esserci un programma differente da quello utilizzato per decenni.

uutils non deve semplicemente offrire programmi che “fanno più o meno la stessa cosa” delle GNU Coreutils: il progetto dichiara esplicitamente di voler diventare un sostituto completo e considera le differenze rispetto a GNU come bug. Nel nostro approfondimento Rust Coreutils vuole compatibilità al 100% con i comandi GNU: cosa significa abbiamo analizzato proprio questo problema. Replicare l’interfaccia è relativamente semplice; replicare decenni di comportamenti, compresi quelli su cui il software ha finito involontariamente per fare affidamento, è molto più difficile.

Con Ubuntu 26.10 la situazione cambia ancora. Come abbiamo recentemente raccontato in Ubuntu 26.10 completa la svolta Rust: cambiano anche i comandi cp, mv e rm, la maturazione di uutils ha permesso di estendere la migrazione anche alle tre utility che Ubuntu 26.04 aveva prudentemente lasciato a GNU. Nei repository rimane comunque disponibile coreutils-from-gnu: parlare di “eliminazione di GNU” sarebbe quindi eccessivo. Più precisamente, Canonical sta sostituendo l’implementazione predefinita di una parte importante degli strumenti GNU mantenendone nomi, sintassi e, per quanto possibile, comportamento.

Non solo Ubuntu: uutils si fa strada nelle altre distribuzioni

La tendenza, inoltre, non riguarda soltanto Ubuntu. uutils risulta già pacchettizzato, con modalità differenti, per Debian, Fedora, Arch Linux, Alpine, Gentoo, Manjaro, NixOS e altre distribuzioni.

Debian ha lavorato esplicitamente sulla possibilità di migliorare la compatibilità delle Rust Coreutils e semplificare l’eventuale sostituzione delle GNU Coreutils. Fedora offre a sua volta uutils-coreutils, anche se per Fedora 44 il progetto ha chiarito di non prevederne al momento l’adozione come coreutils predefinite. Ubuntu resta quindi molto più avanti nell’impiego di uutils come sostituto operativo di GNU.

Curiosamente, questa concorrenza non significa che le GNU Coreutils siano ferme. Nell’articolo Linux, GNU Coreutils 9.11 accelera cat fino a 15 volte: che cosa cambia abbiamo visto come il progetto storico continui a ottimizzare il codice C e a ottenere incrementi prestazionali notevoli senza ricorrere a una riscrittura in Rust. Si stanno quindi confrontando due approcci: da una parte decenni di compatibilità e maturazione del codice GNU, dall’altra una reimplementazione che prova a sfruttare le garanzie di memory safety offerte da Rust.

GNU resta profondamente presente in molte distribuzioni, ma non è più scontato che un comando nato e reso familiare dal progetto GNU utilizzi effettivamente la sua implementazione. Ubuntu mostra bene la direzione: l’interfaccia Unix rimane, i nomi dei comandi rimangono e gli script dovrebbero continuare a funzionare, mentre sotto la superficie alcuni dei mattoni software cambiano completamente.

L’eredità più importante a distanza di 43 anni

Ridurre GNU a una raccolta di utility non rende giustizia al progetto ideato da Stallman, adesso “sotto l’egida” di FSF. La parte forse più duratura dell’iniziativa consiste nell’aver dimostrato che software tecnicamente sofisticato poteva nascere, evolvere e circolare mantenendo per gli utenti il diritto di studiarlo, modificarlo e redistribuirlo.

Il mondo del software libero del 2026 è molto diverso da quello immaginato nel 1983: lo sviluppo collaborativo è ormai normale, piattaforme pubbliche ospitano enormi quantità di codice, aziende multimiliardarie contribuiscono a kernel, compilatori e librerie aperte e gran parte dell’infrastruttura Internet poggia su componenti liberamente disponibili. Allo stesso tempo, disponibilità del sorgente, libertà del software e controllo effettivo dell’utente non coincidono automaticamente: licenze, servizi cloud, firmware proprietari, hardware e dipendenze esterne rendono il quadro molto più articolato.

Il problema dei costi di manutenzione

Il codice può essere liberamente utilizzabile, a seconda della licenza, ma il lavoro necessario a mantenerlo non è gratuito.

Scrivere patch, analizzare vulnerabilità, verificare segnalazioni, mantenere infrastrutture di build e test, rispondere alle regressioni e garantire compatibilità (soprattutto nell’era dell’AI) richiede tempo e competenze. Più un componente diventa fondamentale, più queste attività aumentano: eppure una parte sorprendentemente ampia dell’infrastruttura digitale mondiale continua a dipendere da progetti sostenuti da pochissime persone.

Nell’articolo “Non ce la facciamo più”: l’allarme dietro curl, software usato su 30 miliardi di dispositivi abbiamo raccontato lo sfogo di Daniel Stenberg, ideatore e principale manutentore del progetto curl.

curl e la libreria libcurl si trovano in una quantità sterminata di dispositivi e applicazioni, ma dietro una tecnologia utilizzata su una scala di questo tipo non esiste una struttura economica proporzionata alla sua importanza. Anzi, il successo aumenta il lavoro: più installazioni significano maggiore attenzione da parte dei ricercatori, più segnalazioni di sicurezza, più casi limite da verificare e maggiori aspettative da parte di aziende e utenti.

Una situazione per certi versi ancora più paradossale riguarda sudo. Nel nostro approfondimento Sudo resta fondamentale su Linux ma è senza risorse: il maintainer spiega cosa rischia davvero abbiamo descritto le difficoltà di un componente che per decenni ha rappresentato uno dei pilastri dell’amministrazione dei sistemi Unix e Linux. Milioni di macchine dipendono dalla sua affidabilità e dalla rapidità con cui eventuali problemi di sicurezza possono essere corretti; ciò non garantisce, però, che il progetto disponga automaticamente di denaro e sviluppatori sufficienti.

L’industria deve finanziare i progetti

È forse una delle contraddizioni più importanti da ricordare celebrando i 43 anni di GNU.

La libertà di copiare e modificare il software non implica che qualcuno debba necessariamente lavorare gratis per mantenerlo. Aziende, Pubbliche Amministrazioni e organizzazioni che costruiscono prodotti e servizi sopra componenti liberi hanno quindi un interesse molto concreto nel finanziare i progetti da cui dipendono, contribuire con sviluppatori, sostenere audit e infrastrutture oppure partecipare direttamente alla manutenzione. Senza questo passaggio, il rischio è di costruire servizi dal valore economico enorme sopra componenti essenziali affidati alla disponibilità di pochi maintainer.

Qualcosa, fortunatamente, si sta muovendo. Abbiamo visto ad esempio come Monaco abbia deciso di finanziare direttamente libexpat, libreria utilizzata su migliaia di server dell’amministrazione, trasformando la manutenzione di una dipendenza open source in un’attività esplicitamente finanziata.

È un modello interessante perché ribalta l’approccio tradizionale: invece di aspettare una vulnerabilità grave e investire denaro dopo l’incidente, si riconosce preventivamente che la manutenzione è parte della sicurezza.

GNU ha contribuito a dimostrare che si può costruire software complesso garantendo libertà che il modello proprietario tradizionale non concede. 43 anni dopo, la sfida non riguarda soltanto la possibilità di leggere, modificare e distribuire quel codice. Bisogna anche trovare modelli capaci di sostenere economicamente le persone che continuano a correggerlo, verificarlo e farlo funzionare. Il software libero può essere copiato praticamente a costo zero; la competenza necessaria per mantenerlo, invece, ha un costo molto reale.

L’immagine in apertura è frutto di un’elaborazione creativa (AI): non rappresenta Richard Stallman.