Se você acompanha tópicos de código aberto no X/Twitter, pode ser perdoado por acreditar que o maior problema do código aberto hoje são as empresas que relicenciam seu código-fonte aberto sob licenças diferentes. Thierry Carrez, vice-presidente da OSI, por exemplo, emitiu recentemente um alerta terrível: “o único fornecedor é o novo proprietário”. Parece terrível, certo? Quero dizer, uma vez que você esqueça que a grande maioria dos softwares que você e eu usamos todos os dias em nossos telefones, laptops, servidores, etc., é proprietário. (Sim, com bastante código aberto enterrado e efetivamente “relicenciado”.)
Aqui estão apenas alguns dados que fazem essas preocupações parecerem bobas: Das mais de 10.000 empresas que participam de projetos da Linux Foundation (e de código aberto em geral), houve exatamente 14 eventos de relicenciamento de um único fornecedor. Sim, 14. E desses 14, apesar de toda a tinta digital que derramamos falando sobre a necessidade crítica de bifurcar para manter a liberdade, apenas três foram bifurcados. Novamente, são 14 projetos/repositórios dos 162 milhões relatados pelo GitHub.
Em outras palavras, estamos nos concentrando em poucos casos extremos quando há problemas fundamentais e significativos no código aberto que precisam ser corrigidos.
Uma questão de confiança
Os maus atores estão impressionando a própria natureza de como o código aberto funciona. O maravilhoso do código aberto é que qualquer pessoa pode participar, mas isso também pode ser um ponto fraco. Como vimos recentemente com a exploração do XZ Utils, e mais recentemente com um ataque semelhante, maus atores sofisticados (talvez apoiados por estados-nação) estão a utilizar o processo padrão de contribuição de código aberto para se infiltrarem em projetos relativamente obscuros, mas amplamente utilizados.
Tais táticas de engenharia social são difíceis de detectar, dada a superfície de ataque quase infinita que o código aberto oferece e a natureza sofisticada dos ataques mais recentes (que surgem em tempo de execução). É claro que a natureza aberta significa que detectar os problemas e corrigi-los pode ser mais fácil do que em software proprietário. Mas com os desenvolvedores incluindo código-fonte aberto em quase 100% de todos os softwares, inclusive proprietários, detectar todos os problemas torna-se um jogo sério de Whac-A-Mole.
A Linux Foundation e outras já estão trabalhando em maneiras de introduzir novas formas de aprofundar a confiança no processo de código aberto. Suas ideias deveriam funcionar para tentativas recentes de explorar pacotes de código aberto, onde contribuições foram propostas por recém-chegados ao projeto em circunstâncias suspeitas. Mas isso teria impedido a exploração do XZ Utils, que aconteceu ao longo dos anos? Isso parece menos provável.
As tentativas de melhorar os processos de código aberto também são complicadas pela natureza da maioria dos softwares de código aberto: eles não são escritos por um único fornecedor ou mesmo por uma comunidade de fornecedores. Foi escrito por uma desenvolvedora solo em seu tempo livre. Dadas essas realidades, o que pode ser feito? De acordo com Jack Cable e Aeva Black, ambos da Agência de Segurança Cibernética e de Infraestrutura dos Estados Unidos (CISA), tudo se resume aos fornecedores fazerem o que alguns de nós defendemos há anos. Como argumentam, “todos os fabricantes de tecnologia que lucram com software de código aberto devem fazer a sua parte, sendo consumidores responsáveis e contribuintes sustentáveis dos pacotes de código aberto dos quais dependem”.
Eu acrescentaria que talvez devêssemos começar pelo topo, com os fornecedores que tiram o máximo proveito do código aberto, mas às vezes dão menos. Sim, empresas de nuvem de trilhões de dólares ganham dezenas de bilhões com código aberto, mas dificilmente conseguem reunir dezenas de milhares de linhas de código para qualquer projeto. Quer que a segurança do código aberto melhore da noite para o dia? Responsabilize os fornecedores por retribuir, como sugere a CISA.
Tornando a IA de código aberto acessível
Outro grande problema: inteligência artificial. Ou melhor, a dificuldade de aplicar código aberto à IA. Não vou entrar em detalhes aqui porque já fiz isso longamente (veja aqui ou aqui), mas há também o problema da acessibilidade na IA. Segundo uma estimativa, custou à OpenAI US$ 78 milhões para treinar o GPT-4, e o Google gastou US$ 191 milhões para treinar seu modelo Gemini Ultra. Esses não são os únicos grandes modelos de linguagem, é claro; há muitos, incluindo modelos de IA de “código aberto” (entre aspas porque, mesmo com o reconhecimento do OSI, ainda não está definido o que significa código aberto em IA). Ainda está em debate se o código é realmente aberto se apenas as empresas mais ricas puderem usá-lo.
Este não é um problema novo, é claro. Exatamente o mesmo problema assola a nuvem. Quase 20 anos atrás, perguntei aos executivos de código aberto do Google e do Yahoo! por que eles não contribuíram com mais código. Eles, com razão, ficaram ofendidos. Ambas as empresas estavam entre as líderes em contribuições de código aberto, mas uma delas também disse, com efeito: “Mesmo que abrissemos o código-fonte de nossa infra-estrutura, você não poderia usá-la porque não teria recursos para fazer qualquer coisa com ela”.
Na nuvem, descobrimos maneiras de contornar isso (Kubernetes, por exemplo) e, esperançosamente, veremos algo semelhante com a IA. Até que o façamos, no entanto, o código aberto em IA pode ser como colocar código num museu; você pode olhar, mas não há uma maneira prática de tocar no código ou usá-lo.
De volta à minha premissa central. Podemos optar por gastar nosso tempo torcendo as mãos por causa de um número infinitesimal de projetos de código aberto relicenciando para melhor capacitar-nos a investir em segurança e inovação contínua (Divulgação: eu trabalho para um deles), e podemos fazer declarações ondulantes sobre “IA de código aberto” sem defini-la ou torná-la útil para desenvolvedores comuns (e/ou seus empregadores). Ou podemos fazer o trabalho mais difícil e importante de descobrir como fazer com que o código aberto funcione de forma mais segura para todos no planeta e garantir que a IA não seja apenas para as empresas mais ricas. Este trabalho mais árduo renderá dividendos reais à sociedade. O primeiro irá – no máximo – lhe render elogios no X/Twitter.
