A alteração na licença do Redis não afeta ninguém, exceto as empresas como a AWS e outras grandes empresas de computação em nuvem. Se elas contribuíssem um pouco, não seriam necessários forks complicados.
Recentemente houve uma mudança na licença do Redis, o que resultou em muita desinformação, incluindo a afirmação equivocada de que os programadores de nível básico não poderão mais usar o código Redis. Além disso, uma empresa de nuvem de grande porte, a AWS, anunciou um garfo do Redis em meio a essa polêmica.
Isso não é correto. Para a grande maioria dos desenvolvedores, seus direitos sob a licença permanecem inalterados em comparação com a licença de código aberto mais permissiva. Isso implica que grandes empresas de nuvem, como a AWS, não podem mais utilizar o código do Redis sem contribuir de volta.
AWS, após um longo período de lucros provenientes de seu serviço Elasticache (baseado no Redis), decidiu lançar um novo projeto chamado Valkey, envolvendo outros para dividir os custos. Essa decisão foi motivada por experiências anteriores, como o caso do Elasticsearch, que resultou na criação do OpenSearch. Apesar de parecer uma estratégia para conquistar a comunidade em detrimento das corporações, é importante ressaltar que essa “comunidade” é composta por grandes empresas de tecnologia com alto poder financeiro, que buscam garantir um acesso fácil e barato a software, sem contribuir significativamente para o seu desenvolvimento. Os membros desse grupo de empresas bilionárias possuem fundadores cujo valor supera as avaliações de mercado do Redis e de outros projetos de código aberto.
É momento de deixarmos de ignorar que as grandes empresas de tecnologia, especialmente uma delas, são as principais responsáveis por essa situação caótica. A narrativa em torno do Redis pode ser relacionada ao lucro, mas o verdadeiro poder está nas gigantes corporações com enormes recursos financeiros.
E quanto aos programadores?
Vamos começar esclarecendo: A maioria dos desenvolvedores não são afetados pela alteração na licença do Redis. A única categoria de desenvolvedores que pode ser afetada por essas mudanças são aqueles que trabalham para empresas de nuvem, mas mesmo assim, a maioria não contribuiu de forma significativa. Isso foi destacado por um comentarista do Hacker News.
Para utilização pessoal em minha empresa ou iniciativa como pessoa física.
- Posso cantar, tenho permissão para copiar e alterar completamente a fonte? Sim.
- Posso contribuir com melhorias através de um pull request? Com certeza.
- Posso baixar, usar e ter o Redis gratuitamente na minha empresa, mesmo que meu projeto seja comercial e esteja gerando lucro? Sim, sou autorizado a fazê-lo.
- Posso desenvolver um produto que utilize o Redis gratuitamente em meu projeto inicial? Sim…
- Posso clonar o repositório git e instalá-lo da mesma maneira que antes? Sim…
- Posso executar o código fonte do Redis na minha nuvem sem ter que pagar por uma licença? Não, isso não é possível.
Capturaste isso? A única coisa que um desenvolvedor não pode fazer com o código Redis é criar um serviço de nuvem gerenciado, a menos que queira contribuir com a infraestrutura utilizada para hospedá-lo. Isso é considerado open source? Não, de acordo com a Definição de Fonte Aberta. No entanto, é o fim do mundo para os desenvolvedores, como estão dizendo? Não.
Embora seja possível alterar e distribuir o código do Redis, é importante considerar que a maioria dos desenvolvedores não tem interesse em fazê-lo. O que eles realmente desejam é um código robusto que seja continuamente suportado e aprimorado ao longo do tempo. Nesse sentido, o investimento da Redis Inc. desempenha um papel crucial. A inovação no Redis não é proveniente da AWS, Microsoft ou Google, com uma exceção que será mencionada posteriormente. Muitas vezes se fala sobre o desenvolvimento da comunidade de projetos de código aberto, mas isso geralmente se mostra mais um mito do que uma realidade. As empresas que seguem o caminho da bifurcação do Redis contribuíram muito pouco para o desenvolvimento atual do Redis.
Pense em Salvatore Sanfilippo, o fundador do Redis. Você esperaria que alguém com um impacto significativo no Redis fosse bem recebido pelos forks, não é mesmo? No entanto, não é bem assim, como aponta um comentarista do Hacker News.
Antirez [Salvatore] conta com 21 mil seguidores em sua conta do GitHub e recebe apoio de 9 patrocinadores. Não são 10, nem 50, nem 1.000, mas sim 9 – um carpinteiro que sofreu um acidente de trabalho ainda pode contar com o suporte deles.
Por sinal, nenhum dos patrocinadores mencionados é uma empresa provedora de serviços em nuvem. É provável que não tenham mais interesse em Sanfilippo, visto que ele não está mais ligado ao desenvolvimento do Redis. Além disso, essas empresas nunca o apoiaram durante a criação do Redis.
Os desenvolvedores necessitam principalmente de um código de qualidade ao qual possam ter acesso livre, utilizar e confiar que será bem mantido. O Redis não decepcionou nesse aspecto, pois procurou garantir que os desenvolvedores continuassem tendo acesso ao seu código e impedir que terceiros atrapalhassem seu investimento nele.
Por que alterar as licenças?
Vaughn-Nichols destaca um padrão recorrente: uma empresa começa a utilizar código aberto em seu programa, obtém grande lucro a partir disso e somente depois decide licenciar o software, deixando seus colaboradores, clientes e parceiros em uma situação complicada enquanto tentam lucrar bilhões. Ele considera isso preocupante, assim como as práticas das empresas envolvidas. Geralmente, essas mudanças só ocorrem sob pressão ou controle.
Vaughn-Nichols aponta que o equívoco está no fato de que essas empresas interpretaram “open source” como um modelo de negócio, mas ele está enganado sobre isso. O verdadeiro problema é que as empresas de tecnologia confundiram o conceito de código aberto como algo que poderiam usar sem contribuir de volta.
Uma justificativa que defendo é a necessidade do OSI cumprir sua missão e promover o copyleft robusto para aplicativos de nuvem. Ao fornecer aos desenvolvedores (sejam eles corporativos ou não) os recursos para preservar a liberdade de seu código, poderemos observar uma redução na disponibilidade de software de código aberto. A solução é simples assim.
Enquanto isso, o garfo Valkey afirma que as nuvens temem perder a oportunidade de adquirir o molho Redis, para o qual elas tiveram uma contribuição insignificante. Esse comentário se refere principalmente a uma nuvem específica (AWS).
A ironia reside no fato de que Redis é uma das áreas em que a AWS realmente contribui. Eu costumo mencionar o excelente trabalho de Madelyn Olson, um mantenedor do Redis, como um exemplo diário para a AWS. Isso se deve em parte à incrível habilidade de Olson e, em parte, ao fato de que ela era praticamente o único exemplo que a AWS tinha. Como ela recentemente observou, “Eu trabalhei no Redis no meu tempo livre.” Isso não significa que ela nunca tenha trabalhado com o Redis para a AWS, mas destaca a situação da engenharia open source na AWS. Uma das principais razões pelas quais os engenheiros da AWS contribuem menos do que seus colegas em outras plataformas de nuvem é que a liderança de engenharia vê pouco valor nisso. Algumas equipes começaram a mudar essa mentalidade (como as equipes RDS/Aurora que perceberam que era de seu interesse pessoal contribuir mais para o Postgres), mas elas são a exceção, não a regra.
Desconfia de mim? Mesmo com o interesse crescente da AWS pela Fundação Linux por meio do projeto Valkey/Redis, é difícil encontrar evidências de contribuições significativas da AWS em termos financeiros. Recomendo verificar os dados de desenvolvimento da CNCF para mais informações.
Escolha um projeto. O Kubernetes é um exemplo. A AWS é o principal fornecedor de Kubernetes e obtém grandes lucros com isso. No entanto, suas contribuições são mínimas se comparadas com as do Google ou da Red Hat. As contribuições da AWS para o Kubernetes ficam atrás da empresa DaoCloud Network Technology Co. Ltd. e à frente da Scale Factory Limited. É possível que você não conheça essas empresas, mas elas estão contribuindo tanto quanto a AWS.
Prometheus, OpenTelemetry e outros projetos são fundamentais para a AWS fornecer seus serviços de nuvem, no entanto, a empresa não se destaca entre os maiores contribuidores para OpenTelemetry, nem mesmo entre os 20 principais contribuidores para o Prometheus. Embora a AWS lucre bilhões de dólares por meio desses projetos de código aberto, com exceção de alguns lançamentos próprios, a empresa contribui com poucas linhas de código.
Violando o código aberto? De forma alguma. Contudo, é o motivo pelo qual as pessoas criticaram o Redis por ser um “seguidor de código aberto”.
O que você acha de um cliente extremamente interessado?
Eu costumava expressar essa opinião quando trabalhava na AWS, onde gerenciava a estratégia de código aberto e marketing. Antes de sair, redigi um documento descrevendo como a AWS poderia melhor apoiar seus parceiros de código aberto, argumentando que investir mais nessa área tornaria mais lucrativo para as empresas manterem seus softwares livres. Embora atualmente trabalhe na MongoDB, que mudou sua licença recentemente, isso não muda o fato de que essa era uma preocupação constante para mim, independentemente do empregador.
Eu confiei naquilo naquele momento, e continuo confiando, acreditando que isso manteria a cadeia de fornecimento de código aberto da AWS segura, ao mesmo tempo em que atenderia melhor aos clientes. Os clientes não desejam, de fato, Valkey (o garfo Redis) ou OpenTofu (o garfo Terraform), ou OpenSearch (o garfo Elasticsearch). Eles preferem a versão original e completa.
Não é complicado encontrar maneiras de assegurar que os clientes continuem a ter acesso a serviços como Redis, Elasticsearch, Terraform, entre outros. As empresas de nuvem estão aprendendo a colaborar de forma mais eficaz. Por exemplo, o Google Cloud tem apoiado a Elastic para oferecer uma excelente experiência com Elasticsearch. A Microsoft também tem contribuído ativamente, tanto com código quanto com financiamento, para projetos de código aberto, incluindo uma parceria significativa com a Elastic. Por outro lado, a AWS tem adotado uma abordagem mais controversa em relação ao Elasticsearch, retratando-se como vítima em publicações de blog e lançando uma versão própria do serviço.
Para ser imparcial em relação à AWS, é importante mencionar que sua adesão aos Princípios de Liderança afeta e torna mais complexa sua relação com o software de código aberto. Enquanto a abordagem centrada no cliente é vista como algo positivo para a empresa, a necessidade de ter controle para alcançar resultados pode dificultar as parcerias.
É um dilema complicado, mas por que a situação interna enfrentada pela AWS deve ser transferida para empresas de código aberto que já estão dedicando esforços significativos no desenvolvimento de software? Embora a AWS tenha feito melhorias, que foram elogiadas, não deveríamos considerá-la como a heroína do código aberto no caso do Redis.
Atualmente, só conseguimos visualizar um cenário em que as nuvens ajudam as comunidades já existentes, em vez de dividir essas comunidades quando suas receitas bilionárias são ameaçadas pela ideia de trabalharem juntas. Isso é algo alcançável se você se esforçar.
