SSPL (Server Side Public License) é ruim

Por que a SSPL é ruim

• A SSPL (Server Side Public License) é uma licença terrível para todos os usuários, empresas e, de modo geral, para a comunidade
• Produtos licenciados sob SSPL não são open source, têm como objetivo matar concorrentes de nuvem e serviços gerenciados, aumentar os preços de hospedagem e matar o open source
• O objetivo da SSPL pode estar mais próximo de devolver dinheiro aos investidores do que de enfrentar grandes empresas

O que é a SSPL

• A SSPL foi introduzida em 2008 pela MongoDB, Inc. como uma licença para restringir o uso do MongoDB
• Produtos como Elasticsearch, Kibana e Graylog também agora usam a licença SSPL
• De acordo com a seção 13, se você quiser oferecer o produto diretamente aos clientes, deverá disponibilizar publicamente o "código-fonte do serviço"

Por que a SSPL é ruim para todos

• A SSPL foi apresentada como uma boa solução para impedir que algumas empresas de nuvem de má-fé lucrassem sem contribuir com a comunidade, mas na prática é uma ameaça à liberdade e uma licença para eliminar concorrentes
• Essa licença não passa de uma forma de pegar produtos que eram open source e aprisioná-los em produtos comerciais, escondidos atrás do falso espírito de "gratuito". Talvez agora devêssemos chamar esse tipo de software de software "freemium"
• MongoDB, Elasticsearch, Kibana e Graylog não são mais produtos open source, e essas empresas agora podem decidir completamente quem pode oferecer seus produtos aos clientes. Isso significa eliminar concorrentes
• Elas agora podem oferecer suas próprias soluções de hospedagem em nuvem sem concorrência e, sem abrir o código-fonte, podem matar a concorrência e a inovação com as taxas que elas mesmas definirem
• Isso significa que nós, clientes, já não temos mais o poder de escolher nosso provedor de nuvem
• De forma mecânica, os preços de hospedagem vão subir, e nossa única opção será manter uma equipe dedicada para administrar a parte de hospedagem em nossa própria infraestrutura. Exatamente aquilo de que tentamos escapar nos últimos anos com as soluções de hospedagem em nuvem

Empresas que usam a SSPL

• Os produtos da MongoDB usam a licença SSPL desde 2018, com a MongoDB, Inc. por trás disso
• Os produtos do Elasticsearch usam a licença SSPL desde 2021, com a Elastic NV por trás disso
• Os produtos do Graylog usam a licença SSPL desde 2020, com a GrayLog, Inc. por trás disso

Algumas perguntas que deveríamos fazer a nós mesmos

• Como uma empresa que não usa mais open source pode exigir que outros "devolvam algo à comunidade"?
• Como uma empresa que não divulga o código-fonte do próprio serviço em nuvem pode exigir que outros divulguem seu código-fonte?
• Como uma empresa pode declarar que o open source faz parte do seu DNA enquanto usa uma licença que não é open source?
• De mais de 3.000 funcionários, quantos compartilham seu trabalho e seu código-fonte com a comunidade? (Spoiler: muito menos)
• É uma empresa de tecnologia que quer compartilhar com a comunidade ou uma empresa de vendas que quer aumentar o retorno dos investidores?

Alegações equivocadas sobre a SSPL

• A alegação "isso não me diz respeito porque eu não sou um provedor de nuvem" ignora que todos precisam reconhecer que esse problema afeta todo mundo
• A alegação "essas empresas precisam de dinheiro para sobreviver" precisa entender que ganhar dinheiro com open source não é algo ruim, mas a SSPL não é a solução correta
• A alegação "os concorrentes ainda existem; a SSPL é negociável" na prática significa permitir que a empresa que controla o mercado defina os preços e as condições dos concorrentes
• A alegação "a SSPL combate os grandes players de nuvem e é boa para pequenos negócios" precisa reconhecer que a SSPL pode, na prática, levar pequenos concorrentes à falência e ao desaparecimento

Conselhos para projetos open source

• A SSPL pode parecer uma boa solução no início, mas a recomendação é não cometer esse erro
• Se há um problema com alguns provedores de nuvem, ele não pode ser ignorado e todos nós devemos enfrentá-lo juntos. Sair do mundo open source para lutar não é um bom caminho
• Se a lucratividade é necessária, usem licença enterprise e suporte premium: "Se você precisar de suporte, temos a melhor equipe para isso."
• Usem uma licença copyleft para permitir que empresas devolvam algo à comunidade: "Se você modificar nosso código, compartilhe com a comunidade"
• Se ainda assim você escolher a licença SSPL... você vai:
  • perder muitos contribuidores independentes e contribuidores funcionários de grandes empresas
  • trair os contribuidores que se esforçaram para melhorar o software open source
  • deixar o mundo open source e passar a desenvolver software freemium
  • associar seu produto a uma reputação muito ruim
  • perder o benefício de inúmeros players diferentes que ajudam a promover o produto no mundo todo, aumentando a necessidade de suporte premium

[aer0700]

Por ser open source, dá para escolher, mas por ser open source, às vezes também acaba sendo excluído das opções.
Deve ser uma licença que surgiu por causa de a AWS ter pego o MongoDB e criado o DynamoDB, então, para quem gosta de open source, pode parecer meio suspeita.

[coremaker]

Acho que também seria interessante comparar com a AGPL.
https://sktelecom.github.io/guide/use/obligation/agpl-3.0/

[xguru]

Como o domínio e o nome do site SSPL is BAD mostram, este é um site criado com uma intenção clara.
Há também certo exagero nas conclusões. Vale a pena ler junto com as opiniões abaixo do Hacker News.

Opiniões do Hacker News

• Há uma oposição de princípio ao SSPL, mas também existe compreensão sobre o contexto por trás dele. Também há críticas de que a descrição do artigo 13 teve uma intenção sensacionalista, mais do que uma análise objetiva.

  • MongoDB e Elastic não previram que a AWS iria reempacotar seus produtos, oferecê-los como serviço e se tornar concorrente. A licença Apache usada pelo Elasticsearch permitia isso, mas há quem diga que, do ponto de vista ético, isso deveria ter sido impedido.
  • A AWS poderia ter construído uma relação de “ganha-ganha” por meio de contratos OEM ou parcerias, mas não o fez, o que teria provocado um bloqueio desagradável como o SSPL.
  • Há reclamações de que o SSPL foi criado para agradar investidores, mas, mesmo sendo software open source, a empresa não tinha fins beneficentes; por isso, há quem diga não entender por que Elastic ou MongoDB são criticadas, enquanto a AWS não é.

• Afirma-se que o SSPL é ruim para os usuários, pois favorece monopólios e reduz a participação da comunidade, o que no fim afeta todos os usuários.

• É natural que as pessoas queiram ganhar dinheiro, e também é possível escolher não usar projetos sob SSPL. Apresenta-se a visão de que software publicado sob SSPL ainda é melhor do que não haver software algum.

• Há a opinião de que o ecossistema atual é muito diferente do de 10 anos atrás, e de que pequenas empresas querem caminhos para sobreviver à concorrência e crescer. Licenças como a BSL (Business Source License) podem não ser perfeitas, mas podem ser vistas como uma tentativa de encontrar um meio-termo saudável.

• Há quem ache estranho criticar o SSPL sem mencionar a AGPL. Também se aponta para pessoas que querem usar software livre, mas não querem contribuir.

• Há a opinião de que não se deve pender totalmente para um lado ou para o outro, e que cada caso deve ser tratado de forma diferente. O SSPL pode ser bom para algumas empresas que tentam sobreviver contra gigantes da nuvem, mas pode ser ruim para empresas que tentam explorar contribuidores.

• É proibido oferecer diretamente aos clientes os produtos MongoDB, Elasticsearch e Graylog. A palavra “diretamente” no SSPL abre espaço para disputas legais, e isso é uma das preocupações levantadas.

• A FSL (Functional Source License) é apresentada como uma boa licença alternativa, que se converte automaticamente para Apache 2.0 ou MIT após 2 anos. Ela é simples, mantém o código-fonte aberto e oferece uma forma razoável para empresas de SaaS operarem.

• Correção da informação errada de que o SSPL teria sido introduzido em 2008. Na realidade, ele foi introduzido em 2018.

• Crítica a uma visão unidimensional sobre o futuro dos direitos autorais.