Explore licenças comuns de código aberto

  • 8 minutos

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

O espectro de licenças

As licenças de código aberto existem num espectro que vai de altamente permissivo a fortemente copyleft:

Captura de ecrã do espectro de licenças.

Licenças de atribuição permissiva

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

  • Caraterísticas: Permite o uso de código em software proprietário sem exigir que o software proprietário seja de código aberto.
  • Requisito principal: Atribuição — preserve os avisos de direitos autorais e o texto da licença.
  • Uso comercial: Totalmente compatível com a construção e venda de software comercial proprietário.
  • Liberdade a jusante: Os usuários podem escolher se querem trabalhos derivados de código aberto.

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

Licenças Copyleft

No lado direito do espectro estão licenças copyleft com fortes requisitos recíprocos:

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

Exemplos: Licença Pública Geral GNU (GPL v2 e v3), Licença Pública Geral GNU Affero (AGPL).

Licenças copyleft fracas

No meio do espectro estão licenças copyleft fracas que equilibram entre a abertura e a viabilidade comercial.

  • Caraterísticas: Exigir que as modificações no componente licenciado sejam de código aberto, mas permitir a incorporação do componente em trabalhos proprietários maiores.
  • Compatível com bibliotecas: Projetado para bibliotecas que podem ser usadas em aplicativos proprietários.
  • Copyleft no nível do arquivo ou no nível do módulo: Os requisitos aplicam-se ao componente licenciado em si, não a todo o aplicativo.
  • Equilíbrio prático: Habilite o uso comercial e, ao mesmo tempo, garanta que as melhorias no componente permaneçam de código aberto.

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 MIT é uma das licenças de código aberto mais simples e permissivas:

Palavras-chave:

  • Permissões: Usar, copiar, modificar, fundir, publicar, distribuir, sublicenciar e vender o software.
  • Condições: Inclua o aviso de direitos autorais e o texto da 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 de licença curto 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 na forma 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 exigida: Deve preservar os avisos de direitos autorais — normalmente satisfeitos com a inclusão de texto de licença na documentação do aplicativo ou nas caixas de diálogo Sobre.
  • Não concessão de patente: A Licença MIT não aborda explicitamente as patentes, criando ambiguidade potencial.

Apache Licença 2.0

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

Palavras-chave:

  • Permissões: Usar, reproduzir, preparar trabalhos derivados, exibir, executar, sublicenciar e distribuir.
  • Condições: Incluir aviso de direitos autorais, texto de licença e aviso de modificações; preservar os avisos de patentes; fornecer atribuição.
  • Concessão de patentes: Concessão explícita de direitos de patente por parte dos contribuidores.
  • Retaliação de patentes: As concessões de patentes cessam se o licenciado iniciar um litígio em matéria de patentes contra os contribuidores.
  • Limitações: Sem garantia, sem responsabilidade, sem direitos de marca comercial.

Por que os projetos escolhem o Apache 2.0:

  • Clareza das patentes: A concessão explícita de patentes proporciona segurança jurídica.
  • Transparência da modificação: A obrigatoriedade de documentar modificações promove a transparência.
  • Confiança corporativa: Termos claros e proteções de patentes deixam as empresas confortáveis em 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 por patente: A concessão explícita de patentes reduz o risco de litígios em matéria de patentes por parte dos contribuidores.
  • 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.
  • Rescisão defensiva: As concessões de patentes terminam se você processar os contribuintes por violação de patente, incentivando a coexistência pacífica.

Licenças BSD (cláusula 2 e cláusula 3)

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

BSD de 2 Cláusulas (Simplificado BSD):

  • Permissões: Redistribuição e utilização nas formas fonte e binária, 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.

BSD 3-Cláusula (BSD modificado):

  • Condição adicional: Não pode usar os nomes dos detentores de direitos autorais para endossar produtos derivados sem permissão.
  • Proteção de marca: Evita que implique o endosso dos autores originais.

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

Implicações para as organizações:

  • Semelhantes ao MIT: Restrições mínimas, comerciais amigáveis.
  • Restrição de uso de nome: 3-Cláusula BSD impede o uso de nomes de projetos para marketing sem permissão.
  • Bem estabelecido: Longa história em software acadêmico e comercial.

Licenças copyleft comuns

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

A GNU General Public License é a licença copyleft mais conhecida:

Termos chave GPL v2:

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

Aprimoramentos da GPL v3:

  • Proteção por patente: Concessões explícitas de patentes semelhantes ao Apache 2.0.
  • Prevenção de Tivoização: Impede que restrições de hardware sejam usadas para evitar que os utilizadores executem software modificado.
  • Compatibilidade internacional: Maior clareza jurídica para as jurisdições internacionais.
  • Compatibilidade com Apache 2.0: Pode combinar o código GPL v3 com o código Apache 2.0.

Por que os projetos escolhem a GPL:

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

Projetos populares licenciados pela 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 sob GPL quando distribuídos.
  • Preocupações de ligação: A vinculação de código proprietário com bibliotecas GPL pode acionar 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: A GPL v2 e v3 não exigem a divulgação do código-fonte para software como serviço, a menos que a AGPL seja usada.

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

A AGPL estende a GPL v3 com uma provisão de uso de rede:

Requisito adicional da AGPL:

  • Copyleft de rede: Se modificares o software da AGPL e os utilizadores interagirem com ele através de uma rede (SaaS), deverás fornecer o código-fonte a esses utilizadores.
  • Fechando a lacuna do ASP: Impede que as empresas modifiquem o software e o ofereçam como um serviço sem compartilhar modificações.

Por que os projetos escolhem a AGPL:

  • Proteção SaaS: Garante que os serviços na nuvem não podem usar software de código aberto sem contribuir de volta.
  • Copyleft mais forte: Máxima proteção contra utilização proprietária.

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

Implicações para as organizações:

  • Evite para SaaS: A maioria das organizações evita software licenciado pela AGPL para ofertas de serviços porque requer modificações de fonte aberta.
  • Uso interno: Pode usar internamente sem acionar requisitos se não estiver exposto aos usuários em uma rede.
  • Avaliação dos riscos: Avalie cuidadosamente se o software se qualifica como "interação através de uma rede".

Licenças copyleft fracas comuns

GNU Licença Pública Geral Menor (LGPL)

A LGPL permite vincular a bibliotecas sem acionar todos os requisitos da GPL:

Palavras-chave:

  • Utilização da biblioteca: Pode ligar-se a bibliotecas licenciadas pela LGPL a partir de software proprietário sem ter de tornar open source a aplicação proprietária.
  • Modificações na biblioteca: As modificações na própria biblioteca da LGPL devem ser de código aberto.
  • Ligação dinâmica: A LGPL permite explicitamente a ligação dinâmica com 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 a LGPL:

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

Projetos populares licenciados pela LGPL: Qt (dual-licenciado com opção comercial), GTK, GStreamer, muitas bibliotecas C.

Implicações para as organizações:

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

Licença Pública Mozilla (MPL) 2.0

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

Palavras-chave:

  • Copyleft no nível de arquivo: Os requisitos aplicam-se apenas aos ficheiros originalmente sob MPL.
  • Maior isenção de trabalho: Pode combinar arquivos MPL'd com arquivos proprietários no mesmo aplicativo.
  • Divulgação do código-fonte: Devem fornecer o código-fonte para arquivos sob licenciamento MPL.
  • Concessão de patentes: Inclui concessão explícita de patentes e rescisão defensiva.
  • Compatibilidade com GPL: MPL 2.0 é compatível com GPL.

Por que os projetos escolhem o MPL 2.0:

  • Saldo: Mais forte do que as licenças permissivas, mais flexível do que a GPL.
  • Uso comercial: Permite o uso comercial enquanto protege o componente de código aberto.
  • Rastreamento de arquivos: O copyleft ao nível de ficheiro facilita o rastreamento da conformidade.

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

Implicações para as organizações:

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

Compatibilidade de licenças

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

Combinações compatíveis

  • MIT + Apache 2.0: Compatível — pode ser combinado 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 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 ser combinado no mesmo trabalho.
  • GPL + Proprietário: Incompatível—A GPL requer que os trabalhos derivados sejam sob GPL.
  • Diferentes licenças copyleft: Geralmente incompatíveis — não se pode geralmente combinar o código GPL, AGPL e LGPL com outras licenças copyleft de formas que satisfaçam as condições de todas.

Considerações de compatibilidade

Ao selecionar dependências:

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

Estratégias de licenciamento duplo

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

Código aberto + Comercial

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

Várias licenças de código aberto

  • Estratégia: Permita que os usuários escolham entre várias licenças compatíveis.
  • Justificação: Maximize a compatibilidade com diferentes projetos.
  • Exemplos: Algumas bibliotecas oferecem opções de licenciamento Apache 2.0 ou MIT.

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