Quando as Dependências Escolhem um Lado: O Risco de Open Source Que Ninguém Está a Avaliar
O pressuposto discreto por trás de qualquer stack empresarial era que quem mantém as dependências open source decide pelo mérito técnico. Um movimento de «código-fonte ético» diz agora o contrário, em voz alta, e isso transforma a governação numa questão de continuidade de negócio.
Todas as stacks de software empresarial assentam em código que os seus proprietários não escreveram, não conseguem ver na íntegra e nunca contrataram por escrito. É esse o acordo do open source, e durante duas décadas manteve-se de pé graças a um pressuposto discreto: quem mantém as suas dependências decide com base no mérito técnico. Qualidade do patch, não política. Esse pressuposto é agora uma questão em aberto, e o risco das dependências open source merece o mesmo tratamento que qualquer outro ponto único de falha na cadeia de abastecimento.
De quem são os valores certos é, aqui, uma questão secundária. O que importa é a previsibilidade. Um fornecedor que se consegue modelar é um fornecedor com o qual se pode planear. Um fornecedor cujas decisões dependem de fatores que não se conseguem observar, avaliar ou contratualizar é uma fonte de risco não segurado. E um movimento crescente dentro do open source diz agora isto mesmo, em voz alta. O movimento Ethical Source, fundado por quem criou o Contributor Covenant, o código de conduta que milhares de projetos, incluindo o kernel Linux, já adotaram, defende abertamente que o software e as comunidades à sua volta nunca foram neutros, e que a participação e a utilização podem ser condicionadas a valores. Quando os responsáveis de um projeto o dizem em voz alta, revelam algo preciso sobre a engrenagem: o mérito técnico deixou de ser o único critério e pode já não ser o que decide.
O que muda realmente quando um projeto deixa de ser neutro?
Siga-se o mecanismo. O open source funciona porque o incentivo para corrigir um erro é amplamente partilhado. Quem precisa de uma correção o suficiente pode propor um patch, e o trabalho de quem mantém o projeto é avaliar o código, não a pessoa. Essa separação, o código por um lado, quem contribui por outro, é o que permite a um projeto recrutar de um conjunto global de pessoas que não concordam em quase nada, exceto que o software deve funcionar.
Condicionar a contribuição ao alinhamento não técnico quebra essa separação. O conjunto de pessoas dispostas e capazes de manter código crítico atualizado reduz-se a quem passa também num teste de valores, além do teste de competência. Dois filtros em série deixam sempre passar menos candidatos do que um. A redundância com que as empresas contam, silenciosamente, o facto de que se um mantenedor esgota outro pode assumir o seu lugar, torna-se mais ténue. É um problema de «bus factor» vestido de opção de política. A política é a manchete; a base de contribuidores a encolher é o que entra no balanço.
Há uma versão mais aguda do mesmo risco do lado do financiamento e da colaboração, e não é hipotética. Em 2018, um dos mantenedores do Lerna, uma ferramenta de monorepo em JavaScript amplamente usada, reescreveu por breve tempo a licença para proibir a utilização do software a uma lista de empresas nomeadas que tinham contratos com a agência norte-americana de imigração e alfândegas (ICE). A cláusula foi revertida dias depois, porque quebrava os próprios termos que tornavam o Lerna open source, e quem a introduziu perdeu o acesso de commit. A tentativa falhou por causa da licença, mas demonstrou a vontade. Quatro anos depois, a questão deixou de depender de licenças. Em março de 2022, após a invasão da Ucrânia pela Rússia, quem mantinha o node-ipc, um pacote de rede puxado por milhões de instalações por semana como dependência transitiva, lançou uma atualização que apagava deliberadamente ficheiros em máquinas geolocalizadas na Rússia e na Bielorrússia, a par de uma versão mais branda, «peacenotwar», que se limitava a colocar uma mensagem de protesto no ambiente de trabalho dos utilizadores. Sem cláusula de licença, sem votação, sem aviso: uma única pessoa a agir por convicção, a fazer passar código pelo mesmo canal em que as empresas confiam para correções de segurança. A licença nunca foi o controlo que importava.
Pode um projeto open source recusar-se a trabalhar com a sua empresa?
Nada numa licença aberta obriga quem mantém o projeto a aceitar o seu patch, a receber o seu dinheiro ou a validar a sua integração. A licença regula o que pode fazer com o código que já tem. Nada diz sobre o fluxo futuro de correções, e é esse fluxo futuro a razão de fundo pela qual se depende de um projeto vivo e não de uma cópia congelada no tempo. Portanto sim, na prática um projeto pode recusar-se a trabalhar consigo, e quanto mais explicitamente a sua governação estiver organizada em torno de valores, mais essa possibilidade passa de impensável a apenas improvável. Improvável é um número, e os números têm lugar num modelo de risco.
É aqui que o debate sobre a neutralidade deixa de ser um espetáculo de bancada. A pergunta relevante para uma empresa não é se concorda com a posição de um projeto. É se essa posição introduz um caminho de decisão em que o software que integra deixa de receber atenção por razões que não consegue influenciar com uma correção de engenharia ou um cheque. Se a resposta for sim, tem uma dependência que classificou como infraestrutura mas que se comporta como uma contraparte.
A lacuna de financiamento por baixo de tudo isto
Eis a parte que devia preocupar um diretor financeiro mais do que qualquer manifesto. Os projetos mais silenciosamente críticos são muitas vezes os pior financiados. Quando a falha Heartbleed atravessou o OpenSSL em 2014, a biblioteca protegia uma parte substancial dos servidores web do mundo. Segundo os próprios números públicos da OpenSSL Software Foundation na altura, o projeto arrecadava qualquer coisa como 2.000 dólares por ano em donativos diretos, longe do suficiente para manter sequer uma pessoa a tempo inteiro. Adoção quase universal; financiamento reduzido a um erro de arredondamento. A resposta do setor, a Core Infrastructure Initiative da Linux Foundation, existiu precisamente porque todo o mercado vinha a beneficiar, à boleia, de código que ninguém pagava para manter. Quando quase todos andam à boleia, são os poucos dispostos a fazer o trabalho por muito pouco que acabam por definir a governação.
Esta é a síntese incómoda. A viragem para os valores e a lacuna de financiamento não são duas histórias separadas. Um projeto subfinanciado tem menos mantenedores, menos lastro institucional e uma base de governação que uma minoria empenhada consegue orientar, em qualquer direção. Subfinancie os bens comuns e não obtém, por defeito, uns bens comuns neutros. Obtém aquilo que os responsáveis que restam decidirem, e já abdicou da única alavanca que tinha para influenciar essa decisão, que era aparecer e contribuir. As empresas que tratam o open source como um input gratuito são as mesmas mais expostas quando esse input passa a ter opiniões.
Como deve ser hoje uma análise séria de dependências?
Acrescente uma pergunta à sua due diligence de software: este projeto vai tomar decisões contra os nossos interesses por razões que nada têm a ver com o código? Depois trate a resposta como trataria qualquer outra conclusão de continuidade de negócio. Para uma dependência que falhe este teste, quer o mesmo que quereria para qualquer componente de fornecedor único: um fork mantido que consiga assumir, conhecimento interno do código, e uma relação de financiamento suficientemente robusta para que o seu envolvimento seja um facto e não um favor. Chame-lhe estratégia técnica aplicada a um input que a maioria das empresas nunca pensou em tratar como estratégico. É a mesma disciplina que evita que sistemas agênticos e de IA herdem riscos que quem os construiu nunca examinou.
Os reguladores já deixaram de tratar isto como opcional. O governo federal dos Estados Unidos exige um inventário de materiais de software (SBOM) aos seus fornecedores desde a Executive Order 14028, de 2021, e o Regulamento de Ciber-resiliência da União Europeia, em vigor desde dezembro de 2024, vai exigir aos fabricantes o envio de um SBOM e a gestão de vulnerabilidades ao longo do ciclo de vida suportado do produto a partir de dezembro de 2027, uma obrigação que se aplica também às empresas portuguesas que operam no mercado europeu. Um inventário que lista todas as dependências mas não testa nenhuma delas quanto ao risco de governação é um artefacto de conformidade, não uma defesa. As organizações que sairão bem desta fase serão as que deixarem de tratar o open source como o tempo meteorológico, algo que simplesmente lhes acontece, e passarem a tratá-lo como um conjunto de relações com pessoas que têm interesses próprios. Mapeie a dependência, avalie o risco, financie aquelas de que não consegue prescindir. A neutralidade nunca foi garantida. Era apenas barata o suficiente para que ninguém verificasse a conta.
Perguntas frequentes
Uma licença permissiva como a MIT ou a Apache é suficiente para me proteger do risco de governação?
Não. Uma licença cobre o que pode legalmente fazer com o código que já tem. Não obriga quem mantém o projeto a continuar a aceitar os seus patches, o seu financiamento ou a sua integração, e é esse fluxo contínuo de correções a verdadeira razão pela qual se depende de um projeto vivo e não de uma cópia estática.
Como avalio o risco de governação numa dependência open source?
Olhe para como as decisões são realmente tomadas: quantos mantenedores ativos existem, como se restringe a contribuição, como o projeto é financiado, e se os responsáveis já declararam que vão decidir com base em critérios não técnicos. Trate qualquer dependência de que não consiga prescindir e que não consiga influenciar como uma exposição de continuidade de fornecedor único, e planeie em conformidade, com um fork que consiga assumir e uma relação de financiamento real.
Contribuir com dinheiro reduz mesmo o risco?
Muda a sua posição de quem anda à boleia para parte interessada, que é a única alavanca que tem sobre a direção e os quadros de um projeto. Projetos subfinanciados concentram a governação em quem estiver disposto a trabalhar por pouco, por isso um financiamento significativo e sustentado mantém o código atualizado e garante aos seus interesses um lugar à mesa.
Relacionado
- No Ubuntu 26.04 LTS, o Coreutils Que Sustenta as Suas Compilações Já Não É GNU
- O Prêmio da Soberania: por que a IA soberana corporativa está vencendo pelo acesso, não pela velocidade
- Os Processos por Segredos Comerciais Ganham-se Anos Antes de Alguém se Demitir. Pergunte à Faccenda Chicken.
- Security & Trust
Escrito por uma persona editorial de IA do sistema editorial proprietário da Abyshire e revisto pela nossa equipa.