Nota perev. : A flexibilidade e as liberdades oferecidas pelas licenças de código aberto permitiram que os provedores modernos de grandes soluções SaaS questionassem o sucesso de pequenas empresas que estão por trás do desenvolvimento de projetos populares de código aberto. Neste artigo, dos autores do CockroachDB - um RDBMS distribuído e tolerante a falhas - a essência do problema e a maneira possível de resolvê-lo são totalmente divulgadas.
O CockroachDB foi concebido como software de código aberto. Nos anos que se passaram desde que o projeto apareceu no GitHub
(o código foi publicado pela primeira vez em fevereiro de 2014 - aprox. Transl. ) , Seguimos um caminho de desenvolvimento relativamente típico, equilibrando a filosofia do código aberto e criando um negócio viável. O código principal foi licenciado sob a Apache License 2 (APL), um serviço gerenciado foi lançado e alguns complementos para empresas foram emitidos sob uma licença corporativa.
Mas nossas idéias anteriores sobre o
modelo de negócios certo foram baseadas na norma-chave do mundo OSS: você pode construir um negócio em torno de um poderoso produto Open Source sem assumir que uma empresa de tecnologia maior venha a oferecer o mesmo produto como um serviço. Esta norma não é mais válida.
Em princípio, legalmente, nada impediu os concorrentes de oferecer um produto OSS como serviço criado por outra empresa. E agora vemos que isso está realmente acontecendo. Hoje estamos testemunhando um aumento no número de fornecedores altamente integrados que tiram vantagem de sua posição única e oferecem versões como serviço dos produtos OSS. É claro que sua alta integração aprimora muito a experiência do usuário. Mais recentemente, isso aconteceu com o fork do ElasticSearch, "emprestado" pela Amazon (Salil Deshpande no
artigo TechCrunch descreveu com habilidade o que aconteceu como "egoísta e racional").
Respondendo a essa concorrência desleal, alteramos os termos de nossa licença. Os detalhes são fornecidos abaixo no
GitHub . As breves alterações são as seguintes:
A partir de hoje, estamos apresentando uma versão exclusivamente permissiva da Business Source License (BSL). Os usuários do CockroachDB podem escalar nosso DBMS para qualquer número de nós. Eles são livres para usar o CockroachDB e integrá-lo em seus aplicativos (independentemente de entregá-los aos consumidores ou oferecê-los como um serviço). Você também pode executar o CockroachDB como um serviço para os objetivos internos da sua empresa. A única coisa que você não pode fazer é oferecer a versão comercial do CockroachDB como serviço sem comprar a licença apropriada .
Para garantir o desenvolvimento do projeto, nossa restrição tem um limite de tempo de movimentação: três anos após o lançamento, a licença se transforma em uma licença padrão do Apache 2.0. Alterando as condições da licença e introduzindo um limite de tempo, temos dois objetivos:
- Crie um banco de dados competitivo como serviço (DbaaS)
- ao longo do caminho, verifique se o produto principal permanece totalmente aberto.
Comparação de diferentes abordagens de licenciamento de código aberto
Algumas empresas já licenciaram seus produtos para uma finalidade dupla semelhante. Avaliando os métodos existentes, descobrimos que todos eles tendem a duas abordagens principais: copyleft e um modelo multinível. Infelizmente, nenhum deles correspondeu ao que gostaríamos de conseguir alterando a licença.
Modelo de copyleft
O fundador da tradição copyleft é a GNU GPL. Seu objetivo é impedir o aparecimento de garfos proprietários, em alguns casos exigindo o lançamento do código fonte. A Licença Pública Geral Affero (AGPL) e a Licença Pública do lado do servidor irmã (SSPL) se enquadram neste campo. É no SSPL que é dada atenção especial ao problema dos serviços concorrentes.
No entanto, acreditamos que todas essas licenças são redundantes e insuficientes. Eles são redundantes no sentido de que os detalhes são complexos e os requisitos de copyleft nem sempre são claros. Muitos usuários em potencial se assustam com os requisitos de divulgação de código que são potencialmente muito amplos. Eles são insuficientes no sentido de que os concorrentes estão prontos e podem revelar o suficiente de seu código para que eles não tenham nenhuma dúvida, sem trazer benefícios para os desenvolvedores da tecnologia principal. A Amazon fez isso com o
Open Distro for Elasticsearch , embora a licença copyleft não exigisse.
Precisávamos de algo mais simples e mais rígido.
Modelo em camadas
Também consideramos a possibilidade de usar um modelo de três níveis: o núcleo de código aberto, componentes corporativos e um certo nível intermediário com funções cujo código-fonte está fechado, mas elas podem ser usadas completamente gratuitamente. Este modelo é bastante popular no mundo do software; e com algumas variações, usamos até hoje.
No entanto, gera a mensagem errada para a nossa empresa. Acontece que não é rentável implementarmos novas funções em um núcleo aberto e faz sentido concentrar todos os esforços em componentes fechados. De fato, somos tentados a enganar a confiança de nossos usuários e ocultar os recursos mais interessantes para uma licença de volume. A longo prazo, essa abordagem não é um bom presságio para o ecossistema de código aberto.
Solução encontrada: BSL
Começamos a estudar licenças com tempo limitado e descobrimos que não havia necessidade de criar uma nova licença a partir do zero. A versão 1.1 da Business Source License (BSL) do MariaDB contém tudo o que você precisa e já
foi aprovada pelo fundador da OSI, Bruce Perens. O BSL é uma licença
parametrizada , por isso a usamos de forma diferente do MariaDB.
A principal diferença é a concessão de uso adicional - por exemplo, o MariaDB permite o uso do MaxScale
em até três servidores .
A concessão de uso adicional no CockroachDB permite que você use nosso produto em qualquer número de nós, desde que você não o ofereça como DbaaS comercial. Por três anos, nossa versão BSL protege o código CockroachDB existente de ser usado como DBaaS sem adquirir uma licença de volume apropriada. Após 3 anos, essa restrição é removida e o código fica aberto (no sentido incorporado na licença do Apache) e pode ser usado livremente para qualquer finalidade.
Aplicamos esta licença à versão base do CockroachDB (ou seja, ao código que se enquadrava anteriormente no Apache 2.0). Isso significa que o núcleo do CockroachDB não está mais aberto (de acordo com a
Open Source Definition da OSI), embora o código completo ainda esteja disponível e qualquer uso comercial seja permitido, exceto DBaaS. Acreditamos que esta é a melhor maneira de equilibrar as necessidades de negócios com nosso compromisso de código aberto. A nova licença permite que a grande maioria dos usuários use, distribua e modifique livremente o código CockroachDB (e após três anos, ele se abre incondicionalmente).
O que é o quê: como funciona o BSL
Estamos introduzindo uma nova licença do CockroachDB a partir da versão 19.2. Agora, o código não pode ser usado para organizar um banco de dados comercial como serviço (DBaaS) sem entrar em um contrato apropriado com o Cockroach Labs. Um limite de três anos se aplica a cada versão.
Os complementos corporativos do CockroachDB continuarão a ser liberados sob a CCL (Cockroach Community License). Trabalhar com eles exige um contrato de licença apropriado com a Cockroach Labs; esta licença não será convertida em código aberto após três anos.
Vamos explicar com um exemplo específico. O CockroachDB 19.2 (programado para outubro de 2019) será o primeiro lançamento a aderir ao novo esquema de licenciamento. Incluirá o código em BSL e CCL. Em outubro de 2022 (três anos após o lançamento), a parte do CockroachDB 19.2, que se enquadra no BSL, será convertida em APL. Os patches não alteram a data da conversão: todos os lançamentos da versão 19.2.x serão convertidos em outubro de 2022, embora nessa época apenas a versão base 19.2.0 de três anos seja executada por três anos. O CockroachDB 20.1 (programado para abril de 2020) será aberto em abril de 2023 e assim por diante.
As versões antigas não serão afetadas: o CockroachDB 19.1 continuará funcionando sob a licença Apache, e todos os patches futuros 19.1.x também serão lançados sob o APL.
Estamos comprometidos com os ideais de código aberto e nos esforçamos para criar um poderoso produto de código aberto. Embora formalmente a BSL não seja uma licença de código aberto, esse compromisso é o mais próximo do espírito do código aberto, mas ao mesmo tempo protege os nossos negócios. Além disso, três anos após o lançamento, nosso compromisso com a filosofia do software de código aberto é automaticamente reafirmado. Acreditamos que o caminho escolhido nos permitirá apoiar a empresa, salvaguardando a rica herança do Código Aberto nesta nova realidade.
PS do tradutor
Leia também em nosso blog: