- A partir do Redis 7.4, o Redis deixa de ser distribuído sob a BSD 3-Clause e passa a ser oferecido sob RSALv2 ou SSPLv1, mudando significativamente os limites de licenciamento
- O código-fonte continuará sendo oferecido gratuitamente como Redis Community Edition, mas as novas licenças não se enquadram como open source segundo a definição da OSI
- O Redis pretende integrar Core e Stack, reunindo busca, JSON, vetores, estruturas de dados probabilísticas e modelo de dados de séries temporais em um único pacote gratuito
- Uso interno e pessoal, bibliotecas cliente, parceiros de integração e clientes existentes do Redis Enterprise não serão afetados, mas serviços gerenciados concorrentes não poderão usar gratuitamente o novo código-fonte do Redis
- A partir do Redis 8, os recursos do Redis Stack deverão ser incorporados ao próprio Redis, e depois disso começará o fim de vida de builds separadas do Redis Stack
Escopo da mudança de licença do Redis
- Todas as versões futuras do Redis passarão a ser distribuídas sob uma licença com código-fonte disponível
- A partir do Redis 7.4, o software Redis Core poderá ser usado sob a Redis Source Available License v2 ou a Server Side Public License v1
- Ele não será mais distribuído sob a licença BSD 3-Clause
- O código-fonte do Redis continuará sendo disponibilizado gratuitamente como Redis Community Edition por meio do repositório GitHub do Redis
- Tanto a RSALv2 quanto a SSPLv1 não são licenças aprovadas pela OSI e cada uma tem restrições de uso
Integração do Redis Stack e mudanças na composição do produto
- As futuras releases com código-fonte disponível vão integrar o Redis Core e o Redis Stack
- A integração abrange busca, JSON, vetores, estruturas de dados probabilísticas e modelo de dados de séries temporais
- Isso será oferecido em um único pacote gratuito para download, e o Redis poderá ser usado como
- armazenamento chave/valor de alto desempenho
- armazenamento de documentos
- engine de consultas
- banco de dados vetorial de baixa latência para aplicações de IA generativa
- A partir do Redis 8, os novos tipos de dados e engines de processamento antes oferecidos no Redis Stack sob RSALv2 ou SSPLv1 deverão passar a fazer parte do pacote padrão
- Depois da disponibilização do Redis 8, builds separadas do Redis Stack deixarão de ser necessárias, iniciando o fim de vida do Redis Stack
Motivo da mudança e posição do Redis
- O Redis afirma que já vinha aplicando licenciamento duplo aos módulos avançados do Redis nas distribuições do Redis Stack, e que mais de 50% dos downloads em redis.io desde o Redis 6 vieram do Redis Stack
- A empresa entende que manter várias distribuições ao mesmo tempo entra em conflito com o avanço futuro do desenvolvimento do Redis
- distribuição open source
- distribuição com código-fonte disponível
- software comercial otimizado para ambientes on-premises e plataformas em nuvem
- O Redis considera que os principais provedores de serviços em nuvem estão comercializando os investimentos do Redis e da comunidade open source
- A mudança é uma medida para gerenciar o uso comercial e continuar investindo em software gratuito rico em recursos e em produtos enterprise
- Com essa mudança, o Redis deixa de ser open source segundo a definição da OSI
Impacto para usuários e parceiros
- Usuários finais que utilizam versões open source existentes do Redis ou novas releases com licenciamento duplo para uso interno ou pessoal não serão afetados
- Também não há mudanças para parceiros que criam bibliotecas cliente ou outras integrações com o Redis
- Todas as bibliotecas cliente mantidas pelo Redis continuarão sob licenças open source
- Clientes atuais do Redis Enterprise não serão afetados, pois recebem a tecnologia sob termos de licença negociados separadamente
- Parceiros de integração e de serviços gerenciados que usem o Redis Community Edition ou o Enterprise de forma não concorrente poderão continuar construindo, operando e oferecendo soluções por meio da parceria com o Redis
- O Partner Program oferecerá acesso exclusivo a futuras tecnologias, recursos e releases do Redis
Restrições para serviços em nuvem e produtos concorrentes
- Sob as novas licenças, provedores de serviços em nuvem que ofereçam serviços hospedados de Redis não poderão usar gratuitamente o código-fonte do Redis
- Por exemplo, um provedor de nuvem só poderá oferecer o Redis 7.4 após chegar a um acordo de licenciamento com o Redis, mantenedor do código
- A definição de “oferta concorrente” do Redis se refere a um produto derivado da base de código do Redis, com grande sobreposição às funções dos produtos comerciais do Redis e vendido a terceiros
- Isso também inclui venda por meio de contratos de suporte pagos
- Um exemplo é hospedar ou embutir o Redis em soluções vendidas de forma concorrente ao Redis Enterprise Software ou ao Redis Cloud
- Soluções que usem o Redis sem competir especificamente com o próprio Redis não serão afetadas
- Dúvidas sobre casos de uso específicos devem ser encaminhadas para redis_licensing@redis.com
Termos da RSALv2 e da SSPLv1
- A RSALv2 é uma licença permissiva, de caráter não copyleft, que permite usar, copiar, distribuir, disponibilizar e preparar obras derivadas do software
- A RSALv2 tem duas principais restrições
- não é permitido comercializar o software nem oferecê-lo como serviço gerenciado para terceiros
- não é permitido remover ou ocultar a licença, copyright e outros avisos
- A SSPLv1 é baseada na AGPL e exige que, ao oferecer o software como serviço, todo o código-fonte do serviço seja publicado sob SSPL
- Isso inclui software de gerenciamento, interface de usuário, API, automação, monitoramento, backup, armazenamento e hospedagem
- A MongoDB é a emissora dessa licença
- Versões modificadas de software licenciado sob SSPL não podem ser redistribuídas sob outra licença
- Em um licenciamento duplo, se a RSALv2 for escolhida, é possível modificar e redistribuir dentro dos limites das restrições da RSALv2, como não fornecer a funcionalidade como serviço a terceiros
Versões BSD existentes e patches de segurança
- A mudança de licença não será aplicada retroativamente
- Todo o código-fonte e todas as releases anteriores à mudança permanecerão sob a licença BSD 3-Clause
- Os usuários poderão continuar usando indefinidamente as versões BSD existentes, desde que cumpram os termos dessa licença
- O Redis planeja continuar fornecendo atualizações de segurança e correções críticas para essas releases de acordo com a política de segurança atual, enquanto o Redis Community Edition estiver disponível
- Backports de patches críticos de segurança para versões existentes sob BSD 3-Clause serão fornecidos até o lançamento do Redis Community Edition 9.0; depois disso, os patches passarão a ser disponibilizados sob o novo licenciamento duplo
Nomes, contribuições e condições de combinação de código
- O Redis 7.2 e releases anteriores continuarão sendo chamados de Redis OSS
- A partir do Redis 7.4, a versão pública e gratuita passará a se chamar Redis Community Edition
- Não será mais permitido usar “Redis” ou “for Redis” no nome do produto, mas será possível indicar na descrição do produto que ele é compatível com Redis ou baseado em legacy-Redis
- Contribuições da comunidade continuarão sendo aceitas, mas para revisão será necessário concordar com o Contributor License Agreement
- Código sob RSALv2 ou SSPLv1 pode ser usado junto com código sob outras licenças desde que cada componente mantenha sua própria licença e não seja misturado com código de copyleft forte como GPL
- É permitido hospedar o Redis como serviço dentro da própria organização, e organização inclui afiliadas e subsidiárias
1 comentários
Opiniões no Hacker News
Acho bem provável que isso prejudique a Redis Labs, assim como a Hashicorp acabou ficando pressionada e procurando um comprador, e nem deve impedir quem quiser copiar a Redis Labs
Quem realmente sai prejudicado são as pequenas startups que querem usar cache Redis sem dor de cabeça jurídica. A AWS pode fazer um fork do Redis e, se lançar esse fork sob uma licença permissiva, a Redis Labs pode virar a opção pior do ponto de vista de licenciamento
É uma escolha difícil, mas acho melhor manter o código proprietário ou então continuar com Apache ou MIT. Mudar a licença no meio do caminho é muito ruim e parece destinado a sair pela culatra
Open source significa permitir que os usuários sejam donos do software. Quando se tenta contornar isso com malabarismos jurídicos para ganhar dinheiro, quem se machuca são os usuários, não as equipes de grandes empresas. O Redis sempre foi um projeto open source permissivo, e teve sucesso exatamente por isso. Mudar essas condições também muda a conta daqui para frente e prenuncia um resultado ruim para todos os envolvidos
Precisamos enxergar com mais clareza a diferença entre software pertencente a uma fundação, como o PostgreSQL, e open source pertencente a uma empresa. Quando o foco é “maximizar valor para os acionistas”, o objetivo de proteger a liberdade dos usuários inevitavelmente acaba ficando em segundo plano
Para a comunidade Redis, teria sido muito melhor se Antirez tivesse separado a relação de emprego da propriedade do projeto e a colocado nas mãos de uma entidade sem fins lucrativos. Algo como um Apache Redis teria sido melhor para a comunidade, e a Redis Labs ainda poderia ter construído extensões proprietárias e um negócio de nuvem ao redor disso
Temos visto repetidamente que, quando uma empresa publica seu software principal sob uma licença permissiva, um concorrente maior aparece e vende uma solução que redistribui esse software
Se o objetivo central da empresa é lucro, isso é uma ameaça existencial. Por outro lado, se o objetivo da empresa é atuar como guardiã sem fins lucrativos para garantir que o software continue existindo, então isso é um grande sucesso
Essa lógica não se aplica a softwares auxiliares que não são o produto principal, por exemplo ferramentas úteis criadas durante o desenvolvimento, mas que não são aquilo que a empresa vende diretamente para ganhar dinheiro
Esta mudança de licença tenta atacar exatamente esse problema: impedir que hiperescaladores de nuvem peguem carona de graça
Para mim, soa como uma AGPL melhor. Não me importo com nuances filosóficas nem com a lista de aprovação da OSI; no fim, ela é muito menos restritiva que a AGPL. Há código-fonte, posso rodá-lo localmente e posso usá-lo da mesma forma nos meus projetos e em projetos comerciais, no trabalho, em bare metal, VM, Docker, k8s e Azure
O fato de a Microsoft ter que dividir parte do prêmio que já cobra não tem nada a ver comigo. Pelo contrário, é digno de aplauso que tenham encontrado um modelo de negócio sustentável
Desenvolvedores de OSS mantêm os direitos autorais. Exceto no domínio público, somente os autores podem alterar a licença e os termos. Os usuários recebem uma licença para fazer várias coisas com o software e o código; eles não obtêm propriedade
Concordo totalmente, e parece mais um exemplo que se soma ao argumento de Cory Doctorow
A esta altura, acho que um fork já deve estar em andamento. É meio triste ver uma empresa se afastando por conta própria da sua comunidade de desenvolvedores
Entendo por que estão fazendo isso, mas não acho que funcione no longo prazo
A maioria dos usuários do Redis nunca pagou um centavo sequer à empresa por trás dele, e eu também não. Entendo que façam isso para ganhar dinheiro, mas meu comportamento não vai mudar. Vou simplesmente usar o fork. A imensa maioria dos outros usuários do Redis, contribuidores externos e todos os provedores de nuvem que ofereciam Redis comercialmente também farão isso; com o tempo, uma boa parte dos funcionários atuais da Redis pode acabar indo para esse lado também
Como há muitos usuários comerciais e provedores de nuvem, acho que não vai demorar para eles se organizarem. Como já há muita gente pagando, na prática isso é quase inevitável
Já existem precedentes parecidos com Terraform, Elasticsearch, Red Hat etc. Fazer com que uma boa parte dos usuários-alvo e clientes em potencial passe a depender de um fork open source parece uma direção errada como estratégia de negócios
Quando a Oracle assumiu os projetos open source da Sun, como mysql, hudson, openoffice e outros, também perdeu rapidamente a maior parte do controle. As tentativas de convencer as pessoas a usar os produtos fechados da Oracle não deram muito resultado. Até o Java acabou recuando em certa medida, e hoje o centro é o openjdk. Tirando alguns bancos, quase ninguém usa o Oracle JDK. Não há necessidade, e a Oracle parou há muito tempo de fingir que ele tinha vantagens. Todo o desenvolvimento acontece no OpenJDK, e há várias empresas oferecendo builds certificados
Pessoalmente, faço consultoria em Elasticsearch e Opensearch, e a maioria dos clientes recentes adota Opensearch como padrão. Simplesmente é para onde as coisas caminharam. Todos escolhem a opção gratuita e open source
A conclusão é uma só: será criado um fork do Redis que a maioria dos usuários atuais do Redis vai acabar usando
[1] https://www.microsoft.com/en-us/research/blog/introducing-ga...
Do ponto de vista das empresas, elas podem aceitar aumentos de preço para não migrar completamente, ou durante uma migração de curto prazo
Para evitar uma saída no curto prazo, o fornecedor também pode “comprar tempo”, mantendo os preços baixos, e depois aumentá-los quando o projeto já tiver se diferenciado o suficiente do fork para tornar a migração muito mais difícil
De um jeito ou de outro, no longo prazo, pode ser possível ganhar muito dinheiro com poucas empresas, em vez de continuar dando suporte a muitas empresas de vários portes. Não gosto disso, mas parece que pode funcionar
Só dividir a comunidade do MySQL, reduzir o uso e o desenvolvimento externo e desacelerar o projeto como um todo já pode ter gerado um bom retorno sobre o investimento
A grande força motriz desses projetos continua sendo a receita de hospedagem, e é por isso que acontecem mudanças de licença
Observando a tendência, parece que o único tipo de open source que faz sentido para a empresa dona do projeto são as bibliotecas. Se for um programa, por exemplo software de servidor como um banco de dados, ele precisa ser source-available ou ficar sob uma fundação. É difícil, e não sei qual é a resposta
Eu gostaria de ver um modelo que trouxesse de volta licenças open source permissivas também para programas complexos, mas ainda não vejo uma forma viável. Talvez seja algo com aplicação de marca registrada, código open source e fornecimento apenas de builds licenciados
De qualquer forma, continuaremos vendo a ascensão e queda, ou mudanças de licença, de softwares open source populares. As vantagens para desenvolvedores e empresas começarem como open source são grandes demais, e a pressão para mudar depois também é grande demais
Pelo menos quero reconhecer que o valor que o Redis entregou ao mundo foi muito maior do que o valor que capturou. A diferença é realmente enorme
Vai ser interessante ver quão rápido um fork surgirá e terá sucesso, e como será a curva de crescimento de receita da empresa Redis daqui a 5 anos
Não entendo muito de licenças, mas tenho bastante empatia pela situação de empresas pequenas e médias que criam a tecnologia de base e acabam tendo isso comoditizado e revendido a preços altos por gigantes oligopolistas da nuvem. Na verdade, é surpreendente que tenha demorado tanto
Quando se diz que empresas e open source querem um ecossistema saudável, fico curioso sobre que alternativas existem além de mudar a licença
Há muitos casos em que uma única empresa decide, na prática, “fazer um fork” para fora da fundação e sair, e a comunidade acaba enfrentando o mesmo resultado
https://spdx.org/licenses/AGPL-3.0-or-later.html
Quem cria ferramentas de trabalho também tem contas a pagar
Em certo sentido, os próprios desenvolvedores também têm responsabilidade pelo fracasso do sonho FOSS
Estamos voltando lentamente aos tempos do domínio público e do shareware
As pessoas sempre disseram que o modelo para ganhar dinheiro com open source era serviços de suporte. Por exemplo, se uma empresa usa Postgres, um especialista ajuda na configuração on-premises e resolve incidentes.
Mas, na era da “nuvem”, as empresas simplesmente usam serviços gerenciados oferecidos por Amazon, Microsoft, Google etc., e as oportunidades financeiras dos mantenedores do projeto e das pessoas ao redor praticamente desaparecem. Ninguém quer trabalhar até a exaustão em OSS e ver a AWS ganhar milhões de dólares sem devolver nada
Madelyn Olson, empregada pela AWS, fez durante anos o trabalho duro, conquistou a confiança de outros desenvolvedores centrais do Redis e se tornou mantenedora principal. Ela e outros desenvolvedores da AWS contribuíram bastante para o motor central do Redis. Também se pode dizer que eles trabalharam duro pela comunidade Redis.
É possível ler mais sobre essas contribuições aqui: https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...
Mais projetos open source deveriam adotar a SSPL ou experimentar abordagens como a do Llama 2, que impõe limites ao porte das empresas que podem usar gratuitamente. Por exemplo, seria open source, mas não se aplicaria a hiperescaladores de nuvem de dezenas de bilhões de dólares.
Quando desenvolvedores individuais contribuem, não era para viabilizar o uso gratuito pela AWS.
O maior motivo pelo qual os projetos estão migrando para licenças mais restritivas é a AWS. A coisa certa que a AWS deveria ter feito era respeitar o trabalho do autor ou da empresa original e fortalecer o produto apoiado pelo desenvolvedor original. Em vez disso, quando vê um produto OSS fazer sucesso, a AWS cria um produto concorrente. Por causa de integrações mais estreitas e força de marketing, fornecedores terceirizados não têm chance.
Além disso, Amazon e AWS são grandes — talvez os maiores — beneficiários do open source, mas devolvem muito pouco. Google, Microsoft e até a Oracle contribuem mais para o open source do que a Amazon
Nunca contribuí para projetos com CLA e não pretendo fazê-lo no futuro, a menos que meu empregador me pague por isso
Mas, para a viabilidade de longo prazo do FOSS, talvez sejam necessárias restrições para nos protegermos de gigantes corporativos que, na prática, exploram desenvolvedores FOSS
Redis, Mongo, ES, o conjunto de produtos da HashiCorp e todo o ecossistema de big data ficaram mais conhecidos por serem oferecidos pela AWS. Há também muitos bancos de dados pouco conhecidos, desenvolvidos por anos, que as pessoas ainda não conhecem porque a AWS ou outros grandes provedores de nuvem não os impulsionaram.
Além disso, graças a licenças permissivas, muitos projetos receberam contribuições como relatórios de bugs, PRs e patches à medida que o uso e a popularidade aumentaram. Não tenho muita vontade de contribuir com algo licenciado sob SSPL ou licenças da família BSL, porque não quero desperdiçar tempo em algo que talvez eu não possa usar livremente depois
Se o Redis tivesse surgido com restrições parecidas com as do Llama 2, teria fracassado desde o início. Os principais consumidores são empresas, e a principal razão pela qual o Llama 2 ficou popular foi oferecer cedo um LLM de alta qualidade que indivíduos podiam usar para fins pessoais.
Um armazenamento chave-valor compatível com RESP não é algo especialmente extraordinário. A Microsoft acabou de lançar sua própria implementação, garnet, sob licença MIT. O valor do Redis sempre esteve em ser gratuito e open source, e na comunidade que sustentou isso. Agora, ele está abrindo mão do maior motivo para usar Redis
Mas esse é praticamente o único caso que conheço; em quase todos os outros casos, como MongoDB, Redis, Memcached, MySQL, PgSQL etc., não é assim
A Redis Inc. está migrando o projeto https://github.com/redis/redis/ da licença BSD de 3 cláusulas para um modelo de licença dupla com duas licenças não aprovadas pela OSI.
Antes, ela já havia dito que “a licença do Redis core é 3-Clause-BSD e sempre continuará sendo”. (https://redis.com/blog/redis-labs-modules-license-changes/)
Se você está preocupado com o fim do suporte, o Redis 7.4 será o primeiro lançamento sob a nova licença, e o 7.2 será o último lançamento sob a licença antiga.
O Redis dá suporte, em um determinado momento, a dois lançamentos adicionais: latest major.(minor-1), (major-1).(last-minor)
Em linhas gerais, isso significa que, quando o 8.0 sair, o suporte ao 6.2 termina; e, quando o 7.6 ou o 8.0 sair, o suporte ao 7.2 termina.
Olhando os lançamentos anteriores, espera-se que o 8.0 saia por volta de março a maio de 2025. Portanto, se você depende do Redis sob a licença 3BSD, deve se planejar de acordo.
O Ubuntu empacota o redis no repositório
universe, portanto upgrades de segurança são fornecidos apenas a clientes do Ubuntu Pro. Assim, no Ubuntu 20.04, os upgrades do redis param em abril de 2024, exceto para usuários do ESM no Ubuntu Pro.O Debian 11/12 acompanha o Redis 6.0/7.0, então tem a responsabilidade de fazer backport dos patches do 7.2. Se o 7.2 deixar de receber atualizações de segurança e elas passarem a ser fornecidas apenas no branch 7.4, não está claro como isso vai ficar.
Mesmo que a sua forma de uso direto seja compatível com a nova licença, você pode ser afetado indiretamente. Como é provável que as distribuições excluam o redis dos repositórios oficiais nos próximos lançamentos, é preciso considerar isso no próximo ciclo de upgrade da distribuição.
(Eu mantenho https://endoflife.date/redis, então, se alguém souber claramente quais serão os impactos sobre o fim do suporte e a manutenção, posso fazer merge de um PR.)
A nova licença, a SSPL, provavelmente não é open source, ao menos por causa da restrição de campo de uso: https://opensource.stackexchange.com/questions/7522/sspl-and... https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
https://opensource.org/definition-annotated#6
Esse é exatamente o ponto central do open source e, em certo sentido, do software livre. Licenças copyleft têm restrições, mas, se você as seguir, pode construir o que quiser com aquele software. As licenças SSPL, FSL e BUSL bloqueiam de antemão a concorrência em determinados formatos comerciais.
O fato de a maioria dos modelos de negócio não querer seguir copyleft não significa que ele não seja open source. Significa apenas que ele não se encaixa nesses modelos de negócio.
Novas licenças como SSPL, BSL e FSL estão ficando cada vez mais populares, e há bons motivos para isso. Vinte anos atrás, não havia uma situação em que a AWS revendesse FOSS para o mundo todo, então as condições eram muito diferentes das de hoje.
Por causa das restrições, não é “open source”, mas o termo mais próximo depois disso, “source-available”, também não reflete bem a realidade. Ele sugere algo mais próximo de “o código-fonte está tecnicamente em algum lugar”.
ElasticSearch, Sentry e outros ainda são desenvolvidos publicamente; pessoas sem relação com o projeto podem enviar PRs; e qualquer um pode fazer o que quiser, desde que não esteja tentando competir publicamente com a empresa por trás do projeto.
Ao mesmo tempo, a Microsoft abriu o Garnet: https://github.com/microsoft/garnet
O timing é bom.
A lógica era que a MS lançaria a isca e depois mudaria a licença quando precisasse, então seria melhor ficar com o Redis, que sempre manteria uma licença open source. Foi uma previsão e tanto.
Os fundadores técnicos da Redis e da Hashicorp acabaram deixando suas respectivas empresas antes que elas se afastassem do FOSS e enfrentassem uma grande tempestade. Isso se o cronograma estiver correto.
Fico curioso se eles sabiam disso com antecedência e eram contra, se sabiam mas queriam evitar o dano à reputação, ou se a mudança só pôde ser levada adiante porque eles saíram. Concorde-se ou não com esse movimento, há dano reputacional.
É pura especulação, mas chama atenção que parece estar se repetindo na Redis o que vimos na Hashi.
Eu também não deixei passar a semelhança com a Hashi.