Examinar as implicações e classificações da licença

  • 9 minutos

Compreender os termos de licença é apenas o primeiro passo — as organizações devem avaliar como as licenças afetam seus modelos de negócios específicos, práticas de desenvolvimento e estratégias de distribuição de produtos. As implicações da licença determinam se os componentes de código aberto são adequados para casos de uso específicos e quais obrigações as organizações devem cumprir.

Implicações da licença para software comercial

Diferentes tipos de licença têm implicações dramaticamente diferentes para o desenvolvimento de software comercial:

Implicações permissivas da licença

Software usando componentes licenciados permissivos (MIT, Apache 2.0, BSD):

Restrições mínimas:

  • Distribuição proprietária: Pode incorporar componentes em software proprietário sem abrir o seu código.
  • Produtos comerciais: Pode construir e vender produtos comerciais que incorporam componentes licenciados permissivamente.
  • Distribuição fechada: Nenhum requisito para fornecer código-fonte aos clientes.
  • Sublicenciamento: Normalmente, pode distribuir sob seus próprios termos de licença.

Obrigação principal:

  • Atribuição: Deve preservar avisos de direitos autorais e texto de licença, geralmente satisfeitos pela inclusão de avisos na documentação, caixas de diálogo Sobre ou arquivos de agregação de licença.

Considerações sobre patentes:

  • MIT e BSD: Não inclua concessões explícitas de patentes, criando ambiguidade potencial sobre os direitos de patente.
  • Apache 2.0: Inclui concessão explícita de patentes, proporcionando proteção mais clara e rescisão defensiva para litígios de patentes.

Implicações para as empresas:

  • Escolha segura: As licenças permissivas representam um risco mínimo para os produtos comerciais.
  • Conformidade simples: Os requisitos de atribuição são simples de cumprir.
  • Máxima flexibilidade: Habilite qualquer modelo de negócios, incluindo vendas de software proprietário.

Implicações fracas da licença copyleft

Software usando componentes de copyleft leve (LGPL, MPL):

Uso da biblioteca permitido:

  • Aplicações proprietárias: Pode usar bibliotecas copyleft fracas em aplicativos proprietários.
  • Ligação permitida: Pode vincular código proprietário com bibliotecas copyleft fracas (especialmente através de vinculação dinâmica).
  • Sem copyleft completo: O uso de bibliotecas não aciona o requisito de código aberto de todo o aplicativo.

Requisitos de modificação:

  • As modificações da biblioteca devem ser compartilhadas: Se você modificar o componente copyleft fraco em si, essas modificações deverão ser de código aberto.
  • Rastreamento no nível de arquivo (MPL): Para MPL, os requisitos se aplicam no nível do arquivo, tornando os limites mais claros.
  • Trabalhos derivados: A criação de trabalhos derivados da biblioteca aciona requisitos de código aberto.

Considerações sobre conformidade:

  • Disposição do código-fonte: Deve fornecer código-fonte para a biblioteca copyleft fraca (incluindo quaisquer modificações).
  • Preservação da licença: Deve manter os termos de licença para a biblioteca.
  • Separação clara: Mantenha limites claros entre o código da biblioteca e o código proprietário.

Implicações para as empresas:

  • Geralmente aceitável: A maioria das empresas pode utilizar bibliotecas de copyleft fracas em seus produtos proprietários.
  • Encargos com a modificação: A modificação de bibliotecas cria obrigações de conformidade contínuas.
  • Preocupações com ligações estáticas: A ligação estática pode criar requisitos mais rigorosos; Prefira a vinculação dinâmica.

Fortes implicações da licença copyleft

Software usando componentes copyleft fortes (GPL, AGPL):

Propagação copyleft:

  • Trabalhos derivados: Criar trabalhos derivados ou combinar código com o software da GPL aciona os requisitos de copyleft.
  • Toda a aplicação: A GPL normalmente se aplica a todo o aplicativo, não apenas ao componente GPL'd.
  • Requisito do código-fonte: Deve fornecer código-fonte completo ao distribuir binários.
  • Mesma licença: Os trabalhos derivados devem ser distribuídos sob GPL.

Gatilhos de distribuição:

  • Distribuição binária: A distribuição de binários executáveis requer o fornecimento de código-fonte.
  • Utilização da rede (AGPL): Para a AGPL, a simples disponibilização de software através de uma rede desencadeia requisitos.
  • Uso interno: Usar o software da GPL internamente sem distribuição não aciona requisitos.

Preocupações de integração:

  • Ligação estática: Cria claramente trabalho derivado que requer conformidade com GPL.
  • Ligação dinâmica: A interpretação jurídica varia – alguns consideram-na segura, outros acreditam que cria trabalho derivado.
  • Separação de processos: A execução do software GPL como processo separado (microsserviços) pode evitar o status de trabalho derivado.

Implicações para as empresas:

  • Incompatível com software proprietário: Não é possível incorporar componentes GPL em software proprietário que você distribui.
  • pt-PT: Produtos de código aberto: Pode usar a GPL para produtos que está disposto a tornar de código aberto.
  • Exceção SaaS: A GPL v2 e v3 não exigem divulgação de fonte para ofertas de SaaS (a AGPL exige).
  • Alto risco: A GPL apresenta um risco significativo para o software proprietário comercial.

Classificações de risco de licença

As organizações geralmente classificam as licenças com base no risco que representam para o desenvolvimento de software comercial:

Quadro de classificação de risco

Baixo risco (Verde):

  • Licenças: MIT, BSD, Apache 2.0, ISC, outras licenças permissivas.
  • Caraterísticas: Restrições mínimas, principalmente requisitos de atribuição.
  • Casos de uso: Seguro para qualquer uso comercial, incluindo software proprietário.
  • Encargos em matéria de conformidade: Baixo — principalmente a manutenção de avisos de atribuição.

Médio risco (Amarelo):

  • Licenças: LGPL, MPL, EPL, outras licenças copyleft fracas.
  • Caraterísticas: Permitir o uso em software proprietário com restrições de modificações.
  • Casos de uso: Aceitável para o uso de bibliotecas não modificadas; Cuidado necessário ao modificar.
  • Encargos em matéria de conformidade: Moderado — deve rastrear a origem da biblioteca e fornecê-la mediante solicitação.

Alto risco (Vermelho):

  • Licenças: GPL v2, GPL v3, AGPL, outras licenças copyleft fortes.
  • Caraterísticas: Exigem trabalhos derivados de fonte aberta e aplicações combinadas.
  • Casos de uso: Incompatível com a distribuição de software proprietário; aceitável para projetos de código aberto.
  • Encargos em matéria de conformidade: Alto — deve fornecer código-fonte completo para todo o aplicativo.

Risco desconhecido (laranja):

  • Licenças: Licenças personalizadas, licenciamento pouco claro, informações de licença ausentes, licenças obsoletas.
  • Caraterísticas: Termos pouco claros, compatibilidade incerta, revisão legal necessária.
  • Casos de uso: Evite até que a revisão legal esclareça termos e implicações.
  • Encargos em matéria de conformidade: Desconhecido até que os termos da licença sejam esclarecidos.

Fatores que afetam a avaliação dos riscos

Modelo de negócio:

  • Produtos de código aberto: A GPL é um risco aceitável.
  • Software proprietário: A GPL é um risco inaceitável.
  • Ofertas de SaaS: GPL v2/v3 aceitável, AGPL inaceitável.
  • Ferramentas internas: Todas as licenças normalmente aceitáveis, uma vez que não há distribuição.

Método de distribuição:

  • Distribuição binária: Aciona os requisitos da GPL.
  • Implantação de SaaS: Desencadeia os requisitos da AGPL.
  • Apenas para uso interno: Não aciona a maioria dos requisitos.
  • Disponibilização da biblioteca: Aciona os requisitos LGPL/MPL.

Extensão da modificação:

  • Componentes não modificados: Menor carga de conformidade.
  • Componentes modificados: Aumenta as obrigações, especialmente para copyleft.
  • Integração profunda: Torna a conformidade mais complexa.

Enquadramento jurídico:

  • Diferenças jurisdicionais: A interpretação da licença varia de acordo com o país/região.
  • Histórico de execução: Algumas licenças têm um precedente de aplicação mais forte.
  • Considerações sobre patentes: As cláusulas de patente interagem com as estratégias organizacionais de patentes.

Considerações em matéria de propriedade intelectual

As opções de licença afetam a propriedade intelectual organizacional:

Proteção IP proprietária

Licenças permissivas:

  • IP preservado: Seu código proprietário permanece proprietário.
  • Segredos comerciais protegidos: Não há obrigação de divulgar detalhes da implementação.
  • Vantagem competitiva mantida: Não precisa compartilhar inovações com os concorrentes.

Licenças copyleft fortes:

  • Divulgação de IP necessária: A GPL requer trabalhos derivados de fonte aberta, potencialmente expondo algoritmos proprietários, lógica de negócios e inovações.
  • Segredos comerciais perdidos: A divulgação do código-fonte elimina a proteção contra segredos comerciais.
  • Vantagem competitiva reduzida: Os concorrentes podem usar as suas inovações.

Considerações sobre patentes

Concessão de patentes:

  • Apache 2.0: Inclui concessão explícita de patente que fornece direitos claros e rescisão defensiva.
  • GPL v3: Inclui disposições de concessão de patentes e anti-tivoização.
  • MIT/BSD: Não existem disposições explícitas em matéria de patentes, o que cria uma potencial ambiguidade.

Rescisão defensiva de patente:

  • Apache 2.0 e GPL v3: As concessões de patentes terminam se o licenciado processar os contribuidores por violação de patente.
  • Implicações estratégicas: Organizações com estratégias agressivas de patentes podem enfrentar complicações.

Agrupamentos de patentes:

  • Algumas licenças integram-se com pools de patentes: As licenças podem interagir com acordos de patentes da indústria.

Implementação de conformidade

A implementação bem-sucedida de software de código aberto requer processos de conformidade sistemáticos:

Inventário de dependência

Acompanhamento abrangente:

  • Lista de materiais: Mantenha um inventário completo de todos os componentes de código aberto.
  • Dependências transitivas: Rastreie não apenas dependências diretas, mas dependências de dependências.
  • Acompanhamento da versão: Registre versões específicas, pois as licenças às vezes mudam entre versões.
  • Monitorização de atualizações: Monitorize continuamente as atualizações das dependências e das suas licenças.

Ferramentas automatizadas:

  • Gerenciadores de pacotes: npm, pip, Maven rastreiam automaticamente dependências diretas.
  • Ferramentas SBOM: As ferramentas de lista de materiais de software geram inventários de dependência abrangentes.
  • Scanners de licença: Ferramentas como FOSSA, WhiteSource, Black Duck identificam licenças em árvores de dependência.

Verificação de compatibilidade de licenças

Verificação de compatibilidade:

  • Varredura automatizada: As ferramentas identificam automaticamente incompatibilidades de licença.
  • Revisão legal: Casos complexos exigem perícia jurídica para avaliar a compatibilidade.
  • Fluxos de trabalho de aprovação: Estabeleça processos para revisar novas dependências antes do uso.

Incompatibilidades comuns:

  • GPL + Apache 2.0 (GPL v2): Incompatível — não pode combinar.
  • GPL + Proprietário: Incompatível com software distribuído.
  • Várias licenças copyleft: Geralmente são incompatíveis entre si.

Cumprimento de Requisitos de Atribuição

Cumprimento dos requisitos de atribuição:

  • Agregação de licenças: Colete todos os textos de licença em um único arquivo (geralmente LICENSES.txt ou THIRD_PARTY_NOTICES).
  • Sobre as caixas de diálogo: Inclua atribuições no aplicativo Sobre caixas de diálogo ou configurações.
  • Documentação: Inclua informações de licença na documentação do produto.
  • Geração automatizada: Use ferramentas para gerar automaticamente arquivos de atribuição a partir de dados de dependência.

Fornecimento do código-fonte

Para licenças copyleft:

  • Acesso à fonte: Fornecer código-fonte completo para componentes GPL e trabalhos derivados.
  • Mesmo meio: Historicamente, era necessário fornecer a fonte no mesmo meio que os ficheiros binários; o download pela internet é agora aceitável.
  • Oferta escrita: Pode oferecer-se para fornecer código-fonte em vez de agrupá-lo.
  • Instruções de compilação: Inclua instruções de compilação para que os usuários possam reconstruir a partir do código-fonte.

Segurança da cadeia de valor de software

A conformidade e a segurança da licença são preocupações interligadas:

Gestão de vulnerabilidades

Segurança é igual ao componente mais fraco:

  • Dependência da cadeia: A segurança do aplicativo depende de cada componente na árvore de dependência.
  • Propagação de vulnerabilidades: A vulnerabilidade em qualquer dependência afeta todos os aplicativos que a utilizam.
  • Urgência de atualização: As vulnerabilidades de segurança exigem atualizações rápidas em todos os aplicativos afetados.

Análise de vulnerabilidades:

  • Deteção automatizada: Ferramentas como Snyk, Dependabot, WhiteSource verificam dependências em busca de vulnerabilidades conhecidas.
  • Monitorização de CVE: Rastreie identificadores de vulnerabilidades e exposições comuns para dependências.
  • Pontuação CVSS: Use o Sistema Comum de Pontuação de Vulnerabilidades para priorizar a correção.
  • Resposta rápida: Estabeleça processos para atualizar rapidamente as dependências quando vulnerabilidades críticas forem divulgadas.

Ataques à cadeia de abastecimento

Mitigação de riscos:

  • Verificação do pacote: Verifique as assinaturas de pacotes e as somas de verificação.
  • Reputação da fonte: Prefira pacotes com manutenção ativa, grandes bases de usuários e mantenedores respeitáveis.
  • Registos privados: Espelhe pacotes públicos em registros privados para controlar o que os desenvolvedores usam.
  • Bloqueio de dependências: Bloqueie versões específicas para impedir atualizações automáticas para versões comprometidas.

Avaliação da qualidade dos componentes

Indicadores de qualidade:

  • Manutenção ativa: Atualizações regulares indicam projeto mantido.
  • Tamanho da comunidade: Grandes comunidades proporcionam melhor sustentabilidade.
  • Qualidade da documentação: Uma boa documentação sugere uma manutenção profissional.
  • Cobertura do teste: Testes automatizados indicam foco na qualidade.
  • Práticas de segurança: Processos de divulgação responsáveis e avisos de segurança demonstram compromisso com a segurança.

Políticas organizacionais

Um gerenciamento de código aberto eficaz requer políticas organizacionais claras:

Fluxos de trabalho de aprovação

Avaliação pré-utilização:

  • Revisão de segurança: Analise vulnerabilidades conhecidas antes da aprovação.
  • Revisão da licença: Verifique a compatibilidade da licença com o uso pretendido.
  • Avaliação da qualidade: Avalie a qualidade do código, o status de manutenção e a integridade da comunidade.
  • Análise alternativa: Considere se existem alternativas aprovadas.

Listas de pacotes aprovados:

  • Componentes pré-aprovados: Manter listas de pacotes aprovados para necessidades comuns.
  • Adoção mais rápida: Os desenvolvedores podem usar pacotes aprovados imediatamente.
  • Reavaliação periódica: Revise regularmente os pacotes aprovados quanto ao status de segurança e manutenção.

Formação de programadores

Programas de formação:

  • Reconhecimento de licença: Eduque os desenvolvedores sobre tipos de licença e implicações.
  • Práticas de segurança: Treine na avaliação da segurança dos componentes.
  • Processos de conformidade: Explicar como solicitar aprovação para novas dependências.
  • Sensibilização para os riscos: Ajude os desenvolvedores a entender as preocupações organizacionais.

Monitorização contínua

Conformidade contínua:

  • Atualizações de dependência: Monitore novas versões e patches de segurança.
  • Alterações de licença: Acompanhe quando os projetos alteram licenças.
  • Divulgação de vulnerabilidade: Assine os avisos de segurança para dependências.
  • Auditorias de conformidade: Audite periodicamente os aplicativos para conformidade com licenças.

Compreender as implicações da licença e implementar processos de conformidade sistemáticos permite que as organizações aproveitem os benefícios de código aberto enquanto gerenciam os riscos de forma eficaz. A próxima unidade fornece um resumo dos principais conceitos abordados neste módulo.