Como os desenvolvedores podem evitar problemas de licenciamento de código aberto

Usar código aberto pode ir mal, e o frontend não está imune aos perigos. Desde software corrompido até alterações de licença, o software de código aberto pode “se voltar” contra os desenvolvedores.

“O frontend não é diferente de qualquer outro software. Definitivamente, é uma exposição”, disse Dotan Horovits, evangelista-chefe da Logz.io. Horovits é um defensor do código aberto como embaixador da Cloud Native Computing Foundation (CNCF), mas também fala sobre o lado negativo do código aberto.

Código aberto deu errado

Ele apontou para o incidente de 2022 com Marak Squires, que corrompeu as bibliotecas faker.js (com 2,5 milhões de downloads na época) e colors.js (com 22,4 milhões de downloads quando o incidente ocorreu).

“Foi massivo, até que o npm foi revertido e impediu que o efeito cascata se espalhasse ainda mais”, disse Horovits. “Então sim, o frontend está exposto, assim como qualquer um de nós. Não se trata do domínio. É sobre software.”

Existem outros exemplos, como a mudança da licença Terraform pela HashiCorp. Originalmente sob a Licença Pública Mozilla v2.0 (MPL 2.0) de código aberto da Mozilla, a licença do Terraform foi alterada para Business Source License (BSL) v1.1, que não é de código aberto, mas é considerada “fonte disponível”. Isso levou a comunidade Terraform a bifurcar o Terraform para criar o OpenTF e a Linux Foundation a assumi-lo como OpenTofu.

“Não foi apenas um novo licenciamento”, disse Horovits ao The New Stack. “Também estava pegando o registro do Terraform, que era um local oficial, o hub, por assim dizer, para colocar todos os módulos do Terraform e torná-lo fechado para outras utilidades.”

Elasticsearch é outro exemplo. A Elastic migrou o Elasticsearch e sua ferramenta de análise de dados, Kibana, da licença Apache 2.0 para uma licença dupla sob a Server Side Public License (SSPL) e a Elastic License. Mas foi mais do que uma mudança de licença, disse Horovits.

“Eles tinham transportadores que coletavam a telemetria localmente do aplicativo e depois a enviavam para um cluster de back-end do Elasticsearch para armazenamento, indexação e assim por diante; e por mais de uma década, tem sido de código aberto”, disse ele. “Agora eles mudaram o backend – isso todo mundo sabe. O que as pessoas talvez estejam menos cientes é que mesmo os remetentes que permaneceram para licenciar o Apache – que é uma licença de código aberto para todos os fins, aprovada pela OSI (Open Source Initiative) – eles fizeram alterações para verificar se o cluster de back-end está funcionando. que eles enviam, isso não faz parte do código aberto. Se o cluster de destino, cluster remoto, não estiver autorizado, não funcionará. Isso vai quebrar.”

Linkerd fornece outro exemplo problemático. Lá, o código-fonte permanece sob uma licença de código aberto, mas o Linkerd não está mais lançando artefatos implantáveis.

“Há algo além da licença, e é o contrato, digamos, o acordo, com a comunidade. Agora, há muito tempo, a comunidade concorda que o projeto libera artefatos que você pode pegar, implantar e usar em seu ambiente de produção, e de repente não é mais o caso”, disse ele.

“A razão pela qual isso não acontece mais não é uma decisão mútua de um comitê de governança de todas as (pessoas) que representam toda a comunidade. Foi principalmente conduzido por um único fornecedor para orientar as organizações que desejam implantar o Linkerd para uso em produção em sua oferta comercial.

Sinais de alerta que seu projeto de código aberto está virando

O licenciamento é apenas o começo da história, disse Horovits. Os desenvolvedores e organizações que usam software de código aberto precisam adotar uma abordagem mais madura para seu uso.

“As pessoas precisam olhar para o código aberto com mais maturidade, entender e fazer mais perguntas, além de qual licença. Pergunte também quem está por trás do código aberto? Trata-se de um único fornecedor ou de uma diversidade sustentável de entidades, talvez até de uma mistura de fornecedores e utilizadores finais, que garantirá uma melhor sustentabilidade e menores probabilidades de tal acontecer?” Ele disse. “Existe uma política de governança clara por trás do código aberto para definir claramente as formas pelas quais as modificações podem ser feitas – certamente licenciamento, mas ainda menores – e quem pode aderir?”

Um sinal precoce de problema pode ser o bloqueio das contribuições externas repentinas ou os mantenedores do projeto não responderem às sugestões da comunidade, disse ele.

“Por que isso seria? Provavelmente porque isso, de certa forma, entra em conflito com a oferta comercial que eles desenvolveram em torno do código aberto ou pensam que (é) simplesmente não é sua prioridade”, disse ele. “Essas coisas não deveriam acontecer em código aberto.”

A política de governação também pode fornecer um sinal de alerta, tal como uma mistura de código aberto e código proprietário, acrescentou.

Verifique a licença

Não há muito que os desenvolvedores possam fazer se alguém decidir alterar a licença, exceto possivelmente bifurcar o projeto de uma versão anterior. A mudança de licença não será retroativa às versões anteriores, disse Horovits.

O que os desenvolvedores podem fazer é trabalhar com um escritório jurídico ou de programas de código aberto em questões de licenciamento. Isso porque mesmo com uma licença de código aberto, pode haver cláusulas que gerem repercussões para os desenvolvedores e suas organizações.

Os desenvolvedores também devem realizar verificações de licença sempre que precisarem atualizar o código-fonte aberto para garantir que a licença não foi alterada.

“Se você atualizar automaticamente para a próxima versão, se a próxima versão tiver sido licenciada novamente, você estará automaticamente exposto, sem que ninguém tenha qualquer julgamento sobre o assunto, só porque você puxou a versão mais recente e pronto”, disse ele.

Revise o código-fonte

Ele também sugeriu analisar o código para entender como ele funciona e verificar se há códigos incomuns que possam indicar um problema futuro.

“Enquanto você estiver lá, mantenha seus olhos e ouvidos abertos e se você vir algo que possa indicar esse tipo de padrão de código não aberto”, disse ele. “Quando o Elasticsearch mudou a licença e a comunidade bifurcou o projeto para criar o OpenSearch, a visão era que você apenas clicasse no botão do fork e teria seu próprio fork, certo? Mas na verdade foi um processo muito, muito (muito) tedioso, a ponto de alguns desenvolvedores precisarem ir linha por linha para separar o código proprietário. No caso da Elastic, é chamado de XPack, licenciado a partir do código-fonte aberto.”

Entenda a governança

Existem etapas proativas que os desenvolvedores também podem seguir. Por exemplo, os desenvolvedores podem optar por código que não seja controlado por um único fornecedor.

“O outro lado, além do licenciamento, é olhar e entender quem está por trás da licença, da governança, da política”, disse ele.

Outra opção para fornecer alguma proteção é usar um fornecedor especializado na distribuição de uma solução de código aberto específica. Um fornecedor de distribuição pode oferecer indenização contra exposição, disse ele. Eles também oferecem outros benefícios, como suporte e certificação para execução em configurações de hardware específicas.

Os desenvolvedores também podem procurar soluções de código aberto que estejam sob uma fundação, em vez de uma única empresa, sugeriu ele, embora tenha alertado que mesmo isso não é uma medida à prova de falhas.

“Mesmo as fundações não são à prova de balas”, disse ele. “As fundações fornecem alguma supervisão, alguma governança e alguns outros meios para reduzir o risco. Mas se, no final das contas, no futuro, ele acabar novamente sendo apoiado por um único fornecedor, então isso será um problema mesmo sob os alicerces.”

As fundações também precisam aprender a melhor orientar e governar um projeto com transparência, acrescentou.

“Dentro da CNCF, estamos revisitando o entendimento mais rigoroso em termos do que se espera, ou pelo menos para que o projeto indique com muita clareza qual é a expectativa”, disse.

A postagem Como os desenvolvedores podem evitar problemas de licenciamento de código aberto apareceu pela primeira vez em The New Stack.