Histórico de Licenciamento do Redis e o Fork Valkey

Entender um pedaço da história do Redis que não tem nada a ver com comandos ou estruturas de dados mas que muda qual binário você deveria de fato instalar: o Redis era open source licenciado sob BSD desde sua criação em 2009 até 2023 (a era em que os dois livros-fonte deste módulo foram escritos); a Redis Inc. o relicenciou para uma licença dupla source-available em março de 2024, por causa de provedores de nuvem monetizando o Redis sem contribuir de volta; a Linux Foundation lançou um fork licenciado permissivamente chamado Valkey em oito dias, apoiado por AWS, Google Cloud e Oracle entre outros; e em maio de 2025 a Redis Inc. voltou atrás e adicionou a AGPLv3, aprovada pela OSI, como opção de licenciamento para o Redis 8. Este conceito não tem fonte de livro nenhuma: é um histórico de licenciamento e governança, não um mecanismo técnico, e toda data e citação abaixo é verificada diretamente contra os próprios posts de blog da Redis Inc., o próprio comunicado de imprensa da Linux Foundation, e o próprio documento de governança do Valkey em vez de presumida a partir de conhecimento de treinamento, porque errar uma data de histórico legal é pior do que errar uma flag de comando.

• Escolher qual binário fazer docker pull ou apt install para um projeto novo. "Redis" e "Valkey" são dois projetos diferentes, compatíveis em protocolo, com duas licenças diferentes hoje, e a escolha precisa ser feita uma vez, deliberadamente, em vez de assumida por padrão a partir de qualquer tutorial pesquisado primeiro.
• Explicar a uma equipe jurídica ou de compras por que "Redis" aparece sob dois nomes de licença diferentes em uma auditoria de dependência. Uma base de código construída antes de março de 2024 referencia Redis licenciado sob BSD; uma construída entre março de 2024 e maio de 2025 pode referenciar Redis licenciado sob RSALv2/SSPLv1; uma construída desde maio de 2025 pode referenciar Redis licenciado sob AGPLv3: três respostas diferentes para "qual licença rege essa dependência" dependendo exatamente de quando foi puxada.
• Avaliar uma oferta de Redis/Valkey gerenciado de um provedor de nuvem. Saber que o AWS ElastiCache, o Google Cloud Memorystore, e as ofertas da Oracle se moveram em direção ao Valkey especificamente por causa do relicenciamento de 2024 explica por que o serviço "compatível com Redis" de um dado provedor às vezes está literalmente rodando Valkey por baixo dos panos.
• Decidir se os termos de copyleft de rede da AGPLv3 são compatíveis com um produto que embute o Redis e o expõe como parte de um serviço hospedado: uma pergunta real para quem constrói um produto SaaS por cima do Redis 8 hoje, não uma resolvida.

2009-2023: BSD 3-Clause, a era que os dois livros-fonte descrevem

O Redis foi criado em 2009 por Salvatore Sanfilippo ("antirez") e lançado sob a licença permissiva BSD 3-Clause desde o início. Essa é a realidade de licenciamento contra a qual os dois livros-fonte deste módulo (2013 e 2015) foram escritos, e é por isso que nenhum dos dois livros tem nada a dizer sobre licenciamento: pelos primeiros quinze anos da existência do Redis, "open source" e "a licença sob a qual o Redis vem" eram simplesmente a mesma pergunta com uma resposta. O próprio anúncio de março de 2024 da Redis Inc. confirma a licença e sua própria data final com precisão: "Consequentemente, o Redis não será mais distribuído sob a licença Berkeley Software Distribution (BSD) de três cláusulas", começando com o Redis 7.4. Todo release de 1.0 até 7.2 permaneceu BSD, e, segundo o FAQ desse mesmo anúncio, "a mudança de licença não é retroativa", então todo código-fonte e releases pré-7.4 permanecem licenciados sob BSD permanentemente, usáveis indefinidamente sob os termos originais.

20 de março de 2024: a mudança para a dupla RSALv2/SSPLv1

Em 20 de março de 2024, a Redis Inc. anunciou que o Redis 7.4 e todos os releases futuros viriam sob uma licença dupla: a Redis Source Available License v2 (RSALv2) ou a Server Side Public License v1 (SSPLv1), em vez de BSD. O próprio post de blog da Redis Inc. é explícito de que isso é uma saída deliberada do open source aprovado pela OSI, não um rebranding: "reconhecemos abertamente que essa mudança significa que o Redis não é mais open source sob a [definição da OSI]", e o FAQ explica a mecânica da nova restrição claramente: "a RSALv2 é uma licença permissiva sem copyleft... [que tem] apenas duas limitações principais. Sob a RSALv2, você não pode: comercializar o software ou fornecê-lo a outros como um serviço gerenciado; e remover ou obscurecer qualquer aviso de licenciamento, copyright, ou outro." A SSPLv1, "baseada na GNU Affero General Public License (AGPL)... exige que quem torna software licenciado sob SSPL disponível a terceiros... como parte de um 'serviço' precisa liberar o código-fonte da totalidade do serviço."

A justificativa declarada da própria Redis Inc. é diretamente sobre provedores de nuvem extraindo valor sem reinvestir: "a maioria das vendas comerciais do Redis é canalizada pelos maiores provedores de serviço em nuvem, que comoditizam os investimentos do Redis e sua comunidade open source... Sob a nova licença, provedores de serviço em nuvem hospedando ofertas do Redis não terão mais permissão para usar o código-fonte do Redis de graça." Rowan Trollope, CEO da Redis Inc., fez o mesmo ponto de novo um ano depois, no post de blog anunciando a eventual reversão: "como você continua inovando e investindo em projetos OSS quando provedores de nuvem colhem os lucros e controlam a infraestrutura sem contribuições proporcionais de volta para os projetos que exploram?": a mesma reclamação, reafirmada como o motivo pelo qual a mudança de 2024 aconteceu em primeiro lugar.

A reação da comunidade foi imediata e negativa o bastante para que a própria Redis Inc. depois descrevesse o desdobramento em suas próprias palavras: "isso alcançou nosso objetivo (a AWS e o Google agora mantêm seu próprio fork), mas a mudança prejudicou nosso relacionamento com a comunidade Redis. A SSPL não é verdadeiramente open source porque a Open Source Initiative esclareceu que ela carece dos requisitos para ser uma licença aprovada pela OSI." Essa admissão, do próprio CEO da Redis Inc., no próprio blog da Redis Inc., é uma confirmação tão direta da reação negativa da comunidade quanto qualquer comentário de terceiros poderia oferecer.

28 de março de 2024: a Linux Foundation lança o Valkey

Oito dias depois do anúncio de relicenciamento, em 28 de março de 2024, a Linux Foundation anunciou que hospedaria o Valkey, uma continuação licenciada permissivamente do código-fonte do Redis pré-relicenciamento, feita como fork do Redis 7.2.4, o último release licenciado sob BSD. O próprio anúncio da Linux Foundation declara a escolha de licença diretamente: o Valkey "manteria o projeto disponível para uso e distribuição sob a licença open source Berkeley Software Distribution (BSD) de três cláusulas", e nomeia seus apoiadores fundadores como Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson, e Snap Inc., com mais de cinquenta empresas adicionais, incluindo Alibaba, Tencent, Huawei, ByteDance, Percona, e Canonical, se juntando em semanas.

A governança do Valkey é deliberadamente multi-fornecedor em vez de empresa única, por regra escrita explícita. Seu GOVERNANCE.md declara que "o TSC é responsável pela supervisão de todos os assuntos técnicos, de projeto, aprovação e política para o Valkey", e limita diretamente a influência de qualquer empresa sobre esse órgão: "a qualquer momento, não mais do que um terço (1/3) dos membros do TSC podem ser funcionários, contratados, ou representantes da mesma organização ou organizações afiliadas." No momento desta escrita, os membros do TSC incluem representantes da Amazon, Google, Oracle, Tencent, Alibaba, e Ericsson: a mesma coalizão de empresas de nuvem e infraestrutura que apoiou o fork no lançamento, agora formalmente compartilhando controle técnico dele sob governança da Linux Foundation em vez de qualquer fornecedor único segurá-lo.

Maio de 2025: a Redis Inc. adiciona a AGPLv3 de volta

Em 1º de maio de 2025, a Redis Inc., de novo via um post de blog escrito por Rowan Trollope, cronometrado para o lançamento de disponibilidade geral do Redis 8, anunciou que o Redis adicionaria a licença AGPLv3 aprovada pela OSI como uma terceira opção de licenciamento junto com a RSALv2 e a SSPLv1, efetiva a partir do Redis 8: "adicionando a AGPL aprovada pela OSI como uma opção de licenciamento adicional para o Redis, a partir do Redis 8 (disponível agora)." O post liga a reversão a dois desdobramentos concretos que a empresa nomeia diretamente. Primeiro, pessoal: "Depois da nossa mudança de licença, em novembro de 2024 Salvatore Sanfillipo (antirez) decidiu voltar ao Redis como evangelista de desenvolvedor... Com orientação de Salvatore, nosso CTO, Benjamin Renaud, e nossos desenvolvedores principais, tomamos algumas decisões-chave para melhorar o Redis daqui para frente": creditando o retorno do autor original do Redis por conduzir a reversão de licenciamento. Segundo, um reconhecimento implícito mas claro do sucesso do fork: o mesmo post que anuncia a AGPLv3 também anuncia dobrar os módulos do Redis Stack (antes só sob RSALv2/SSPLv1: JSON, Time Series, o Query Engine, tipos probabilísticos, e o novo tipo Vector Sets) diretamente para dentro do core do Redis 8 sob AGPLv3: fechando, em um release, tanto a lacuna de licenciamento que empurrou a comunidade para o Valkey quanto a lacuna de fragmentação de recursos que fazia de "Redis" e "Redis Stack" dois downloads diferentes. O padrão (pressão competitiva de um fork bem apoiado e compatível em protocolo ganhando adoção real de provedores de nuvem, seguida de uma reversão que devolve exatamente a propriedade aprovada pela OSI que o fork foi criado para garantir) é o fio condutor que conecta as três datas.

Note precisamente o que não aconteceu: o Redis não abandonou RSALv2/SSPLv1 e voltou para BSD. A AGPLv3 foi adicionada como uma terceira opção; RSALv2 e SSPLv1 continuam escolhas disponíveis para quem as quiser. A AGPLv3 é uma licença de copyleft forte, com divulgação disparada por uso em rede: um conjunto de obrigações materialmente diferente tanto da permissividade quase total da BSD quanto da restrição anticompetitiva mais estreita da RSALv2, então "o Redis é open source de novo" é verdade no sentido da OSI mas não significa "o Redis voltou aos seus termos originais, mais permissivos."

A decisão que essa história cria, hoje

Dois projetos ativamente mantidos, compatíveis em protocolo, e compatíveis entre si de forma plug-and-play agora existem, e escolher entre eles é uma decisão genuína e ainda em aberto, não uma com uma resposta obviamente correta:

• Redis, da Redis Inc., agora licenciado sob uma escolha entre AGPLv3 (aprovada pela OSI), RSALv2, ou SSPLv1. É o projeto no qual Salvatore Sanfilippo está diretamente envolvido de novo, e ele lança novas capacidades primeiro: o tipo de dado Vector Sets do Redis 8, os módulos Query Engine/JSON/Time Series/probabilísticos dobrados para dentro, e o trabalho de desempenho descrito no conceito irmão redis-8-stack-in-core-json-search-vectorsets-timeseries todos chegaram no Redis antes de qualquer equivalente existir no Valkey.
• Valkey, da Linux Foundation, licenciado sob a permissiva BSD 3-Clause, governado por um Technical Steering Committee multi-fornecedor com um teto rígido de um terço para a representação de qualquer empresa única, e apoiado operacionalmente pelos provedores de nuvem mais propensos a rodá-lo em escala: AWS, Google Cloud, e Oracle entre os principais. Ele fica atrás do Redis nos recursos mais novos por design: é uma continuação do código-fonte pré-relicenciamento mais seu próprio desenvolvimento independente, não um espelho em tempo real de tudo que a Redis Inc. lança.

Nenhuma resposta é "correta" independentemente do contexto. Uma organização que se importa principalmente com permissividade de licença, quer governança espalhada entre vários fornecedores em vez de concentrada em uma empresa, ou já está rodando em um serviço gerenciado baseado em Valkey de um provedor de nuvem, tem um caso direto para o Valkey. Uma organização que quer os tipos de dado e o trabalho de desempenho mais novos no primeiro dia, ou tem necessidades de suporte comercial que apontam diretamente para a Redis Inc., tem um caso igualmente direto para o Redis. A opção AGPLv3 estreita a lacuna de licenciamento entre os dois (ambos agora são realisticamente descritíveis como "open source" no sentido da OSI), mas não apaga a diferença de governança (empresa única vs. TSC multi-fornecedor) nem a diferença de cronograma de recursos (primeiro vs. seguinte), e essas duas diferenças são o que de fato separa os dois projetos hoje.

• AGPLv3 não é um retorno à BSD, e as obrigações diferem em tipo, não só em grau. A BSD 3-Clause impõe quase nenhuma condição além de atribuição. A AGPLv3 é uma licença de copyleft forte cujo traço distintivo (uso em rede conta como distribuição) significa que oferecer Redis licenciado sob AGPLv3 como parte de um serviço hospedado pode disparar obrigações de divulgação de código-fonte que nunca se aplicaram sob os termos BSD originais. Tratar "o Redis adicionou AGPLv3" como "o Redis é permissivo de novo" é uma má leitura real e evitável do que mudou.
• RSALv2 e SSPLv1 ainda são opções ativas, não obsoletas. O anúncio de maio de 2025 da Redis Inc. adicionou a AGPLv3; não removeu as outras duas. Uma equipe consumindo Redis hoje ainda pode acabar sob RSALv2 ou SSPLv1 dependendo de qual opção de licença um distribuidor ou empacotador escolheu, então "o Redis é open source agora" precisa de uma pergunta de acompanhamento: sob qual das três licenças, especificamente.
• O Valkey fica atrás do Redis em recursos por design estrutural, não por acidente. A Redis Inc. controla o roteiro do Redis e lança novas capacidades no próprio código-fonte primeiro; o Technical Steering Committee do Valkey, deliberadamente limitado para que nenhuma empresa única (incluindo qualquer um de seus apoiadores provedores de nuvem) possa dominá-lo, precisa construir ou portar funcionalidade equivalente independentemente. Vector Sets, o tipo de dado nativo mais novo discutido no conceito irmão redis-8-stack-in-core-json-search-vectorsets-timeseries, é um exemplo concreto de uma capacidade primeiro-no-Redis que um adotante de Valkey deveria esperar aguardar, se é que chega de todo.
• "Compatível de forma plug-and-play" é um alvo em movimento, não uma garantia permanente. O Valkey fez fork do Redis 7.2.4 e vem acompanhando a compatibilidade de protocolo de perto desde então, mas as duas bases de código agora divergiram por bem mais de um ano sob governança independente. Compatibilidade que valia no momento do fork não é um contrato permanente; precisa ser reverificada contra as versões específicas de fato em uso, especialmente para recursos mais novos do Redis 8 que o Valkey pode implementar diferentemente, mais tarde, ou não implementar de jeito nenhum.
• Essa é uma história de ritmo rápido e ar adversarial em que o instantâneo de hoje pode ser o fato desatualizado de amanhã. Três mudanças de licenciamento em quatorze meses (BSD para licença dupla em março de 2024, o fork Valkey oito dias depois, AGPLv3 adicionada em maio de 2025) é uma taxa de mudança incomumente alta para algo normalmente tão estático quanto uma licença de software. Quem estiver tomando uma decisão Redis-vs-Valkey para um projeto novo deveria reconferir o status atual de licença e roteiro dos dois projetos diretamente em vez de confiar nessa história como uma resposta permanentemente congelada.