O que as compras realmente pedem

Porque os produtos não ficam congelados numa versão: os engenheiros integram atualizações de dependências, adicionam SDKs, trocam tipos de letra, e atualizam pacotes transitivos, muitas vezes sem que uma única pessoa acompanhe o quadro completo das obrigações. Não pode dizer com fiabilidade “isto é tudo o que está a correr em produção neste momento” a partir de uma folha de cálculo construída há meses.

Um PDF, ficheiro zip, ou anexo de SBOM é um snapshot. No momento em que alguém lança uma versão com novos pacotes, esse snapshot torna-se histórico. Não errado por má-fé, apenas desatualizado. As compras arquivam-no, presumem que está atualizado, e descobrem a lacuna meses depois, numa auditoria ou renovação.

O requisito real não é “enviar um URL em vez de um PDF.” Precisa de um inventário revisto associado ao que lança, atualizado quando as dependências mudam, e partilhado só depois de os portões de publicação serem ultrapassados. Uma página de conformidade pública é uma forma de alojar esse registo, para que ambas as partes vejam a mesma versão. As ligações não são magia; o registo por trás delas é que tem de ser atualizado.

Querem prova de que tem controlo operacional sobre as obrigações de licenças de terceiros, não que uma vez correu npm list num portátil. Questionários diferentes usam palavras diferentes (página de licenças open source, lista de software de terceiros, divulgação de OSS, software bill of materials mais texto de licença), mas a intenção é semelhante.

Um software bill of materials, por si só, muitas vezes não satisfaz o pedido. Os elementos mínimos de um SBOM, conforme definidos pela NTIA dos EUA, centram-se na identidade dos componentes para uso em vulnerabilidades e inventário, não em divulgação de licenças revista. Os revisores de compras e jurídico continuam a querer o texto integral de licença e alguma confirmação de que a lista se mantém alinhada com os lançamentos.

• Inventário revisto de terceiros e open source para o produto em análise.
• Texto integral de licença ou ligações fiáveis, não apenas identificadores SPDX sem texto.
• Atribuição e aviso onde as licenças os exigirem.
• Clareza sobre que produto, lançamento, ou data a divulgação reflete.
• Muitas vezes um URL, exportação, ou anexo, conforme o processo deles especificar.
• Cada vez mais: como mantém o registo atualizado quando as dependências mudam.

Não envie o rodapé de licenças do seu site de marketing corporativo, se o comprador estiver a avaliar o seu produto de API, aplicação móvel, ou instalador on-premise. Cada produto lançado pode precisar do seu próprio registo de divulgação, ou de uma secção claramente delimitada.

Pergunte que SKU, nome de produto, versão, ou data de lançamento a revisão abrange. A conformidade de licenças é específica por produto. Enviar documentação para o produto errado cria mais retrabalho do que não enviar nada.

• Que produto ou SKU está em análise?
• Que versão, tag de lançamento, ou data a divulgação deve refletir?
• Querem um URL, um ficheiro de exportação, ou ambos?
• A revisão é para SaaS, software instalável, incorporado, ou todos os modelos de entrega?
• Quem é o público-alvo: compras, jurídico, segurança, ou os três?

Antes de responder, confirme que o registo corresponde ao build que os clientes recebem. Não à branch main, não à máquina local de um programador, não a um inventário que ninguém revê desde o trimestre passado.

Numa equipa com várias pessoas, as dependências mudam sem aviso centralizado. Um engenheiro atualiza uma versão de patch; outro adiciona um SDK de analytics; um pacote transitivo muda os metadados de licença no registo. Sem portões de importação, revisão e publicação, ninguém sabe que a divulgação está desatualizada até um comprador perguntar.

Compare a sua divulgação com o lockfile, SBOM, ou exportação do lançamento em análise. Verifique por amostragem os componentes copyleft, os SDKs comerciais, e tudo o que estiver marcado como por rever. Se não conseguir verificar cada linha, corrija a lacuna ou seja honesto quanto ao prazo.

• Importe a partir da branch de lançamento ou artefacto de CI, não de uma lista manual desatualizada.
• Confirme que todos os componentes no âmbito têm texto de licença aprovado.
• Resolva as linhas por rever antes de representar o registo externamente.
• Verifique que o nome do produto na divulgação corresponde ao que o comprador está a adquirir.
• Registe a tag de lançamento ou data que o inventário reflete, e indique-o na sua resposta.

Envie o que pediram (URL, exportação em PDF, pacote JSON) a partir do mesmo snapshot de publicação aprovado. Indique que produto e lançamento cobre. Descreva brevemente como atualiza o registo quando as dependências mudam: reimportar, rever de novo, republicar.

Não dê a entender aprovação jurídica, a menos que o seu advogado a tenha aprovado. Não diga “isto é tudo o que existe na nossa stack para sempre.” Diga o que foi revisto, para que produto, a partir de que lançamento, e que mantém o registo à medida que a base de código muda.

Se o registo não estiver pronto, dê uma data realista. As compras preferem honestidade a um snapshot que falha na revisão porque alguém fez merge de cinco atualizações de dependências desde que o gerou.

• Comece com o nome do produto e “divulgação de licenças de terceiros” ou “conformidade de licenças open source”.
• Indique o lançamento, tag, ou data que o inventário reflete.
• Forneça o URL ou anexo que pediram, a partir dos mesmos dados revistos.
• Uma frase sobre manutenção: como republica quando as dependências mudam.
• Ofereça exportações, se o questionário as exigir, geradas a partir do mesmo snapshot.

Exportar uma lista uma vez e reutilizá-la em vários lançamentos. Presumir que ninguém adicionou pacotes desde a última RFP. Enviar um SBOM em bruto sem texto de licença revisto. Enviar um PDF de trust center sobre segurança que nunca lista licenças de terceiros.

Alegar que o SOC 2 ou a ISO 27001 cobrem as obrigações de licenças open source (normalmente não cobrem). Tratar “usamos open source” como divulgação. Cada um destes falha quando o comprador compara a sua resposta com o que realmente é lançado, ou o que foi lançado dois sprints depois de ter respondido.

A solução é operacional: inventário a partir dos inputs do build, revisão humana antes da partilha externa, atualização a cada mudança de dependência. Não é um melhor formato de ficheiro.