HashiCorp adota a Business Source License
(hashicorp.com)- A HashiCorp vai mudar a licença do código-fonte de futuros lançamentos de produtos de MPL 2.0 para Business Source License v1.1, buscando continuar investindo na comunidade e nos produtos
- A empresa avalia que o modelo open source existente criou um grande ecossistema, mas o problema de alguns fornecedores explorarem comercialmente o trabalho da comunidade sem contribuir de forma efetiva cresceu
- A BSL 1.1 é uma licença de código-fonte disponível que permite cópia, modificação, redistribuição, uso não comercial e uso comercial sob condições; APIs, SDKs e a maioria das bibliotecas permanecem sob MPL 2.0
- Usuários finais, parceiros, clientes enterprise e clientes de produtos gerenciados em nuvem em geral poderão continuar com o uso atual, mas a oferta de produtos que concorram com a HashiCorp será uma exceção
- Fornecedores que oferecem serviços concorrentes sobre produtos comunitários da HashiCorp terão mais dificuldade para incorporar futuros lançamentos, correções de bugs e patches de segurança
Escopo da mudança de licença
- A licença do código-fonte de todos os futuros lançamentos de produtos da HashiCorp mudará de Mozilla Public License v2.0 (MPL 2.0) para Business Source License (BSL ou BUSL) v1.1
- As APIs, SDKs e quase todas as outras bibliotecas da HashiCorp continuarão sob MPL 2.0
- O código-fonte dos produtos e as atualizações continuarão públicos nos repositórios GitHub e nos canais de distribuição da HashiCorp
- A HashiCorp afirma que busca uma forma de compartilhar amplamente o código-fonte e permitir uso gratuito, minimizando ao mesmo tempo o impacto sobre comunidade, parceiros e clientes
Modelo open source e ônus da comercialização
- Quando foi fundada, a HashiCorp tinha três motivos para lançar seus produtos como open source
- Profissionais da área deveriam poder baixar e revisar livremente o código-fonte e resolver problemas por conta própria
- Era preciso criar um ecossistema e uma comunidade ao redor dos produtos para viabilizar integrações amplas
- Transparência é importante para os usuários
- Por mais de 10 anos, a empresa ofereceu novos produtos e recursos sob licenças open source gratuitas, formando uma grande comunidade de usuários, contribuidores, parceiros e clientes
- A empresa investe dezenas de milhões de dólares por ano em P&D de produtos open source, e clientes comerciais que trabalham com a HashiCorp em infraestrutura de missão crítica tornam esse modelo possível
- A HashiCorp colaborou de perto com provedores de nuvem para oferecer integrações a usuários e clientes em comum, além de ter trabalhado com centenas de parceiros de tecnologia
Como a BSL 1.1 será aplicada
- A BSL 1.1 é uma licença de código-fonte disponível que permite cópia, modificação, redistribuição, uso não comercial e uso comercial sob certas condições
- Nos últimos anos, Couchbase, Cockroach Labs, Sentry e MariaDB também seguiram caminho semelhante, e a MariaDB desenvolveu essa licença em 2013
- Confluent, MongoDB, Elastic e Redis Labs também são citadas como casos de adoção de licenças alternativas com restrições ao uso comercial
- A aplicação da BSL pela HashiCorp inclui permissões adicionais de uso para viabilizar um uso amplo e permissivo do código-fonte
- Durante o desenvolvimento da licença, a empresa consultou especialistas em licenças OSS e partes interessadas do setor para alinhá-la às práticas da indústria
Impacto para usuários, parceiros e clientes
- Usuários finais poderão continuar copiando, modificando e redistribuindo o código para todos os usos não comerciais e comerciais, exceto no caso de oferecer produtos que concorram com a HashiCorp
- Parceiros poderão continuar construindo integrações para clientes em comum
- A empresa diz que pretende continuar trabalhando de perto com provedores de serviços em nuvem para manter suporte profundo às tecnologias mútuas
- Não haverá mudanças para clientes enterprise e de produtos HashiCorp gerenciados em nuvem
- Fornecedores que oferecem serviços concorrentes à HashiCorp com base em produtos da comunidade não poderão mais incorporar aos seus produtos futuros lançamentos, correções de bugs e patches de segurança da HashiCorp
Orientações adicionais
- A HashiCorp afirma que seus compromissos com comunidade, parceiros e clientes não mudaram
- Para dúvidas adicionais, disponibiliza perguntas frequentes
1 comentários
Opiniões no Hacker News
A única conclusão a tirar daqui é que a HashiCorp não é mais uma empresa open source
A existência de “fornecedores que se aproveitam do modelo OSS puro e do trabalho da comunidade para objetivos comerciais sem devolver contribuições reais” é 100% compatível com o espírito do open source
Se isso é um problema, basta adotar uma licença open source como a AGPL, que força os desenvolvedores a publicar o código
Isto é apenas uma forma de a HashiCorp permitir que só ela comercialize antigos projetos open source, e isso em si é ok, mas então deveria simplesmente virar closed source e admitir, em vez de tentar ficar com os dois lados
O post do blog não é honesto. Tentamos várias vezes contribuir correções upstream para provedores do Terraform, mas a HashiCorp nunca aceitou, então tivemos de manter forks
A HashiCorp perdeu seu DNA OSS há muito tempo, e esta medida é o último prego no caixão
Felizmente, com o tempo, eles transferiram grande parte da responsabilidade pela maioria dos provedores do Terraform para parceiros, então espero que o ecossistema de provedores continue ativo e aberto
Acredito profundamente em open source. Meu último projeto na Microsoft também foi tornar o .NET open source e multiplataforma, nosso CTO participou da criação do TypeScript, e a Pulumi também é um projeto open source Apache. A HashiCorp parece não ser mais assim
Em linhas gerais, os tempos mudaram, e vejo código aberto não como “se você não entregar tudo de graça, não é de verdade”, mas como uma relação de benefício mútuo entre quem cria e quem usa
Os usuários devem poder entender e ampliar, pelo código-fonte, aquilo que está em execução, e os gestores, mantenedores e donos do projeto devem poder continuar fazendo esse trabalho
Isso não é um ponto de equilíbrio a ser alcançado, mas um equilíbrio a ser mantido sob tensão
Conferi a Wikipedia e ela diz que a HashiCorp definiu os termos do IPO em 29 de novembro de 2021
Cada vez mais acho que essa hipótese está certa. Dados anedóticos, sejam contraexemplos ou casos de apoio, são bem-vindos
O fato de não ser open source não significa que seja preciso impedir as pessoas de ver o código-fonte, nem que seja preciso remover todas as características de uma licença aprovada pela OSI
Claro, teria sido melhor se fosse software livre, mas isso é o mesmo que dizer que seria melhor se todo software fosse software livre
O problema surge quando uma licença que não pode receber aprovação da OSI se passa por open source. A HashiCorp não continua afirmando que é open source e agora chama isso de “source-available”
Bastante decepcionante. Pessoalmente, não usei muito além do Vault; experimentei o Terraform, mas não gostei nem construí nada em cima dele, e isso é exatamente o oposto do que eu mais apreciava nos produtos da HashiCorp
Eu até contribuí para gerenciamento de certificados, uma das partes do código que mais uso no Vault, e agora preciso reavaliar se poderei recomendar esse serviço a clientes daqui para frente e se voltarei a contribuir
Com o capital de VC secando, parece que o pior futuro das licenças que não são do tipo GPL está se revelando
É triste para quem aprendeu deliberadamente OSS e sua operação com o sonho de, um dia, usar esse conhecimento para criar serviços, ser seu próprio chefe e continuar retribuindo ao OSS que os trouxe até aqui
Tenho bastante experiência implementando e operando o Vault Enterprise para gerenciamento de segredos de aplicações em toda a infraestrutura de empresas
Ao longo de alguns anos adotando o Vault e negociando contratos, vi engenheiros de vendas fazerem afirmações imprecisas ou enganosas sobre recursos “necessários” para casos de uso, além de prometerem recursos de longo prazo que não poderiam cumprir
Eles também recomendavam formas de integração que tornavam a migração para fora do Vault praticamente impossível ou arriscada, e continuavam retirando recursos que achávamos que seriam gratuitos para sempre. O maior exemplo era o login Okta/MFA; é difícil passar por uma auditoria de compliance séria sem isso, e parece que a HashiCorp percebeu que equipes muito dependentes do Vault acabariam tendo de pagar por esse recurso
No geral, parecia um forte vendor lock-in, e a cada ano passávamos a pagar mais pelo mesmo conjunto de recursos, ou por menos recursos. A política de preços, que nem os engenheiros conseguiam explicar, também continuava mudando arbitrariamente
Considero o Vault em si um software excelente, mas, como perdi a confiança na HashiCorp, pessoalmente não acho que dependeria dele para algo importante
Se for literalmente isso, nada mudou, e não é decepcionante, é uma escolha inteligente. É uma forma de se proteger dos provedores de nuvem que abusaram repetidamente da boa vontade da comunidade open source
Não se deve confiar em projetos OSS que exigem cessão de copyright dos contribuidores, e eles nem deveriam aceitar contribuições de boa-fé para começo de conversa
Caso contrário, mesmo que hoje seja Apache 2.0, amanhã pode virar comercial sem pedir permissão a ninguém. Porque o mantenedor possui 100% do código
É geralmente raro que projetos OSS apoiados por entidades comerciais recebam uma quantidade significativa de contribuições externas, mas ainda assim esse é um detalhe importante a considerar em OSS
Ao dizer algo como “o modelo de open source comercial precisa evoluir para que o ecossistema continue oferecendo software aberto e disponível livremente”, insinuar que licenças não open source como a BUSL fazem parte da evolução do modelo open source é uma confusão grave ou uma tentativa deliberada de induzir ao erro.
Algum ator de porte significativo já usou produtos da HashiCorp para competir de fato com a HashiCorp?
[1]: https://www.pulumi.com/docs/concepts/vs/terraform/#:~:text=U...
A Pulumi consegue converter qualquer Terraform Provider para ser usado no Pulumi, permitindo gerenciar com programas Pulumi toda a infraestrutura suportada pelo ecossistema de Terraform Providers.
Empresas tomam esse tipo de medida porque companhias como a Amazon usam licenças livres e open source para criar versões auto-hospedadas de projetos open source.
ctrl+fpara procurar “open source”, dá para ver a partir de onde eles param de usar essa expressão.A HashiCorp descreve essa mudança não como uma forma de manter o “open source”, mas de manter produtos abertos e disponíveis livremente.
Acho que, nesse ponto, eles são mais honestos do que outros, por não dizerem que continuam sendo “open source” depois de mudar a licença. Claramente sabem a reação negativa que receberiam se chamassem assim.
É interessante que @mitchellh não esteja participando da conversa. No passado, ele interagia diretamente no HN, e imagino que teria tido influência final nessa decisão.
No geral, parece uma jogada de perdedor. Basta ver o que aconteceu com o Elasticsearch. Para mim e para a maioria das pessoas, o ES não existe mais. Migrei de bom grado para o OpenSearch e não olho para trás para o pobre kimchi. Pelas próprias ações, o Elasticsearch deixou de ser relevante.
Será que esse movimento da HashiCorp vai desencadear um esforço semelhante para fazer fork da última versão sob licença open source do Terraform e de outras ferramentas? Quando o criador fica mesquinho e inseguro e passa a agir de forma hostil contra a comunidade open source que ajudou a construí-lo, que outra opção existe?
Fiquei extremamente decepcionado com a liderança da HashiCorp. MitchellH e Armon Dadgar deveriam ter tratado a comunidade melhor do que isso.
Fiz entrevista na HashiCorp em 2016 e acabei recusando a vaga; em alguns momentos me arrependi um pouco dessa decisão. Agora que a verdadeira face apareceu, tenho certeza de que foi a escolha certa.
Há aquele ditado sobre confiança. Confiança leva anos para ser construída, segundos para ser quebrada e uma eternidade para ser recuperada.
É surpreendente que pessoas que eu considerava inteligentes possam ser tão tolas assim.
Não há necessidade de insultar alguém que realizou muita coisa.
O software deles era open source, e as coisas boas serão forkadas, então não há necessidade de odiar a HashiCorp.
Também não concordo com a frase “confiança leva anos para ser construída, segundos para ser quebrada e uma eternidade para ser recuperada”. É agressiva demais.
A HashiCorp criou coisas excelentes e tentou construir um negócio baseado em open source. Não quebrou contratos nem fez algo imoral; esta é uma escolha deles.
Parece o desfecho inevitável para toda empresa open source depois que o dinheiro fácil acaba. O que incomoda é que a redação é bastante ambígua.
A HashiCorp define produtos concorrentes como “produtos ou serviços oferecidos a usuários ou clientes fora da organização cujas funcionalidades se sobreponham substancialmente às de produtos ou serviços comerciais da HashiCorp”.
Por exemplo, digamos que não exista um serviço de estimativa de custos, você crie algo e ele fique famoso: https://github.com/infracost/infracost
O que acontece se, dois anos depois, o Terraform Cloud vier atrás e lançar algo parecido? Você precisa fechar o negócio?
Mas, em produtos maiores e essenciais ao negócio, como bancos de dados, aparecem distorções muito mais estranhas, como dificultar a auto-hospedagem ou limitar recursos indispensáveis.
É melhor do que código fechado, mas não é ideal. Há algum tempo penso que licenças provavelmente são uma saída prática, mas elas precisam ser amplamente compreendidas, justas e claras.
A expressão “produtos ou serviços oferecidos a usuários ou clientes fora da organização e com funcionalidades que se sobreponham substancialmente” é problemática. Pela redação, (1) é pouco clara e (2) o poder sobre essa ambiguidade pende para a empresa, abrindo caminho para aplicação seletiva.
Em uma situação em que se assina um documento legal, “não se preocupe, ninguém vai perseguir você” não é convincente. Considero um grande sinal de alerta quando um contrato parece brando no presente ou acumula poderes que podem ser exercidos no futuro.
Tenho curiosidade sobre como outras pessoas veem essa licença em si.
O ponto de “daqui a dois anos o Terraform Cloud vem atrás” é realmente muito bom. O escopo de uma empresa muda.
Segundo https://www.couchbase.com/blog/couchbase-adopts-bsl-license/, a BSL normalmente define uma data de mudança entre 1 e 4 anos, quando a licença BSL passa para uma licença de mudança open source, como GPL, AGPL, Apache etc.
Portanto, a pergunta mais importante é qual é a licença de mudança e quanto tempo isso leva.
Se for para MPL 2.0 depois de 1 ano, tudo bem. Mas, se for muito mais longo e restritivo, é uma mudança completa de postura, e a versão open source fica tão distante da versão mais recente que, na prática, se torna inutilizável.
Correção: é MPL 2.0 depois de 4 anos.
https://www.hashicorp.com/license-faq#What's-the-difference-...
Quando segurança está envolvida, 4 anos são, na prática, apenas “interesse histórico”.
São 4 anos, MPL 2.0.
Não sei quanto a outras empresas, mas sempre me pergunto onde o software dessas empresas estaria hoje se tivesse sido lançado desde o início sob uma licença não livre.
Isso é hostil não só às grandes empresas que querem “roubar” o código e rodá-lo como serviço, mas também aos usuários finais, indivíduos e pequenas empresas.
Se você operar e usar com sucesso software da HashiCorp e for considerado concorrente, a HashiCorp pode decidir bloquear você.
Por exemplo, https://github.com/hashicorp/vault/blob/main/go.mod#L25
Acho que, se tivesse começado com BSL desde o início, não teria sido adotado de forma tão ampla.
Página de CLA da HashiCorp de dois meses atrás: https://web.archive.org/web/20230610041432/https://www.hashi...
Ela dizia que “a HashiCorp exige que contribuidores externos assinem um Contrato de Licença de Contribuidor (CLA) para que a HashiCorp possa construir um negócio sustentável, mantendo ao mesmo tempo os projetos sob licenças livres e open source como a MPL2”.
Também dizia que “a HashiCorp se compromete a aplicar licenças de software livre e open source (FOSS) genuínas ao software não comercial. O CLA permite que a HashiCorp comercialize seus produtos com segurança, preservando todos os direitos concedidos por licenças FOSS padrão, como o direito de usar em seus próprios projetos ou negócios, redistribuir código-fonte modificado e fazer forks completos”.
É decepcionante que o texto não jurídico da página insinuasse repetidamente que assinar o CLA ajudava a manter os projetos da HashiCorp open source, embora o texto real do contrato não desse essa garantia.
Alguém deveria contestar isso agora que mudou a premissa do CLA, ou seja, a situação em que as contribuições são relicenciadas como não FOSS.
A maioria dos CLAs é bem seca, mas a HashiCorp colocou várias declarações no seu CLA, então isso pode causar problemas.
O único motivo para exigir algo assim é relicenciamento, e, se já é FOSS, o único motivo para querer relicenciar é migrar para software proprietário.
O Linux não exige CLA para contribuições. Só esses palhaços que fingem ser open source exigem.
Nossa empresa OSS foi construída sob Apache 2.0, com o Nomad no núcleo.
Oferecemos orquestração de servidores de jogos acoplando alguns serviços ao redor dele, e isso pode ser interpretado erroneamente pela HashiCorp como “oferta de produto concorrente”.
Como a licença é intencionalmente ambígua, pretendemos congelar nossa versão do Nomad na última versão MPL.
Também usamos CockroachDB, que é BSL, mas não oferecemos nenhum produto que concorra com eles.
É provável que eu continue recomendando produtos da HashiCorp, como Nomad, Consul, Terraform e Packer, a quem pedir conselho, mas essa mudança soa decepcionante.
Para quem tiver curiosidade, mantemos um SBOM simples: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...
Sou líder de engenharia do Nomad. A licença está fora do meu controle, mas há muitos usuários apreensivos, sem saber se algum dia poderão ser interpretados como concorrência.
Não posso prometer nada, mas farei tudo o que puder para dar a confiança de que o Nomad ainda é a ferramenta certa para o seu trabalho.
Pessoalmente, não vejo problema. Se o objetivo final é virar uma plataforma SaaS, eu gostaria que mais projetos de código aberto começassem desde o início com a Business Source License
Já vi repetidamente grandes empresas abusarem do espírito do código aberto para seu próprio ganho financeiro, sem devolver nada e agindo de má-fé
Usar algo que foi disponibilizado publicamente não é visto como má-fé, e essas pessoas também ficam felizes em distribuir de graça
Se não for assim, não é código aberto. Claro que nem todo software precisa ser código aberto, então tudo bem também
Quem abusa do espírito do código aberto é quem cria regras arbitrárias sobre o uso
Ainda assim, é melhor deixar isso claro desde o início