Publicação atrasada de código aberto surge como rival de código aberto

Uma combinação de licenciamento proprietário e de código aberto está se tornando mais popular e representando uma ameaça ao software de código aberto.

Em uma mudança notável na indústria de software, a Publicação Atrasada de Código Aberto (DOSP) emergiu como uma estratégia diferenciada que combina licenciamento proprietário e de código aberto. Esta abordagem envolve inicialmente o lançamento de software sob uma licença proprietária, seguido por uma transição planejada para uma licença de código aberto.

Freqüentemente, esses programas são lançados primeiro como software de código aberto e depois relançados com a promessa de eventualmente reaparecerem como um programa de código aberto. A Open Source Initiative (OSI) lançou um estudo investigando a história, os padrões e as tendências em evolução do DOSP.

O estudo realizado pelos especialistas em código aberto Seth Schoen, James Vasile e Karl Fogel descobriu que, embora a Business Source License (BSL) seja a licença DOSP que a maioria de nós conhece, não há nada de novo no DOSP.

Uma das primeiras instâncias do DOSP foi o Aladdin GhostScript sob a “Licença Pública Gratuita Aladdin” por volta de 1998, que mais tarde fez a transição para um modelo proprietário e de lançamento GPL simultâneo.

Outro exemplo é a biblioteca Qt do KDE, que incorpora o DOSP como uma salvaguarda contra a potencial interrupção do desenvolvimento. O histórico de licenciamento do Qt é complexo, para dizer o mínimo, e hoje está disponível sob licenças comerciais e de código aberto GPL 2.0, GPL 3.0 e LGPL 3.0.

Como a publicação atrasada de código aberto é usada

Os pesquisadores descobriram que existem três tipos de DOSP.

• Relicenciamento programado incondicional. Essa abordagem direta envolve um atraso predefinido antes da transição para o licenciamento de código aberto.
• Relicenciamento orientado a eventos. Aqui, a publicação de código aberto está vinculada a eventos específicos, como o lançamento de uma nova versão proprietária, levando ao código aberto de seu antecessor. Embora isso já tenha sido comum, agora raramente é usado.
• Relicenciamento condicional. Esse tipo depende de certas condições, como garantir financiamento ou encontrar uma casa sem fins lucrativos adequada, antes da transição para o código aberto. Escusado será dizer que esta promessa pode ou não ser cumprida

Uma variação relacionada ao DOSP é “fonte visível” ou “fonte disponível”. Nestes modelos, o código-fonte normalmente está disponível, mas sem as liberdades garantidas pela Open Source Definition (OSD). O exemplo mais recente e conhecido disso é o modelo de linguagem grande de IA da Meta, Llama 2 Community License, onde o código está disponível, mas seu uso comercial é restrito.

Nos primeiros dias do DOSP, os pesquisadores do OSI descobriram que o DOSP “normalmente tratava de monopolizar a receita comercial direta: a licença concederia a maioria das permissões necessárias para o código aberto, mas, o que é crucial, reteria a permissão para usar o software comercialmente”. Esta restrição se aplicaria a todos os licenciados downstream, incluindo usuários, e não apenas aos desenvolvedores.

“Mais recentemente, no entanto”, escreveram os pesquisadores, “algumas licenças DOSP visam impedir que qualquer licenciado use o software em um produto ou serviço que concorra com certos tipos específicos de software que são estrategicamente importantes para o licenciante, independentemente da receita direta. ”

Por exemplo, o BSL 1.1, que foi escrito para MariaDB, não permite que código licenciado seja usado na produção, a menos que o licenciante use o mecanismo de Concessão de Uso Adicional (AUG). Os AUGs não estão especificados na própria licença.

AUGs variam de empresa para empresa. MariaDB, por exemplo, define “uso comercial” como sendo se sua aplicação utiliza o trabalho licenciado com mais de três instâncias de servidor. Em outras palavras, você não pode usar o MariaDB sem uma licença comercial se for usá-lo como base para Software como Serviço (SaaS) ou produção. A implementação do BSL da HashiCorp, AUG, permite o uso em produção… exceto em produtos que sejam competitivos com os programas e serviços da Hashicorp.

O que isto significa na prática é que nem todos os BSLs são criados iguais. Graças aos AUGs, cada instância BSL é, na verdade, uma licença substancialmente diferente.

Código antigo de código aberto: um processo complicado

De qualquer forma, sob uma BSL, versões mais antigas do código serão eventualmente lançadas sob uma licença de código aberto. A palavra-chave é “eventualmente”.

A BSL exige que o licenciante especifique uma “Data de Alteração” e uma “Licença de Alteração”. Na futura Data de Alteração, a licença do artefato coberto será alterada para Licença de Alteração, que é uma licença de código aberto.

A data de alteração do MariaDB é quatro anos após o lançamento de uma versão específica e sua licença de alteração é GPLv2. No entanto, como apontaram os pesquisadores do OSI, “o BSL é conceitualmente projetado para ser aplicado a versões de software específicas, de modo que uma data de mudança se aplique a uma versão específica de uma base de código. Isso significa que, para um projeto com prática DOSP contínua, o BSL deve ser reaplicado periodicamente com detalhes atualizados.

“A maioria dos projetos que vimos ainda não demonstraram como irão lidar com esse processo de forma contínua. A maioria não tem uma maneira claramente visível e sistemática de aplicar as atualizações do BSL ao desenvolvimento contínuo. … Para alguns projetos, à primeira vista não está claro exatamente a qual versão ou versões da base de código a concessão BUSL se destina a se aplicar. O conceito de Data de Mudança pode ser complicado pelo fato de que nem todos os projetos de software contemporâneos possuem um cronograma confiável de eventos discretos de ‘lançamento’.”

Confuso, não é?

A ascensão das licenças de origem comercial

A mudança da HashiCorp da Licença Pública Mozilla 2.0 para BSL 1.1 para Terraform é um exemplo de duas tendências crescentes. A primeira é a ascensão do BSL. Hoje, existem mais de uma dúzia de projetos usando BSL, incluindo CouchBase, DragonflyDB e ArangoDB.

Além disso, as licenças DOSP recentes e os seus utilizadores estão mais centrados na prevenção da concorrência do que na monopolização das receitas comerciais. Em particular, os utilizadores de BSL estão cada vez mais concentrados em impedir a concorrência direta com os interesses estratégicos do licenciante. Esta mudança é evidente nas concessões de utilização adicionais e nos termos específicos acrescentados a estas licenças.

Além das licenças DOSP, vários projetos de software orientados para nuvem, como MongoDB e Redis, também abandonaram licenças de código aberto nos últimos anos para adotar licenças com cláusulas de não concorrência. Essas licenças, como a Licença Pública do Lado do Servidor (SSPL), normalmente permitem que você veja o código, mas os provedores de serviços em nuvem não podem usá-lo em SaaS. Estas não são licenças compatíveis com DOSP.

Ao anunciar a publicação do relatório, o Diretor Executivo da OSI, Stefano Maffuli, elogia suas descobertas importantes, entre as quais a menos importante são “as complexidades e compromissos desde os primeiros dias do movimento de código aberto”, e por levantar novas questões que exigem pesquisas mais dedicadas.

Pessoalmente, vejo o DOSP como um compromisso desagradável entre código aberto e licenciamento proprietário. Parece-me que, muitas vezes, ele é usado para pegar o trabalho de programadores de código aberto e depois fechar a porta atrás de seu código, uma vez que um projeto tenha alcançado impulso suficiente para que seus proprietários o monetizem.

A publicação atrasada de código aberto surge como rival de código aberto apareceu pela primeira vez em The New Stack.