O conflito entre AWS e Elastic em torno do ElasticSearch
(blog.opsnow.com)Recentemente vi artigos sobre a desistência do Elasticsearch do open source, a declaração de adoção da SSPL e a decisão da AWS de fazer um fork separado e manter uma comunidade open source sob a licença Apache License 2.0, então resolvi resumir o conflito entre as duas empresas que já vinha acontecendo há algum tempo.
Se houver partes incompletas ou incorretas ao longo do texto, deixem comentários que serão refletidos posteriormente.
10 comentários
Pessoalmente, eu não entendo muito bem por que a OSI cancelou o registro da SSPL como licença de código aberto. Eu entendia que era uma licença mais específica que a AGPL, exigindo que provedores de SaaS divulgassem todo o código-fonte, mas não consigo entender muito bem por que a OSI interpreta isso como uma "restrição" ao SaaS.
Mesmo lendo o posicionamento da OSI 1, eles criticam a intenção da Elastic ao adotar a SSPL, mas não explicam qual cláusula da SSPL estaria de fato "restringindo" o uso. Lendo o texto, eu não consigo perceber claramente se há alguma "restrição" em relação à AGPL. Será que sou eu que estou interpretando a licença errado...?
Quem retirou a questão da licença foi a MongoDB. Não foi algo rejeitado pela OSI. Claro que a própria OSI também reagiu dizendo que, devido aos pontos controversos, seria difícil reconhecer isso como open source, mas a MongoDB identificou essa situação com antecedência e acabou retirando o pedido.
Obrigado pela correção. Minha descrição ficou um pouco imprecisa. Ainda assim, é verdade que a MongoDB retirou primeiro, mas mesmo olhando a postagem da OSI apresentada no link, a OSI deixa claro que não tem intenção de aceitar a versão atual da SSPL... então a ordem dos acontecimentos não parece ser tão importante assim.
Concordo. ^^
Eu também estava com certa dúvida e estava pesquisando, então deixo aqui o link para este material.
https://ceart.kr/component/file/…
Trecho
Primeiro, a diferença entre a SSPL e a AGPL é a seguinte. A AGPL anterior determinava que, mesmo quando um software não é distribuído e é executado no lado do servidor, o provedor do serviço, assim como no GPL, deve divulgar todo o código-fonte das modificações e adições feitas nesse software, ficando isso limitado ao próprio servidor.
Já a SSPL exige que, além desse código, ao oferecer o software no formato As-a-Service, também sejam divulgados os códigos de todos os softwares executados pelo usuário do As-a-Service, como software de administração necessário de forma acessória, interface de usuário, API, software de automação, software de monitoramento, software de backup e de armazenamento. Em outras palavras, quando provedores de nuvem oferecem o MongoDB como serviço, a condição é que também tenham de divulgar todo o código-fonte de todos os softwares que criaram para manter sua vantagem competitiva no serviço.
Eu também estava pensando em pesquisar sobre MongoDB e Redis... mas aqui estava muito bem explicado!
Além disso, se você olhar o PDF, também há uma explicação sobre quais pontos não estão em conformidade com a OSI. Pelo que dizem, trata-se de restrições à liberdade e limitações sobre obras derivadas separadas.
Oh... no geral, é um PDF muito bem escrito. Obrigado pelo link.
Vendo assim, dá para entender a diferença em relação à AGPL e o motivo de não aceitarem a SSPL, mas também me faz pensar se a OSI não está um pouco inclinada demais ao lado permissivo.
A história toda foi muito bem organizada, então li com facilidade. Obrigado!
Ver artigos relacionados
https://pt.news.hada.io/topic?id=3620 - AWS anuncia um fork open source do Elasticsearch e do Kibana
https://pt.news.hada.io/topic?id=3606 - Elastic altera a licença para impedir o uso pela AWS