As Guerras de Licenças de Código Aberto: Como HashiCorp, Redis e Elastic Mudaram as Regras

O Padrão Que Não Para de se Repetir

Três dos projetos de software de infraestrutura mais amplamente utilizados no mundo mudaram suas licenças em poucos anos um do outro. A HashiCorp mudou o Terraform da Mozilla Public License 2.0 para a Business Source License (BSL) em agosto de 2023. A Redis mudou de BSD para Server Side Public License (SSPL) em março de 2024. A Elastic já havia movido Elasticsearch e Kibana para SSPL em 2021. As três empresas deram explicações semelhantes: provedores de nuvem estavam usando seu software para construir serviços gerenciados concorrentes sem contribuir de volta.

Todas as três enfrentaram forks imediatos da comunidade. O OpenTofu (Terraform) surgiu semanas após o anúncio da HashiCorp, apoiado pela Linux Foundation. O Valkey (Redis) foi lançado em março de 2024, também sob a Linux Foundation, com commits de engenheiros da AWS, Google, Oracle e Alibaba. O OpenSearch (Elasticsearch) já havia sido lançado em 2021, liderado pela AWS. O padrão é consistente o suficiente para constituir um manual — para ambos os lados.

O Que as Mudanças de Licença Realmente Fazem

A Business Source License (BSL), desenvolvida pela MariaDB e adotada pela HashiCorp, permite uso gratuito para a maioria dos propósitos, mas proíbe usar o software em um produto comercial concorrente sem uma licença comercial. Criticamente, o software licenciado sob BSL se converte em uma licença de código aberto (geralmente Apache 2.0) após quatro anos. A HashiCorp definiu uma janela de conversão de quatro anos: o Terraform 1.6 lançado em agosto de 2023 se tornaria Apache 2.0 em agosto de 2027.

A SSPL, criada pela MongoDB, é mais agressiva: exige que qualquer pessoa que ofereça o software como um serviço gerenciado deve abrir o código de toda a pilha usada para fornecer esse serviço — incluindo orquestração, monitoramento e infraestrutura de suporte. Como isso é essencialmente impossível para um provedor de nuvem com infraestrutura proprietária cumprir, a SSPL funciona como uma proibição prática de oferecer serviços gerenciados. A Open Source Initiative não reconhece a SSPL como uma licença de código aberto. Tampouco a Free Software Foundation. Tanto o Redis quanto o Elasticsearch sob SSPL são, pelas definições que mais importam na indústria, software proprietário que por acaso publica seu código-fonte.

HashiCorp: A Aquisição Que Veio Depois

O desenvolvimento mais comercialmente significativo nesta história é o que aconteceu com a HashiCorp após a mudança de licença. A IBM adquiriu a HashiCorp em abril de 2024 por US$ 6,4 bilhões — uma das maiores aquisições em software de infraestrutura empresarial. A IBM opera a Red Hat, que é construída quase inteiramente em software de código aberto e é a maior empresa Linux empresarial do mundo. A aquisição da HashiCorp traz Terraform, Vault, Consul e Nomad para o portfólio da IBM, ao lado do OpenShift e Ansible da Red Hat.

O fork OpenTofu, enquanto isso, alcançou a versão 1.7 em maio de 2024, implementando recursos que o Terraform ainda não havia lançado. O apoio da Linux Foundation significa que o OpenTofu tem suporte institucional e é improvável que entre em colapso por esgotamento dos mantenedores — o destino de muitos forks da comunidade. O OpenTofu é agora uma alternativa crível de longo prazo ao Terraform para organizações desconfortáveis com as restrições da BSL ou com a propriedade da IBM.

A questão prática para equipes que atualmente usam Terraform é direta: se você não está oferecendo Terraform-como-serviço comercialmente e não está em um provedor de nuvem, a BSL não o restringe. A maioria dos usuários empresariais não é afetada. A mudança de licença importa mais para empresas que desejam construir serviços gerenciados do Terraform — e para elas, o OpenTofu é o caminho óbvio.

Redis: O Fork Que Se Moveu Mais Rápido

A mudança de licença do Redis foi a mais dramática em termos de velocidade e amplitude de resposta. Dentro de uma semana do anúncio de março de 2024, AWS, Google Cloud, Oracle e Alibaba Cloud comprometeram recursos de engenharia para o Valkey — um fork da Linux Foundation do Redis 7.2.4, a última versão sob a antiga licença BSD. O repositório GitHub do Valkey teve mais contribuidores em seu primeiro mês do que a maioria dos projetos de código aberto acumula em anos.

A Redis Ltd. (a empresa, distinta do projeto Redis) manteve que o Redis nunca foi verdadeiramente "código aberto da comunidade" da mesma forma que Linux ou PostgreSQL — sempre foi controlado pela empresa. Isso é tecnicamente verdade: a Redis Ltd. possuía os direitos autorais, exigia um CLA para contribuições e tomava todas as principais decisões arquitetônicas. A licença BSD foi uma escolha de negócios, não um princípio fundador. Quando o cálculo comercial mudou — especificamente, quando o AWS ElastiCache e outros serviços gerenciados do Redis cresceram o suficiente para reduzir significativamente o mercado endereçável da Redis Ltd. — a licença mudou.

O Valkey 7.2 é agora a oferta padrão compatível com Redis em várias grandes plataformas de nuvem. Para novos projetos começando hoje, a escolha prática é entre Valkey (Linux Foundation, Apache 2.0, suporte nativo à nuvem) e Redis 7.4+ (SSPL, Redis Ltd., licenciamento comercial para serviços gerenciados). Ambos são maduros, ambos têm bom desempenho e a API é quase idêntica. O ecossistema está se dividindo.

Elastic: O Caso Mais Antigo Que Agora Parece o Modelo

A mudança de licença da Elastic em 2021 foi a mais antiga e, de certa forma, o caso mais claro. A Elastic moveu Elasticsearch e Kibana para SSPL em resposta direta à Amazon oferecer um serviço gerenciado do Elasticsearch — Amazon Elasticsearch Service — sem contribuições substanciais de volta ao projeto. A resposta da Amazon foi bifurcar o Elasticsearch 7.10 (a última versão Apache 2.0) e criar o OpenSearch, que agora mantém e contribuiu para a Linux Foundation.

Quatro anos depois, o OpenSearch divergiu significativamente do Elasticsearch. A AWS envia recursos no OpenSearch que não têm equivalente no Elastic, e a Elastic enviou recursos no Elasticsearch que não estão no OpenSearch. Os dois não são mais compatíveis para casos de uso avançados. Equipes escolhendo entre eles hoje estão efetivamente escolhendo entre dois produtos diferentes que compartilham um ancestral comum, não entre "a coisa real" e "um fork".

O Modelo Open Core e Seus Limites

As empresas que evitaram essa dinâmica com mais sucesso são aquelas que construíram modelos open core desde o início, em vez de depender de licenças permissivas para produtos populares que esperavam monetizar mais tarde. GitLab, Grafana e o próprio Vault da HashiCorp são exemplos onde o produto principal é código aberto, mas recursos empresariais substanciais (SSO, log de auditoria, RBAC avançado, ferramentas de conformidade) são apenas comerciais. Isso cria captura de valor clara sem restringir o uso da comunidade que impulsiona a adoção.

O caminho da mudança de licença — lançar sob uma licença permissiva, construir adoção massiva, depois mudar para uma licença mais restritiva quando um provedor de nuvem está competindo — é cada vez mais visto como uma porta de mão única. Uma vez que um fork da comunidade existe e tem apoio institucional, o projeto original perdeu a boa vontade da comunidade que a licença permissiva estava gerando. Fica com o negócio comercial, mas sem o posicionamento de "projeto de código aberto que todos usam" que o impulsionou.

Para desenvolvedores e equipes de infraestrutura, a lição prática é: trate qualquer projeto de código aberto controlado por uma única empresa com um requisito de CLA como potencialmente proprietário. A licença que você vê hoje pode não ser a licença que rege o software em três anos. O software de código aberto mais seguro, do ponto de vista de risco de licenciamento, é aquele pertencente a uma fundação (Linux Foundation, Apache Software Foundation, CNCF) ou que tenha governança genuinamente distribuída, em vez de controle de uma única empresa.

O Que Vem a Seguir

As guerras de licenças não acabaram. Vários outros projetos de infraestrutura amplamente utilizados — mantidos por empresas bem financiadas com concorrência de provedores de nuvem — enfrentam dinâmicas semelhantes. As empresas observaram o que aconteceu com HashiCorp, Redis e Elastic e estão tomando decisões de licenciamento de acordo.

Um modelo emergente: licenciamento duplo desde o primeiro dia, onde o software está disponível tanto sob uma licença de código aberto para uso da comunidade quanto sob uma licença comercial para uso empresarial em produção, com limites claros que não mudam retroativamente. Outro: propriedade da fundação desde o início, sem que uma única empresa controle a licença. Nenhum dos modelos resolve perfeitamente a tensão fundamental entre dinâmicas de adoção de código aberto e monetização de software comercial — mas ambos evitam o dano à confiança que vem de mudar licenças depois que a comunidade já construiu sobre seu software.