Licença dupla (múltipla)

Por que dar várias licenças a um mesmo código

O titular pode licenciar o mesmo código sob várias condições ao mesmo tempo. Quem recebe escolhe uma delas e cumpre as condições correspondentes. Há dois objetivos principais.

1. Ampliar a compatibilidade — para se encaixar bem em ecossistemas diferentes.
2. Modelo de negócio — para publicar como open source e, ao mesmo tempo, vender uma licença comercial separada.

Tipo 1: duas permissivas juntas — MIT OR Apache-2.0

É o modelo usado pela linguagem Rust e pela maioria dos crates Rust. O usuário escolhe a que for mais conveniente entre MIT e Apache-2.0.

• Escolhendo a Apache-2.0, recebe a concessão explícita de patentes.
• Escolhendo a MIT, pode incluir o código também em projetos GPL-2.0-only (por causa da posição da FSF de que a Apache-2.0 é incompatível com a GPL-2.0).

Como se aproveitam as duas vantagens, o modelo é popular entre autores de bibliotecas. Por convenção, o repositório traz dois arquivos, LICENSE-MIT e LICENSE-APACHE.

Tipo 2: copyleft + comercial — 'GPL, ou pague'

O código é publicado sob GPL ou AGPL, e às empresas que não querem assumir a obrigação de divulgar o código-fonte vende-se uma licença comercial por contrato separado. MySQL (GPL + licença comercial da Oracle) e Qt (LGPL-3.0/GPL + comercial) são exemplos típicos.

Esse modelo só funciona se o titular detiver os direitos de todo o código. Isso porque o titular não tem o direito de vender sob licença comercial o código que contribuidores externos enviaram apenas sob a GPL.

CLA e DCO

• CLA (Contributor License Agreement): contrato pelo qual o contribuidor concede à entidade que mantém o projeto amplos direitos de uso sobre a contribuição (incluindo relicenciamento) ou cede os direitos autorais. Na prática, é necessário para fazer licença dupla comercial. Há também formas como o ICLA da Apache Foundation, que concede apenas o direito de relicenciar e deixa o copyright com o contribuidor.
• DCO (Developer Certificate of Origin): o contribuidor confirma em cada commit que 'tem o direito de enviar este código sob a licença deste projeto' (git commit -s acrescenta a linha Signed-off-by:). É usado pelo kernel Linux. O DCO não concede direito de relicenciamento, portanto não basta para uma licença dupla comercial.

Como escrever com expressões SPDX

A relação entre várias licenças é escrita com expressões de licença SPDX.

Confundir OR e AND inverte totalmente o sentido. Se o usuário pode escolher, é OR; se é preciso cumprir todas, é AND.

Cuidados

• Direitos já recebidos continuam valendo: mesmo que depois só reste a licença comercial, a permissão das versões já distribuídas como open source normalmente continua válida.
• É diferente de 'open core': o modelo em que o núcleo é open source e os recursos extras são vendidos como comerciais fechados não é licença dupla. Licença dupla é dar duas licenças ao mesmo código.
• Não confunda com licenças de código disponível: aumentaram os casos de migração para licenças como BUSL e SSPL, em que o código é visível mas não é open source segundo a OSI. Essa é uma estratégia diferente da licença dupla.
• Arquivos de aviso corretos: se for por escolha, forneça o texto completo de cada licença e deixe claro no README que se trata de 'escolher uma das duas'.

Exemplo de aplicação

Para aplicar uma licença dupla no estilo Rust, baixe no gerador os arquivos MIT e Apache-2.0, salve-os como LICENSE-MIT e LICENSE-APACHE e escreva license = "MIT OR Apache-2.0" nos metadados. No cabeçalho de cada arquivo, use SPDX-License-Identifier: MIT OR Apache-2.0.

Este texto é informação geral e não constitui aconselhamento jurídico. Para decisões importantes, consulte um profissional.

Fontes

• SPDX Specification, License Expressions — https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
• Rust API Guidelines, Licensing — https://rust-lang.github.io/api-guidelines/necessities.html
• Developer Certificate of Origin — https://developercertificate.org/
• Apache ICLA — https://www.apache.org/licenses/contributor-agreements.html