O que esta verificação lhe consegue e não consegue dizer

Responde a uma pergunta específica: este URL público mostra sinais óbvios de divulgação de licenças de terceiros, ou lacunas óbvias? Ajuda equipas que nunca auditaram o seu site de marketing a encontrar ligações em falta, redirecionamentos para a página inicial ou páginas de licenças vazias.

Para fornecedores de SaaS, o site de marketing é muitas vezes o primeiro sítio onde os compradores olham antes de pedirem a verdadeira página de conformidade de licenças do produto lançado.

• Respostas HTTP em caminhos comuns de licenças e avisos (/license, /legal, /oss, etc.).
• Se essas páginas contêm texto plausível de licença ou de aviso de terceiros, e não estão vazias.
• Alguns URLs de scripts de terceiros visíveis no HTML da página inicial.
• Redirecionamentos óbvios que enviam caminhos de licenças para páginas sem relação.
• Ligações em falta: sem rodapé de licenças, sem menção a open source, sem URL de conformidade no mapa do site.

Não consegue ver o que não está na página pública: a conformidade de licenças de um produto lançado está nos inputs do build (lockfiles, SBOMs, pacotes de lançamento), não na sua página inicial. Uma verificação limpa não significa que a sua aplicação móvel, instalador desktop ou backend de API estejam documentados.

A verificação não lê dependências transitivas de npm, não verifica identificadores SPDX, não confirma o texto integral de licença de cada componente, nem sabe se um humano aprovou a publicação. Essa lacuna é grande: o relatório OSSRA 2025 da Black Duck indica que as dependências transitivas causaram quase 30% dos conflitos de licenças encontrados, e nenhum deles é visível a partir de uma página inicial. Não consegue substituir a divulgação de licenças de terceiros associada ao que é lançado.

• Dependências incluídas em produtos iOS, Android, desktop ou incorporados, fora da web pública.
• Pacotes transitivos nunca carregados em JavaScript visível no navegador.
• Se as licenças listadas correspondem ao que realmente é lançado no produto em análise.
• Estado de revisão e aprovação de publicação: portões, validações, registo de auditoria.
• Conformidade de copyleft: ofertas de código-fonte, código-fonte correspondente, gatilhos de distribuição.
• Tipos de letra, SDKs e ícones não referenciados no URL verificado.
• Componentes apenas internos ou modelos de entrega air-gapped.

A verificação é um teaser que encontra lacunas visíveis num único URL público; uma página de conformidade de licenças é o registo operacional: inventário revisto, texto integral de licença, atribuição, um URL estável para as compras, e exportações alinhadas com os lançamentos.

As equipas passam numa verificação de superfície ao adicionar uma ligação no rodapé para uma página de aviso pouco detalhada. As equipas passam na diligência enterprise ao manter documentação de conformidade de licenças por produto, atualizada sempre que as dependências mudam.

Se a verificação encontrar lacunas, encare isso como um estímulo, não um fracasso. Construa o inventário a partir de lockfiles ou SBOMs para o que realmente lança. Reveja as licenças. Publique divulgação mantida que possa partilhar em qualquer formato que a diligência peça.

Se a verificação parecer limpa, pergunte na mesma se a página visível cobre o produto em contrato. Os rodapés de licenças do site de marketing e as páginas de conformidade de licenças do produto são muitas vezes artefactos diferentes. Pode ser necessário ter ambos; só um satisfaz um pedido de divulgação de licenças de terceiros sobre o produto lançado.