As confusões de licenciamento têm sido uma faceta definidora do espaço comercial de código aberto. Alguns dos maiores fornecedores mudaram para uma licença “copyleft” mais restritiva, como fizeram a Grafana e a Element, ou se tornaram totalmente proprietárias, como a HashiCorp fez no ano passado com o Terraform.
Mas uma empresa de 8 mil milhões de dólares seguiu o caminho inverso.
A Elastic, criadora do mecanismo de pesquisa corporativa e recuperação de dados Elasticsearch e do painel de visualização Kibana, surpreendeu no mês passado quando revelou que estava se tornando open source mais uma vez – quase quatro anos depois de mudar para algumas licenças proprietárias de “fonte disponível” . A mudança vai na contramão de uma tendência que fez com que inúmeras empresas abandonassem completamente o código aberto. Alguns estão até criando um paradigma de licenciamento totalmente novo, como vemos com a “fonte justa”, que foi adotada por diversas startups.
“Estava demorando muito”
Em 2021, a Elastic mudou para licenças de código fechado após vários anos de conflito com a subsidiária de nuvem da Amazon, AWS, que estava vendendo sua própria versão gerenciada do Elasticsearch. Embora a AWS estivesse perfeitamente dentro de seu direito de fazê-lo, dada a natureza permissiva da licença Apache 2.0, a Elastic ficou ofendida com a caminho que a AWS estava comercializando sua encarnação, usando marcas como “Amazon Elasticsearch”. A Elastic acreditava que isso estava causando muita confusão, já que os clientes e usuários finais nem sempre prestam muita atenção às complexidades dos projetos de código aberto e aos serviços comerciais associados.
“As pessoas às vezes pensam que mudamos a licença porque ficamos chateados com a Amazon por pegar nosso projeto de código aberto e fornecê-lo ‘como um serviço’”, disse o cofundador e CTO da Elastic, Shay Banon, ao TechCrunch em uma entrevista esta semana. “Para ser sincero, sempre aceitei isso, porque está na licença que eles podem fazer isso. O que sempre enfrentamos foi apenas a violação da marca registrada.”
A Elastic buscou caminhos legais para fazer com que a Amazon se retirasse da marca Elasticsearch, um cenário que lembra a confusão contínua do WordPress que vimos na semana passada. E embora a Elastic mais tarde tenha resolvido sua disputa de marca registrada com a AWS, essas disputas legais consomem muitos recursos, quando tudo o que a empresa queria fazer era salvaguardar sua marca.
“Quando analisamos a via legal, sentimos que tínhamos um caso muito bom, e na verdade acabamos ganhando, mas isso não era mais relevante por causa da mudança que fizemos (no Elasticsearch licença)”, disse Banon. “Mas estava demorando muito – você pode passar quatro anos ganhando um processo legal e, a essa altura, já terá perdido o mercado devido à confusão.”
De volta ao futuro
A mudança sempre foi um ponto delicado internamente, já que a empresa foi forçada a usar uma linguagem como “gratuito e aberto” em vez de “código aberto”. Mas a mudança funcionou como a Elastic esperava, forçando a AWS a bifurcar o Elasticsearch e criar uma variante chamada OpenSearch, que a gigante da nuvem transferiu para a Linux Foundation apenas este mês.
Com o passar do tempo e o OpenSearch agora firmemente estabelecido, Banon e empresa decidiram reverter o curso e tornar o Elasticsearch open source mais uma vez.
“Sabíamos que a Amazon faria um fork do Elasticsearch, mas não é como se houvesse um grande plano mestre aqui – eu esperava, porém, que se passasse tempo suficiente com o fork, talvez pudéssemos retornar ao código aberto”, disse Banon. “E para ser honesto, é por uma razão muito egoísta – eu adoro código aberto.”
No entanto, o Elastic ainda não completou o círculo. Em vez de readoptar sua licença permissiva Apache 2.0 de outrora, a empresa optou pela AGPL, que tem restrições maiores – exige que qualquer software derivado seja lançado sob a mesma licença AGPL.
Nos últimos quatro anos, a Elastic deu aos clientes a escolha entre sua licença proprietária da Elastic ou a SSPL (licença pública do lado do servidor), que foi criada pelo MongoDB e posteriormente não conseguiu ser aprovada como “código aberto” pela Open Source Initiative (OSI). ), os administradores da definição oficial de código aberto. Embora o SSPL já ofereça alguns dos benefícios de uma licença de código aberto, como a capacidade de visualizar e modificar código, com a adição da AGPL, a Elastic volta a se chamar de código aberto — a licença é reconhecida como tal pela OSI.
“As licenças Elastic (e SSPL) já eram muito permissivas e permitiam usar o Elasticsearch gratuitamente; eles simplesmente não tinham o selo de ‘código aberto’”, disse Banon. “Sabemos muito sobre esse espaço, mas a maioria dos usuários não. Eles apenas pesquisam ‘banco de dados de vetores de código aberto’ no Google, veem uma lista e escolhem entre eles porque se preocupam com o código aberto. E é por isso que me preocupo em estar nessa lista.”
Seguindo em frente, a Elastic diz que espera trabalhar com o OSI para criar uma nova licença, ou pelo menos discutir sobre quais licenças podem ou não ser classificadas como código aberto. A licença perfeita, de acordo com Banon, é aquela que fica “em algum lugar entre a AGPL e a SSPL”, embora ele admita que a AGPL por si só pode na verdade ser suficiente na maior parte.
Mas, por enquanto, Banon diz que simplesmente poder se chamar de “código aberto” novamente é suficiente.
“Ainda é mágico dizer ‘código aberto’ – ‘pesquisa de código aberto’, ‘monitoramento de infraestrutura de código aberto’, ‘segurança de código aberto’”, disse Banon. “Ele resume muito em duas palavras – encapsula o código aberto e todos os aspectos da comunidade. Ele encapsula um conjunto de liberdades que nós, desenvolvedores, adoramos ter.”
