«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.
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