Ieri hai aperto un bug. Un problema di margine nel renderer dei documenti, quindici righe di contesto, due screenshot. Lo hai firmato con il tuo vero nome. Il vostro profilo GitHub lo mostra; il progetto, un’iniziativa di sovranità europea, vi è sembrato esattamente il tipo di lavoro che merita una firma.

Stamattina la tua carta di credito smette di funzionare.

Quella sequenza, oggi, non è documentata. È la forma di una sequenza che gli ultimi diciotto mesi hanno reso progressivamente plausibile. Il 5 maggio 2025, l’account Microsoft 365 di Karim Khan, procuratore capo della Corte penale internazionale, ha smesso di funzionare dopo che l’amministrazione Trump lo aveva designato personalmente ai sensi dell’Executive Order 14203. Nel maggio 2026, Microsoft ha consegnato i dati personali e le comunicazioni di funzionari pubblici olandesi — regolatori incaricati di applicare il Digital Services Act dell’UE — a un mandato di comparizione del Congresso degli Stati Uniti. In entrambi i casi, le persone colpite avevano scelto, anni prima, un fornitore di servizi con sede negli USA, sulla base di un procurement istituzionale ragionevole. La conseguenza politica era una proprietà della catena di fornitura che non avevano mai sottoposto ad audit.

Oggi un’alleanza di imprese europee lancia un’alternativa a Microsoft 365. Il comunicato stampa la definisce una pietra miliare per la sovranità digitale europea. Il codice sorgente è ospitato da Microsoft. La pipeline di build gira sui server di Microsoft. Le immagini dei container sono distribuite tramite il container registry di Microsoft. Ogni contributo viene registrato nel database di Microsoft nel momento in cui viene fatto — sotto il vostro vero nome.

Non si tratta di una fuga di dati, di uno scandalo o di una svista. I repository di Euro-Office su github.com/euro-office sono apertamente osservabili. L’alleanza dietro al lancio — IONOS, Nextcloud, EuroStack, Open-Xchange, XWiki, OpenProject e altre sei rispettate organizzazioni OSS europee — ha scelto deliberatamente questo hosting, e continua a considerarlo appropriato. La copertura della stampa di settore sul lancio odierno non lo menziona. Le comunicazioni di lancio non lo menzionano. Il Tech Sovereignty Package della Commissione europea, redatto in parallelo, non lo affronta.

Vale la pena dirlo chiaramente: è assurdo. Non nel senso colloquiale di sorprendente — è, a una lettura serena della documentazione pubblica, esattamente ciò che ci si aspetterebbe — ma nel senso che ogni definizione standard di sovranità digitale prodotta dal discorso europeo negli ultimi quattro anni è incoerente con quanto è appena accaduto. O Euro-Office non è un prodotto di sovranità, oppure le definizioni di sovranità in circolazione non sono coerenti. Il lancio impone una scelta.

La versione utile di questo articolo non è l’indignazione, che si scrive da sola. È l’audit, il riinquadramento e la domanda di approvvigionamento che ne conseguono, una volta accettato che il discorso attuale sulla sovranità ha un errore portante al suo centro — e che il bug report che hai aperto ieri è, su una linea temporale sufficientemente lunga, parte della pista di audit.

Cosa viene lanciato

Euro-Office pubblica la v1.0 martedì 9 giugno 2026. L’alleanza che lo sostiene è tecnicamente coerente: IONOS ospita la variante managed cloud da Karlsruhe, Nextcloud integra la suite in Hub 26 come sostituto predefinito di Collabora, Open-Xchange porta l’eredità del groupware, mentre XWiki, OpenProject, Soverin, Abilian, BTactic e Office.eu contribuiscono ai livelli adiacenti di collaborazione e hosting.

I quattro repository principali su github.com/euro-office — eurooffice-nextcloud (PHP, AGPL-3.0), server (JavaScript, AGPL-3.0), sdkjs-forms (JavaScript, AGPL-3.0) e document-templates (Apache-2.0) — adottano la postura di licenza difensiva appropriata per un software offerto come servizio: qualsiasi provider commerciale che eroghi un Euro-Office ospitato deve pubblicare le proprie modifiche. L’Apache-2.0 sui template è la scelta corretta per i contenuti. È la combinazione di licenze più forte nel mercato europeo delle suite di produttività OSS, materialmente più solida della MPL-2.0 di Collabora Online o dell’AGPL a fornitore unico di OnlyOffice.

La compatibilità con il formato Office Open XML regge sui carichi di lavoro che storicamente hanno fatto saltare le migrazioni OSS europee: cartelle Excel multi-foglio con tabelle pivot, documenti Word con revisioni e commenti, PowerPoint con animazioni incorporate. Le opzioni di deployment disponibili coprono managed cloud, ibrido e self-hosted Docker o Kubernetes, sul Proxmox o VMware del cliente. La storia di sovranità a runtime è reale: dati nei data center tedeschi, licenze protette da fork closed-source, indipendenza di formato dalla cadenza di rilascio di Microsoft.

Su questo punto non c’è asterisco. Il prodotto è buono. La decisione di procurement come decisione di prodotto è difendibile.

L’audit

La decisione di procurement come decisione di sovranità è il punto in cui l’architettura smette di collaborare.

Ogni commit a ogni repository di Euro-Office, ogni issue, ogni pull request, ogni esecuzione di pipeline CI/CD, ogni build di immagine container e ogni release artefact passa attraverso github.com. GitHub è una controllata interamente di proprietà di Microsoft dal giugno 2018. Le comunicazioni di lancio non lo affrontano. La copertura della stampa di settore sul lancio non lo affronta. L’alleanza non si è impegnata a fornire un mirror Codeberg o Forgejo, e non ha annunciato l’intenzione di operare una pipeline di build non statunitense.

Non è un problema contrattuale — la licenza AGPL preserva il diritto di fare mirror, di forkare e di ricostruire — è un problema operativo. Il diritto di fare mirror è inutile finché il mirror non esiste.

Il precedente di enforcement è documentato e specifico. Nel luglio 2019, GitHub ha ristretto l’accesso ai repository privati e agli account organizzativi a pagamento per gli sviluppatori in Iran, Siria e Crimea, in conformità con le sanzioni dell’OFAC. I progetti privati sono spariti dall’oggi al domani. I repository pubblici sono rimasti accessibili in sola lettura, ma l’infrastruttura operativa — issue tracker, pull request, GitHub Actions, immagini container, distribuzione dei pacchetti — è rimasta non disponibile per gli account interessati finché GitHub non ha ottenuto una licenza OFAC per ripristinare il servizio agli sviluppatori iraniani nel gennaio 2021. Tra marzo e aprile 2022, lo stesso meccanismo è stato applicato a entità in Russia e a porzioni occupate dell’Ucraina sotto designazione OFAC. Gli account associati a entità sanzionate hanno perso l’accesso; gli account organizzativi a pagamento in Crimea, Donetsk e Luhansk sono rimasti soggetti a restrizioni. Le Acceptable Use Policies di GitHub citano ancora la compliance al controllo delle esportazioni USA come regola governante.

La probabilità che questo meccanismo di enforcement si applichi a un’azienda municipalizzata tedesca o a un établissement public francese in un dato trimestre è bassa. La probabilità su un orizzonte di procurement quinquennale, contro uno stack Euro-Office con diverse centinaia di dipendenze OSS upstream mantenute a livello globale, è materialmente superiore allo zero. Il tasso base rilevante non sono i casi da titolo — Iran, Russia, Crimea — ma la coda lunga: una qualsiasi dipendenza critica, ospitata da un qualsiasi sviluppatore in una qualsiasi giurisdizione che diventi rilevante per OFAC per una qualsiasi delle dozzine di ragioni plausibili nell’arco di cinque anni. La maggior parte di questi eventi non riguarderà chi adotta Euro-Office. Alcuni sì.

Esiste una seconda categoria di esposizione della catena di fornitura, operativamente più probabile dell’enforcement sanzionatorio: la pressione politica sull’operatore della piattaforma che produce una compliance volontaria. Il pattern di compliance Microsoft 2025–2026 — la sospensione delle email del procuratore della CPI del maggio 2025 dopo le sanzioni USA, la consegna volontaria dei nomi dei regolatori olandesi al Congresso USA nel maggio 2026 — si colloca in questa colonna. Quando un service provider con sede USA affronta una pressione politica USA, la risposta è la compliance, non la resistenza. GitHub ha la stessa architettura. Una futura amministrazione USA che decidesse che i progetti europei di sovranità meritano attenzione non avrebbe bisogno dell’OFAC. Le Acceptable Use Policies di GitHub sono motivo sufficiente per la restrizione, a discrezione della piattaforma stessa.

La conclusione dell’audit è semplice e poco lusinghiera: un’adozione di Euro-Office senza SBOM, senza infrastruttura di mirror e senza piano di continuità non è architettonicamente più sovrana del deployment M365 che sostituisce. È contrattualmente più sovrana — i dati sono a Karlsruhe, la licenza è AGPL — ma la catena di fornitura termina sulla stessa piattaforma di repository di proprietà Microsoft su cui terminerebbe la distribuzione del sorgente di M365, se il sorgente di M365 fosse disponibile, cosa che non è.

Le persone dentro l’audit

L’argomento architettonico, fino a qui, ha trattato il rischio in termini istituzionali — cosa succede a un’azienda municipalizzata, cosa succede a una decisione di procurement. Lo stesso argomento atterra in modo diverso quando parte dalle persone i cui nomi sono documentati.

Prendiamo Khan per primo. La CPI è un’istituzione internazionale permanente, con sede all’Aia, fuori dalla giurisdizione USA. Le comunicazioni del suo procuratore capo erano su Microsoft 365 perché la CPI aveva preso la stessa decisione di procurement che ogni altro grande acquirente del settore pubblico in Europa stava prendendo nello stesso periodo, sulla stessa base — ragionevole all’epoca. Quando l’amministrazione Trump ha designato Khan ai sensi dell’Executive Order 14203 nel febbraio 2025, né il procuratore né la corte avevano un’opzione operativa significativa: Microsoft è un’azienda con sede USA, l’obbligo OFAC è vincolante, la sospensione ne è seguita. La decisione di procurement era stata presa anni prima; la conseguenza è arrivata a maggio, nominale e personale.

Il caso ACM/AP differisce da quello di Khan in un punto importante. Non c’è stato un Executive Order. Il mandato di comparizione è arrivato dalla Weaponization Subcommittee di Jim Jordan della House Judiciary, il cui mandato dichiarato è esaminare ciò che essa stessa definisce «foreign censorship of American speech» — un linguaggio che, per come si autoinquadra, include il Digital Services Act dell’UE e il lavoro dei funzionari pubblici dell’Authority for Consumers and Markets (ACM) e dell’Autoriteit Persoonsgegevens (AP) i cui nomi Microsoft ha consegnato. La sottosegretaria di Stato olandese per la sovranità digitale, Willemijn Aerdts, ha convocato l’ambasciatore USA il venerdì in cui la rivelazione è diventata pubblica. I dati erano già in viaggio. La compliance di Microsoft è stata volontaria in senso giuridico — l’azienda stava rispondendo a un mandato di comparizione, non a un ordine OFAC — e operativamente inevitabile nello stesso modo in cui lo sarebbe stata la compliance di qualunque fornitore di servizi con sede USA, sotto la medesima pressione politica.

Né Khan né il personale di ACM e AP aveva scelto di trovarsi sulla superficie della pressione politica USA. Avevano scelto Microsoft come fornitore di servizi, anni prima, sulla base di un procurement istituzionale del tutto ragionevole. La superficie politica era una proprietà della catena di fornitura che non avevano sottoposto ad audit.

È lo strato su cui ora si trovano i contributori e gli adottanti di Euro-Office.

Ogni sviluppatore che apre una pull request contro github.com/euro-office crea un record nel database di Microsoft che lega la sua identità personale — nome legale sulla maggior parte degli account, indirizzo email reale, indirizzo IP per sessione, pattern temporali di contribuzione — a una partecipazione attiva in un progetto europeo di sovranità digitale che elementi del Congresso USA hanno pubblicamente inquadrato come avversario degli interessi commerciali americani. Il lavoro quotidiano del contributore, il datore di lavoro, il paese di residenza e l’affiliazione politica sono inferibili dalla cronologia pubblica dei commit. Oggi l’inquadramento è retorico. Il caso Khan e il caso ACM/AP dimostrano che lo scarto tra inquadramento retorico e conseguenza personale è, al massimo, largo un Executive Order.

Ogni pubblica amministrazione che adotta Euro-Office eredita, transitivamente, la stessa catena di logging. Ogni responsabile IT che commenta su una issue upstream vede la propria posizione professionale pubblicamente legata al progetto. Ogni sviluppatore di un’azienda municipalizzata che apre un bug report ha la propria identità registrata nella pista di audit di Microsoft. Il CISO comunale che scrive all’alleanza per un chiarimento di sicurezza, il responsabile della protezione dei dati che chiede di un caso limite sulla compliance all’esportazione — ogni interazione è registrata sotto un nome reale, su infrastruttura di proprietà dell’azienda da cui il progetto dovrebbe far migrare.

Nulla di tutto questo è malevolo da parte di Microsoft. È la meccanica di base della gestione di un servizio di code hosting. È anche la meccanica di base di un futuro mandato di comparizione. Il caso Khan mostra cosa succede quando un Executive Order USA nomina un individuo. Il caso ACM/AP mostra cosa succede quando un mandato di comparizione del Congresso USA nomina una categoria. In entrambi i casi, le persone colpite lo hanno appreso dopo che Microsoft aveva già rispettato la richiesta.

L’implicazione strategica è priva di sentimentalismo. Chiunque — individualmente o istituzionalmente — partecipi al progetto europeo di sovranità a livello di contributore o adottante mentre è ospitato su infrastruttura Microsoft sta creando una pista di audit sotto il proprio nome, sulla piattaforma della parte da cui il progetto dovrebbe ridurre la dipendenza. La pista viene creata oggi, in tempo reale, su ogni commit e su ogni commento a un’issue. Non serve che la parte che vi ha accesso agisca su quella pista perché la pista sia portante — basta che esista.

Orwell avrebbe apprezzato l’architettura. Un movimento si organizza per ridurre la propria dipendenza da un’entità. Per farlo, ogni partecipante firma il proprio contributo, con il proprio vero nome, su una piattaforma di proprietà di quell’entità. L’entità conserva le firme indefinitamente, ricercabili, esportabili su richiesta legale. Se l’entità agirà mai su di esse è, nel medio termine, secondario; se l’architettura permetta all’entità di agire su di esse è, nel medio termine, già deciso. Si decide ora, con ogni issue ticket, da chiunque clicchi submit.

La sovranità non è ciò che si compra

È il riinquadramento che il lancio rende difficile da evitare.

L’industria del procurement ha addestrato la domanda riducendola a un problema di selezione del fornitore. Il GDPR, il CLOUD Act, il Tech Sovereignty Package, la modifica al §58 VgV, il modello di maturità ES³ — tutti questi strumenti accettano l’assunto che la sovranità sia una proprietà che l’acquirente acquisisce scegliendo il fornitore giusto. ES³ certifica fornitori. CADA classifica fornitori. Il §58 VgV permette agli acquirenti di preferire certi fornitori. Gli strumenti sono coerenti dentro quell’assunto.

Il lancio di Euro-Office è il caso più chiaro dove l’ipotesi fallisce visibilmente. Il prodotto è la migliore risposta disponibile alla domanda sul fornitore. Adottarlo senza lavoro architettonico cambia il fornitore in fattura e lascia invariata la dipendenza reale. Il fornitore in fattura è ora europeo; la catena di fornitura da cui dipende non lo è. L’acquirente ha acquisito l’apparenza della sovranità senza la sostanza, e la sostanza — la continuità della catena di fornitura — non era mai stata in offerta nel contratto di procurement.

La sovranità, nel senso che conta per la domanda a cui gli acquirenti del settore pubblico e del privato regolato stanno cercando di rispondere, non è una proprietà dei fornitori. È una proprietà delle architetture. Un’organizzazione è digitalmente sovrana nella misura in cui può continuare a operare quando un qualsiasi singolo pezzo della sua catena di fornitura software diventa non disponibile. Quella proprietà si costruisce, non si compra. La decisione sul fornitore è a monte; il lavoro di diventare sovrani è a valle. Saltare il lavoro a valle e chiamare la decisione a monte una risposta di sovranità è l’errore che il lancio di Euro-Office rende impossibile ignorare.

La conseguenza pratica: lo stack Microsoft 365 e lo stack Euro-Office non sono strutturalmente diversi sulla dimensione della catena di fornitura. Si differenziano sulla dimensione runtime (posizione dei dati, giurisdizione dell’operatore) e si differenziano sull’opzione di costruire indipendenza nella catena di fornitura. M365 preclude l’opzione; Euro-Office la preserva. Ma preservare un’opzione non è la stessa cosa che esercitarla. L’esercizio è il lavoro.

La domanda di approvvigionamento che conta davvero

Se la domanda sulla sovranità è propriamente architettonica, la domanda di approvvigionamento segue. Non è più da quale fornitore compriamo? Diventa: qual è la nostra architettura di indipendenza, e dove si colloca nel nostro conto economico?

Tre workstream rispondono alla domanda riformulata. Non sono opzionali, non sono «nice to have», e qualsiasi procurement di sovranità che li ometta è una recita di procurement, non una decisione di procurement.

Uno: inventario. Un audit Software Bill of Materials dei componenti OSS attualmente in produzione, esteso a ogni sistema con esposizione runtime a internet o ai dati dei clienti. Output per componente: endpoint di distribuzione primaria, licenza, profondità dell’albero delle dipendenze, giurisdizione del maintainer. Per un’organizzazione di medie dimensioni che esegue 50–80 componenti OSS distinti in produzione, l’audit richiede 6–10 settimane e costa 25.000–55.000 euro a uno specialista esterno. Il deliverable è una lista, non un piano; il piano deriva dalla lista. La maggior parte delle organizzazioni scopre che l'80% della propria esposizione di catena di fornitura si concentra nel 15% dei componenti, e che la concentrazione non è dove ci si aspettava.

Due: infrastruttura di mirror. Un’istanza Forgejo self-hosted, sincronizzata bidirezionalmente con GitHub per i componenti critici identificati nel workstream uno. Ospitata nell’infrastruttura esistente (Proxmox, VMware o una VM Hetzner), due VM, separate dalla produzione. Il costo in denaro è trascurabile; il lavoro è di 8–15 giorni-uomo di tempo architetto su dodici settimane, a seconda del numero di repository. Il mirror non sostituisce GitHub per lo sviluppo quotidiano; sopravvive a GitHub per la continuità. Codeberg può sostituirlo dove il self-hosting Forgejo non sia giustificato.

Tre: pilota. Un pilota Euro-Office circoscritto su un workflow senza esposizione al pubblico — finanza, HR interno, groupware controllato — eseguito per 6–12 mesi con criteri espliciti di go/no-go legati al raggiungimento di affidabilità production-grade da parte dell’infrastruttura di mirror. Costo: 8.000–20.000 euro in supporto di setup da un partner Nextcloud più il tempo interno. Il pilota valida il prodotto; i workstream uno e due validano la sovranità.

Un acquirente che esegue tutti e tre ha comprato Euro-Office e costruito sovranità. Un acquirente che esegue solo il workstream tre ha comprato un fornitore diverso. La decisione di procurement è la stessa in entrambi i casi. La decisione di architettura no.

La domanda di posizionamento strategico per i prossimi dodici mesi non è se Euro-Office sia il prodotto giusto. È se la vostra organizzazione sia preparata a trattare la sovranità come architettura piuttosto che come procurement — e se il vostro board, i vostri auditor e il vostro regolatore accetteranno la risposta architettonica come risposta di sovranità. Lo faranno, in misura crescente. Il Tech Sovereignty Package propone una classificazione a livello CADA entro il 2027. ES³ certifica già la metodologia anziché i prodotti. I segnali dal livello regolatorio convergono sull’architettura, non sul logo del fornitore. Il logo del fornitore è l’indicatore ritardato; l’architettura è quello anticipatore.

Cosa non è questo articolo

Non è la pretesa che Euro-Office sia la scelta sbagliata. Il prodotto è l’alternativa open source più forte a M365 sul mercato europeo. Non è la pretesa che GitHub bloccherà gli sviluppatori UE. È la pretesa che la sovranità come categoria di procurement sia l’inquadramento sbagliato, che il lancio di Euro-Office sia l’esempio più pulito disponibile del perché, e che il lavoro che quell’inquadramento ha tenuto nascosto sia la vera risposta alla domanda che gli acquirenti del settore pubblico e del privato regolato stanno cercando di porre.

Fonti

Panoramica del tema: Sovranità digitale in Europa Articoli correlati: EU Tech Sovereignty Package, Microsoft consegna nomi olandesi