- Liquibase fez a transição da licença open source anterior para a Functional Source License (FSL)
- Embora a FSL não seja uma licença open source oficial segundo os critérios da Open Source Initiative (OSI), surgiu o questionamento de que o projeto ainda é apresentado como open source no README e em outros locais
- Na comunidade, há opiniões divergentes: algumas afirmam que a FSL viola os critérios oficiais de open source, enquanto outras defendem que a FSL atende aos requisitos de open source
- Dentro do projeto, a correção das referências a open source no README está em andamento
- Há críticas de que a FSL, por incluir cláusulas que restringem o uso competitivo, entra em conflito com partes da OSI Open Source Definition (definição de open source)
Visão geral da questão
- A licença do projeto Liquibase foi alterada recentemente para a Functional Source License (FSL)
- Porém, em documentos oficiais como o README.md, o Liquibase ainda é apresentado como um projeto open source, o que vem gerando confusão e divergências na comunidade
Relato e controvérsia
- O autor da issue aponta como problema o fato de que o Liquibase continua afirmando ser open source mesmo após a mudança para a FSL
- A própria Liquibase já havia mencionado que a FSL não é uma licença open source
- Foi solicitada a correção do README e de outros documentos para que o termo open source deixe de ser usado na documentação do projeto
Opiniões da comunidade e de pessoas relacionadas
- Alguns participantes argumentam que a FSL atende aos critérios de uma licença open source aprovada pela OSI e que, se passar por revisão formal e for aprovada pela OSI, não haveria problema
- Em contrapartida, outros participantes destacam que, por causa de termos como a cláusula de “uso permitido”, a FSL viola vários itens da definição de open source da OSI (seções 1, 3, 5 e 6)
- Também há quem enfatize a distinção entre “Fair Source” e “open source de verdade”, defendendo que a FSL deve ser classificada como Fair Source
Processo de resolução da issue e correções na documentação
- Um colaborador do projeto respondeu ao questionamento ajustando o README.md e removendo gradualmente as menções a open source
- Ainda assim, permanecem no repositório algumas ocorrências de ‘open source’ e ‘oss’, de modo que novas revisões e limpezas devem acontecer
Definição de open source e o problema da FSL (Functional Source License)
- Nomes importantes do movimento open source, como Richard Fontana, deixam claro que a FSL viola a definição de open source da OSI ao incluir cláusulas como a proibição de uso competitivo
- A definição de open source contém regras como “não discriminar áreas de atuação, indivíduos ou organizações”, e proibir usos competitivos entra em conflito com isso
- A FSL será convertida em licença MIT ou Apache License após 2 anos, tornando-se então totalmente open source, mas até lá continuam existindo restrições
Conclusão e situação atual
- A issue acabou impulsionando a discussão sobre transparência na forma como o Liquibase se apresenta como open source e sobre a própria essência do conceito de open source
- As correções em documentos oficiais como o README já começaram, e a distinção entre Fair Source e open source passou a ser debatida com base em um caso real
- Independentemente de aprovação pela OSI, as condições reais da licença têm peso significativo dentro da comunidade internacional de open source
1 comentários
Comentários do Hacker News
Já comecei a procurar alternativas caso não seja mais possível usar a versão 4.x
Entendo a mudança de uma licença OSS para um modelo pago quando alguém quer lucrar com um software útil
Mas mudar a licença de um projeto open source me parece uma espécie de tática de isca e troca
Esse tipo de decisão destrói a confiança imediatamente e também afasta uma base de usuários que talvez não renda agora, mas tenha potencial no longo prazo
Eu esperava que já tivessem aprendido lições importantes com os casos da Elastic e do TerraForm
Também sinto menos confiança no Flyway, já que ele pode seguir um caminho parecido a qualquer momento
Se não surgir um fork, estou até considerando criar do zero uma biblioteca de migration que atenda ao nosso uso em produção
Usávamos o Liquibase só pela conveniência, não porque ele fosse insubstituível
Acho que EventstoreDB (agora KurrentDB) e NATS também são vistos com desconfiança em termos de confiabilidade de serviço
O EventstoreDB já mudou de licença, e a NATS só recuou do plano por causa da reação dos usuários
Agora parece que esse tipo de movimento virou uma estratégia de negócios
A maior vantagem do open source é poder fazer fork de versões anteriores e usá-las quando quiser
Na essência, vejo essa mudança como algo não muito diferente de aumentar o preço do produto
Embora seja específico para Postgres, também existe o projeto pgroll, que leva a automação um passo adiante
Além do Flyway (licença Apache), ainda há licenças open source como Atlas (Apache) e Sqitch (MIT)
Fico me perguntando se a mudança de licença da Elastic realmente foi um fracasso do ponto de vista deles
As ações caíram por um tempo, mas a empresa de fato continua firme
Todos os desenvolvedores de busca e RAG que conheço ainda usam apenas o Elasticsearch fornecido pela Elastic NV (nada de fork open source nem alternativas)
Especialmente olhando para o principal grupo de clientes que mais importa para a Elastic, os pagantes, parece até que o efeito foi o oposto de destruir confiança
A receita real também dobrou em relação a 2020
Ainda há quem diga que isso continua sendo open source, mas a própria Liquibase afirma que a FSL não é uma licença open source
Veja o anúncio no blog oficial da Liquibase
É uma pena ver tantos projetos recentes se venderem como open source quando, na prática, só disponibilizam o código-fonte
Se a Liquibase não queria um copyleft forte (como GNU AGPL) e escolheu Apache, então já deveria esperar que outras empresas criassem derivados proprietários fechados
No fim, foi uma escolha da própria Liquibase, então acho que a responsabilidade também é dela
Parece ser uma estrutura em que a licença muda automaticamente para Apache depois de um período
Não sei se isso é melhor ou não
Na prática, empresas conseguem atingir seus objetivos até mesmo com licenças como AGPL
A Redis também fez essa transição e a reação da comunidade foi positiva
Não acho que os usuários reclamariam se a Liquibase adotasse um modelo de licença dupla com AGPL
Acho que isso deveria ser chamado de "open source com atraso de 2 anos" ou "open source depois de 2 anos"
Na prática, me parece mais "open source quando já não serve mais"
Nesse formato, a essência parece ser passar uma imagem de respeito à liberdade sem realmente respeitá-la
É raro uma versão antiga se tornar inútil tão rápido assim
Não vejo isso como falta de respeito à minha liberdade
O objetivo é impor algumas restrições a empresas (não a pessoas)
No mundo enterprise, acho que o ponto central do open source não é tanto a "liberdade", mas sim confiança e transparência
Só o fato de o código estar disponível já permite aproveitar as vantagens do FOSS sem problemas legais ou de monetização
Na internet, existe uma tendência de confiar cegamente demais no modelo open source
Também acho a política híbrida de 2 anos perfeitamente razoável; se você não quiser a nova licença, use a versão antiga
Open source atrasado, com um duplo sentido parecido com o "late" em inglês
#source-washing
Se você não conhece bem a nova licença, veja esta explicação detalhada sobre a FSL
Mais contexto sobre a FSL: ela foi criada pela Sentry, e você pode ver no blog da Sentry por que essa licença foi considerada necessária e que problema ela tentava resolver
Pessoalmente, a única licença de código fechado que eu consideraria aceitável é a BuSL, "Business Source License"
Depois de 4 anos, ela obrigatoriamente vira open source, e até lá o código fica disponível
Isso também evita uma proliferação desnecessária de licenças
Vale ver também a wiki da Business Source License
Fico em dúvida se 2 anos não é um prazo curto demais
Do ponto de vista de empresas grandes, software de 5 anos ainda é perfeitamente utilizável, e para mim versões como Redis de 2012 ou Postgres de 2020 continuam ótimas
Já organizei o histórico desses casos e uma lista de empresas
Deixei tudo neste post de blog relacionado; se você souber de mais exemplos, compartilhe
Os recursos pro viviam quebrando a sintaxe da versão comunitária, então eu não sentia transparência nenhuma
Claro que o trabalho merece compensação justa, mas esse negócio de "éramos open source e discretamente deixamos de ser" está ficando comum demais
Essas mudanças sempre parecem acontecer em silêncio, como se esperassem que ninguém percebesse
Fico curioso sobre qual é exatamente o dano real ou o principal problema
Na verdade, gosto da distinção entre áreas competitivas e não competitivas
Os comentários aqui estão com um clima meio estranho
A maioria parece olhar só para o "base" do nome e recomendar serviços sem relação nenhuma, ou então afirmar que basta disponibilizar o código para ser open source
Eu nem sabia que a Liquibase tinha mudado de licença
Na verdade, quase todo framework web tem alternativas, e também há opções independentes de framework, como Alembic e Flyway
A esta altura, isso parece meio estranho
Esse problema pode causar impactos até em projetos OSS como o Keycloak
Pelas políticas da CNCF, licenças não open source não podem ser usadas, então o Keycloak não pode usar Liquibase
Como Debian, Fedora e outras distribuições também exigem licenças OSS, fico me perguntando se projetos que dependem de Liquibase poderão ser incluídos nessas distribuições
Link com detalhes da issue do Keycloak
Mas ainda pode ser incluída em repositórios individuais ou personalizados, como o rpm fusion non-free