Na década de 2000, falávamos muito sobre código aberto – talvez até demais. Discutimos se a liberdade de código (GPL) ou a liberdade do desenvolvedor (Apache/BSD) importava mais. Nós nos perguntamos quando o ano do desktop Linux finalmente chegará. (TL;DR nunca. Ou talvez já tenha acontecido. Ou… tanto faz.) Castigamos as empresas por “lavagem aberta” (antecipando os anos de lavagem de nuvem e de IA que viriam). Debatemos modelos de negócios de “núcleo aberto”.
Na década de 2010, o código aberto ficou em segundo plano à medida que se tornou uma infraestrutura essencial para todos os desenvolvedores e empresas do planeta, quer eles soubessem disso ou não. Claro, tivemos erupções esporádicas de tremores de punho contra gigantes da nuvem por mineração a céu aberto de código aberto, e as pessoas fizeram apelos sinceros por código aberto sustentável (mesmo que ele não mostrasse sinais de acabar), mas principalmente levamos o código aberto para o no fundo de nossas mentes, mesmo quando se tornou crítico para quase tudo o que fazemos.
Até agora. O código aberto está novamente em destaque, dada a sua aparente centralidade para garantir que a IA não seja comandada por algumas empresas, para não mencionar a recente decisão da Redis de alterar o seu licenciamento. O problema é que o código aberto não acompanhou as tendências tecnológicas. Não existe “IA de código aberto”, por exemplo, não importa o quanto alguns finjam o contrário. E ainda não existe um bom licenciamento de código aberto para a nuvem. Precisamos aproveitar esse momento de código aberto para garantir que ele seja adequado ao propósito daqui para frente, mas como podemos fazer isso com justiça?
Ficando para trás
Escrevi bastante recentemente sobre essas questões, motivado inicialmente pela dificuldade de aplicar licenças que atendam à definição de código aberto à inteligência artificial. Como diz Mike Linksvayer, chefe de política de desenvolvedores do GitHub: “Não existe uma definição estabelecida do que é IA de código aberto”. Cada vez que você ouve alguém proclamar com confiança que um grande modelo de linguagem é ou não de código aberto, vale a pena perguntar como eles podem ter tanta certeza quando até mesmo o diretor executivo da Open Source Initiative (OSI), Stefano Maffulli, reconhece que o código aberto para IA não está de forma alguma resolvido: “Definitivamente temos que repensar as licenças de uma forma que aborde as limitações reais de direitos autorais e permissões em modelos de IA, mantendo ao mesmo tempo muitos dos princípios da comunidade de código aberto”.
O OSI espera ter orientação até outubro, mas até lá, qualquer um que pretenda ter certeza absoluta sobre o que é ou não código aberto em IA está fazendo exatamente isso: fingindo.
Para ser claro, não acho que o OSI mudará radicalmente o OSD para IA (ou nuvem). Não veremos de repente luz verde dada à discriminação em áreas de atuação, por exemplo. Espero que o caráter essencial do software de código aberto permaneça, mesmo à medida que ganhamos clareza sobre como aplicar o OSD a coisas como números de ponto flutuante, dados de treinamento e pesos.
Espero que também vejamos o OSI revisitar a nuvem, pois acredito que sua falha em aplicar o OSD à distribuição de software na nuvem é a principal razão pela qual vimos tantas empresas recorrerem a licenças disponíveis na fonte. Vejamos por que isso acontece.
A estranha ironia do copyleft
Quando Richard Stallman criou a Licença Pública Geral GNU (GPL), ele o fez para proteger a liberdade do código e garantir que o código permanecesse livre para usuários de software. Você poderia fazer alterações no código, mas se o fizesse, teria que disponibilizá-las. Você não poderia bloquear o código por trás de licenças proprietárias. Mais tarde, para tornar o software livre mais palatável para as corporações, um grupo cunhou o “código aberto” e nasceu um novo tipo de licença que dizia, essencialmente, “Faça o que quiser com este código”.
Mas havia uma estranha ironia em tudo isso. Em 2004, escrevi: “Estamos no modelo de negócios de TI mais emocionante que o capitalismo já viu, tudo graças à GPL”. Alguns anos depois, redobrei esse sentimento, escrevendo: “A maioria das empresas de código aberto bem-sucedidas… usam a GPL”. Como concluí: “A GPL, ao contrário da crença popular, facilita o negócio de software comercial”.
Stallman pretendia isso? Não. Mas isso não importa. O que importa é o texto da licença e seu poder de proteger o código e a liberdade do usuário – ah, e de gerar dinheiro.
Curiosamente, a licença que mais trabalhou para proteger o código e a liberdade do usuário também foi a licença que mais permitiu às empresas construir negócios de sucesso, da Red Hat ao MySQL. Assim que a nuvem chegou, entretanto, a GPL perdeu toda a potência e o hack da Affero GPL fez pouco para sustentá-la. Foi um compromisso pobre que não conseguiu proteger a liberdade do código/usuário e não deu às empresas a confiança de que poderiam usá-lo. (No entanto, permitiu que as empresas de nuvem ganhassem bilhões ao monetizar um fornecimento constante de software gratuito e de código aberto, para o qual contribuem com pouco ou nada. Que pechincha!)
Neste ponto, alguns leitores estão gritando: “Mas as chamadas empresas de código aberto não se importam com a liberdade de código! Eles só se preocupam com dinheiro!!”
Mais código livre, mais bom
Isso importa? Isso importa nem um pouquinho? Isso não. Se o código for gratuito, o utilizador a jusante pode pegá-lo, utilizá-lo, modificá-lo e distribuí-lo, desde que mantenha o código livre e aberto. Como diz a licença: “Você deve fazer com que qualquer trabalho que você distribua ou publique, que no todo ou em parte contenha ou seja derivado do Programa ou de qualquer parte dele, seja licenciado como um todo, sem nenhum custo para todos os terceiros sob o termos desta Licença.” Por que alguém se preocuparia com as motivações por trás do uso da licença, desde que o resultado final – liberdade de código – permanecesse?
Estou convencido de que se uma empresa hoje escrevesse a GPL exatamente como Stallman a escreveu décadas atrás – palavra por palavra de forma idêntica – ela seria rejeitada pela OSI. Por que? Porque as pessoas diriam (provavelmente corretamente) que a intenção por trás das palavras era diferente. Mas isso deveria importar? O texto da licença (que persiste muito depois de as intenções terem mudado) não deveria ser o padrão? Não deveríamos ser gratos pelo software livre, não importa por que foi licenciado como tal?
Em 2007, Charlie Babcock escreveu: “Uma das grandes ironias da GPL, 17 anos após a sua criação, é que ela se tornou uma criadora descarada de empresas que competem de forma eficaz”. Podemos nos perguntar se empresas como o MySQL (em sua época) usavam a GPL para fins de amor à liberdade ou se ela servia a um fim corporativo, mas em 2024 vamos apenas ser gratos porque 30 anos após o início do desenvolvimento do MySQL, ainda conseguimos use-o como software livre, graças à GPL.
Precisamos tornar o copyleft real novamente, atualizando ou criando uma nova licença aprovada pela OSI para a nuvem. Isso atenderá às necessidades daqueles no campo de Stallman que desejam liberdade de código, bem como dos tipos corporativos que desejam um negócio forte (o que, por sua vez, alimenta o desenvolvimento de mais código). Ah, também atende às necessidades daquelas pessoas que gostam de liberdade de código e também de pagar aluguel. De qualquer forma, todos nós ganhamos porque teremos mais software livre e de código aberto.
