Compatibilidade e relicenciamento de licença

por Richard Stallman

Se você quiser combinar dois programas livres em um, ou mesclar o código de um para o outro, isso levanta a questão de saber se suas licenças permitem combiná-los ou proíbem combiná-las.(*)

Não há problema em mesclar programas que possuem a mesma licença se ela for uma licença razoavelmente comportada, já que quase todas as licenças livres são.(**)

O que, então, fazer quando as licenças são diferentes? Em geral, dizemos que várias licenças são compatíveis se houver uma maneira de mesclar o código sob essas várias licenças e, ao mesmo tempo, cumprir todas elas. O resultado, muitas vezes, é um programa com partes sob várias licenças compatíveis diferentes – mas nem sempre. Essa capacidade de combinação, ou a ausência dela, é uma característica de um determinado conjunto de licenças e não depende da ordem em que você as menciona. O conjunto de licenças também controla qual licença é necessária para o programa combinado.

Nós dividimos as licenças em três classes: leniente (também “permissivo” ou, em inglês, “pushover” ou “lax”), intermediária e copyleft. Uma licença leniente faz nada para interferir na colocação de código em software privativo. Uma licença protegida por copyleft proíbe isso, exigindo que toda a reutilização esteja em programas sob a mesma licença. Uma licença intermediária coloca algumas condições em adicionar código privativo, mas não tenta proibi-lo.

Em geral, licenças permissivas e lenientes (BSD modificado, X11, Expat, Apache, Python etc.) são compatíveis entre si. Isso é porque elas não têm requisitos sobre outro código que é adicionado ao programa. Eles até permitem colocar todo o programa (talvez com alterações) em um produto de software privado; assim, nós as chamamos de “licenças lenientes” porque eles não podem dizer “não” quando um usuário tenta negar a liberdade a outros.

Em uma combinação de programas sob licenças lenientes, cada parte carrega a licença com a qual veio. Quando o código é mesclado ao ponto em que as partes não podem mais ser distinguidas, esse código mesclado deve conter todas as licenças das partes mescladas. Já que todas licenças são lenientes, isso não causa nenhum problema prático, exceto que a lista de licenças fica mais longo.(***)

Da mesma forma, as licenças lenientes são geralmente compatíveis com qualquer licença protegida por copyleft. No programa combinado, as partes que vieram sob licenças lenientes ainda as carregam, e o programa combinado como um todo carrega a licença copyleft. Uma licença leniente, o Apache 2.0, tem cláusulas de patentes incompatíveis com a versão 2 da GPL; já que acho que essas cláusulas de patente são boas, tornei a versão 3 da GPL compatível com elas.

A única exceção importante é a licença BSD original, por causa da “desagradável cláusula de publicidade”. Esta condição exigia um aviso específico em toda publicidade de qualquer produto contendo qualquer código lançado sob a licença BSD original. Isso era e é incompatível com todas as licenças copyleft. Também era uma dor de cabeça para cada distro, pois os programas se acumulavam com requisitos de publicidade semelhantes, mas diferentes. Em um ponto, uma distro BSD exigia mais de 70 avisos diferentes.

Eu praticamente eliminei esse problema principalmente convencendo um reitor, Hal Varian, a providenciar para que a UC Berkeley publicasse a “licença BSD modificada” (sem a cláusula de publicidade) e relançar o código do Berkeley System Distribution sob ela. Hoje em dia, a licença BSD original é (felizmente) raramente usada, mas ainda devemos tomar cuidado para não falar sobre “a” Licença BSD.

Em geral, duas licenças copyleft diferentes são inevitavelmente incompatíveis, a menos que tenham disposições de compatibilidade explícitas. Isso não se deve a um erro de detalhes; é inerente à ideia de copyleft. A ideia do copyleft é que “Versões modificadas e estendidas devem estar sob a mesma licença”. Se a licença A (no prorgrama P) diz que os programas estendidos devem estar sob a licença A, e a licença B (no programa Q) diz que os programas estendidos devem estar sob a licença B, elas têm um desacordo irreconciliável; a licença do programa combinado que inclui código de P somado ao código de Q teria que ser A e teria que ser B.

É por isso que a GPL versão 2 é incompatível com a GPL versão 3; isso não poderia ser evitado. Da mesma forma, as condições da CC-BY-SA 4.0 seriam inerentemente incompatíveis com as da CC-BY-SA 3.0, e os autores não poderiam ter evitado isso.

Existem duas abordagens para evitar o problema de incompatibilidade causado por versões diferentes de licenças copyleft.

A FSF usa a abordagem de pedir às pessoas para lançar programas sob “GNU GPL versão N ou qualquer versão posterior”. Este licenciamento é compatível com a versão N, e também com N+1 (pois oferece a versão N+1 como opção). Quando você combina um código sob “GPL 3 ou posterior” com um código sob “GPL 2 ou posterior”, a licença da combinação é sua interseção, que é “GPL 3 ou posterior”.

Esperamos nunca precisar fazer uma GNU GPL versão 4, mas nada é perfeito e não podemos presumir que antecipamos todos os problemas. Ao liberar seu código sob GNU GPL 3 ou posterior, você permite que seu código seja atualizado para GNU GPL versão 4, se precisarmos de uma.

A outra abordagem é fazer com que cada versão da licença permita explicitamente a atualização para versões posteriores. A Fundação Mozilla usa essa abordagem, assim como PHP. A Creative Commons usa-a para CC-BY-SA: a versão 4.0 (a versão atual) permite explicitamente que qualquer usuário atualize para versões posteriores de CC-BY-SA para obras modificadas.

Apenas as licenças GNU dão aos autores a escolha de permitir atualizações para futuras versões de licença. Quando escrevi a primeira versão da GNU GPL, em 1989, considerei incluir uma opção de atualização de licença como é encontrada agora nas licenças CC, mas achei mais correto dar essa escolha a cada autor. Assim, o autor poderia lançar um programa sob “GPL 1 apenas” ou “GPL 1 ou posterior”.

Desde então, comecei a questionar a sabedoria dessa decisão. Programas como o Linux, que permitem apenas uma versão GNU GPL e rejeitam atualizações de licença, causam incompatibilidade prática.(****) Se algum dia fizermos uma GNU GPL 4, talvez devêssemos incluir uma cláusula de atualização que automaticamente permite relicenciamento para versões de números maiores, 5 e superiores.

Algumas licenças copyleft permitem combinações de copyleft cruzadas com uma cláusula explícita de relicenciamento, dando permissão para colocar o código sob uma licença copyleft diferente. Por exemplo, a CeCILL dá permissão explícita para relicenciar o código para GNU GPL versão 2 e versões posteriores. Se o programa P está sob a CeCILL, e você deseja combiná-lo com o programa Q que está sob a GPL versão 3 ou posterior, a CeCILL diz que você pode fazer isso e colocar a combinação ou código mesclado na GPL versão 3 ou posterior.

A permissão explícita de relicenciamento não é a mesma coisa que compatibilidade (embora relicenciar código possa torná-lo compatível com outro código) e não é simétrica. Por exemplo, a CeCILL dá permissão explícita para relicenciar o código para GNU GPL, mas a GNU GPL não permite o relicenciamento para a CeCILL. Assim, você não pode combinar esses dois programas P e Q e distribuir a combinação sob a CeCILL; isso violaria a GPL no uso do programa Q. A única maneira permitida de lançar esse programa combinado é sob a(s) versão(ões) apropriada(s) da GPL.

Da mesma forma, a CC-BY-SA 4.0 permite explicitamente o relicenciamento de versões modificadas para GNU GPL versão 3, mas a GPL versão 3 não permite o relicenciamento para CC-BY-SA. Esse problema nunca deve surgir para o código de software; a Creative Commons diz que suas licenças não são destinadas a código e diz que a licença de uso para código é a GNU GPL. Mas existem outros tipos de obras, como designs de hardware ou arte de jogos, onde você pode ter a oportunidade de mesclar material lançado sob CC-BY-SA com material lançado sob a GNU GPL. Isso pode ser feito por meio da permissão explícita de relicenciamento da CC-BY-SA.

Infelizmente, a CC-BY-SA 4.0 não permite o relicenciamento para futuras versões da GPL. O que você deve fazer, ao relicenciar o material sob CC-BY-SA 4.0 para a GPL, é especificar-se como um intermediário de versão de licença para indicar se futuras versões GPL foram autorizadas para esse material. Se algum dia houver uma GPL versão 4 e a Creative Commons decidir permitir o relicenciamento de CC-BY-SA para GPL versão 4, você, como intermediário, poderá autorizar retroativamente o uso desse material relicenciado sob a GPL versão 4. (Alternativamente, você pode pedir aos autores desse material que deem permissão imediatamente.)

A Licença Pública Geral GNU comum e a Licença Pública Geral Affero GNU são duas licenças copyleft diferentes, portanto, são naturalmente incompatíveis. Estabelecemos um tipo especial de compatibilidade explícita entre elas: você pode incluir o código-fonte sob a GNU GPL versão 3 junto com outro código-fonte sob a GNU Affero GPL em um único programa combinado. Isso é permitido porque ambas as licenças dizem isso explicitamente e o efeito é que a GNU AGPL se aplica ao programa combinado. No entanto, você não pode simplesmente relicenciar o código da GNU GPL (com ou sem “ou posterior”) para a GNU Affero GPL ou vice-versa; nenhuma dessas licenças dá permissão para isso. Observe também que a GNU Affero GPL versão 3 não é uma “versão posterior” da GNU GPL versão 2 comum, porque a GNU Affero GPL e a GNU GPL são duas séries diferentes de licenças.

A Licença Pública Geral Menor GNU, versão 3, é realmente a Licença Pública Geral GNU versão 3 mais algumas permissões extras adicionadas. A GPL versão 3 (seção 7) diz que você sempre pode remover as permissões adicionadas e, ao fazer isso, você obtém o mesmo código na GNU GPL versão 3 comum. Se um programa permitir o uso sob a GNU LGPL versão 3 ou posterior, você pode relicenciar para a GPL versão 3 ou posterior; para cada futura GPL versão N (N > 3), faremos uma versão LGPL N que consiste na versão GPL N mais permissões adicionadas.

Quanto à GNU Menor GPL versão 2.1, que permite explicitamente o relicenciamento para o GNU GPL versão 2 ou posterior.

Licenças intermediárias são aquelas que possuem requisitos substantivos de redistribuição, mas não são licenças copyleft. Os exemplos incluem a Licença Pública Eclipse e a Licença Pública Mozilla. Licenças intermediárias tendem a ser incompatíveis com quaisquer licenças copyleft porque seus requisitos não permitem que o programa combinado esteja sob a licença copyleft. A Licença Pública Mozilla permite o relicenciamento para a GNU GPL, exceto quando o código explicitamente nega essa permissão.

Finalmente, e quanto ao licenciamento duplo?(*****) Uma licença dupla é uma disjunção: significa que o mesmo programa carrega uma escolha de duas ou mais licenças diferentes. Por exemplo, as versões mais antigas do Perl carregavam uma licença dupla: a disjunção da Licença Artística e a Licença Pública Geral GNU. Isso significa que cada usuário pode escolher usar e redistribuir o Perl sob uma licença ou outra, ou em ambas em disjunção, como o próprio lançamento do Perl. Uma disjunção é compatível com um conjunto de outras licenças se qualquer uma das opções de licença na disjunção for compatível com aquele conjunto.

Ao escolher uma licença para o seu código, escolha GNU GPL versão 3 ou posterior, ou alguma licença compatível com ela. Esta é a maneira de tornar seu código combinável com quase todo o corpus de software livre. Escolher GPL ou AGPL, versão 3 ou posterior, também fará o máximo para defender a liberdade de todos os usuários de todas as versões de seu código.

Combinando código

Quando um conjunto de licenças é compatível, isso significa que você pode legalmente combinar ou mesclar uma série de programas, cada um licenciado sob uma dessas licenças. Como, então, o programa combinado é licenciado?

Cada licença de software livre diz que você deve manter a licença com o código que é coberto por ela. Portanto, em um sentido estrito, o licenciamento do programa combinado inclui as licenças de todas as suas partes. No entanto, às vezes você deseja uma resposta resumida à questão de como o programa combinado é licenciado. A quais licenças alguém que usa o programa combinado precisa prestar atenção?

Para calcular isso, você começa com uma lista de todas as licenças pertinentes. Em seguida, você pode excluir da lista qualquer licença incluída por outra da lista.

Dizemos que uma licença A inclui a licença B quando a conformidade com a licença A implica conformidade com a licença B.

Por exemplo, a GNU GPL versão N e a GNU Affero GPL versão N incluem a GNU Menor GPL versão N, e todas as três incluem a GNU Menor GPL versão 2.1.

Qualquer licença GNU, versão N, inclui a licença Apache 2.0, desde que N seja pelo menos 3.

A GNU GPL, versão N, inclui todas as versões da Licença Pública Mozilla que são compatíveis com ela.

A licença Apache 2.0 inclui as licenças BSD, Expat, X11, ISC e CC-0. A cláusula BSD 3 inclui a cláusula BSD 2. As licenças BSD incluem as licenças Expat, X11 e ISC e CC-0.

Não se trata de uma lista completa, mas se formos informados de outros casos dignos de menção, iremos acrescentá-los.

Quando alguma licença é incluída, você ainda precisa incluir uma cópia dela em toda a distribuição do programa combinado.

Notas de rodapé

* Não é inconcebível que outras questões legais possam surgir sobre uma combinação específica de programas, questões não relacionadas às licenças de direitos autorais dos programas a serem combinados. Discutimos apenas as implicações das próprias licenças.

** A licença principal em uso real que não é razoavelmente comportada é a licença do TeX: se dois programas são licenciados da mesma forma que o TeX, não existe uma maneira autorizada de distribuir uma versão mesclada deles.

A licença do TeX permite a distribuição de uma versão modificada somente na forma da versão original mais um arquivo de diferenças. Se A e B forem lançados separadamente dessa maneira, então, mesclar, distribuir o programa mesclado como A mais um arquivo de mudanças viola a licença de B. Distribuir isso como B mais um arquivo de mudanças viola a licença de A. Distribuir isso de qualquer outra forma viola ambas as licenças.

Não é coincidência que o TeX tenha sido lançado em 1982: nossa comunidade aprendeu, desde então, a escrever licenças razoavelmente comportadas.

*** Ao distribuir na forma de código-fonte, geralmente é suficiente deixar os avisos de licença no código-fonte como estão; requisitos extras de aviso de licença normalmente aparecem apenas para licenças lenientes ao distribuir binários sem o código-fonte.

**** Além disso, a GPL versão 2 ainda permite que binários se tornem não livres por hardware que rejeita tudo, exceto binários assinados especiais, e ainda não permite a distribuição de binários por torrent. Corrigimos essas e outras coisas na versão 3, mas não podemos mudar a versão 2.

***** Alguns usam inexplicavelmente o termo “licenciamento duplo” para se referir a vender exceções, mas isso é um nome impróprio. Consulte Vender exceções. Observe que se o programa no qual a licença é vendida inclui qualquer código que não esteja na versão livre, isso não é vender exceções, isso é software não livre.