A Redis anunciou que futuras versões do Redis serão distribuídas sob licenças source-available. A partir do Redis 7.4, o projeto passa a adotar licenciamento duplo com Redis Source Available License v2, a RSALv2, e Server Side Public License v1, a SSPLv1. Com isso, o Redis deixa de ser distribuído sob a licença BSD de três cláusulas.1

A decisão é uma das mudanças mais sensíveis no ecossistema de infraestrutura de software. Redis é amplamente usado como cache, banco em memória, fila, componente de streaming e base para aplicações de baixa latência. Alterar sua licença afeta desenvolvedores, provedores de nuvem, fornecedores gerenciados, empresas usuárias e distribuições.

Source-available não é open source tradicional

A Redis afirma que o código continuará disponível gratuitamente para desenvolvedores, clientes e parceiros por meio do Redis Community Edition. A empresa também diz que futuras versões source-available unificarão o Redis core com recursos do Redis Stack, como busca, JSON, vetores, estruturas probabilísticas e séries temporais.1

O ponto jurídico, porém, muda. Nem RSALv2 nem SSPLv1 são licenças aprovadas pela Open Source Initiative. A própria FAQ da Redis reconhece que ambas têm restrições. A RSALv2 limita comercialização do software como serviço gerenciado, enquanto a SSPLv1 impõe obrigações fortes para quem oferece o produto como serviço.

Para desenvolvedores que usam Redis em aplicações internas, a mudança pode parecer distante. Para empresas que redistribuem, embutem ou operam Redis como serviço, o impacto precisa ser analisado com cuidado por equipes jurídicas e de arquitetura.

A disputa é com a economia da nuvem

A Redis justifica a mudança citando o desafio de manter desenvolvimento enquanto grandes provedores de nuvem comercializam serviços baseados no projeto. Segundo a empresa, provedores que hospedam ofertas Redis não poderão usar o código do Redis 7.4 gratuitamente como serviço gerenciado sem acordo de licenciamento.1

Esse argumento repete uma tensão recorrente em infraestrutura aberta: projetos ganham adoção por permissividade, mas empresas mantenedoras buscam capturar valor quando nuvens empacotam o software em serviços lucrativos. Elastic, MongoDB e outros fornecedores já passaram por debates semelhantes.

O risco para a Redis é fragmentação. Quando uma tecnologia muito usada muda de licença, a comunidade pode aceitar os novos termos, permanecer em versões antigas, migrar para alternativas ou apoiar forks. A decisão de licenciamento vira decisão de governança, confiança e previsibilidade.

Empresas devem mapear dependências

O primeiro passo para usuários corporativos é inventariar onde Redis aparece: cache de aplicação, sessões, filas, workers, feature stores, busca, vetores, observabilidade ou serviços gerenciados. Depois, é preciso identificar versão, origem do pacote, contrato cloud e plano de atualização.

Clientes de Redis Enterprise não têm mudança imediata, segundo a empresa. Bibliotecas cliente sob responsabilidade da Redis também permanecem open source. Ainda assim, times de plataforma devem atualizar políticas de aquisição e compliance para diferenciar Redis sob BSD em versões anteriores, Redis 7.4 sob licenças source-available e serviços gerenciados oferecidos por terceiros.

A mudança reforça uma regra prática para software de base: licença é parte da arquitetura. Performance, comunidade e facilidade de uso continuam importantes, mas a permissão de uso em produção, redistribuição e serviço gerenciado pode decidir o custo real de longo prazo.


  1. Redis, "Redis Adopts Dual Source-Available Licensing", 20 mar. 2024.