Soberania digital exige financiamento, não só adoção
Nesta página
A Comissão Europeia abriu uma consulta pública para uma nova “European Open Digital Ecosystems Strategy”.1 A consulta vai até 3 de fevereiro, e o enquadramento diz muito: o código aberto como um “public good to be freely used, modified, and redistributed” que poderia fortalecer a independência tecnológica e a cibersegurança da UE.2
Eles identificaram o problema direito. Governos e empresas europeus dependem demais de fornecedores de software de fora da UE, como Microsoft, Google e Amazon, e isso cria vulnerabilidades na cadeia de suprimentos da infraestrutura crítica. A solução que eles buscam é o código aberto. Sem aprisionamento a fornecedor. Código auditável. A liberdade de fazer um fork se o projeto morrer ou se a empresa mudar de rumo contra os seus interesses.
Já escrevi em outro texto sobre como o CLOUD Act dos EUA e a confiança cada vez menor no tratamento transatlântico de dados já estão empurrando governos europeus a se desfazer das dependências da Microsoft. A revolta silenciosa da Europa contra a nuvem americana mostra o risco de soberania em termos concretos: um governo americano hostil poderia obrigar provedores a reter ou apreender dados, e a Europa ficaria exposta a menos que controlasse a própria pilha.
É o instinto certo. Mas não vai funcionar se eles não estiverem dispostos a pagar por isso.
Código aberto é mesmo a ferramenta certa
Vamos ser claros: a UE não erra na escolha da tecnologia. O código aberto é mesmo o caminho para a soberania digital, e o raciocínio é direto.
Quando o seu governo roda em software proprietário, você está alugando a sua própria infraestrutura. A Microsoft pode mudar os termos de licenciamento. A Oracle pode te auditar até você ceder. A Amazon pode descontinuar o serviço gerenciado em que você construiu seus sistemas. Você não tem a quem recorrer, porque o código não é seu.
O código aberto muda a relação de poder. Você pode auditá-lo atrás de vulnerabilidades e backdoors, o que é essencial em sistemas de governo. Pode fazer um fork se os mantenedores levarem o projeto para uma direção que não serve a você. Pode contratar desenvolvedores locais para adaptá-lo às suas necessidades. Você não fica preso ao roadmap de um único fornecedor.
Isso não é teoria. Munique migrou para o Linux, voltou para o Windows e agora reconsidera o Linux de novo.3 Esse vai e vem não é um fracasso do código aberto. É a prova de que existe opção. Eles podiam trocar. Tente fazer isso com dez anos de integrações com o Microsoft 365.
O que eu vi no código aberto
Escrevo código profissionalmente há mais de quinze anos, e o código aberto é a base de tudo que construí. Os produtos em que trabalhei, Flowstate, Jamie, MimeProtect e Blinq, rodam sobre milhares de dependências mantidas por gente que eu nunca vou conhecer.
Alguns desses mantenedores são funcionários de grandes empresas que contribuem com código aberto como parte do modelo de negócio. Mas muitos não são. São pessoas mantendo infraestrutura crítica no tempo livre, muitas vezes por pouco dinheiro ou nenhum.
Já vi esse padrão se repetir. Um desenvolvedor brilhante cria uma biblioteca que resolve um problema difícil. Ela é adotada. Empresas constroem produtos em cima dela. As notificações do GitHub do mantenedor viram uma avalanche. Ele esgota. O projeto é abandonado ou segue mancando, com atualizações esporádicas.
O pior é quando algo quebra. Uma vulnerabilidade é divulgada. O mantenedor, que faz isso de graça e muitas vezes ainda tem um emprego de dia, de repente tem a internet inteira exigindo um patch urgente. Alguns lidam bem com isso. Outros somem.
Isso não se sustenta. Construímos a economia digital sobre trabalho voluntário e continuamos fingindo surpresa quando os voluntários ficam sem energia.
O problema da extração de valor
O que a consulta da UE reconhece é que grande parte do valor gerado por projetos europeus de código aberto fica com grandes empresas internacionais de tecnologia, em vez de beneficiar a economia da UE.4
Desenvolvedores europeus criam ferramentas. Publicam como código aberto. A Amazon pega essas ferramentas, embrulha em serviços gerenciados e revende para empresas europeias. Elastic, Redis, MongoDB: o padrão está bem documentado. Os criadores constroem e os hyperscalers monetizam.
Esse é o vazamento de soberania que a UE tenta tapar. Mas você não resolve isso só usando mais código aberto. Se governos europeus adotam código aberto e os desenvolvedores por trás desses projetos continuam sem conseguir pagar o aluguel, você só trocou a dependência da Microsoft por uma dependência de voluntários sem remuneração.
O valor precisa ficar dentro do ecossistema. Isso significa pagar quem constrói e mantém o software.
Subsídios não são a resposta
A UE sabe financiar coisas. Horizon Europe, Digital Europe, programas nacionais de inovação: não faltam mecanismos de subsídio. Mas subsídios resolvem o problema errado.
Subsídios são orientados a metas. Você se candidata a um financiamento para construir algo novo. Bate marcos. Entrega um relatório final. O projeto acaba.
Infraestrutura de código aberto não funciona assim. A biblioteca OpenSSL, que protege boa parte da internet, não ficava sem recursos porque ninguém financiou uma nova implementação de TLS. Ficava sem recursos porque ninguém financiava a manutenção contínua de uma que já existia. Quando o Heartbleed estourou, em 2014, o mundo descobriu que uma infraestrutura crítica de criptografia era mantida por um punhado de desenvolvedores em meio período.5
O Log4j foi a mesma história. Uma biblioteca de log usada por praticamente toda aplicação Java do planeta, mantida por voluntários. Quando a vulnerabilidade Log4Shell apareceu, esses voluntários tiveram que correr para corrigir uma falha crítica que afetava bilhões de sistemas, sem receber nada por isso.6
Você não chega a uma infraestrutura por meio de subsídios. Subsídios financiam projetos, e infraestrutura precisa de operação. A diferença importa.
Como é um financiamento de verdade
A consulta da UE menciona “sustainable developer compensation models”, e representantes do setor enviaram um roadmap de 70 pontos que cobre mecanismos de investimento.7 São as conversas certas a ter.
Financiamento de verdade para código aberto se parece com isto:
Orçamento operacional, não subsídio por projeto. Pague um salário aos mantenedores para manter a infraestrutura crítica segura e atualizada. Financie o trabalho chato: patches de segurança, atualização de dependências, documentação, gestão de comunidade.
Preferência na compra pública. Se governos europeus gastam bilhões em software, exija que esse gasto dê preferência a soluções de código aberto com mantenedores europeus. Cada euro gasto em licenças da Microsoft é um euro que não foi gasto em alternativas soberanas.
Apoio à infraestrutura. Construa e hospede os serviços de que projetos de código aberto precisam: CI/CD, repositórios de pacotes, hospedagem de documentação. A Linux Foundation e a Apache Foundation oferecem parte disso, mas há espaço para equivalentes europeus.
Redação técnica e acessibilidade. Boa documentação torna os projetos utilizáveis. Financie redatores técnicos para deixar as ferramentas de código aberto acessíveis a times de TI de governo que podem não ter a experiência para trabalhar só com o código-fonte.
O retorno da consulta mostra que a comunidade entende isso.8 A pergunta é se a UE vai se comprometer com o orçamento.
Soberania é uma decisão de gasto
A UE gasta somas enormes com software. Órgãos de governo por toda a Europa pagam licenças à Microsoft, ao Google e à Amazon que somam bilhões por ano. Parte desse gasto é inevitável, porque ninguém vai trocar o Windows da noite para o dia.
Mas toda decisão de compra é uma escolha. Toda renovação de contrato corporativo é dinheiro que poderia financiar alternativas soberanas.
Soberania digital não é uma escolha de tecnologia. É uma linha do orçamento.
A UE identificou direito que o código aberto é a ferramenta. Mas uma ferramenta parada no galpão não constrói nada. É preciso gente para usá-la, mantê-la e melhorá-la. Essa gente precisa pagar o aluguel.
O código aberto não vai salvar a Europa da dependência tecnológica a menos que a Europa pague por ele. Não com subsídios para projetos novos e chamativos, mas com financiamento operacional para a infraestrutura de que já dependemos. Não com programas de inovação, mas com políticas de compra que direcionem o dinheiro para mantenedores europeus.
A consulta fecha em 3 de fevereiro. A pergunta não é se a UE entende o problema, porque claramente entende. A pergunta é se vão assinar os cheques.
Footnotes
-
EU launches call for evidence on European open digital ecosystems – Linuxiac ↩
-
Munich considers Linux, again – ZDNet ↩
-
O artigo do Linuxiac observa que “much value generated by European open-source projects is captured by large international tech companies rather than benefiting the EU economy.” ↩
-
The Heartbleed Bug and Open Source Security – OpenSSL Security Advisory, 2014 ↩
-
The Log4j vulnerability and the importance of open source security – CISA ↩
-
O artigo da LWN.net cita um roadmap de 70 pontos de representantes do setor, que cobre desenvolvimento tecnológico, capacitação, práticas de compra, mecanismos de investimento e estruturas de governança. ↩
-
Have your say: European Open Source Strategy – European Commission ↩