Lista de verificação de conformidade de licenças: o que verificar antes de partilhar prova

Uma página forte identifica o produto lançado, lista os componentes de terceiros com licenças revistas, inclui o texto integral de licença ou ligações fiáveis, e mostra atribuição onde as licenças a exigem. As compras e os auditores esperam mais do que uma lista de pacotes npm.

Se a sua página só disser “usamos open source”, sem inventário, texto de licença ou um âmbito claro, não vai satisfazer um pedido de divulgação de licenças de terceiros. Isto aplica-se mesmo quando a engenharia passou numa revisão de segurança interna.

A necessidade é generalizada: o relatório Open Source Security and Risk Analysis 2025 da Black Duck concluiu que 97% das bases de código auditadas continham open source, pelo que quase todos os produtos têm obrigações de terceiros, estejam ou não documentadas.

• Nome e versão do produto (ou canal de lançamento) que a página cobre.
• Inventário de componentes de terceiros e open source, diretos e transitivos, onde o seu processo o exigir.
• Identificadores de licença em estilo SPDX ou equivalente, após revisão humana, não apenas suposições do registo.
• Texto integral de licença para cada componente, ou ligações estáveis que resolvam para o texto integral.
• Blocos de atribuição e aviso onde a MIT, Apache, BSD, GPL, ou licenças personalizadas os exigirem.
• Rotulagem clara se a página é de exemplo, beta, ou produção, quando relevante.

A conformidade de licenças começa com o inventário: todos os componentes na sua página de conformidade devem corresponder ao build atualmente lançado, não a uma branch de desenvolvimento, não a staging, não a uma linha de produto que ainda não está a vender.

As equipas muitas vezes esquecem tipos de letra, pacotes de ícones, SDKs de analytics, JavaScript incorporado em sites de marketing, e dependências transitivas trazidas por uma única importação direta. A conformidade falha silenciosamente quando o inventário está incompleto. O relatório OSSRA 2025 da Black Duck indica que as dependências transitivas causaram quase 30% dos conflitos de licenças encontrados, pelo que uma lista de verificação que se limita às importações diretas perde uma grande parte do risco.

• Todos os componentes na página correspondem ao build que os clientes recebem hoje.
• As dependências transitivas de npm, pnpm, yarn, Go, Rust, Python, Java, .NET, PHP, ou Ruby estão incluídas, conforme a sua política.
• Tipos de letra, ícones, imagens com termos de licença, e SDKs comerciais não são ignorados.
• As camadas base de contentores e as bibliotecas nativas incluídas estão no âmbito, se as distribuir.
• Os itens marcados como desconhecidos ou por rever são resolvidos ou explicitamente excluídos, com motivo documentado.
• A origem do inventário (lockfile, SBOM CycloneDX, entrada manual) é rastreável até ao lançamento.

Exige que os revisores consigam ler a licença real, não um resumo: divulgação de licenças de terceiros significa texto integral de licença por componente. As compras e o jurídico comparam a sua página com as obrigações da GPL, LGPL, Apache, MIT, e acordos de SDK proprietários.

A atribuição é separada do aviso e separada do texto integral de licença. Uma página que liste “MIT” sem o texto da licença MIT ou o aviso de direitos de autor exigido está incompleta para a maioria das revisões enterprise.

• Cada componente tem uma licença identificada, revista por um humano, não copiada cegamente dos metadados do pacote.
• O texto integral de licença está presente na página, ou ligado sem barreiras de início de sessão ou URLs com expiração.
• Os componentes copyleft (GPL, AGPL, LGPL, etc.) passaram pelos seus portões de revisão interna.
• A redação de atribuição corresponde ao que cada licença exige, não um rodapé genérico de “licenças open source”.
• Os componentes de dupla licença ou personalizados têm uma decisão explícita registada.
• Nenhum componente é publicado como aprovado até o texto de licença estar anexado ou ligado.

Uma página de conformidade de licenças é um registo vivo. O URL que as compras guardaram no seu ficheiro de fornecedores deve continuar exato depois do seu próximo lançamento. A conformidade quebra-se quando a página se desvia do que é lançado.

Os portões de publicação (revisão antes de publicar) impedem as equipas de reivindicar conformidade que não verificaram. As exportações (JSON, ficheiros de atribuição, pacotes de divulgação) devem corresponder ao mesmo inventário revisto do URL público.

• Um responsável identificado aprovou a publicação para este produto e lançamento.
• O URL da página de conformidade é estável, público, e acessível sem autenticação.
• As exportações e os pacotes de lançamento correspondem ao inventário publicado.
• As verificações de deriva ou de pipeline sinalizam novos pacotes antes da próxima auditoria do cliente.
• Tem um processo documentado para atualizar a página de licenças quando as dependências mudam.
• Não dá a entender aprovação jurídica, a menos que o seu advogado tenha revisto. A página é um registo operacional.

Abra a página de conformidade de licenças numa janela anónima. Confirme que carrega, identifique o produto, e verifique por amostragem cinco componentes aleatórios em relação ao seu inventário interno. Se as compras pedirem prova, é isto que vão fazer.

Quando a lista de verificação for cumprida, envie o formato que pediram (URL, exportação ou anexo) a partir do mesmo snapshot de publicação revisto. Identifique o produto e o lançamento ou data que reflete. O tipo de ficheiro importa menos do que saber se o inventário foi revisto e aprovado antes de o enviar.

Não. Uma lista de verificação de SBOM confirma a identidade dos componentes num formato legível por máquina. Uma de conformidade de licenças confirma licenças revistas, texto completo, atribuição e um estado de publicação que estão dispostos a partilhar. Muitas vezes precisam de ambas, nessa ordem.

Voltem a executá-la antes de qualquer partilha externa, e de novo sempre que as dependências mudem numa branch de release vigiada. O desvio entre a última publicação aprovada e o lockfile atual é o modo de falha habitual.

Escolham um dono responsável por produto, normalmente engineering com revisão jurídica em licenças de alto risco. Propriedade partilhada sem um gate de publicação é como URL desatualizados acabam em ficheiros de fornecedores.