Lo que realmente pide compras

Porque los productos no quedan congelados en una versión: los ingenieros fusionan actualizaciones de dependencias, añaden SDK, cambian fuentes y actualizan paquetes transitivos, a menudo sin que una sola persona haga seguimiento del panorama completo de obligaciones. No puedes afirmar con fiabilidad "esto es todo lo que corre en producción ahora mismo" a partir de una hoja de cálculo que construiste hace meses.

Un PDF, un archivo zip o un adjunto de SBOM son una instantánea. En el momento en que alguien distribuye una versión con paquetes nuevos, esa instantánea pasa a ser histórica. No está mal por mala fe, simplemente está desactualizada. Compras la archiva, asume que está al día, y descubre el vacío meses después en una auditoría o renovación.

El verdadero requisito no es "envía una URL en lugar de un PDF". Necesitas un inventario revisado vinculado a lo que distribuyes, actualizado cuando cambian las dependencias, y compartido solo después de superar las puertas de publicación. Una página de cumplimiento pública es una forma de alojar ese registro para que ambas partes vean la misma versión. Los enlaces no son magia; el registro que hay detrás debe actualizarse.

Quieren pruebas de que tienes control operativo sobre las obligaciones de licencia de terceros, no que una vez ejecutaste npm list en un portátil. Distintos cuestionarios usan palabras distintas (página de licencias de open source, lista de software de terceros, divulgación de OSS, lista de materiales de software más texto de licencia), pero la intención es similar.

Una lista de materiales de software por sí sola a menudo no satisface la solicitud. Los elementos mínimos de un SBOM, según los define la NTIA de EE. UU., se centran en la identidad de los componentes para uso en vulnerabilidades e inventario, no en la divulgación de licencias revisada. Los revisores de compras y legal siguen queriendo el texto completo de la licencia y alguna confirmación de que la lista se mantiene alineada con las versiones.

• Inventario de terceros y de open source revisado para el producto en revisión.
• Texto completo de la licencia o enlaces fiables, no identificadores SPDX sin texto.
• Atribución y aviso donde las licencias los exijan.
• Claridad sobre qué producto, versión o fecha refleja la divulgación.
• A menudo una URL, una exportación o un adjunto, lo que especifique su proceso.
• Cada vez más: cómo mantienes el registro al día cuando cambian las dependencias.

No envíes el pie de página de licencias de tu sitio corporativo de marketing si el comprador está evaluando tu producto de API, tu app móvil o tu instalador on-premise. Cada producto distribuido puede necesitar su propio registro de divulgación, o una sección claramente delimitada.

Pregunta qué SKU, nombre de producto, versión o fecha de versión cubre la revisión. El cumplimiento de licencias es específico de cada producto. Enviar documentación del producto equivocado genera más retrabajo que no enviar nada.

• ¿Qué producto o SKU está en revisión?
• ¿Qué versión, etiqueta de versión o fecha debe reflejar la divulgación?
• ¿Quieren una URL, un archivo de exportación, o ambos?
• ¿La revisión es para SaaS, software instalable, integrado, o todos los modelos de entrega?
• ¿Quién es la audiencia: compras, legal, seguridad, o los tres?

Antes de responder, confirma que el registro coincide con la build que reciben los clientes. No la rama main, no la máquina local de un desarrollador, no un inventario que nadie ha revisado desde el trimestre pasado.

En un equipo de varias personas, las dependencias cambian sin un aviso centralizado. Un ingeniero actualiza una versión de parche; otro añade un SDK de analítica; un paquete transitivo cambia los metadatos de licencia en el registro. Sin puertas de importación, revisión y publicación, nadie sabe que la divulgación está desactualizada hasta que un comprador pregunta.

Compara tu divulgación con el lockfile, el SBOM o la exportación de la versión en revisión. Comprueba al azar los componentes copyleft, los SDK comerciales y todo lo marcado como pendiente de revisión. Si no puedes verificar cada línea, corrige el vacío o sé honesto sobre el plazo.

• Importa desde la rama de versión o el artefacto de CI, no desde una lista manual desactualizada.
• Confirma que todos los componentes dentro del alcance tienen el texto de licencia aprobado.
• Resuelve las filas sin revisar antes de presentar el registro externamente.
• Comprueba que el nombre del producto en la divulgación coincide con lo que compra el comprador.
• Anota la etiqueta de versión o fecha que refleja el inventario, e indícalo en tu respuesta.

Envía lo que hayan pedido (URL, exportación en PDF, paquete JSON) a partir de la misma instantánea de publicación aprobada. Indica qué producto y versión cubre. Describe brevemente cómo actualizas el registro cuando cambian las dependencias: reimportar, revisar de nuevo, volver a publicar.

No des a entender una aprobación legal a menos que tu asesoría la haya dado. No digas "esto es todo lo que hay en nuestro stack para siempre". Di qué se revisó, para qué producto, a fecha de qué versión, y que mantienes el registro a medida que cambia la base de código.

Si el registro no está listo, da una fecha realista. Compras prefiere la honestidad a una instantánea que falla en la revisión porque alguien fusionó cinco actualizaciones de dependencias desde que la generaste.

• Empieza con el nombre del producto y "divulgación de licencias de terceros" o "cumplimiento de licencias de open source".
• Indica la versión, etiqueta o fecha que refleja el inventario.
• Proporciona la URL o el adjunto que solicitaron, a partir de los mismos datos revisados.
• Una frase sobre mantenimiento: cómo vuelves a publicar cuando cambian las dependencias.
• Ofrece exportaciones si el cuestionario las exige, generadas a partir de la misma instantánea.

Exportar una lista una vez y reutilizarla en varias versiones. Asumir que nadie añadió paquetes desde la última RFP. Enviar un SBOM en bruto sin texto de licencia revisado. Enviar un PDF de centro de confianza sobre seguridad que nunca lista licencias de terceros.

Afirmar que SOC 2 o ISO 27001 cubren las obligaciones de licencia de open source (normalmente no lo hacen). Tratar "usamos open source" como divulgación. Cada uno de estos falla cuando el comprador compara tu respuesta con lo que realmente se distribuye, o con lo que se distribuyó dos sprints después de que respondieras.

La solución es operativa: inventario a partir de las entradas de la build, revisión humana antes de compartir externamente, actualización cuando cambian las dependencias. No un mejor formato de archivo.