Soberania nos servidores da Microsoft:
o lançamento que devia ter sido impossível
Ontem submeteu um bug. Um problema de margens no renderizador de documentos, quinze linhas de contexto, duas capturas de ecrã. Assinou-o com o seu nome verdadeiro. O seu perfil do GitHub mostra-o; o projeto, uma iniciativa de soberania europeia, pareceu-lhe exatamente o tipo de trabalho que merece uma assinatura.
Esta manhã o seu cartão de crédito deixa de funcionar.
A sequência não está, hoje, documentada. É a forma de uma sequência que os últimos dezoito meses tornaram progressivamente mais plausível. A 5 de maio de 2025, a conta Microsoft 365 de Karim Khan, Procurador-Chefe do Tribunal Penal Internacional, deixou de funcionar depois de a administração Trump o ter designado pessoalmente ao abrigo da Ordem Executiva 14203. Em maio de 2026, a Microsoft entregou os dados pessoais e as comunicações de funcionários públicos neerlandeses — reguladores que aplicavam o Regulamento dos Serviços Digitais da UE — a uma intimação do Congresso dos EUA. Em ambos os casos, as pessoas afetadas tinham escolhido um prestador de serviços com sede nos EUA anos antes, com base em contratação institucional razoável. A consequência política foi uma propriedade da cadeia de fornecimento que não tinham auditado.
Hoje, uma aliança de empresas europeias lança uma alternativa ao Microsoft 365. O comunicado de imprensa chama-lhe um marco para a soberania digital europeia. O código-fonte está alojado pela Microsoft. O pipeline de build corre nos servidores da Microsoft. As imagens de contentores são distribuídas através do registo de contentores da Microsoft. Cada contribuição para a soberania europeia é registada na base de dados da Microsoft no momento em que é feita — sob o seu nome verdadeiro.
Isto não é uma fuga, um escândalo ou um descuido. Os repositórios do Euro-Office em github.com/euro-office estão abertamente observáveis. A aliança por detrás do lançamento — IONOS, Nextcloud, EuroStack, Open-Xchange, XWiki, OpenProject e mais seis organizações europeias respeitadas de OSS — escolheu este alojamento deliberadamente, e continua a considerá-lo apropriado. A cobertura da imprensa especializada sobre o lançamento de hoje não o menciona. As comunicações de lançamento não o mencionam. O Pacote de Soberania Tecnológica da Comissão Europeia, redigido em paralelo, não o aborda.
Vale a pena dizê-lo com clareza: isto é absurdo. Não no sentido coloquial de surpreendente — é, numa leitura serena da documentação pública, exatamente o que seria de esperar — mas no sentido de que toda definição-padrão de soberania digital que o discurso europeu produziu nos últimos quatro anos é inconsistente com aquilo que acabou de acontecer. Ou o Euro-Office não é um produto de soberania, ou as definições de soberania em circulação não são coerentes. O lançamento força a escolha.
A versão útil deste artigo não é a indignação, que se escreve sozinha. É a auditoria, o reenquadramento e a questão de contratação pública que decorrem de aceitar que o discurso atual de soberania tem um erro de carga estrutural — e que o relatório de bug que submeteu ontem é, num horizonte suficientemente longo, parte da trilha de auditoria.
O que é lançado
O Euro-Office publica a v1.0 na terça-feira, 9 de junho de 2026. A aliança por detrás dele é tecnicamente coerente: a IONOS aloja a variante de cloud gerida a partir de Karlsruhe, a Nextcloud integra a suite no Hub 26 como substituto padrão do Collabora, a Open-Xchange traz a herança de groupware, e XWiki, OpenProject, Soverin, Abilian, BTactic e Office.eu contribuem com camadas adjacentes de colaboração e alojamento.
Os quatro repositórios principais em 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) — adotam a postura defensiva de licenciamento adequada a software que é alojado como serviço: qualquer fornecedor comercial que ofereça um Euro-Office alojado tem de publicar as suas modificações. A Apache-2.0 nos modelos é a escolha correta para conteúdo. Esta é a combinação de licenciamento mais forte no mercado europeu de suites de escritório OSS, materialmente mais forte do que a MPL-2.0 do Collabora Online ou a AGPL de fornecedor único do OnlyOffice.
A compatibilidade de formato de ficheiro com o Office Open XML mantém-se válida nas cargas de trabalho que historicamente quebraram as migrações europeias de OSS de escritório: livros Excel multi-folha com tabelas dinâmicas, documentos Word com alterações registadas e comentários, PowerPoint com animações embebidas. As opções de implementação disponíveis abrangem cloud gerida, híbrido e auto-alojado em Docker ou Kubernetes, no Proxmox ou VMware do próprio cliente. A história de soberania em runtime é real: dados em centros de dados alemães, licenciamento protegido contra fork de código fechado, independência de formato face à cadência de releases da Microsoft.
Não há asterisco nesta parte. O produto é bom. A decisão de contratação pública enquanto decisão de produto é defensável.
A auditoria
A decisão de contratação pública enquanto decisão de soberania é onde a arquitetura deixa de cooperar.
Cada commit em cada repositório do Euro-Office, cada issue, cada pull request, cada execução de pipeline CI/CD, cada build de imagem de contentor e cada artefacto de release passam por github.com. O GitHub é subsidiária integralmente detida pela Microsoft desde junho de 2018. As comunicações de lançamento não tratam disto. A cobertura da imprensa especializada do lançamento não trata disto. A aliança não se comprometeu com um espelho em Codeberg ou Forgejo, nem anunciou intenção de operar um pipeline de build fora dos EUA.
Isto não é um problema contratual — a licença AGPL preserva o direito de espelhar, fazer fork e reconstruir — é um problema operacional. O direito a espelhar não vale nada enquanto o espelho não existir.
O precedente de execução está documentado e é específico. Em julho de 2019, o GitHub restringiu o acesso a repositórios privados e a contas organizacionais pagas para developers no Irão, na Síria e na Crimeia, em cumprimento das sanções do OFAC. Projetos privados desapareceram da noite para o dia. Repositórios públicos mantiveram-se acessíveis em modo só-leitura, mas a infraestrutura de trabalho — issue tracker, pull requests, GitHub Actions, imagens de contentor, distribuição de pacotes — esteve indisponível para as contas afetadas até o GitHub obter uma licença OFAC para restaurar o serviço aos developers iranianos em janeiro de 2021. Em março e abril de 2022, o mesmo mecanismo aplicou-se a entidades na Rússia e a partes ocupadas da Ucrânia sob designação OFAC. Contas associadas a entidades sancionadas perderam o acesso; as contas organizacionais pagas na Crimeia, em Donetsk e em Lugansk permaneceram restringidas. As Políticas de Utilização Aceitável do GitHub continuam a citar o cumprimento do controlo de exportação dos EUA como regra governante.
A probabilidade de este mecanismo de execução se aplicar a um Stadtwerke alemão ou a um établissement public francês num dado trimestre é baixa. A probabilidade num horizonte de contratação pública de cinco anos, face a uma stack do Euro-Office com várias centenas de dependências OSS upstream mantidas globalmente, é materialmente superior a zero. A taxa-base relevante não são os casos de manchete — Irão, Rússia, Crimeia — mas a cauda longa: qualquer dependência crítica, alojada por qualquer developer em qualquer jurisdição que se torne relevante para a OFAC por qualquer uma de dezenas de razões plausíveis ao longo de cinco anos. A maioria desses eventos não afetará os adotantes do Euro-Office. Alguns afetarão.
Há uma segunda categoria de exposição da cadeia de fornecimento que é operacionalmente mais provável do que a execução de sanções: a pressão política sobre o operador da plataforma que produz cumprimento voluntário. O padrão de cumprimento da Microsoft em 2025–2026 — a suspensão do email do procurador do TPI em maio de 2025 após sanções dos EUA, a entrega voluntária ao Congresso dos EUA dos nomes de reguladores neerlandeses em maio de 2026 — encaixa-se nesta coluna. Quando um fornecedor de serviços com sede nos EUA enfrenta pressão política dos EUA, a resposta é o cumprimento, não a resistência. O GitHub é a mesma arquitetura. Uma futura administração dos EUA que decidisse que os projetos europeus de soberania mereciam atenção não precisaria da OFAC. As Políticas de Utilização Aceitável do GitHub são fundamento suficiente para restrição, ao critério da própria plataforma.
A conclusão da auditoria é direta e pouco lisonjeira: uma adoção do Euro-Office sem SBOM, sem infraestrutura de espelhamento e sem plano de continuidade não é arquitetonicamente mais soberana do que a implementação de M365 que substitui. É contratualmente mais soberana — os dados estão em Karlsruhe, a licença é AGPL — mas a cadeia de fornecimento termina na mesma plataforma de repositórios propriedade da Microsoft em que terminaria a distribuição do código-fonte do M365, se a fonte do M365 estivesse disponível, o que não está.
As pessoas dentro da auditoria
O argumento arquitetónico, até aqui, tratou o risco institucionalmente — o que acontece a um Stadtwerke, o que acontece a uma decisão de contratação pública. O mesmo argumento ressoa de forma diferente quando começa pelas pessoas cujos nomes estão documentados.
Tomemos Khan primeiro. O TPI é uma instituição internacional permanente, com sede em Haia, fora da jurisdição dos EUA. As comunicações do seu Procurador-Chefe estavam no Microsoft 365 porque o TPI tinha tomado a mesma decisão de contratação pública que qualquer outro grande comprador do setor público europeu estava a tomar na mesma altura, com os mesmos fundamentos razoáveis-na-altura. Quando a administração Trump designou Khan ao abrigo da Ordem Executiva 14203 em fevereiro de 2025, nem o Procurador nem o tribunal tinham uma opção operacional significativa: a Microsoft é uma empresa com sede nos EUA, a obrigação da OFAC é vinculativa, a suspensão seguiu-se. A decisão de contratação pública tinha sido tomada anos antes; a consequência chegou em maio, com nome e em pessoa.
O caso ACM/AP difere do de Khan num ponto importante. Não houve Ordem Executiva. A intimação partiu da Subcomissão de Instrumentalização da Comissão de Justiça da Câmara, presidida por Jim Jordan, cujo mandato declarado é escrutinar o que apelida de “censura estrangeira ao discurso americano” — uma formulação que, segundo o seu próprio enquadramento, inclui o Regulamento dos Serviços Digitais da UE e o trabalho dos funcionários públicos da Autoridade para os Consumidores e Mercados (ACM) e da Autoriteit Persoonsgegevens (AP) cujos nomes a Microsoft entregou. A secretária de Estado neerlandesa para a soberania digital, Willemijn Aerdts, convocou o embaixador dos EUA na sexta-feira em que a divulgação se tornou pública. Os dados já estavam a caminho. O cumprimento da Microsoft foi voluntário no sentido jurídico — a empresa estava a responder a uma intimação, não a uma ordem da OFAC — e operacionalmente inevitável da forma como o seria o cumprimento de qualquer prestador de serviços com sede nos EUA sob a mesma pressão política.
Nem Khan nem o pessoal da ACM e da AP escolheram estar na superfície da pressão política dos EUA. Escolheram a Microsoft como prestador de serviços, anos antes, com base em contratação institucional inteiramente razoável. A superfície política foi uma propriedade da cadeia de fornecimento que não auditaram.
É esta a camada em que os contribuidores e adotantes do Euro-Office agora se encontram.
Cada developer que abre um pull request contra github.com/euro-office cria um registo na base de dados da Microsoft que liga a sua identidade pessoal — nome legal na maioria das contas, endereço de email real, endereço IP por sessão, padrões temporais de contribuição — à participação ativa num projeto europeu de soberania digital que elementos do Congresso dos EUA já enquadraram publicamente como adversário dos interesses comerciais americanos. O trabalho diurno do contribuidor, o seu empregador, país de residência e afiliação política são inferíveis a partir do histórico público de commits. Hoje o enquadramento é retórico. O caso Khan e o caso ACM/AP demonstram que a distância entre o enquadramento retórico e a consequência pessoal é, no máximo, da largura de uma Ordem Executiva.
Cada administração pública que adote o Euro-Office herda, por transitividade, a mesma cadeia de registo. Cada responsável de TI que comenta numa issue upstream tem a sua posição profissional ligada publicamente ao projeto. Cada developer de um Stadtwerke que submete um relatório de bug tem a sua identidade registada na trilha de auditoria da Microsoft. O CISO municipal que escreve à aliança a pedir um esclarecimento de segurança, o encarregado de proteção de dados que pergunta sobre um caso-limite de conformidade de exportação — cada interação fica registada sob um nome verdadeiro, em infraestrutura propriedade da empresa de que o projeto pretende migrar para fora.
Nada disto é malicioso por parte da Microsoft. É a mecânica básica de operar um serviço de alojamento de código. É também a mecânica básica de uma futura intimação. O caso Khan mostra o que acontece quando uma Ordem Executiva dos EUA nomeia um indivíduo. O caso ACM/AP mostra o que acontece quando uma intimação do Congresso dos EUA nomeia uma categoria. Em ambos os casos, as pessoas afetadas souberam disso depois de a Microsoft já ter cumprido.
A implicação estratégica é sóbria. Quem — individual ou institucionalmente — participe no projeto europeu de soberania ao nível de contribuidor ou adotante enquanto está alojado em infraestrutura da Microsoft está a criar uma trilha de auditoria sob o seu próprio nome, na plataforma da parte de que o projeto pretende reduzir a dependência. A trilha está a ser criada hoje, em tempo real, a cada commit e a cada comentário de issue. A parte que tem acesso à trilha não precisa de agir sobre ela para que a trilha seja portante — basta que exista.
Orwell teria apreciado a arquitetura. Um movimento organiza-se para reduzir a sua dependência de uma entidade. Para o fazer, cada participante assina a sua contribuição, sob o seu nome verdadeiro, numa plataforma propriedade da entidade. A entidade preserva as assinaturas indefinidamente, pesquisáveis, exportáveis a pedido legal. Se a entidade alguma vez agirá sobre elas é, no médio prazo, secundário; se a arquitetura lhe permite agir sobre elas é, no médio prazo, coisa decidida. Está a decidir-se agora, com cada ticket de issue, por todos os que carregam em submeter.
A soberania não é o que se compra
Este é o reenquadramento que o lançamento torna difícil de evitar.
A indústria da contratação pública treinou a questão como um problema de seleção de fornecedor. O RGPD, o CLOUD Act, o Pacote de Soberania Tecnológica, a alteração ao §58 VgV, o modelo de maturidade ES³ — todos estes instrumentos aceitam o pressuposto de que a soberania é uma propriedade que o comprador adquire ao escolher o fornecedor certo. O ES³ certifica fornecedores. A CADA classifica fornecedores. O §58 VgV permite que os compradores prefiram certos fornecedores. Os instrumentos são coerentes dentro do pressuposto.
O lançamento do Euro-Office é o caso mais claro onde a hipótese falha visivelmente. O produto é a melhor resposta disponível à pergunta sobre o fornecedor. Adotá-lo sem trabalho arquitetónico muda o fornecedor na linha de contratação e deixa a dependência efetiva inalterada. O fornecedor na linha é agora europeu; a cadeia de fornecimento da qual ele depende não é. O comprador adquiriu a aparência de soberania sem a substância, e a substância — continuidade da cadeia de fornecimento — nunca esteve no contrato de aquisição.
A soberania, no sentido que importa para a pergunta que compradores do setor público e do privado regulado estão a tentar responder, não é uma propriedade dos fornecedores. É uma propriedade das arquiteturas. Uma organização é digitalmente soberana na medida em que consegue continuar a operar quando qualquer peça da sua cadeia de fornecimento de software se torna indisponível. Essa propriedade constrói-se, não se compra. A decisão de fornecedor está a montante; o trabalho de se tornar soberano está a jusante. Saltar o trabalho a jusante e chamar à decisão a montante uma resposta de soberania é o erro que o lançamento do Euro-Office torna impossível ignorar.
A consequência prática: a stack do Microsoft 365 e a stack do Euro-Office não são estruturalmente diferentes na dimensão da cadeia de fornecimento. Diferem na dimensão do runtime (localização dos dados, jurisdição do operador) e diferem na opção de construir independência da cadeia de fornecimento. O M365 fecha a opção; o Euro-Office preserva-a. Mas preservar uma opção não é o mesmo que exercê-la. O exercício é o trabalho.
A questão de contratação que verdadeiramente conta
Se a questão de soberania é propriamente arquitetónica, a questão de contratação segue-se. Já não é a que fornecedor compramos? Torna-se: qual é a nossa arquitetura de independência, e onde fica ela na nossa demonstração de resultados?
Três correntes de trabalho respondem à questão reenquadrada. Não são opcionais, não são “nice to have”, e qualquer aquisição de soberania que as omita é uma encenação de aquisição, não uma decisão de aquisição.
Um: inventário. Uma auditoria de Software Bill of Materials dos componentes OSS em produção atual, com âmbito a cada sistema com exposição de runtime à internet ou a dados de clientes. Resultado por componente: endpoint primário de distribuição, licença, profundidade da árvore de dependências, jurisdição do mantenedor. Para uma organização de média dimensão a correr 50–80 componentes OSS distintos em produção, a auditoria leva 6–10 semanas e custa 25 000–55 000 € a um especialista externo. O entregável é uma lista, não um plano; o plano deriva da lista. A maioria das organizações descobre que 80% da sua exposição da cadeia de fornecimento se concentra em 15% dos seus componentes, e que a concentração não está onde esperavam.
Dois: infraestrutura de espelhamento. Uma instância auto-alojada de Forgejo, sincronizada bidirecionalmente com o GitHub para os componentes críticos identificados na corrente um. Alojada em infraestrutura existente (Proxmox, VMware, ou uma VM na Hetzner), duas VMs, separadas da produção. O custo em caixa é negligenciável; o trabalho são 8–15 pessoa-dias de tempo de arquiteto ao longo de doze semanas, conforme o número de repositórios. O espelho não substitui o GitHub no desenvolvimento diário; sobrevive ao GitHub para efeitos de continuidade. O Codeberg pode substituir onde o auto-alojamento de Forgejo não se justifique.
Três: piloto. Um piloto de Euro-Office com âmbito definido num fluxo de trabalho sem exposição pública — financeiro, RH interno, groupware controlado — a correr 6–12 meses com critérios explícitos de go/no-go ligados ao momento em que a infraestrutura de espelhamento atingir fiabilidade de grau de produção. Custo: 8 000–20 000 € em apoio de setup por um parceiro Nextcloud mais tempo interno. O piloto valida o produto; as correntes um e dois validam a soberania.
Um comprador que execute as três comprou Euro-Office e construiu soberania. Um comprador que execute apenas a corrente três comprou um fornecedor diferente. A decisão de contratação pública é a mesma nos dois casos. A decisão de arquitetura não é.
A questão de posicionamento estratégico para os próximos doze meses não é se o Euro-Office é o produto certo. É se a sua organização está preparada para tratar a soberania como arquitetura em vez de como contratação pública — e se o seu conselho, os seus auditores e o seu regulador aceitarão a resposta arquitetónica como a resposta de soberania. Aceitarão, cada vez mais. O Pacote de Soberania Tecnológica propõe classificação ao nível da CADA até 2027. O ES³ já certifica metodologia em vez de produtos. Os sinais da camada regulatória estão a convergir para a arquitetura, não para o logo do fornecedor. O logo do fornecedor é o indicador atrasado; a arquitetura é o indicador avançado.
O que este artigo não é
Não é uma afirmação de que o Euro-Office é a escolha errada. O produto é a alternativa open-source mais forte ao M365 no mercado europeu. Não é uma afirmação de que o GitHub vai bloquear developers da UE. É a afirmação de que a soberania como categoria de contratação pública é o enquadramento errado, o lançamento do Euro-Office é o exemplo mais limpo disponível do porquê, e o trabalho que o enquadramento tem estado a esconder é a resposta efetiva à pergunta que compradores do setor público e do privado regulado estão a tentar fazer.
Fontes
- Nextcloud: Sovereign office suite Euro-Office to release June 9
- Nextcloud: Euro-Office general availability set for June 9
- GitHub: Euro-Office organisation repositories
- TechCrunch: GitHub confirms it has blocked developers in Iran, Syria and Crimea (July 2019)
- GitHub blog: GitHub is fully available in Iran (January 2021)
- GitHub blog: Our response to the war in Ukraine (sanctions response, March–April 2022)
- GitHub: Acceptable Use Policies — export controls clause
- Codeberg: European Git hosting cooperative
- Forgejo: free software fork of Gitea
- FSF: GNU Affero General Public License v3
- SPDX SBOM specification
- Microsoft entrega nomes de reguladores neerlandeses ao Congresso dos EUA
Visão geral temática: Soberania Digital na Europa Artigos relacionados: Pacote UE de Soberania Tecnológica, Microsoft entrega nomes neerlandeses