Esplora la filosofia del software libero di Richard Stallman, il progetto GNU e la GPL — e come hanno rimodellato licenze, diritti degli sviluppatori e l'ecosistema open source.
Il software non è solo un prodotto tecnico: è anche un insieme di permessi. Chi può eseguirlo, copiarlo, condividerlo con un amico, correggere un bug o costruire qualcosa sopra? A queste domande risponde meno il codice e più la licenza. Quando il software è diventato centrale per lavoro, comunicazione e ricerca, le regole su “cosa ti è permesso fare” hanno cominciato a modellare l'innovazione quanto le funzionalità.
Richard Stallman (spesso chiamato “RMS”) conta perché ha reso impossibile ignorare quelle regole. All'inizio degli anni ’80 vide un cambiamento: sempre più programmi venivano distribuiti senza codice sorgente e agli utenti si diceva che potevano usare il software solo secondo i termini imposti da altri. Stallman inquadrò questo non come un fastidio, ma come una perdita di libertà per utenti e sviluppatori — e rispose proponendo principi chiari e strumenti legali per proteggere quelle libertà.
Questo articolo si concentra sulle idee di Stallman e sulle loro conseguenze pratiche: la definizione di Software Libero, il Progetto GNU, il copyleft e la GNU General Public License (GPL) — e su come questi hanno plasmato l'ecosistema open source moderno e le norme sulle licenze software.
Non è una biografia né un tuffo tecnico nella compilazione del kernel o nella gestione di repository. Non serve un background di programmazione per seguirlo.
Stallman è influente e anche controverso. L'obiettivo qui è restare fattuali e leggibili: cosa ha sostenuto, quali meccanismi legali sono nati, come imprese e sviluppatori si sono adattati e dove continuano i dibattiti — così puoi capire perché il suo lavoro incide ancora sulle scelte software quotidiane.
“Software libero” è facile da fraintendere perché la parola libero sembra indicare un prezzo. Richard Stallman usava libero per intendere libertà — la capacità degli utenti di controllare il software su cui contano.
Se un programma costa $0 ma non ti è permesso ispezionarlo, cambiarlo o condividerlo, può essere “gratis come la birra” ma comunque non libero nel senso che interessava a Stallman.
Il software libero è definito da quattro permessi di base:
Queste libertà riguardano l'autonomia: non sei solo un consumatore di strumenti — puoi diventare un partecipante che verifica, adatta e migliora.
Le libertà 1 e 3 sono impossibili senza accesso al codice sorgente — le istruzioni leggibili dall'uomo. Senza di esso, il software è più simile a un elettrodomestico sigillato: puoi usarlo, ma non capire cosa fa, ripararlo quando si rompe o adattarlo a nuove esigenze.
L'accesso al sorgente è importante anche per la fiducia. Permette revisioni indipendenti (per privacy, sicurezza e correttezza) e rende possibile mantenere il software anche se lo sviluppatore originale smette di supportarlo.
Pensa a un pasto al ristorante.
Questa è l'idea centrale: il software libero riguarda le libertà che gli utenti devono avere per restare padroni del loro computing.
Prima che la “licenza software” diventasse un tema discusso, molte pratiche di programmazione — specialmente in università e laboratori di ricerca — si basavano su un'assunzione: se potevi migliorare uno strumento, condividevi il miglioramento. Il codice sorgente viaggiava con il software, le persone imparavano leggendo i lavori altrui e le correzioni si diffondevano tramite collaborazione informale.
Quella cultura cambiò quando il software divenne un prodotto a sé. Aziende (e alcune istituzioni) cominciarono a considerare il codice sorgente un vantaggio competitivo. La distribuzione arrivò con termini di “vietata condivisione”, il codice non veniva più fornito con i programmi e gli accordi di riservatezza divennero comuni. Per sviluppatori abituati a risolvere problemi collettivamente, questo cambiamento non fu solo un fastidio: fu una modifica delle regole che rendeva rischioso risolvere problemi in comunità.
Uno degli aneddoti più raccontati riguarda una stampante al MIT AI Lab. Stallman ha descritto come una nuova stampante arrivò con software distribuito solo in forma binaria, senza codice sorgente. Il problema pratico era banale: il laboratorio voleva modificare il programma per gestire notifiche di inceppamento o instradare i job in modo più intelligente. Secondo le vecchie norme “hacker”, qualcuno avrebbe patchato il codice e condiviso la correzione. Qui non si poteva — perché non era permesso vedere o cambiare il sorgente.
Vale la pena mettere le cose in proporzione: non è stata una stampante a creare il movimento globale. È stato un esempio chiaro e riconoscibile di una tendenza più ampia: strumenti su cui le persone dipendevano diventavano non riparabili dagli utenti.
Per Stallman, il nodo non era solo l'accesso tecnico: era la perdita della libertà di cooperare. Se non puoi studiare come funziona un programma, non puoi davvero controllarlo. Se non puoi condividere miglioramenti, le comunità si frammentano e tutti finiscono per reinventare correzioni in privato.
Quella motivazione ha modellato le innovazioni di licenza che sono seguite. Invece di affidarsi alla buona volontà o alle norme informali, Stallman voleva regole che preservassero la capacità di usare, studiare, modificare e condividere il software — così la collaborazione non potesse essere revocata nel momento in cui un programma diventava commercialmente prezioso.
La mossa più grande di Stallman non fu solo scrivere un manifesto: fu avviare un progetto ingegneristico pratico. Nel 1983 annunciò il Progetto GNU, con un obiettivo ambizioso: costruire un sistema operativo completo che chiunque potesse usare, studiare, modificare e condividere, mantenendo la compatibilità con Unix così da poter eseguire programmi e workflow familiari.
Un sistema operativo non è un solo programma: è un intero stack. GNU si propose di creare tutti i pezzi necessari per rendere un computer utile quotidianamente, inclusi:
In termini semplici: GNU costruiva l'impianto, non solo un singolo dispositivo.
All'inizio degli anni ’90, GNU aveva prodotto gran parte di questo “userland”, ma mancava un pezzo critico: il kernel (la parte che gestisce direttamente l'hardware e le risorse di sistema). Quando Linux apparve nel 1991, colmò quella lacuna.
Per questo molti sistemi popolari oggi combinano componenti GNU con il kernel Linux — spesso indicati come “GNU/Linux”.
GNU rese l'idea del software libero concreta creando una base funzionante su cui altri potevano costruire. La filosofia spiegava perché la libertà importava; GNU fornì gli strumenti che rendevano la libertà pratica, ripetibile e scalabile.
Il copyleft è una strategia di licenza pensata per mantenere il software libero (in termini di libertà) non solo nella prima versione, ma anche nelle versioni future. Se ricevi codice copyleft, puoi usarlo, studiarlo, modificarlo e condividerlo — ma quando distribuisci la tua versione modificata devi trasferire le stesse libertà agli altri.
Il copyleft sembra “anti-copyright”, ma si basa proprio sul diritto d'autore. L'autore usa il suo copyright per imporre regole di permesso in una licenza: “Puoi copiare e modificare questo, ma se lo ridistribuisci devi mantenerlo sotto la stessa licenza.” Senza copyright non ci sarebbe un meccanismo legale per far rispettare queste condizioni.
Pensalo come una regola che segue il codice:
L'obiettivo è prevenire un modello che Stallman temeva: qualcuno prende il lavoro della comunità, lo migliora e poi nasconde quei miglioramenti.
Le licenze permissive (come MIT o BSD) generalmente ti permettono di fare quasi tutto col codice, compreso ridistribuire versioni modificate sotto una licenza proprietaria chiusa. Le licenze copyleft (come la GNU GPL) permettono comunque un ampio uso e modifica, ma richiedono che le opere derivate ridistribuite rimangano sotto gli stessi termini copyleft — così la libertà è preservata a valle.
La GNU General Public License (GPL) ha cambiato il modo di fare licenze trasformando la “condivisione” in una regola applicabile, non solo in un gesto di cortesia. Prima della GPL, potevi ricevere il sorgente, migliorarlo e poi distribuire una versione chiusa che gli utenti non potevano studiare o modificare. La GPL ha girato quella dinamica: protegge le libertà degli utenti collegando condizioni alla ridistribuzione.
A livello pratico, la GPL concede agli utenti il diritto di eseguire il programma per qualsiasi scopo, leggere e modificare il sorgente e condividere le versioni originali o modificate.
Se ridistribuisci software GPL (soprattutto in un prodotto), devi trasferire le stesse libertà. Questo di solito significa:
Le obbligazioni della GPL si attivano principalmente quando distribuisci il software ad altri — spedire binari, vendere dispositivi con il software, o consegnare copie ai clienti. Se modifichi codice GPL per uso interno e non lo distribuisci, in genere non sei obbligato a pubblicare il sorgente.
Non serve la teoria legale per cogliere il succo: se il tuo programma incorpora codice GPL in modo da creare un'opera combinata (ad esempio collegandolo alla tua applicazione), il risultato è generalmente trattato come opera derivata e deve essere distribuito sotto GPL. Semplicemente eseguire un programma GPL, o comunicare con esso come processo separato tramite interfacce standard, spesso è diverso.
GPLv2 è la versione classica e molto utilizzata. GPLv3 aggiunge protezioni su accordi di brevetto e sulla “tivoizzazione” (vendo hardware che blocca software modificato). La LGPL è pensata per librerie: permette il linking da programmi proprietari in certe condizioni mantenendo libera la libreria stessa.
Le licenze libere (soprattutto la GNU GPL) non si limitano a “permettere” la condivisione — proteggono il diritto di studiare, modificare e ridistribuire il software in modo difficile da revocare. Per gli sviluppatori, questo significa che i tuoi miglioramenti possono restare disponibili per gli altri sotto le stesse condizioni, invece di essere assorbiti in un prodotto chiuso senza che la comunità ne tragga beneficio.
Con la GPL puoi:
Per questo la GPL è spesso descritta come “reciprocità applicabile”. Se qualcuno distribuisce un programma coperto da GPL (o un'opera derivata), non può aggiungere restrizioni che impediscano agli utenti a valle di modificare e condividere.
Questi diritti comportano obblighi quando distribuisci software:
Queste responsabilità non sono “trappole”: sono il meccanismo che impedisce che la collaborazione diventi estrazione unidirezionale.
I team dovrebbero trattare la conformità delle licenze come l'igiene del rilascio. Tracciare:
Un semplice Software Bill of Materials (SBOM) e una checklist ripetibile per i rilasci possono prevenire la maggior parte dei problemi molto prima che intervengano i legali.
A livello di codice, “software libero” e “open source” spesso descrivono molti degli stessi progetti. La differenza riguarda soprattutto perché la condivisione è importante.
Il movimento del Software Libero (associato a Richard Stallman e alla Free Software Foundation) considera la libertà del software una questione etica: gli utenti dovrebbero avere il diritto di eseguire, studiare, modificare e condividere il software. Non è solo migliore ingegneria: è la protezione dell'autonomia degli utenti.
L'approccio Open Source enfatizza risultati pratici: maggiore collaborazione, iterazioni più veloci, meno bug e miglior sicurezza grazie alla trasparenza. È comodo presentare l'apertura come un modello di sviluppo superiore senza dover assumere una posizione morale.
Nel 1998 l'Open Source Initiative (OSI) ha popolarizzato il termine “open source” per renderlo più appetibile alle aziende. “Software libero” veniva spesso frainteso come “senza costo” e alcune aziende diffidavano di un messaggio centrato su diritti ed etica. “Open source” ha dato alle organizzazioni un modo per dire “possiamo lavorare così” senza apparire ideologici.
Molti progetti che si definiscono open source usano la GNU GPL o altre licenze copyleft, mentre altri scelgono licenze permissive come MIT o Apache. Il testo legale può essere lo stesso; cambia la storia raccontata ai contributori, agli utenti e ai clienti. Un messaggio è “questo protegge le tue libertà”, un altro è “questo riduce l'attrito e migliora la qualità”.
Se la priorità del tuo team è garantire che gli utenti a valle mantengano le stesse libertà, orientati verso il software libero e considera il copyleft.
Se la priorità è massimizzare l'adozione (incluso da aziende che potrebbero non volere obblighi reciproci), l'inquadratura open source — e spesso una licenza permissiva — può essere più adatta.
Se vuoi ampia collaborazione ma vuoi anche che i miglioramenti ricadano nella comunità, usa un linguaggio open source per approcciare il pubblico e scegli una licenza copyleft per il risultato.
Software libero non significa “nessuno viene pagato”. Significa che gli utenti hanno la libertà di eseguire, studiare, modificare e condividere il codice. Molte aziende costruiscono ricavi sani intorno a quella libertà — spesso offrendo servizi per problemi reali: affidabilità, responsabilità e tempo.
Alcuni modelli comprovati:
Una svolta moderna nel modello “offerta gestita” è l'ascesa di piattaforme che generano e avviano applicazioni rapidamente. Per esempio, Koder.ai è una piattaforma vibe-coding che aiuta i team a costruire app web, backend e mobile via chat — supportando al contempo l'esportazione del codice sorgente. Questa combinazione (iterazione rapida più proprietà del codice) si allinea ai valori della libertà del software: la possibilità di ispezionare, cambiare e spostare il tuo software quando necessario.
La scelta di licenza può determinare chi cattura il valore:
“Commerciale” descrive come si vende; “software libero” descrive i diritti dell'utente. Un'azienda può vendere software libero, offrire supporto a pagamento e rispettare comunque la libertà del software.
Prima di adottare o basare un prodotto su un progetto FOSS, chiediti:
La GPL e il “FOSS” sono spesso discussi, ma alcuni miti ricorrenti confondono — specialmente per team che vogliono solo distribuire un prodotto senza violare licenze.
Non è così. Il pubblico dominio significa che non c'è un titolare del copyright che impone condizioni — chiunque può riutilizzare l'opera senza obblighi.
La GNU GPL è l'opposto del “nessuna condizione”. L'autore mantiene il copyright e concede ampie autorizzazioni a usare, modificare e condividere — ma solo se rispetti i termini della GPL (in particolare condividere il sorgente quando distribuisci i binari coperti).
Rendere il codice visibile può aiutare la sicurezza, ma non la garantisce. Un progetto open source può comunque essere:
La sicurezza viene da manutenzione attiva, audit, disclosure responsabile e buone pratiche operative — non dall'etichetta di licenza.
Si parla spesso della GPL come “virale” per suggerire che si diffonde incontrollata in tutto ciò che tocca. È una metafora carica.
Si riferisce in genere al copyleft: se distribuisci un'opera derivata del codice GPL, devi fornire il sorgente corrispondente sotto GPL. Quella clausola è deliberata: preserva le libertà degli utenti a valle. Non è un'infezione; è una condizione che puoi scegliere di accettare — o evitare usando codice con licenza diversa.
Una regola pratica: gli obblighi scattano principalmente sulla distribuzione.
Quando è rilevante, ottieni una lettura precisa basata su come il codice è combinato e distribuito — non affidarti a soli assunti.
Richard Stallman è una figura controversa. Si può riconoscerlo e allo stesso tempo parlare chiaramente dell'influenza duratura delle idee e delle licenze a lui associate.
Un punto utile è separare due conversazioni: (1) i dibattiti su Stallman come persona e membro della community; (2) l'impatto misurabile dei principi del software libero, del Progetto GNU e della GNU GPL sulle licenze software e sui diritti degli sviluppatori. Il secondo può essere discusso con fonti primarie (testi di licenza, storie di progetto, pattern di adozione) anche quando le opinioni sulla prima sono forti.
Una critica ricorrente non riguarda le licenze ma la governance: come i progetti prendono decisioni, chi ha autorità e cosa succede quando fondatori, maintainer e utenti vogliono cose diverse. Le comunità del software libero si sono confrontate con domande come:
Queste questioni contano perché le licenze stabiliscono termini legali, ma non creano automaticamente processi decisionali sani.
Un altro dibattito riguarda inclusività e norme comunitarie: come i progetti definiscono comportamenti rispettosi, come gestiscono conflitti e quanto siano accoglienti per i nuovi arrivati. Alcune community adottano codici di condotta formali; altre preferiscono regole minime e moderazione informale. Nessun approccio è automaticamente “giusto”, ma i compromessi sono reali e vanno discussi senza attacchi personali.
Se valuti l'eredità di Stallman, aiuta mantenere le affermazioni verificabili: cosa richiede la GPL, come il copyleft ha cambiato le pratiche di conformità e come queste idee hanno influenzato licenze e istituzioni successive. Puoi essere critico, favorevole o indeciso — mira sempre a precisione, rispetto e chiarezza su ciò che si sta criticando.
Il dono pratico più grande di Stallman per i team di tutti i giorni è una domanda chiara: quali libertà vuoi garantire a valle? Rispondere a questa domanda trasforma la “scelta della licenza” da sensazione in decisione.
Se sei indeciso, decidi in base all'obiettivo: adozione (permissiva) vs reciprocità (copyleft) vs reciprocità compatibile con librerie (copyleft debole).
LICENSE nella radice del repo (copia il testo completo della licenza).Se costruisci prodotti usando sviluppo assistito dall'AI (inclusi strumenti chat come Koder.ai), questa checklist è ancora più importante: stai comunque distribuendo dipendenze reali, artefatti reali e obblighi di licenza reali. La velocità non rimuove la responsabilità — la rende solo più utile una routine di conformità ripetibile.
Rendila noiosa e ripetibile:
Per confronti più approfonditi, vedi /blog/choosing-an-open-source-license e /blog/gpl-vs-mit-vs-apache.
“Software libero” significa libertà, non prezzo.
Un programma può costare $0 e rimanere comunque non libero se non puoi ispezionarlo, modificarlo o condividerlo. Il software libero si concentra sui diritti di eseguire, studiare, modificare e ridistribuire il software di cui ti servi.
La definizione si basa su quattro permessi:
Se una di queste manca, gli utenti perdono controllo e la collaborazione diventa più difficile.
Perché non puoi realisticamente studiare o modificare il software senza il codice sorgente.
L'accesso al sorgente permette:
Il copyleft usa il diritto d'autore per imporre il principio “condividi allo stesso modo” quando ridistribuisci.
Puoi usare, modificare e anche vendere il software, ma se distribuisci una versione modificata devi garantire ai destinatari le stesse libertà (di solito rilasciando il codice corrispondente sotto la stessa licenza).
La GPL concede ampi diritti (uso, studio, modifica, condivisione) e chiede reciprocità alla distribuzione.
Se ridistribuisci binari coperti dalla GPL, di norma devi:
Spesso, no.
Per il software GPL le obbligazioni scattano di solito al momento della distribuzione. Se modifichi codice GPL per uso interno e non dai copie a soggetti esterni, normalmente non sei obbligato a pubblicare le modifiche.
(Ci sono eccezioni: considera questo come una regola pratica, non consulenza legale.)
Dipende da come il codice è combinato.
In generale:
Quando conta, mappa il pattern di integrazione esatto prima di distribuire.
Si rivolgono a preoccupazioni diverse:
Scegli in base a quanto desideri reciprocità forte (GPL) o compatibilità per librerie (LGPL).
Di solito no con la GPL.
Se esegui software GPL sui tuoi server e gli utenti interagiscono solo via rete, normalmente non stai “distribuendo” copie, quindi gli obblighi di condivisione del sorgente non si attivano.
Se vuoi che l'uso via rete richieda la condivisione del sorgente, valuta l'AGPL e analizza attentamente il tuo modello di deployment.
Sì—molte aziende monetizzano software libero/aperto tramite servizi e delivery, non bloccando i diritti degli utenti.
Modelli comuni:
La scelta della licenza influenza la strategia: permissive favoriscono l'adozione; copyleft favoriscono la reciprocità e possono scoraggiare fork chiusi.