Quando o open-source muda de licença: o que fazer com a sua stack

O roteiro já se repetiu vezes suficientes para ser previsível. Um projeto open-source consolidado, mantido por uma empresa, anuncia que a próxima versão sai sob uma licença restritiva. A comunidade reage. Em semanas nasce um fork sob governança de fundação. E milhares de equipes que só queriam continuar operando o que já funcionava precisam tomar uma decisão que não pediram.

Aconteceu com o Terraform em 2023, quando a HashiCorp adotou a Business Source License e o OpenTofu nasceu na Linux Foundation. Aconteceu com o Redis em 2024, com a troca para licenças duplas restritivas e o surgimento do Valkey. Antes disso, com o Elasticsearch, que gerou o OpenSearch. E com o MongoDB, e com outros.

Vale entender o padrão, porque a próxima vez é questão de tempo.

O que essas licenças realmente restringem

Aqui está a parte que reduz o pânico: para a esmagadora maioria dos usuários, essas licenças não proíbem nada do que você faz.

A BSL (Business Source License) permite usar, modificar e redistribuir, com uma única exclusão relevante: você não pode oferecer o software como serviço concorrente ao do mantenedor. E ela tem data de validade — cada versão vira open-source de verdade depois de um prazo, tipicamente quatro anos.

A SSPL exige que, se você oferecer o software como serviço a terceiros, publique também todo o código da infraestrutura que faz esse serviço funcionar. Uma exigência tão ampla que, na prática, funciona como proibição de oferecer o serviço.

Ou seja: se você usa Terraform para provisionar a sua própria infraestrutura, ou Redis como cache da sua aplicação, essas licenças não restringem o seu uso. Elas foram desenhadas para atingir provedores de nuvem que vendiam o software como produto gerenciado sem contribuir de volta.

Então por que a reação foi tão forte?

Por que a comunidade reagiu mesmo assim

Três motivos, e nenhum deles é o texto da licença em si:

• Deixa de ser open-source pela definição. Isso não é purismo. Políticas de compra, listas de software aprovado, distribuições Linux e o próprio processo de compliance de muitas empresas usam a definição formal — "aprovado pela OSI" — como critério binário. Um projeto que sai dela é removido de repositórios oficiais e reprova em auditoria, independentemente do que a licença permita.
• A regra pode mudar de novo. Se a licença mudou uma vez por decisão unilateral, ela pode mudar duas. O que se perde não é o direito de uso de hoje; é a previsibilidade sobre amanhã.
• Ambiguidade. "Serviço concorrente" é claro para uma nuvem pública e nebuloso para uma empresa que oferece software como serviço com aquele componente por dentro. Departamento jurídico não gosta de nebuloso, e o custo de resolver a dúvida costuma superar o de trocar de componente.

Vale registrar também o outro lado, que raramente aparece na discussão: manter software de infraestrutura crítico custa caro, e ver provedores faturando com o próprio trabalho sem retorno é um problema econômico real. As mudanças de licença são tentativas — desajeitadas, mas compreensíveis — de resolver isso.

E as duas coisas podem ser verdade ao mesmo tempo. Alguns projetos, inclusive, voltaram atrás depois: o Redis reincorporou uma opção de licença aprovada pela OSI em 2025, já com o Valkey estabelecido. A reversão não desfaz o fork — a previsibilidade, uma vez quebrada, não volta por decreto.

Os forks funcionaram melhor do que se esperava

Diferente de brigas anteriores no ecossistema, esses forks pegaram tração rápido, e por um motivo estrutural: eles nasceram dentro de fundações, com múltiplas empresas financiando, não como projeto paralelo de uma pessoa insatisfeita.

Na prática, os forks começaram como substitutos diretos — mesma configuração, mesmo protocolo, mesmos comandos — e foram divergindo aos poucos, com funcionalidades próprias. Isso significa que a migração é fácil hoje e tende a ficar menos fácil com o tempo. Quem migra cedo troca de nome; quem migra tarde troca de produto.

O que fazer se um componente seu mudar de licença

Um roteiro em quatro passos, na ordem certa.

1. Confirme se a mudança atinge você. Leia a exclusão específica da licença, não o resumo da rede social. Se você usa o software internamente ou dentro do seu produto sem revendê-lo como serviço gerenciado equivalente, quase certamente não atinge.

2. Verifique a versão que você roda. Mudanças de licença valem da versão anunciada em diante; o que já está instalado continua sob a licença antiga. Você tem tempo. Não faça migração de emergência em fim de semana.

3. Decida com critério, não com indignação. Três caminhos legítimos:

• Ficar. Se a licença não restringe o seu uso e o produto atende, ficar é uma escolha válida. O custo é aceitar depender de decisões futuras do mantenedor.
• Migrar para o fork. Faz sentido quando há exigência formal de licença aprovada pela OSI, quando a ambiguidade jurídica incomoda, ou quando você prefere apostar em governança de fundação. Migre enquanto a compatibilidade ainda é alta.
• Reavaliar a categoria inteira. A mudança é uma boa desculpa para perguntar se aquele componente ainda é necessário. Não é raro descobrir que o Redis servia de cache para algo que o banco resolve, ou que o Terraform gerencia doze recursos que cabiam em um script.

4. Teste antes de trocar em produção. Substituto direto na documentação não é substituto direto na sua configuração. Suba em máquina separada, aponte um ambiente de homologação, rode a carga real. Se for troca in-place, tire um snapshot antes — e confirme que o serviço volta, porque nomes de unit e caminhos de configuração mudam entre forks, com o sintoma clássico de serviço que não sobe.

Como reduzir a exposição desde já

Não dá para prever qual será o próximo. Dá para ficar menos vulnerável a qualquer um deles.

• Prefira o padrão à implementação. Aplicação que fala o protocolo do Redis troca de servidor sem tocar no código. Aplicação amarrada a uma extensão exclusiva de um fornecedor, não. Vale para banco, fila, cache e formato de armazenamento — usar a API S3 em vez de uma API proprietária de armazenamento é exatamente o mesmo raciocínio, e é o motivo de o Object Storage compatível com S3 ser fácil de trocar de provedor.
• Saiba quem sustenta cada peça. Um inventário simples — componente, licença, mantenedor, se é fundação ou empresa — leva uma tarde e responde antecipadamente perguntas que hoje viram reunião de emergência.
• Desconfie da funcionalidade exclusiva. É justamente ela que fecha a porta de saída. Quando um recurso proprietário for realmente melhor, adote-o de olhos abertos e registre a decisão.
• Mantenha o provisionamento reproduzível. A facilidade de migrar de um componente é, na prática, a facilidade de subir um ambiente novo. Quem consegue criar uma VPS e reconstruir o serviço em uma hora troca de tecnologia com muito menos drama do que quem depende de uma máquina configurada à mão em 2019.

A lição que fica

O que essas mudanças revelaram não foi fragilidade jurídica das licenças; foi concentração. Muitos projetos de infraestrutura considerados "da comunidade" eram, na verdade, mantidos por uma única empresa com direito de mudar as regras.

A pergunta a fazer sobre cada peça da sua stack não é "isto é open-source?". É "quem decide o futuro disto, e o que acontece comigo se essa decisão mudar?". Fundação com governança aberta e vários financiadores responde melhor do que uma empresa, por melhor que ela seja hoje.

É exatamente a mesma pergunta que o fim do CentOS impôs a quem operava servidor na família RHEL — e a resposta que serviu lá serve aqui.