052.2 Lição 1
Certificação: |
Open Source Essentials |
---|---|
Versão: |
1.0 |
Tópico: |
052 As licenças de software open source |
Objetivo: |
052.1 Licenças de software Copyleft |
Lição: |
1 de 1 |
Introdução
A importância das licenças tanto para o uso quanto para o desenvolvimento de software já foi descrita. Assim, não é de espantar que o software livre também tenha sido caracterizado desde o início por novas abordagens de licenciamento: as condições para o uso irrestrito ou o desenvolvimento colaborativo de software devem ser legalmente definidas para que possam ser protegidas e aplicadas.
Conscientes de que a lei de direitos autorais, que está firmemente ancorada em quase todos os sistemas jurídicos do mundo, não poderia ser questionada ou substituída, os desenvolvedores de software adotaram já na década de 1980 uma abordagem que respeita as regulamentações de direitos autorais, complementando-as com novas regulamentações que enfatizam o princípio de “liberdade”: o copyleft.
Copyleft e a Licença Pública Geral GNU (GPL)
Richard Stallman, na época desenvolvedor do renomado MIT, fundou o Projeto GNU em 1983 para desenvolver aquilo que ele considerava um sistema operacional “livre”. Logo ficou claro que o código desenvolvido pelo projeto precisava ser protegido legalmente para que não pudesse simplesmente ser fagocitado por fornecedores comerciais, tornando-se “não-livre”.
Assim, Stallman fundou a Free Software Foundation (FSF), uma fundação sem fins lucrativos, em 1985. A missão da FSF é resumida em seu site da seguinte forma: “A Free Software Foundation trabalha para garantir a liberdade dos usuários de computadores, promovendo o desenvolvimento e o uso de software e documentação livres…”
Um instrumento fundamental para esta missão é uma licença que respeita a lei aplicável (especialmente a lei de direitos autorais), por um lado e, por outro, que implemente as suas próprias ideias de liberdade de forma legalmente límpida. O resultado foi a primeira versão da GNU General Public License (GPLv1) em 1989. Esta licença e inúmeros artigos — como “What is Free Software?” (o que é o software livre?), escrito por Stallman em 1992 — deixam claras as motivações e valores dos desenvolvedores de software livre, que agora também se veem como um “movimento”.
O núcleo programático ainda é formado pelas “quatro liberdades essenciais” formuladas por Stallman no artigo acima mencionado, cuja numeração começa com 0:
A liberdade de executar o programa como você desejar, para qualquer finalidade (liberdade 0).
A liberdade de estudar o funcionamento do programa e alterá-lo para que ele opere do jeito que você deseja (liberdade 1). O acesso ao código-fonte é uma pré-condição para isso.
A liberdade de redistribuir cópias para que você possa ajudar outras pessoas (liberdade 2).
A liberdade de distribuir cópias de suas versões modificadas para terceiros (liberdade 3). Ao fazer isso, você dá a toda a comunidade a chance de se beneficiar de suas alterações. O acesso ao código-fonte é uma pré-condição para isso.
What is Free Software?
Ao contrário das licenças para produtos comerciais, que colocam em primeiro plano as restrições ao uso, o software livre representa a liberdade máxima para os usuários e desenvolvedores.
O preâmbulo da GNU GPLv1 resume isso da seguinte forma:
Especificamente, a Licença Pública Geral foi criada para garantir que você tenha a liberdade de doar ou vender cópias de software livre, de receber o código-fonte ou poder obtê-lo se assim quiser, que possa alterar o software ou usar partes dele em novos programas gratuitos; e que você esteja ciente de que pode fazer essas coisas.
version 1
Isto quer dizer que todos têm o direito de usar, distribuir e modificar software sob a GPL sem restrições (o que é possível porque o código-fonte é acessível, ou seja, “aberto”) e, por sua vez, distribuir as modificações. É, ainda, possível cobrar valores monetários pelo repasse do software:
Na verdade, encorajamos as pessoas que redistribuem software livre a cobrar o quanto quiserem ou puderem. Se uma licença não permite aos usuários fazer cópias e vendê-las, essa licença não é livre… Os programas livres às vezes são distribuídos gratuitamente e, às vezes, custam um preço substancial. Freqüentemente, o mesmo programa está disponível das duas formas em locais diferentes. O programa é livre independentemente do preço, pois os usuários têm liberdade para utilizá-lo.
Selling Free Software
Mas se as liberdades são tão abrangentes, até que ponto o software está protegido sob esta licença, por exemplo contra a sua incorporação em produtos proprietários?
Este é o papel do princípio copyleft mencionado anteriormente, que a GPL já aplica na versão 1, mesmo que o termo ainda não apareça explicitamente:
Você não pode copiar, modificar, sublicenciar, distribuir ou transferir o Programa, exceto conforme expressamente previsto nesta Licença Pública Geral.
Isso significa que todas essas liberdades estão vinculadas à condição de que os usuários preservem essas liberdades em tudo o que fizerem com o software.
O copyleft, portanto, não somente garante liberdades, como também exige que todos os usuários concedam essas mesmas liberdades a outros. Para isso, estipula-se que o software sob uma licença copyleft (como a antiga GPLv1) pode ser modificado e redistribuído somente se as modificações forem publicadas sob as mesmas condições, ou seja, sob a mesma licença.
Dessa forma, o ideal do software livre, que consiste na utilização coletiva e no desenvolvimento posterior do software, vem antes das necessidades pessoais que os indivíduos possam ter em relação a ele. O princípio da reciprocidade é fundamental: quem faz uso das liberdades também deve concedê-las. As licenças copyleft são, portanto, frequentemente chamadas de recíprocas.
Essa abordagem completamente inovadora para uma licença de software mostrou-se legalmente sólida e praticável já na versão 1 da GPL, de modo que a GPL passou por apenas duas grandes revisões nos quase 40 anos durante os quais o mercado moderno de TI se desenvolveu.
GPLv2 e GPLv3
Em 1991, a Free Software Foundation apresentou a versão 2 da GNU General Public License (GPLv2), que se estabeleceu como a licença mais popular para projetos de software livre ao longo de muitos anos. Só para dar um exemplo, o núcleo do sistema operacional Linux ainda hoje é licenciado sob a GPLv2.
Em comparação com a versão 1, a versão 2 concentra-se principalmente em estabelecer definições mais precisas para evitar ambiguidades. Assim, por exemplo, a versão 2 explica com muito mais detalhes o que significa “código-fonte.”
Também é interessante a nova Seção 7, que estabelece o princípio da liberdade e, portanto, a validade da licença como absoluta, não dando azo a quaisquer meios-termos — por exemplo, a integração de partes menos livres ao software:
Se você não puder distribuir de modo a satisfazer simultaneamente suas obrigações sob esta Licença e quaisquer outras obrigações pertinentes, consequentemente você não poderá distribuir o Programa de maneira alguma. Por exemplo, se uma licença de patente não permitir a redistribuição isenta de royalties do Programa por todos aqueles que receberem cópias direta ou indiretamente através de você, a única maneira de satisfazer tanto aquela quanto esta Licença seria abster-se inteiramente de distribuição do Programa.
Foi somente 16 anos depois, em 2007, que a FSF publicou uma nova versão da GPL, a fim de levar em conta as inovações técnicas — como a prestação de serviços de software através da Internet — bem como questões de compatibilidade com outras licenças FOSS. No entanto, a licença permanece estável no que diz respeito às declarações principais, apenas acrescentando detalhes para esclarecimentos adicionais. Vamos dar uma olhada em algumas dessas adições.
Ao passo que a GPLv2 ainda se refere geralmente ao fornecimento de software como distribuição, a GPLv3 especifica esse processo com dois novos termos: propagação e transmissão. A principal razão para isso é que o termo “distribuição” está definido em inúmeras leis de direitos autorais em todo o mundo. Para evitar ambiguidade ou conflito, a GPLv3 escolhe esses novos termos e os define assim:
“Propagar” uma obra significa fazer com ela algo que, sem permissão, tornaria você direta ou indiretamente responsável por uma violação sob a lei de direitos autorais aplicável, exceto executá-la em um computador ou modificar uma cópia privada. A propagação inclui cópia, distribuição (com ou sem modificação), disponibilização ao público e, em alguns países, também outras atividades.
“Transmitir” uma obra implica em qualquer tipo de propagação que permita a terceiros criar ou receber cópias. A mera interação com um usuário através de uma rede de computadores, sem transferência de cópia, não é uma transmissão.
Com o número cada vez maior de produtos de software comerciais cuja distribuição é restringida pelos fabricantes através de medidas técnicas como códigos de registro ou componentes de hardware (os chamados dongles), houve uma série de iniciativas legais internacionais no final da década de 1990 para criminalizar a evasão dessas medidas. Essa chamada gestão de direitos digitais (DRM), também chamada depreciativamente pelos opositores como gestão de restrições digitais, é uma pedra no sapato da FSF, uma vez que essas medidas contradizem fundamentalmente a demanda pela distribuição gratuita de software.
Em resposta, a versão 3 da GPL contém um trecho afirmando que o software sob a GPL não pode ser modificado no que diz respeito aos requisitos legais de DRM. Isso também significa que o software licenciado sob a GPLv3 pode usar DRM, mas que outros também estão autorizados a contornar essas medidas.
O termo tivoização também é frequentemente usado neste contexto. A palavra aparecia explicitamente nos primeiros rascunhos da GPLv3, mas não foi incluída na versão final. O termo remonta à empresa TiVo, que usava software licenciado sob a GPLv2 em seu gravador de vídeo digital, mas ao mesmo tempo impedia tecnicamente que qualquer software modificado fosse instalado e usado no dispositivo. Na opinião da FSF, isso contradizia os princípios da GPL e, após alguma discussão, a GPLv3 passou a levar isso em consideração com um parágrafo sobre os chamados produtos de usuário. Ele estipula, de forma geral, que os produtos que usam software licenciado pela GPLv3 também devem fornecer informações sobre como esse software pode ser modificado.
Um outro acréscimo diz respeito às patentes, que a FSF rejeita fundamentalmente sobre software, já que elas obstruem a liberdade e a inovação. Isto já vem declarado no preâmbulo da GPLv3:
Finalmente, todo programa é constantemente ameaçado pelas patentes de software. Os Estados não deveriam permitir que as patentes restrinjam o desenvolvimento e a utilização de software em computadores de uso geral, mas naqueles que o fazem, desejamos evitar o risco específico de que a aplicação de uma patente a um programa livre possa torná-lo, na prática, proprietário. Para isso, a GPL garante que patentes não podem ser usadas para tornar o programa não-livre.
version 1
O texto da licença também contém diversos trechos que permitem a inclusão de código patenteado por meio de uma “licença de patente não exclusiva, mundial e livre de royalties” do licenciante, a fim de proteger os usuários desse código de disputas entre os titulares das patentes e os licenciados.
A Licença Pública Geral Affero GNU (AGPL)
Com a crescente disponibilidade e velocidade da internet, vêm surgindo cada vez mais serviços nos quais o software é meramente instalado nos servidores do fornecedor — o Application Service Provider (ASP) — e cujos clientes interagem com os serviços através da Internet. A tendência ganhou o nome de Software as a Service (Software como Serviço ou SaaS).
Nesses casos, a GPLv2 não esclarecia se e como o código-fonte (possivelmente modificado pelo provedor) deve ser disponibilizado. A versão 3 da GPL veio fechar essa lacuna, conhecida como ASP loophole (brecha ASP), referindo-se explicitamente, na seção 13, a outra licença emitida pela FSF em 2007: a A Licença Pública Geral Affero GNU versão 3 (GNU AGPLv3). O nome faz referência à empresa Affero, que desenvolveu e publicou as duas primeiras versões dessa licença.
Esta AGPLv3 corresponde em quase todos os pontos à GPLv3, mas regula explicitamente o problema do ASP na seção “interação de rede remota.” Além disso, ambas as licenças declaram explicitamente que podem ser combinadas entre si sem restrições.
Em resumo, a GNU AGPL é um suplemento complementar à GPL. A AGPL amplia o escopo da GPL ao aplicar copyleft a software que não é mais utilizado em instalações locais, mas exclusivamente na forma de serviços transmitidos via redes.
Compatibilidade de licenças Copyleft
O desenvolvimento do software livre depende da criação de código baseado no trabalho de outros desenvolvedores, ou seja, integrando, modificando e compartilhando código-fonte já existente. Se todas as partes de um software modificado ou recentemente compilado estiverem sob a mesma licença copyleft, por exemplo a GPLv3, isso é possível sem quaisquer problemas legais. A licença exige simplesmente que o resultado seja distribuído sob a mesma licença.
As coisas ficam mais complicadas quando o software consiste em partes licenciadas sob licenças diferentes. Nesse caso, é preciso levar em conta uma variedade de fatores.
Obras Combinadas e Derivadas
O software livre pode ser criado sob condições muito diferentes. As mudanças vão desde simples correções de erros até projetos complexos com milhões de linhas de código. Independentemente do escopo, é feita uma distinção básica entre dois tipos de obras no que diz respeito ao licenciamento: derivadas e combinadas.
Vamos supor, por exemplo, que falta uma determinada funcionalidade no projeto de software A. Em vez de desenvolver essa funcionalidade do zero, faz mais sentido combinar o código de outro projeto B, que oferece exatamente esta funcionalidade, com A. O software de B nem precisaria ser alterado para isso, podendo simplesmente ser adicionado a A. Trata-se, portanto, de uma obra combinada. Se A e B estiverem sob a mesma licença copyleft, não haverá problemas para a criação combinada.
Se A e B estiverem sob licenças copyleft diferentes, é necessário cautela: a combinação de A e B já é uma obra separada? E, em caso afirmativo, sob que licença ela pode ou deve ser licenciada? Ou seria possível evitar um conflito garantindo que ambas as partes A e B permaneçam separadas com suas respectivas licenças e não constituam uma nova obra?
A coisa fica ainda mais difícil no caso de obras derivadas, ou seja, quando o projeto A só pode fazer uso da funcionalidade de B incorporando o código de B diretamente no código de A. Essa integração cria uma nova obra derivada, cujas partes não podem mais ser separadas.
O copyleft entra em cena para uma obra derivada. Se, por exemplo, A estiver sob uma licença copyleft como a GPLv3, a nova obra derivada também deverá estar sob a GPLv3, de acordo com o princípio da reciprocidade. Mas e se B estiver sob uma licença diferente? É uma licença copyleft compatível com a GPLv3? Ou, se for um tipo de licença diferente, B também pode ser publicado sob uma licença diferente, ou seja, relicenciado? Ou as licenças de A e B são mutuamente exclusivas, sem meios-termos?
O objetivo desta lição não é listar as combinações e soluções possíveis. O importante, aqui, é ilustrar a complexidade do problema resultante da combinação de questões muito diferentes.
Tecnicamente, a primeira coisa a se esclarecer é como as diferentes partes do software (no nosso exemplo, A e B) funcionam juntas: elas podem ser separadas umas das outras ou existem processos cuja execução não pode mais ser claramente atribuída a uma parte ou a outra?
Do ponto de vista jurídico, surgem questões sobre a relação entre as licenças de A e B. Elas são compatíveis entre si, ou apenas em partes, ou apenas em um sentido? O relicenciamento seria uma opção?
Podemos apenas sugerir aqui a complexidade dessas questões, mas não resolvê-las. Essas decisões exigem conhecimentos jurídicos sólidos. Assim, as decisões de licenciamento para novas obras, mas especialmente para obras combinadas e derivadas, devem ser tomadas antecipadamente, cuidadosamente e sempre com base em uma assessoria jurídica minuciosa.
Copyleft mais fraco
O copyleft mostrou-se extremamente robusto ao longo das últimas décadas, especialmente na forma das versões 2 e 3 da GPL. No entanto, requisitos técnicos especiais levaram a FSF a reagir adaptando suas licenças. A Licença Pública Geral Affero GNU é um exemplo. Discutiremos outros exemplos nas subseções a seguir.
A Licença Pública Geral Menor GNU (LGPL)
No desenvolvimento de software, é muito comum a utilização de pequenos módulos para tarefas padrão, como abrir ou salvar arquivos. Esses módulos — ou coleções de módulos — são chamados de bibliotecas de software. Eles geralmente não são aplicativos executáveis de forma independente, mas rotinas que o aplicativo real integra conforme necessário. O processo de integração é conhecido como vinculação, em que é feita uma distinção entre dois métodos.
No caso das bibliotecas estáticas, o aplicativo em si (por meio de programas auxiliares e etapas intermediárias) integra firmemente o código dos módulos no arquivo executável da aplicação. Já com as bibliotecas dinâmicas o aplicativo integra um módulo somente quando necessário em tempo de execução e o carrega na memória de trabalho.
Isto levanta uma questão em relação ao copyleft e ao licenciamento: quais são as implicações de licenciamento da vinculação? Por exemplo, essa forma de controlar o código exige que um aplicativo que usa uma biblioteca sob a GPL adote a própria GPL? E isso se aplica tanto à vinculação estática quanto à vinculação dinâmica?
O processo de vinculação é tão onipresente no desenvolvimento de software, e os problemas associados ao copyleft recíproco são tão extensos, que a FSF procurou desde o início uma solução de licenciamento que permitisse a vinculação através da Licença Pública Geral Menor GNU (LGPL). A LGPL é atualizada ao mesmo tempo que cada nova versão da GPL. O nome da licença na versão 1 era Licença Pública Geral de Bibliotecas GNU, citando assim o problema original que levou à criação da licença. Nas versões 2 e 3, “Bibliotecas” foi substituído por “Menor” para indicar o que está realmente em jogo, nomeadamente um enfraquecimento pragmático do princípio do copyleft.
Uma biblioteca licenciada sob a LGPL pode, portanto, ser usada por um software sem que este software esteja automaticamente sujeito ao copyleft. Os projetos de software sob as chamadas licenças permissivas (abordadas em outra lição), em particular, beneficiam desse meio-termo, uma vez que ele cria uma proteção legal para a combinação de abordagens que não são necessariamente compatíveis sob a lei de licenciamento.
Quaisquer alterações em um software licenciado pela LGPL permanecem sujeitas ao copyleft, ou seja, também devem estar sob a LGPL.
Entretanto, a biblioteca licenciada pela LGPL deve ser intercambiável, permitindo assim que o usuário do software a substitua por uma versão modificada. Devem ser criadas condições adequadas para isso, fornecendo-se informações sobre como realizar essa substituição.
Outras licenças copyleft
Outros projetos e organizações FOSS também procuram o melhor enquadramento legal para as suas necessidades e, por isso, desenvolvem as suas próprias licenças. Um exemplo é a Mozilla Foundation, fundada em 1998 e hoje mais conhecida pelos dois projetos que apóia: o navegador de internet Firefox e o cliente de e-mail Thunderbird.
A versão 1 da Licença Pública Mozilla (MPL) foi publicada em 1998 e a versão atual (em 2024) 2.0 em 2012.
Assim como a LGPL, a MPL é frequentemente referida como uma licença de"`copyleft fraco`". Na verdade, ela busca encontrar um equilíbrio entre os requisitos rigorosos do copyleft e as possibilidades de integração com produtos comerciais. Isso é conseguido, entre outras coisas, por meio de um princípio conhecido como copyleft em nível de arquivo: se você fizer uma alteração em um arquivo que pertence a um software sob a MPL, poderá integrar esse arquivo em software proprietário, desde que o próprio arquivo modificado permaneça sob o MPL e, portanto, esteja acessível.
Outro exemplo de licença copyleft fraca é a Licença Pública Eclipse (EPL), da Eclipse Foundation. A versão atual 2.0 de 2017 é muito semelhante à MPL e é frequentemente referida como a licença copyleft mais “amigável aos negócios”. No entanto, as diversas licenças copyleft — pois há várias outras além das mencionadas aqui — muitas vezes surgiram devido a desenvolvimentos históricos e não a diferenças legais claras.
Exercícios Guiados
-
O que significa a abreviatura GPL?
-
Por que as licenças copyleft também são chamadas de recíprocas?
-
Qual licença copyleft da FSF é adequada para bibliotecas de software?
-
Quais termos em inglês substituem o termo “distribuição” na GPLv3 e por quê?
-
Quais das seguintes licenças copyleft foram emitidas pela Free Software Foundation?
GPL versão 3
AGPL versão 1
LGPL versão 2
MPL 2.0
EPL versão 2
Exercícios Exploratórios
-
Quais das opções a seguir são licenças copyleft?
GPL versão 2
3-clause BSD License
LGPL versão 3
CC BY-ND
EPL versão 2
-
É possível criar uma obra derivada combinando partes de dois projetos de software que estejam sob diferentes licenças copyleft fortes? Por quê?
-
Quais das seguintes licenças têm um copyleft forte e quais têm um copyleft fraco?
Common Development and Distribution License (CDDL) 1.1
GNU AGPLv3
Microsoft Reciprocal License (MS-RL)
IBM Public License (IPL) 1.0
Sleepycat License
-
Descreva alguns problemas de compatibilidade que podem surgir ao combinar software sob uma licença copyleft fraca com software sob uma licença não copyleft.
Resumo
Esta lição trata das características das licenças de software que seguem o princípio do copyleft. Desenvolvida na década de 1980 pela Free Software Foundation, a Licença Pública Geral GNU (GPL) é atualmente a licença mais popular, com direitos autorais firmemente estabelecidos. Apesar de ter sofrido diversas revisões até a atual versão 3, seus requisitos básicos permaneceram praticamente inalterados: As liberdades concedidas pela licença para usar, redistribuir e modificar o software sem restrições devem ser preservadas em todos os momentos. Isto significa que o software modificado só pode ser redistribuído sob as mesmas condições (ou seja, a mesma licença).
As inovações técnicas, bem como o desejo de margem de manobra legal na colaboração com outros projetos, levaram a FSF a desenvolver licenças suplementares ou alternativas. A Licença Pública Geral Menor GNU (LGPL), por exemplo, leva em consideração a vinculação estática ou dinâmica das bibliotecas de software frequentemente usadas no desenvolvimento de aplicativos. A Licença Pública Geral GNU Affero (AGPL) responde à tendência técnica de utilização de software na forma de serviços através da rede (especialmente da internet), ou seja, não em instalações locais.
Além da FSF, outros projetos como a Mozilla Foundation e a Eclipse Foundation desenvolveram licenças copyleft. Estas também procuram um meio-termo entre garantir as liberdades concedidas pela licença e uma relação simplificada com o software sob outras licenças através de um copyleft mais fraco.
Em princípio, a compatibilidade das licenças é uma questão importante nas licenças copyleft, porque o princípio do desenvolvimento de software gratuito e colaborativo deve ser conciliado com as condições legais determinadas pela licença respectiva. Em qualquer forma de combinação de software sob diferentes licenças, as condições legais devem ser examinadas cuidadosamente em cada caso individual.
Respostas aos Exercícios Guiados
-
O que significa a abreviatura GPL?
General Public License (Licença Pública Geral)
-
Por que as licenças copyleft também são chamadas de recíprocas?
O princípio do copyleft exige que as liberdades concedidas por uma licença também sejam concedidas a outras pessoas, sem restrições. Por exemplo, se você fizer uma alteração no software sob a GPL, terá a obrigação a disponibilizar essas alterações a terceiros nas mesmas condições, como dita a reciprocidade.
-
Qual licença copyleft da FSF é adequada para bibliotecas de software?
GNU Lesser General Public License (Licença Pública Geral Menor GNU, ou GNU LGPL)
-
Quais termos em inglês substituem o termo “distribuição” na GPLv3 e por quê?
Os termos “transmitir” e “propagar” vieram substituir “distribuição”. O pano de fundo para isso é que o termo “distribuição” está firmemente ancorado na lei internacional de direitos autorais. Para evitar conflitos ou mal-entendidos, a GPL na versão 3 não utiliza esse termo.
-
Quais das seguintes licenças copyleft foram emitidas pela Free Software Foundation?
GPL versão 3
X
AGPL versão 1
LGPL versão 2
X
MPL 2.0
EPL versão 2
Respostas aos Exercícios Exploratórios
-
Quais das opções a seguir são licenças copyleft?
GPL versão 2
X
3-clause BSD License
LGPL versão 3
X
CC BY-ND
EPL versão 2
X
É possível criar uma obra derivada combinando partes de dois projetos de software que estejam sob diferentes licenças copyleft fortes? Por quê?
+ Não. As licenças com copyleft forte geralmente exigem que as versões modificadas estejam sob a mesma licença. Isso também exclui o relicenciamento. A combinação de licenças, quando ambas seguem esses princípios, representa portanto uma contradição insolúvel.
-
Quais das seguintes licenças têm um copyleft forte e quais têm um copyleft fraco?
Common Development and Distribution License (CDDL) 1.1
fraco
GNU AGPLv3
forte
Microsoft Reciprocal License (MS-RL)
fraco
IBM Public License (IPL) 1.0
fraco
Sleepycat License
forte
-
Descreva alguns problemas de compatibilidade que podem surgir ao combinar software sob uma licença copyleft fraca com software sob uma licença não copyleft
Embora um copyleft forte exija que o software modificado seja distribuído sob a mesma licença, as condições são “afrouxadas” no caso de um copyleft fraco. No entanto, qualquer combinação com outras licenças levanta questões fundamentais de compatibilidade. É necessário levar em conta certos aspectos importantes ao responder a estas questões: as partes originais dos dois projetos de software estão claramente separadas no novo trabalho e, se necessário, ainda podem ser licenciadas de formas diferentes? Em que nível ocorre de fato a conexão entre os dois projetos de software originais? O código-fonte é adotado diretamente ou é “apenas” vinculado dinamicamente ao outro software (biblioteca)? Uma das duas licenças permite o relicenciamento de maneira geral? Todas as questões desse tipo só poderão ser respondidas após uma análise precisa das respectivas licenças e com uma assessoria jurídica especializada.