Explorar licenças comuns de software livre

  • 8 minutos

Existem centenas de licenças de software livre, mas a maioria dos softwares de software livre usa um número relativamente pequeno de licenças populares. Entender essas licenças comuns, seus termos e suas implicações ajuda as organizações a tomar decisões informadas sobre quais componentes de software livre eles podem incorporar com segurança em seus softwares.

O espectro de licença

Licenças software livre existem em um espectro, desde altamente permissivas até fortemente copyleft:

Captura de tela do espectro da licença.

Licenças permissivas (atribuição)

No lado esquerdo do espectro estão licenças permissivas que impõem restrições mínimas:

  • Características: Permitir o uso de código em software proprietário sem exigir que o software proprietário seja de software livre.
  • Requisito principal: Atribuição – preservar avisos de direitos autorais e texto de licença.
  • Uso comercial: Totalmente compatível com a criação e venda de software comercial proprietário.
  • Liberdade downstream: Os usuários podem escolher se desejam tornar código-fonte aberto suas obras derivadas.

Exemplos: Licença do MIT, Licença do Apache 2.0, Licenças BSD.

Licenças copyleft

Na extremidade direita do espectro estão as licenças copyleft com fortes requisitos de reciprocidade:

  • Características: Exigir trabalhos derivados e trabalhos combinados para usar a mesma licença.
  • Natureza viral: A licença “propaga-se” para o software que incorpora ou é combinado com o código licenciado.
  • Requisito de código-fonte: A distribuição de binários requer a disponibilização do código-fonte.
  • Preservação da liberdade: Verifique se o software permanece de software livre à medida que evolui e é incorporado em outros projetos.

Exemplos: GNU General Public License (GPL v2 e v3), GNU Affero General Public License (AGPL).

Licenças copyleft fracas

No meio do espectro estão as licenças de copyleft fraco, que equilibram abertura com viabilidade comercial:

  • Características: Exigir modificações no componente licenciado para ser de software livre, mas permitir a incorporação do componente em trabalhos proprietários maiores.
  • Compatível com bibliotecas: Projetado para bibliotecas adequadas para uso em aplicativos proprietários.
  • Copyleft em nível de arquivo ou módulo: Os requisitos se aplicam ao próprio componente licenciado, não à aplicação inteira.
  • Equilíbrio prático: Habilite o uso comercial, garantindo que as melhorias no componente permaneçam de software livre.

Exemplos: GNU Lesser General Public License (LGPL), Mozilla Public License (MPL), Eclipse Public License (EPL).

Licenças permissivas comuns

Licença MIT

A Licença do MIT é uma das licenças de software livre mais simples e permissivas:

Termos-chave:

  • Permissões: Use, copie, modifique, mescle, publique, distribua, sublicense e venda o software.
  • Condições: Inclua o aviso de direitos autorais e o texto de licença em todas as cópias ou partes substanciais.
  • Limitações: Sem garantia, sem responsabilidade por danos.

Por que os projetos escolhem o MIT:

  • Adoção máxima: Restrições mínimas incentivam o uso generalizado.
  • Simples e claro: Texto curto de licença que é fácil de entender.
  • Comercialmente amigável: Não há barreiras para incorporar código licenciado pelo MIT em software proprietário.
  • Flexibilidade: Os usuários têm total liberdade em como usam e distribuem o software.

Projetos populares licenciados pelo MIT: React, Angular, Node.js, jQuery, Rails, .NET Core.

Implicações para as organizações:

  • Seguro para uso comercial: Pode incorporar componentes licenciados pelo MIT em software proprietário sem restrições.
  • Atribuição obrigatória: É necessário preservar os avisos de copyright—normalmente atendido incluindo o texto da licença na documentação da aplicação ou em caixas de diálogo Sobre.
  • Sem concessão de patente: A Licença do MIT não aborda explicitamente as patentes, criando ambiguidade potencial.

Licença do Apache 2.0

A Licença do Apache 2.0 é uma licença permissiva com proteção de patente explícita:

Termos-chave:

  • Permissões: Use, reproduza, prepare trabalhos derivados, exiba, execute, sublicense e distribua.
  • Condições: Incluir aviso de direitos autorais, texto de licença e aviso de modificações; preservar avisos de patente; fornecer atribuição.
  • Concessão de patentes: Concessão explícita de direitos de patente pelos contribuidores.
  • Retaliação de patente: As concessões de patente terminam se o licenciado iniciar um litígio de patentes contra colaboradores.
  • Limitações: Sem garantia, sem responsabilidade, sem direitos de marca.

Por que os projetos escolhem o Apache 2.0:

  • Clareza de patente: Concessões explícitas de patente fornecem segurança legal.
  • Transparência de modificação: O requisito para documentar modificações promove a transparência.
  • Confiança corporativa: Termos claros e proteções de patentes fazem com que as corporações se sintam à vontade para contribuir.
  • Compatibilidade: Compatível com GPL v3 (mas não GPL v2).

Projetos populares do Apache 2.0: Kubernetes, TensorFlow, Android, Spring Framework, Apache Hadoop, Apache Kafka.

Implicações para as organizações:

  • Proteção de patente: A concessão explícita de patente reduz o risco de litígio de patente de colaboradores.
  • Aviso de modificação: Deve indicar quando os arquivos foram modificados.
  • Requisitos de atribuição: Um pouco mais complexo do que o MIT, exigindo a preservação de arquivos NOTICE.
  • Término defensivo: Os subsídios de patente terminam se você processar colaboradores por violação de patente, incentivando a coexistência pacífica.

Licenças BSD (Cláusula de 2 e Cláusula de 3)

As licenças BSD (Berkeley Software Distribution) são licenças permissivas semelhantes ao MIT:

Cláusula BSD 2 (BSD simplificado):

  • Permissões: Redistribuição e uso em formulários de origem e binários, com ou sem modificação.
  • Condições: Preservar aviso de direitos autorais, lista de condições e isenção de responsabilidade; manter a atribuição na documentação para distribuições binárias.
  • Limitações: Sem garantia, sem responsabilidade.

Cláusula BSD 3 (BSD modificado):

  • Condição adicional: Não é possível usar os nomes dos detentores de direitos autorais para endossar produtos derivados sem permissão.
  • Proteção de marca registrada: Impede a implicação de endosso por autores originais.

Projetos populares licenciados por BSD: FreeBSD, OpenBSD, partes do macOS e do iOS.

Implicações para as organizações:

  • Semelhante ao MIT: Restrições mínimas, comercialmente amigáveis.
  • Restrição de uso de nome: O BSD da cláusula 3 impede o uso de nomes de projeto para marketing sem permissão.
  • Bem estabelecido: Longa história em software acadêmico e comercial.

Licenças copyleft comuns

GPL (Licença Pública Geral) GNU v2 e v3

A Licença Pública Geral do GNU é a licença copyleft mais conhecida:

Termos de chave gpl v2:

  • Permissões: Use, modifique e distribua o software.
  • Condições: Distribuir código-fonte com binários; os trabalhos derivados devem usar GPL v2; preservar avisos de direitos autorais.
  • Escopo do copyleft: Aplica-se a trabalhos derivados e trabalhos combinados que se conectam com código sob GPL.
  • Limitações: Sem garantia, sem responsabilidade.

Aprimoramentos da GPL v3:

  • Proteção de patente: Concessões explícitas de patente semelhantes ao Apache 2.0.
  • Prevenção de Tivoization: Impede o uso de restrições de hardware para impedir que os usuários executem software modificado.
  • Compatibilidade internacional: Maior clareza legal para jurisdições internacionais.
  • Compatibilidade do Apache 2.0: Pode combinar código GPL v3 com código Apache 2.0.

Por que os projetos escolhem GPL:

  • Garantindo a liberdade: A GPL garante que as modificações permaneçam de software livre, impedindo bifurcações proprietárias.
  • Construção da comunidade: Incentiva o compartilhamento de melhorias de volta para a comunidade.
  • Alinhamento filosófico: Alinha-se com a filosofia de software livre de que o software deve permanecer livre.

Projetos populares licenciados por GPL: Kernel linux (GPL v2), Git (GPL v2), WordPress (GPL v2), GCC (GPL v3), Bash (GPL v3).

Implicações para as organizações:

  • Requisitos de trabalho derivados: Se você modificar o código GPL ou criar trabalhos derivados, deverá abri-los em GPL quando distribuídos.
  • Questões de vinculação: Vincular código proprietário com bibliotecas licenciadas sob GPL pode ativar requisitos de copyleft (a interpretação varia).
  • Distribuição comercial: Pode vender software GPL'd, mas deve fornecer código-fonte aos clientes.
  • Considerações sobre SaaS: GPL v2 e v3 não exigem divulgação de código-fonte para software como serviço, a menos que a AGPL seja usada.

AGPL (Licença Pública Geral) da GNU Affero

A AGPL estende a GPL v3 com um provisionamento de uso de rede:

Requisito adicional da AGPL:

  • Copyleft em rede: Se você modificar software sob AGPL e os usuários interagirem com ele pela rede (SaaS), você deve fornecer o código-fonte a esses usuários.
  • Fechando a brecha do ASP: Impede que as empresas modifiquem o software e ofereçam-no como um serviço sem compartilhar modificações.

Por que os projetos escolhem a AGPL:

  • Proteção SaaS: Assegura que os serviços de nuvem não possam usar software livre sem contribuir em troca.
  • Copyleft mais forte: Proteção máxima contra uso proprietário.

Projetos populares licenciados pela AGPL: MongoDB (alterado da AGPL), RocketChat, Grafana.

Implicações para as organizações:

  • Evitar para SaaS: A maioria das organizações evita software licenciado sob AGPL para ofertas de serviço porque exige a abertura do código das modificações.
  • Uso interno: Pode usar internamente sem disparar requisitos se não for exposto aos usuários em uma rede.
  • Avaliação do risco: Avalie cuidadosamente se o software se qualifica como "interagindo em uma rede".

Licenças de copyleft fracas comuns

GNU Lesser General Public License (LGPL)

O LGPL permite vincular a bibliotecas sem disparar requisitos completos de GPL:

Termos-chave:

  • Uso da biblioteca: Pode vincular a bibliotecas LGPL de software proprietário sem tornar o código-fonte do aplicativo proprietário aberto.
  • Modificações de biblioteca: As modificações na própria biblioteca LGPL'd devem ser de software livre.
  • Vinculação dinâmica: O LGPL permite explicitamente a vinculação dinâmica com o código proprietário.
  • Trabalhos derivados: Aplicativos completos não são trabalhos derivados apenas porque usam bibliotecas LGPL'd.

Por que os projetos escolhem LGPL:

  • Adoção da biblioteca: Incentiva o uso em software proprietário enquanto protege a própria biblioteca.
  • Posição de comprometimento: Equilibra a abertura com a viabilidade comercial.
  • Adequação da biblioteca padrão: Apropriado para bibliotecas concebidas como componentes padrão.

Projetos populares licenciados por LGPL: Qt (licença dupla com opção comercial), GTK, GStreamer, muitas bibliotecas C.

Implicações para as organizações:

  • Pode usar em aplicativos proprietários: É seguro usar bibliotecas LGPL'd em aplicativos comerciais.
  • Deve fornecer a origem da biblioteca: Se você modificar a biblioteca LGPL'd, forneça o código-fonte para modificações.
  • Complexidade de vinculação estática: A vinculação estática pode disparar requisitos mais rigorosos; a vinculação dinâmica é mais segura.

Mozilla Public License (MPL) 2.0

O MPL 2.0 fornece copyleft no nível do arquivo:

Termos-chave:

  • Copyleft em nível de arquivo: Os requisitos aplicam-se apenas aos arquivos originalmente sob MPL.
  • Isenção de trabalho maior: Pode combinar arquivos MPL'd com arquivos proprietários no mesmo aplicativo.
  • Divulgação do código-fonte: Deve fornecer o código-fonte para arquivos licenciados sob a MPL.
  • Concessão de patente: Inclui concessão de patente explícita e encerramento defensivo.
  • Compatibilidade de GPL: O MPL 2.0 é compatível com GPL.

Por que os projetos escolhem MPL 2.0:

  • Balanço: Mais fortes que as licenças permissivas, mais flexíveis que a GPL.
  • Uso comercial: Habilita o uso comercial ao proteger o componente de software livre.
  • Acompanhamento de arquivos: O copyleft no nível do arquivo facilita o acompanhamento da conformidade.

Projetos populares licenciados por MPL: Firefox, Thunderbird, LibreOffice.

Implicações para as organizações:

  • Pode se misturar com o código proprietário: Integração mais fácil com software proprietário do que GPL.
  • Acompanhamento no nível do arquivo: Deve manter limites claros entre arquivos sob licença MPL e arquivos proprietários.
  • Modificações compartilhadas: As alterações nos arquivos MPL'd devem ser compartilhadas, mas as adições em arquivos separados não.

Compatibilidade de licença

Licenças diferentes têm regras de compatibilidade diferentes:

Combinações compatíveis

  • MIT + Apache 2.0: Compatível — pode combinar no mesmo projeto.
  • MIT + GPL v3: Compatível — pode incorporar código licenciado pelo MIT em projetos gpl v3.
  • Apache 2.0 + GPL v3: Compatível — a GPL v3 pode incorporar o código do Apache 2.0.
  • LGPL + GPL: Compatível — pode atualizar LGPL para GPL.

Combinações incompatíveis

  • GPL v2 + Apache 2.0: Incompatível — não pode combinar no mesmo trabalho.
  • GPL + Proprietário: Incompatível – a GPL requer que os trabalhos derivados sejam licenciados sob a GPL.
  • Licenças copyleft diferentes: Geralmente incompatível— geralmente não é possível combinar código GPL, AGPL e LGPL com diferentes licenças copyleft de maneiras que satisfaçam ambos.

Considerações de compatibilidade

Ao selecionar dependências:

  • Inventário de licenças: Conheça licenças para todas as dependências.
  • Verificação de compatibilidade: Verifique se as licenças de componentes diferentes são compatíveis.
  • Revisão legal: Casos complexos exigem experiência jurídica para avaliar a compatibilidade.

Estratégias de licenciamento duplo

Alguns projetos oferecem várias opções de licenciamento:

Software livre + Comercial

  • Estratégia: Oferecer sob GPL (copyleft) ou licença comercial.
  • Lógica: Empresas que desejam incorporar software proprietário compram licença comercial; a comunidade de software livre usa a versão GPL.
  • Exemplos: Qt, MySQL, MongoDB (abordagem alterada).

Várias licenças de software livre

  • Estratégia: Permitir que os usuários escolham entre várias licenças compatíveis.
  • Lógica: Maximizar a compatibilidade com projetos diferentes.
  • Exemplos: Algumas bibliotecas oferecem opções de licenciamento do Apache 2.0 ou MIT.

Entender licenças comuns de software livre, seus termos e sua compatibilidade ajuda as organizações a tomar decisões informadas sobre quais componentes de software livre usar e como estruturar seus softwares para manter a conformidade com a licença. A próxima unidade explora implicações de licença e classificações que ajudam a avaliar riscos e tomar decisões.