Bear agora mudou para uma licença de código-fonte aberto
(herman.bearblog.dev)- O projeto Bear mudou da licença MIT para a Elastic License
- A antiga licença MIT permitia uso livre do código e forks, mas a nova licença restringe a oferta como serviço hospedado
- Vários outros projetos de código aberto também vêm adotando mudanças de licença semelhantes para evitar concorrência gratuita
- Na era da inteligência artificial, copiar código e transformá-lo em serviço ficou muito fácil
- A abertura do código é importante, mas a essência do Bear está na comunidade de usuários e na disposição de mantê-lo continuamente
Contexto da mudança de licença de código-fonte aberto do Bear
- No início, o projeto Bear publicou seu código sob a licença MIT, com o objetivo de permitir aprendizado e auditabilidade, além de oferecer aos usuários confiança em relação à privacidade e segurança
- Porém, com o tempo, surgiram casos de serviços concorrentes baseados no código do projeto Bear
- O software foi desenvolvido com carinho, mas houve um sentimento de perda e insegurança econômica ao ver o código ser facilmente copiado e retornar como concorrência
- Embora houvesse crença no valor do código aberto, a situação acabou trazendo dificuldades reais
Decisão de mudar a licença
- Após um incidente recente, foi decidida a mudança da licença MIT para a Elastic License (um modelo de copyleft adotado no Elastic Search)
- A Elastic License é semelhante à MIT, mas proíbe oferecer o software como serviço hospedado ou gerenciado
- Os termos específicos da licença podem ser consultados no link do GitHub
Tendências no ecossistema de código aberto
- A pesquisa mostrou que muitos projetos de código aberto vêm restringindo licenças nos últimos anos para impedir a “concorrência parasitária”
- Exemplos: Plausible, Fathom, Grafana, Snowplow, ScyllaDB, Sentry e vários outros projetos tomaram decisões semelhantes
A era da inteligência artificial e o aumento da concorrência
- Com o surgimento de ferramentas de codificação com IA, tornou-se possível fazer cópias rápidas e transformá-las em serviço, como em “faça um fork deste repositório, mude o nome e implante no EC2”
- Essa mudança de ambiente passou a impor um peso e um risco ainda maiores aos autores originais
O valor especial do Bear
- O verdadeiro valor da plataforma Bear não está simplesmente no código-fonte em si, mas na comunidade que a utiliza e no senso de responsabilidade de longo prazo do operador
- Mesmo que surjam algumas restrições no nível do código daqui para frente, foi expressa a intenção de manter e administrar a plataforma com dedicação
3 comentários
Parece que a GPLv3 e a AGPL não estão sendo usadas conforme a intenção original de seus autores.
Como a maioria acaba permitindo licenciamento duplo, vi vezes demais elas sendo usadas no fim como um mecanismo para forçar o uso comercial.
Nesse sentido, acho que Apache e MIT são algumas das poucas licenças de código aberto que ainda funcionam conforme a intenção inicial.
(Mas não acho que exista uma licença de código aberto completamente perfeita.)
Comentários do Hacker News
Pelo que entendi, o pessoal do campo de "Open Source" tem a posição de que, se a Amazon não puder oferecer isso como serviço na AWS, então não é open source de verdade, e ficam bastante incomodados quando alguém diz o contrário.
Eu queria que mais gente reconhecesse um pouco mais esse fenômeno de "concorrência parasitária" de que o autor fala. O que o Herman está fazendo beneficia todo mundo, então seria bom existir um termo novo, mais acolhedor do que "source-available" e que representasse melhor um projeto de comunidade.
Vou acrescentar porque um comentário abaixo resumiu bem o que penso:
A estrutura natural de concentração do mercado não ajuda a missão do software livre e de código aberto (FOSS). Se não impedirmos que grandes empresas lucrem dessa forma, isso acaba prejudicando seriamente a missão do open source. E, nesse processo, os usuários caem numa armadilha que combina software proprietário de grandes empresas com FOSS
A postura original do campo open source era usar licenças como GPL → GPLv3 → AGPL, apoiando formas de bloquear claramente esse tipo de problema
O fato de licenças totalmente permissivas como MIT/BSD/Apache terem se tornado tão difundidas parece um movimento deliberado, alinhado a interesses corporativos, para enfraquecer a ideologia do software livre
A maioria das pessoas também não tem tanta objeção a software que não é open source
O problema é quando projetos como Terraform ganham popularidade e crescem por serem open source, mas depois o mantenedor muda para uma licença fechada, removendo a base original desse sucesso
E quando os contribuidores assinaram um CLA (Contributor License Agreement), permitindo que até o código deles seja relicenciado livremente para uma licença fechada, isso é duas vezes mais decepcionante
Se você não se importa com open source, é só não usar; até aqui, open source sempre teve um significado claro e consistente
Cada um pode criar software livremente e escolher o que usar de acordo com os valores em que acredita, então não há muito problema nisso
Qualquer um pode usar a licença que quiser, mas vale pensar por que a maioria dos desenvolvedores open source escolhe licenças permissivas como MIT
Na prática, já existe muito bom software open source no mercado, então há bastante opção; se você colocar restrições na licença, as pessoas simplesmente escolhem outra alternativa
Por isso, projetos sob licenças do tipo GPL tendem a ter mais dificuldade para alcançar uso amplo. Claro, há exceções como Linux e WordPress, que tiveram enorme sucesso, mas isso não é exatamente o normal
Já é difícil monetizar mesmo com licenças permissivas como MIT, mas se você nem tiver usuários, fica mais difícil ainda
Dá para discutir se isso é bom ou ruim, mas, na prática, todo mundo parece estar agindo de forma racional. No fundo, software não é tão escasso assim
Não foi exatamente para casos assim que a AGPL foi criada?
A AGPL é uma licença open source reconhecida pela OSI que impõe restrições quando o software é oferecido como serviço de rede
Fico curioso se o mantenedor já olhou o Fair Source fair.io
Acho o Fair Source superior a "source-available", também por oferecer um caminho para se tornar open source completo sob o DOSP (opensource.org/dosp); isso beneficia tanto usuários gratuitos quanto pagos, e é um modelo especialmente ideal para uma plataforma de blog como o Bear
A Fair Source License do FCL (fcl.dev) também segue uma linha parecida com a da licença do Bear Blog e combina bem com o manifesto do Bear (herman.bearblog.dev/manifesto/)
Mesmo que a Bear PTY LTD deixe de existir, seria possível estruturar algo em que o próprio Bear continue existindo (definível via DOSP)
Eu mesmo participei da elaboração do Fair Source
Ainda assim, o termo "fair source" soa bem
Posso entender que software que se torna open source com o tempo, como sob Apache ou MIT, se enquadra como fair source, ou existem critérios mais complexos?
Acho que a pessoa foi ingênua na medida certa. Se você escolhe a licença MIT, qualquer um fica livre para usar seu código como quiser. Depois, quando quer ganhar dinheiro, muda para uma licença exótica para tentar resolver
No fim, as opções são MIT/BSD, GPL, LGPL e AGPL; qualquer outra licença só cria problemas inúteis de compatibilidade
Também concordo com essa visão. Quando você realmente quer liberar o código "sem condições", escolhe MIT
Neste caso, parece claro que a escolha não foi exatamente por isso, mas talvez por uma tentativa meio ambígua de parecer ao mesmo tempo "bonzinho" e "empresário"
Acho a MPL (Mozilla Public License) uma licença bem útil e subestimada
Ela é claramente menos contagiosa que a família GPL e mais restritiva que MIT/BSD (mudanças precisam ter o código-fonte divulgado na distribuição)
MIT e BSD não garantem direitos de patente, o que é um bom motivo para preferir a Apache License
O Guy (o criador) parece simplesmente ter feito o próprio projeto e valorizado o fato de publicar o código-fonte
Não acho que houvesse algum outro objetivo estratégico específico
Usuários que acreditam que um projeto open source ficará open source para sempre também são ingênuos
Os autores têm o direito de mudar a licença; se surpreender com isso, ou acreditar que é fácil transformar open source em negócio, também é, no fim das contas, uma postura ingênua
Se a intenção é bloquear por completo o uso concorrente, isso costuma ser feito dessa forma. Também é uma escolha correta não usar mais o termo open source
Mas, na maioria das situações, acho que a AGPL é uma alternativa melhor. Com AGPL, grandes empresas acabam não podendo usar o código por causa de políticas internas, o que funciona como barreira à entrada de grandes operadores
Isso trai o significado original do open source
"Abri sob MIT, e agora alguém está usando meu código num negócio e ganhando dinheiro com isso. É surpreendente que eu não tenha previsto esse resultado"
Por que isso continua acontecendo? Fico me perguntando por que tantos desenvolvedores não enxergam esse resultado tão óbvio
A MIT era um padrão de entrada fácil no GitHub, algo que você escolhia no dropdown ao criar um projeto novo
Quando o projeto ainda é novo e você não sabe como ele vai evoluir, é difícil imaginar que ele vai crescer a ponto de você precisar se preocupar com licenciamento depois
A licença MIT originalmente permite que o projeto seja relicenciado a qualquer momento
O mantenedor do Bear escolheu uma licença permissiva no começo e, quando a situação mudou, trocou por uma licença mais rígida
Para mim, isso é uma decisão totalmente razoável
Acho que isso aconteceu porque, 15~20 anos atrás, o campo BSD venceu a guerra cultural do open source
Fico curioso para saber como o ecossistema atual seria diferente se o lado das licenças GNU tivesse vencido
Eu apoiava o Bear porque era open source, mas se não é mais, não tenho motivo para continuar apoiando e cancelei minha assinatura
Se isso voltar para AGPL, seria realmente algo a desejar
O Bear tem liberdade para usar a licença que quiser, e eu posso decidir se quero usar isso ou não
O objetivo de uma licença open source é, no fim, compartilhar, não obter ganho financeiro
Também entendo perfeitamente apoiar apenas projetos open source
Quando chega o momento de gerar receita, uma licença open source pode deixar de ser apropriada
Alguns desenvolvedores entendem errado e acham que open source vai proteger sua renda, e alguns usuários se iludem achando que o projeto permanecerá open source para sempre
Modelos como source-available ou shipped-with-source também são um tipo de licença proprietária, não precisam necessariamente ser open source
“Os usuários não podem hospedar ou oferecer como serviço gerenciado aquilo que forneça a funcionalidade principal do software”
Não sou advogado, mas fico na dúvida se essa restrição também impede instalar e operar o Bear por conta própria para uso interno na empresa ou uso pessoal
Na verdade, se isso não for permitido, eu não entendo por que usaram a licença MIT antes
Texto original da licença do Bear Blog
Mas não pode oferecê-lo como serviço para outras pessoas ou empresas
Referência: FAQ da Elastic License
Entendo a frustração, mas a nova licença está meio ambígua
Quando diz "não pode fornecer funcionalidade por hospedagem/serviço gerenciado", isso também restringe um provedor comum de VPS onde se instala via gerenciador de pacotes?
E se houver um script de configuração tipo 1-click install, como isso se encaixa? Se não houver orientação durante o serviço, tudo bem? Parece uma espécie de "teatro" em que um terceiro pode fornecer o script de instalação e, se ninguém mencionar isso na etapa do serviço, então estaria tudo liberado
Ou seja, você não pode oferecer o software a outras pessoas como serviço (gratuito ou pago), mas pode usá-lo só para você mesmo
O ponto central é que fornecer contas em si deve ser visto como proibido
Oferecer hospedagem turnkey também é proibido, mas o problema não é quem fornece a hospedagem em si, e sim quem cria e vende contas de usuário naquela instância hospedada
Essa redação existe para impedir que grandes empresas como a Amazon ofereçam uma instância de banco de dados para terceiros e simplesmente emitam contas ali em cima
Em contrapartida, simplesmente instalar em uma VM com gerenciador de pacotes é aceitável
Ainda assim, esse tipo de licença é extremamente confuso e pouco claro
Se a ideia fosse mantê-lo open source, você naturalmente gostaria que muita gente usasse; mas se não quer que terceiros hospedem, então nem haveria necessidade de compartilhar o código — bastaria deixar como "All rights reserved"
Entendo a motivação e a intenção de publicar o código-fonte, mas, se a preocupação era a concorrência, fico curioso por que não consideraram AGPL em vez de MIT
A AGPL ainda não permitiria que outra pessoa revendesse comercialmente o código sem modificá-lo?
A AGPL apenas obriga a divulgar o código-fonte das modificações
Aqui, o problema parece ser justamente casos em que alguém oferece o Bearblog comercialmente quase sem mudanças, ou apenas com um nome um pouco diferente
Provavelmente, no começo não achavam que concorrência seria um problema, e só mudaram a licença quando isso foi se tornando um problema
Pessoalmente, acho esse modelo (código-fonte disponível + restrição de hospedagem etc.) o melhor modelo de licença
Consigo inspecionar e alterar o código como quiser, enquanto o projeto e o mantenedor preservam sua própria base sem um peso excessivo de concorrência
Se começar assim desde o início, evita-se a confusão de uma mudança repentina mais tarde e também que um fork supere o original
Não acho que o Bear fosse exatamente um projeto do tipo que causaria tanta repercussão assim
Eu também uso o mataroa.blog de vez em quando e espero que o mantenedor do Bear continue encontrando satisfação no próprio projeto
Na verdade, o interesse e as contribuições dos usuários são praticamente os únicos recursos de um projeto open source.
Se ele ainda não estiver completamente estabelecido, quando qualquer um — especialmente uma grande empresa — pode fazer um fork e monopolizar a atenção, no fim você só trabalhou para beneficiar os outros.
Desde o início, essas licenças existiam para a liberdade dos usuários, não para os desenvolvedores.
Você sabia que o
winget, o gerenciador de pacotes CLI do Windows, surgiu quando a Microsoft simplesmente fez um fork do projeto de outra pessoa e lançou com outro nome?Também existe um texto escrito pelo autor do projeto original, o appget.
The Day AppGet Died.
Se você não quer apenas trabalhar para beneficiar os outros — especialmente grandes empresas ou pessoas com grande capacidade de viralização — e valoriza o seu próprio tempo, vale a pena reconsiderar a adoção de uma licença open source.
Mesmo quando ambos são trabalho voluntário, há uma grande diferença entre ter sua contribuição respeitada e ser completamente ignorado.
Dê uma olhada em alternativas como as mencionadas nos comentários do Hacker News.