La Scala della Sovranità del Software
Traduzione dell'articolo originale The Software Sovereignty Scale di Dries Buytaert, pubblicato il 10 febbraio 2026. Tutti i diritti riservati all'autore.
La sovranità digitale dipende meno da dove proviene il software e più da chi lo controlla. Questo articolo introduce una scala che mostra quali tecnologie non possono mai essere sottratte.
“Compra europeo” sta diventando il grido di battaglia dell’Europa per la sovranità digitale. La logica è intuitiva: se vuoi essere indipendente dalla tecnologia americana, acquista da aziende europee. Tuttavia, penso che “Compra europeo” abbia ragione su una cosa e torto su un’altra. Ha ragione nel ritenere che l’Europa tragga beneficio da un’industria tecnologica più forte. Ma acquistare europeo non garantisce la sovranità.
La sovranità non riguarda dove ha sede un’azienda o dove è stato originariamente scritto il software. Riguarda se si mantiene la “libertà d’azione” sulla tecnologia da cui si dipende, anche se il fornitore cambia strategia, viene acquisito o scompare.
La domanda giusta da porsi riguardo a qualsiasi tecnologia è: se le condizioni cambiano, si mantiene la libertà di continuare a usare, modificare e mantenere questo software?
Quando si valuta la sovranità, non è sufficiente chiedersi quanta libertà si ha oggi. Bisogna anche chiedersi quanta di quella libertà è strutturalmente protetta, incorporata nelle fondamenta legali e comunitarie, in modo che non possa essere tolta domani.
La scala proposta misura la protezione strutturale. Non è una classifica di apertura, né cattura ogni dimensione della sovranità. La scala non implica nemmeno che una licenza sia sempre migliore di un’altra. La distinzione più importante nella scala è tra Open Source e proprietario. Tutti e tre i livelli verdi danno libertà d’azione: il diritto di usare, modificare e mantenere il software in modo indipendente, per sempre. Le differenze tra A, B e C riflettono quanto quella libertà sia strutturalmente protetta contro acquisizioni, riconcessioni di licenza o cambiamenti nell’ecosistema. Determinano anche quanto si rischi di restare indietro se la direzione del progetto cambia.
Ho usato cinque livelli, modellati sulle familiari etichette A–E europee per l’efficienza energetica e la nutrizione alimentare, dal sovrano strutturale al completamente dipendente. Quadri di riferimento come il Cloud Sovereignty Framework della Commissione Europea non fanno ancora queste distinzioni strutturali. Questa scala mira a migliorare ciò che esiste e viene usato oggi, e mi aspetto che migliori ulteriormente attraverso critiche e feedback.
| Tipo | Può qualcuno sottrarlo? | Esempi |
|---|---|---|
| A — Copyleft + nessun rischio di relicensing | No. Il codice non può essere riconsolidato, e tutti i derivati devono essere Open Source per sempre. | Linux, Drupal, WordPress |
| B — Copyleft + rischio di relicensing | No. Tutti i derivati devono essere Open Source. Ma le versioni future possono essere riconsolidate se il copyright è concentrato. | MySQL → MariaDB |
| C — Open Source permissivo | No. Ma la licenza consente derivati proprietari che possono spostare il valore lontano dal progetto aperto. | Redis (riconsolidato), Valkey (fork) |
| D — Software proprietario europeo | Sì. Una singola acquisizione trasferisce tutto il controllo. I finanziamenti possono scomparire. Sei un cliente, non uno stakeholder. | Skype |
| E — Software proprietario straniero | Già sottratto. Soggetto ai prezzi, alla roadmap del fornitore e alla giurisdizione del suo governo. Sei un cliente, non uno stakeholder. | Microsoft, Oracle, Salesforce |
Gli obblighi giurisdizionali cambiano con la proprietà
In fondo, al livello E, c’è il software proprietario straniero: nessun codice sorgente, nessun diritto di modifica, e nessuna alternativa se il fornitore cambia i termini. Il tuo fornitore è soggetto alla giurisdizione del suo governo d’origine, e di conseguenza lo sono anche i tuoi dati.
Il livello D è il software proprietario europeo, che è dove di solito entra in gioco il “Compra europeo”. Ha vantaggi reali: giurisdizione europea, allineamento al GDPR, responsabilità locale e mantiene gli investimenti in circolazione nell’ecosistema europeo. Come qualcuno che ha fondato aziende e investe in startup, voglio che più aziende tecnologiche abbiano successo, non meno.
Ma “europeo” può essere una proprietà temporanea di un’azienda: può cambiare con una singola riunione del consiglio di amministrazione. Skype è stata fondata da uno svedese e un danese, costruita da ingegneri estoni e con sede in Lussemburgo. eBay la acquisì nel 2005, e Microsoft la acquisì nel 2011. La transazione con eBay trasformò una tecnologia europea leader mondiale in una americana, e questo fu consolidato con l’accordo con Microsoft.
Quindi la proprietà e la giurisdizione contano, ma non sono sufficienti. Un’azienda europea può essere acquisita domani. L’Open Source offre qualcosa di più importante: separa il codice da qualsiasi singola azienda o paese.
Non tutto l’Open Source è ugualmente sovrano
L’Open Source è ciò che rende possibile la vera sovranità. Al tempo stesso, la sovranità Open Source esiste su uno spettro. Il livello di protezione dipende da due leve legali: la licenza stessa e la proprietà del copyright, che determina chi ha il potere di cambiare la licenza.
Il livello C è Open Source sotto una licenza permissiva come BSD, MIT o Apache. Puoi vedere il codice e farne un fork se necessario, ma la licenza non richiede che i miglioramenti rimangano aperti. Un’azienda può prendere il codice, costruirci sopra e rilasciare una versione proprietaria. Il rischio di relicensing si applica principalmente a progetti a singolo fornitore. Quando un progetto permissivo è ospitato presso una fondazione neutrale rispetto ai vendor come Apache o Eclipse, la fondazione detiene la governance e il rischio di relicensing è minimizzato. Il rischio di relicensing nel livello C deriva principalmente dal controllo aziendale, non dalla licenza stessa.
Redis mostra come si svolge questa dinamica. Era Open Source sotto licenza BSD per quindici anni. Nel marzo 2024, Redis Ltd. l’ha riconsolidata sotto termini restrittivi che la Open Source Initiative non approva come Open Source. Fortunatamente, la comunità ha fatto un fork dell’ultima versione aperta come Valkey, e Valkey è in forte crescita. Questa è la forza dell’Open Source permissivo: puoi fuggire quando i termini cambiano. I governi sono stati fortunati che Redis sia stato forkato, ma il rischio strutturale rimane, e in molti casi gli utenti finali non sono così fortunati. Si trovano a mantenere il software da soli, il che può essere costoso e insostenibile.
Il livello B è Open Source sotto una licenza copyleft come la GPL. Il copyleft aggiunge una protezione che le licenze permissive non hanno: qualsiasi derivato del codice rilasciato deve rimanere Open Source. Per i responsabili politici, questo è un aggiornamento significativo.
Questo è il livello che ha salvato MySQL. MySQL AB, l’azienda svedese dietro MySQL, lo ha rilasciato sotto la GPL, quindi quando Oracle ha acquisito MySQL attraverso l’accordo con Sun Microsystems, la GPL ha garantito che il codice rimanesse aperto. Michael Widenius, il creatore originale di MySQL, ha preso il codice e costruito MariaDB. Oracle ha ottenuto il marchio, ma il mondo ha mantenuto il codice. E poiché MariaDB ha ereditato la licenza GPL di MySQL, deve rimanere aperta. Nessun futuro acquirente può rendere MariaDB proprietaria. Questa è la differenza tra copyleft e una licenza permissiva: il copyleft permette a qualcuno di fare un fork e costringe tutti i fork a rimanere aperti.
Ma il livello B ha ancora una limitazione. Quando il copyright è concentrato, il titolare può rilasciare versioni future sotto una licenza diversa. Il codice esistente è protetto dalla GPL, ma la direzione futura del progetto dipende da chi detiene il copyright e da come è governato. Una fondazione neutrale rispetto ai vendor che detiene il copyright comporta un rischio molto inferiore rispetto a una singola azienda. Alcuni progetti amplificano questo rischio richiedendo ai contributori di firmare un Contributor License Agreement, o CLA, che concede al proprietario del progetto il diritto di riconsolidare il codice contribuito. Elasticsearch, fondata ad Amsterdam, ha usato il suo CLA nel 2021 per riconsolidare da Apache 2.0 a una licenza non open source, nonostante avesse oltre 1.500 contributori.
Infine, il livello A è Open Source copyleft senza rischio di relicensing. Questo accade tipicamente quando il copyright è governato da una fondazione neutrale, o quando centinaia o migliaia di contributori possiedono ciascuno la propria porzione del codice. In quel caso, il relicensing richiederebbe il consenso di ogni contributore, e qualsiasi rifiuto costringerebbe il progetto a riscrivere quel codice da zero. Più la proprietà è distribuita, più difficile diventa il relicensing. Drupal ha avuto contributi da decine di migliaia di persone in 25 anni, il che rende strutturalmente impossibile il relicensing. Nessuna acquisizione, nessun voto del consiglio, nessun cambiamento di strategia può sottrarre questi progetti alle persone che li costruiscono e da cui dipendono.
I progetti copyleft con meno contributori indipendenti possono essere più facili da riconsolidare. Il codice di Drupal è strutturalmente sovrano per design.
La sovranità è un impegno a lungo termine
Passare da E a D è un progresso. Passare da D a C è ciò che conta davvero. Al di sopra di C, la scala evidenzia compromessi più piccoli ma comunque importanti, in modo che quando i governi scelgono un livello inferiore, lo facciano consapevolmente piuttosto che inconsapevolmente.
Un progetto Open Source che perde finanziamenti importanti spesso ha bisogno di investimenti per rimanere vitale. Ma a differenza dell’acquisizione o del relicensing, il rischio di finanziamento è in gran parte sotto il controllo dell’UE attraverso gli appalti pubblici e gli investimenti pubblici.
Raccomandazione per la Commissione Europea
La sovranità implica molte cose: posizione dei dati, catene di approvvigionamento, talenti tecnici e standard. Le licenze e il copyright formano la fondazione strutturale perché determinano se l’indipendenza legale è anche solo possibile.
Il Cloud Sovereignty Framework della Commissione Europea riflette questa visione più ampia. Valuta il software cloud attraverso otto obiettivi di sovranità, ciascuno con punteggio e peso in un punteggio di sovranità composito. La Sovranità Tecnologica (SOV-6), l’obiettivo che riguarda le licenze aperte, rappresenta il 15% di quel composito. Al suo interno, le licenze aperte sono uno dei fattori contributivi tra quattro, insieme agli standard aperti, alla trasparenza architettonica e all’indipendenza informatica dell’UE.
Questo sottovaluta drammaticamente ciò che conta di più: l’Open Source. Gli standard aperti, la trasparenza e l’indipendenza informatica sono capacità che il software proprietario può anche fornire. Possono cambiare se un fornitore viene acquisito o cambia strategia. Le licenze aperte creano diritti permanenti e irrevocabili di usare e modificare il software indipendentemente da ciò che accade al fornitore. È l’unico fattore contributivo all’interno della Sovranità Tecnologica (SOV-6) che rende la sovranità strutturale piuttosto che situazionale, eppure il framework non lo distingue dagli altri.
Né riconosce che le licenze aperte sono alla base degli altri obiettivi di sovranità: l’indipendenza operativa, la resilienza della catena di approvvigionamento e la flessibilità giurisdizionale dipendono tutte dal fatto di avere il diritto di spostare, modificare e mantenere il software.
Incoraggio la Commissione a rafforzare il suo obiettivo di Sovranità Tecnologica in tre modi:
Dare alle licenze aperte un peso significativamente maggiore nel punteggio di sovranità. Le licenze aperte non sono paragonabili agli altri tre fattori contributivi nella Sovranità Tecnologica. Sono l’unico che crea diritti permanenti e irrevocabili. Il framework dovrebbe riflettere ciò.
Distinguere tra tipi di licenza. Le licenze permissive (BSD, MIT, Apache) non pongono alcun obbligo ai derivati di rimanere aperti. Le licenze copyleft (GPL, AGPL) richiedono che le opere derivate siano rilasciate con gli stessi termini aperti.
Valutare la concentrazione del copyright e il rischio di relicensing. Non tutti i progetti comportano uguale rischio di relicensing. Un progetto controllato da una singola azienda può essere riconsolidato. Un progetto con proprietà del copyright distribuita, o governato da una fondazione neutrale rispetto ai vendor, è molto più resistente al relicensing. Questa è la differenza tra un impegno revocabile e uno irrevocabile all’apertura.
Le licenze aperte non sono una considerazione tra le tante. Sono la fondazione che rende duraturi tutti gli altri obiettivi di sovranità. Penso che la politica di procurement europeo dovrebbe ponderarle di conseguenza.
La Software Sovereignty Scale può aiutare: quando un governo seleziona un sistema di gestione dei contenuti per i suoi siti web pubblici o un database per i suoi registri sanitari nazionali, dovrebbe conoscere il livello di sovranità strutturale della tecnologia da cui dipende. Per il software critico, la domanda è semplice: quanto è facile per qualcuno sottrarre il software?
Un ringraziamento speciale a Sachiko Muto e Bert Boerland per la loro revisione e i contributi a questo articolo.
