O risco de licenças de código aberto é o risco jurídico e comercial decorrente de software que incorpora componentes de código aberto sob licenças cujos termos (obrigações de copyleft, exigências de atribuição, cláusulas de extinção por patente e restrições de uso comercial) podem não ser compatíveis com a forma como a empresa implanta o software ou podem impor ao código proprietário do fornecedor obrigações que o fornecedor não divulgou. A adoção do SBOM aumentou a visibilidade sobre quais componentes de código aberto estão incluídos no software dos fornecedores. A gestão do risco de licenças exige entender não apenas quais componentes estão presentes, mas quais obrigações suas licenças impõem no contexto específico de implantação.
O espectro do copyleft é a estrutura conceitual. As licenças de código aberto vão das permissivas (MIT, Apache 2.0, BSD), que impõem obrigações mínimas (normalmente apenas a atribuição), às de copyleft forte (GPL-3.0, AGPL-3.0), que exigem que todo software que incorpore componentes licenciados sob copyleft seja distribuído sob a mesma licença copyleft. A AGPL-3.0 é a variante de copyleft mais forte porque estende a obrigação de copyleft aos serviços de rede: o software usado por meio de uma rede é considerado distribuído para os fins da AGPL, o que aciona a exigência de divulgação do código-fonte. Para um fornecedor cujo software proprietário inclui componentes licenciados sob AGPL e é entregue como serviço de rede, as disposições de copyleft da AGPL podem exigir a divulgação do código-fonte proprietário.
O problema da compatibilidade de licenças é a dimensão técnica. Diferentes licenças de código aberto são compatíveis ou incompatíveis entre si de maneiras que determinam se um produto de software que combina componentes sob várias licenças é juridicamente coerente. Combinar componentes licenciados sob a GPL-2.0 e a GPL-3.0 em um único binário cria incompatibilidade; a cláusula “ou posterior” da GPL-2.0 resolve isso, mas nem todo software licenciado sob a GPL-2.0 a inclui. Combinar Apache 2.0 e GPL-2.0 cria incompatibilidade porque a Apache 2.0 inclui uma cláusula de extinção por patente que é incompatível com os requisitos da GPL-2.0. A análise de compatibilidade de licenças é uma tarefa jurídica especializada que a maioria das equipes de TPRM não consegue realizar sem assessoria jurídica.
Por que isso importa
O risco de licenças de código aberto é importante para TPRM porque o software que sua empresa implanta pode impor obrigações jurídicas que nem a empresa nem o fornecedor identificaram, obrigações que podem surgir após a implantação, quando as implicações jurídicas de uma combinação de licenças são avaliadas. Essas obrigações podem incluir exigências de divulgação do código-fonte, obrigações de pagamento de royalties e disposições de extinção da licença que afetam o direito da empresa de continuar usando o software.
- Risco de licença não avaliado junto com funcionalidade e segurança
- Componentes AGPL e de copyleft forte não identificados no software do fornecedor
- Contexto de implantação como serviço de rede não considerado na análise de copyleft da AGPL
- Compatibilidade de licenças não avaliada para combinações de componentes
- SBOM usado para segurança, mas não para avaliar a conformidade de licenças
Como é uma boa prática
Programas maduros de risco de licenças incluem informações de licença nas solicitações de SBOM, identificam componentes de copyleft forte e AGPL no software dos fornecedores, avaliam a compatibilidade de licenças nas combinações de componentes e realizam análise jurídica do software que inclui componentes AGPL implantados como serviços de rede.
- Informações de licença no SBOM: licenças de todos os componentes identificadas
- Identificação de componentes copyleft, especialmente AGPL em contexto de serviço de rede
- Análise de compatibilidade de licenças para combinações de componentes
- Análise jurídica de software que contém AGPL e é implantado como serviço de rede
- Divulgação da conformidade de licenças pelo fornecedor como parte da avaliação de segurança do software
Ferramentas
Varredura de licenças: FOSSA, Black Duck, Snyk License Compliance para análise de licenças do SBOM
As ferramentas de varredura de licenças de código aberto podem analisar SBOMs e repositórios de código em busca de informações de licença, identificando componentes copyleft, sinalizando problemas de compatibilidade de licenças e gerando relatórios de conformidade de licenças. FOSSA e Black Duck oferecem análise de risco de licenças em nível corporativo. Para profissionais de TPRM, solicitar os resultados da varredura de licenças junto com os resultados da varredura de vulnerabilidades do SBOM oferece um quadro completo do risco de código aberto.
Desafios de governança
O desafio de governança do risco de licenças de código aberto é a necessidade de conhecimento jurídico. A análise de risco de licenças, em especial a análise de copyleft da AGPL e de compatibilidade de licenças, exige um conhecimento jurídico que a maioria das equipes de TPRM e de segurança não tem. A solução de governança é incluir o risco de licenças na avaliação do software dos fornecedores e encaminhar os componentes copyleft identificados à assessoria jurídica para avaliação das implicações.
- Solicitar informações de licença no SBOM
- Identificar componentes AGPL e de copyleft forte no software do fornecedor
- Encaminhar as constatações sobre AGPL à assessoria jurídica para análise das implicações em serviços de rede
- Incluir a conformidade de licenças no contrato com o fornecedor: garantias do fornecedor quanto às obrigações de licença
- Implementar a varredura de licenças do software entregue pelos fornecedores junto com a varredura de vulnerabilidades
Se você faz parte de uma equipe pequena
Da próxima vez que receber um SBOM de um fornecedor, passe-o pelo plano gratuito do FOSSA ou por uma ferramenta equivalente de varredura de licenças. A varredura leva minutos e produz uma classificação de licença para todos os componentes listados, identificando quaisquer componentes AGPL, GPL ou de outras licenças de copyleft forte. Para qualquer componente AGPL, sinalize para análise jurídica se o software for implantado como serviço de rede. Essa varredura de quinze minutos evita a análise jurídica de seis meses pela qual passou a organização do exemplo inicial.
- Passar o SBOM do fornecedor por uma ferramenta de varredura de licenças
- Identificar componentes AGPL e de copyleft forte
- Sinalizar componentes AGPL para análise jurídica em implantações como serviço de rede
- Incluir garantia de conformidade de licenças nos contratos com fornecedores
O que exigir
Pergunte diretamente:
“Seu software inclui algum componente licenciado sob a AGPL-3.0 ou outras licenças de copyleft forte e vocês concluíram uma análise jurídica de suas obrigações de conformidade de licenças, especificamente quanto à disposição da AGPL sobre serviços de rede, caso seu software seja entregue como serviço?”
O que esperar como evidência
- SBOM com informações de licença de todos os componentes
- Resultados da varredura de licenças que identificam componentes copyleft
- Avaliação de conformidade jurídica para componentes AGPL e de copyleft forte
- Garantia de conformidade de licenças no contrato com o fornecedor
Um fornecedor que entrega um SBOM deve ser solicitado a fornecer informações de licença junto com os dados de vulnerabilidade. As varreduras de vulnerabilidades do SBOM tratam do risco de segurança. As informações de licença tratam do risco jurídico. Ambas são necessárias para uma gestão completa do risco de código aberto.
Como comprovar
- Registros de varredura de licenças do software dos fornecedores
- Identificação de componentes copyleft
- Registros de análise jurídica de componentes AGPL
- Documentação da garantia de conformidade de licenças
Principal conclusão
Plataforma de análise implantada. Componente AGPL: não divulgado, ninguém perguntou. Descoberto: 18 meses depois, pelo jurídico. Possível obrigação da AGPL: divulgação do código-fonte proprietário por implantação como serviço de rede. Análise jurídica: 6 meses. O risco de licença é um risco jurídico que existe desde o primeiro dia da implantação. Componentes AGPL em software entregue como serviço de rede podem acionar obrigações de divulgação do código-fonte que se aplicam ao código proprietário do fornecedor. A varredura de licenças os encontra em minutos. A análise jurídica avalia as implicações. Ambas acontecem antes da implantação, não dezoito meses depois. Um SBOM sem informações de licença é visibilidade de segurança sem visibilidade do risco jurídico.