«Passiamo a Linux.» «Puntiamo sul software libero.» Queste frasi ricorrono ogni volta che un comitato affronta il tema della sovranità software, e vengono pronunciate con tono di ovvietà, come se il codice aperto risolvesse la questione per la sua stessa natura. Ne risolve una parte. Ne lascia un’altra intatta e, a volte, sposta il problema senza risolverlo. La sovranità non si gioca sull’opposizione tra software proprietario e libero. Si gioca strato per strato: chi controlla cosa e se è possibile uscirne.

Ciò che l’open source garantisce realmente

Il software libero si basa su quattro libertà, formalizzate dalla Free Software Foundation: eseguire il programma per qualsiasi scopo, studiarne il funzionamento, ridistribuirlo e modificarlo per poi diffondere le versioni modificate. L’open source, definito dall’Open Source Initiative, copre un ambito simile. Queste libertà non sono teoriche. Esse producono tre proprietà concrete.

Innanzitutto, la verificabilità. Il codice sorgente è leggibile, quindi verificabile. Un’organizzazione che lo desideri può far esaminare ciò che un software esegue realmente, senza affidarsi alla parola dell’editore. Per un settore regolamentato, questa trasparenza ha valore probatorio.

In secondo luogo, l’assenza di una licenza revocabile. Una licenza libera, GPL, Apache, MIT, non decade per decisione unilaterale. L’editore non può interrompere l’accesso a una versione già ottenuta, né vietarne l’uso da un giorno all’altro. La continuità non dipende dalla buona volontà di terzi.

Infine, la possibilità di creare un fork. Se il progetto cambia rotta, chiude o cade in mani ostili, il codice rimane disponibile e qualcuno può riprenderne lo sviluppo. La comunità di manutenzione, quando esiste, ripartisce questo onere tra diversi contributori e diverse organizzazioni.

Cosa non garantisce

Nessuna di queste libertà è un servizio. Il codice aperto non viene fornito con alcun supporto, né con garanzie di correzione, né con una roadmap. La libertà di modificare vale solo per chi sa come farlo, e la libertà di verificare vale solo per chi ne ha i mezzi. Leggere il codice sorgente di un kernel, di un hypervisor o di un database per assicurarsi che non contenga vulnerabilità richiede competenze rare e un impegno costante. Il codice disponibile non è il codice verificato.

La sicurezza segue la stessa logica. Un software libero non è sicuro solo perché è aperto; è sicuro quando persone competenti lo leggono, lo testano e lo correggono nel tempo. L’episodio della vulnerabilità critica di log4j nel 2021, componente presente in innumerevoli sistemi e mantenuto da una manciata di volontari, ha ricordato che un componente aperto e onnipresente può rimanere sottofinanziato e poco monitorato. L’apertura rende possibile l’audit, ma non lo realizza.

Soprattutto, l’open source non dice nulla sull’infrastruttura. Un software libero viene sempre eseguito da qualche parte, su macchine, in una rete, sotto una giurisdizione. La licenza del codice e l’appartenenza giuridica del provider di hosting sono due questioni distinte, e la prima non risponde mai alla seconda.

I casi in cui l’OSS cambia davvero qualcosa

Il software libero incide sulla sovranità quando agisce sulle leve giuste. Tre situazioni lo dimostrano.

L’implementazione locale. Un software libero installato su un’infrastruttura controllata dall’organizzazione elimina la dipendenza da un fornitore di servizi remoto. Il codice è in loco, soggetto a una giurisdizione scelta, senza ricorsi verso terzi. È il caso che più si avvicina alla reale indipendenza.

La verificabilità normativa. Per un’autorità sanitaria, una banca, un operatore di importanza vitale, poter produrre il codice esatto che tratta i dati sensibili non è un semplice vantaggio, ma talvolta un obbligo. Un componente proprietario sigillato impedisce tale prova; un componente aperto la consente.

L’assenza di una licenza revocabile. Un servizio proprietario critico può vedere modificate le proprie condizioni, aumentare il proprio prezzo o vedersi interrotto l’accesso per decisione di un editore o in seguito a una misura di extraterritorialità. La licenza libera sottrae a questo rischio il livello software stesso. Non sottrae il resto.

I casi in cui non cambia nulla

Al contrario, l’etichetta «open source» non offre alcuna garanzia di sovranità in diverse configurazioni comuni.

Il software libero implementato presso una terza parte. Un database o un orchestratore libero gestito come servizio gestito su un’infrastruttura estera è soggetto al diritto di tale operatore, esattamente come un prodotto proprietario. Il codice è aperto, la dipendenza rimane totale. La natura della licenza non cambia nulla in merito al vincolo giuridico di chi gestisce la macchina.

La dipendenza da componenti proprietari. Un sistema operativo libero che si avvia solo con driver proprietari, microcodici firmati o un firmware chiuso non è autonomo. Il livello visibile è aperto, ma si basa su elementi che non si possono né leggere, né riprodurre, né sostituire. La libertà si ferma al primo componente hardware sigillato.

L’assenza di capacità di manutenzione interna. La libertà di creare un fork di un kernel critico vale solo per chi è effettivamente in grado di mantenerlo. Un’azienda fortemente regolamentata o un attore del settore della difesa che non dispone delle competenze ingegneristiche per riprendere lo sviluppo di un sistema operativo dal quale l’editore si ritira si ritrova dipendente da un fornitore di servizi, aperto o meno. Il diritto di modificare non crea la capacità di modificare.

In questi tre casi, la proprietà che contava – il controllo del livello e la possibilità di uscirne – non è garantita dalla licenza. Dipende da dove gira il software, su cosa si basa e da chi sa gestirlo.

La domanda giusta non riguarda quindi mai l’etichetta. Si pone livello per livello, dall’hardware al servizio: chi lo controlla, in base a quale diritto, e cosa succede il giorno in cui tale controllo viene meno. Il software libero sposta alcune di queste risposte nella giusta direzione. Non scrive le altre al posto vostro.

Lo Stato francese ha deciso, e questo cambia la scala

Il dibattito ha lasciato i forum. Nel 2026 la direzione interministeriale del digitale, la DINUM, chiede a ogni ministero un piano di riduzione delle dipendenze digitali extraeuropee. Il perimetro è ampio: postazioni di lavoro, strumenti collaborativi, antivirus, intelligenza artificiale, basi di dati, virtualizzazione, apparati di rete. Il passaggio del sistema operativo, da Windows a Linux, è solo lo strato più visibile di un cantiere più profondo.

Attorno all’OS, lo Stato spinge il proprio stack: Tchap per la messaggistica, Visio per la videoconferenza, FranceTransfert per i file, riuniti nella Suite numérique. L’assicurazione malattia ha già migrato 80.000 dipendenti verso questi strumenti. L’obiettivo dichiarato supera i due milioni di dipendenti entro il 2027. L’innesco non è un capriccio tecnico. Il ritorno delle tensioni commerciali nel 2025 ha riacceso la questione della giurisdizione, e quella del CLOUD Act è diventata troppo visibile per essere ignorata.

La gendarmeria l’ha fatto vent’anni fa

La novità è l’ampiezza, non il principio. La Gendarmeria nazionale gira su Linux dal 2008, con GendBuntu, una versione di Ubuntu realizzata su misura. A giugno 2024 equipaggiava 103.164 postazioni, ossia il 97 per cento del parco. Il risparmio è netto: circa due milioni di euro all’anno in meno di licenze, e un costo di possesso ridotto di circa il 40 per cento.

Il dettaglio che conta non è la cifra, è il metodo. La gendarmeria non è passata tutto in una volta. Ha iniziato già nel 2004 con elementi indolori, il browser, la suite per ufficio, la messaggistica, il tempo necessario perché le competenze interne e la governance si costruissero. L’OS è arrivato per ultimo, su un terreno preparato. Nel 2026 la DINUM cita esplicitamente questo modello come la via da seguire per gli altri ministeri. La sovranità del software non si compra, si costruisce, strato dopo strato, nel corso degli anni.

Aperto non vuol dire sicuro

Resta una trappola, ed è esattamente quella che questo articolo segnala fin dall’inizio. Scegliere Linux e l’open source toglie una dipendenza. Non offre la sicurezza in regalo. Uno strumento sovrano non è uno strumento sicuro per costruzione. Va ancora verificato, irrobustito, mantenuto, con tutto il rigore che si applica a qualsiasi software proprietario, a volte di più, poiché la responsabilità non si appalta più a un fornitore.

La messaggistica dello Stato l’ha imparato a proprie spese, scoprendo che l’origine francese e il codice aperto non dispensavano mai dal lavoro di messa in sicurezza. È anzi il contrario: la libertà di guardare sotto il cofano impone il dovere di farlo. L’open source rende la sicurezza verificabile, non la garantisce. Chi non verifica eredita una dipendenza che credeva di aver eliminato, con in più l’illusione di essere protetto.

È tutto il senso di «non basta». Linux è una condizione, non una risposta. La risposta sta in ciò che si fa della libertà che esso rende possibile: la competenza che si conserva, gli strati che si controllano davvero, e la sicurezza che ci si assume invece di delegarla.

Fonti

  • Free Software Foundation, definizione di software libero, gnu.org
  • Open Source Initiative, Open Source Definition, opensource.org
  • Apache Software Foundation, vulnerabilità Log4Shell (CVE-2021-44228), dicembre 2021
  • ANSSI, raccomandazioni sulla sicurezza delle piattaforme software, cyber.gouv.fr