Lista de verificación de cumplimiento de licencias: qué verificar antes de compartir prueba

Una página sólida identifica el producto distribuido, lista los componentes de terceros con licencias revisadas, incluye el texto completo de la licencia o enlaces fiables, y muestra la atribución donde las licencias lo exigen. Compras y los auditores esperan más que una lista de paquetes npm.

Si tu página solo dice "usamos open source" sin inventario, texto de licencia o un alcance claro, no satisfará una solicitud de divulgación de licencias de terceros. Esto se mantiene incluso cuando ingeniería superó una revisión de seguridad interna.

La necesidad es generalizada: el informe Open Source Security and Risk Analysis 2025 de Black Duck encontró que el 97 % de las bases de código auditadas contenían open source, así que casi todos los productos conllevan obligaciones de terceros, estén documentadas o no.

• Nombre y versión del producto (o canal de publicación) que cubre la página.
• Inventario de componentes de terceros y de open source, directos y transitivos donde tu proceso lo exija.
• Identificadores de licencia en formato SPDX o equivalente, tras revisión humana, no solo conjeturas del registro.
• Texto completo de la licencia de cada componente, o enlaces estables que resuelvan al texto completo.
• Bloques de atribución y aviso donde lo exijan MIT, Apache, BSD, GPL o licencias personalizadas.
• Etiquetado claro si la página es de ejemplo, beta o producción, cuando sea relevante.

El cumplimiento de licencias empieza con el inventario: cada componente de tu página de cumplimiento debe coincidir con la build distribuida actual, no con una rama de desarrollo, ni con staging, ni con una línea de producto que todavía no vendes.

Los equipos suelen pasar por alto fuentes, paquetes de iconos, SDK de analítica, JavaScript integrado en sitios de marketing y dependencias transitivas que arrastra una sola importación directa. El cumplimiento falla en silencio cuando el inventario está incompleto. El informe OSSRA 2025 de Black Duck indica que las dependencias transitivas causaron casi el 30 % de los conflictos de licencia que encontró, así que una lista de verificación que se detiene en las importaciones directas pasa por alto una gran parte del riesgo.

• Todos los componentes de la página coinciden con la build que reciben hoy los clientes.
• Las dependencias transitivas de npm, pnpm, yarn, Go, Rust, Python, Java, .NET, PHP o Ruby se incluyen según tu política.
• No se omiten fuentes, iconos, imágenes con condiciones de licencia ni SDK comerciales.
• Las capas base de contenedores y las bibliotecas nativas empaquetadas están dentro del alcance si las distribuyes.
• Los elementos marcados como desconocidos o pendientes de revisión se resuelven o se excluyen explícitamente con un motivo documentado.
• El origen del inventario (lockfile, SBOM CycloneDX, entrada manual) es rastreable hasta la versión.

Requiere que los revisores puedan leer la licencia real, no un resumen: la divulgación de licencias de terceros significa el texto completo de la licencia por componente. Compras y legal comparan tu página con las obligaciones de la GPL, la LGPL, Apache, MIT y los acuerdos de SDK propietarios.

La atribución es distinta del aviso y distinta del texto completo de la licencia. Una página que lista "MIT" sin el texto de la licencia MIT ni el aviso de derechos de autor exigido está incompleta para la mayoría de las revisiones empresariales.

• Cada componente tiene una licencia identificada, revisada por una persona, no copiada a ciegas de los metadatos del paquete.
• El texto completo de la licencia está presente en la página o enlazado sin muros de inicio de sesión ni URL que caducan.
• Los componentes copyleft (GPL, AGPL, LGPL, etc.) han superado tus puertas de revisión internas.
• La redacción de la atribución coincide con lo que exige cada licencia, no un pie de página genérico de "licencias de open source".
• Los componentes con licencia dual o personalizada tienen una decisión explícita registrada.
• Ningún componente se publica como aprobado hasta que se adjunta o enlaza el texto de la licencia.

Una página de cumplimiento de licencias es un registro vivo. La URL que compras guardó en su archivo de proveedores debe seguir siendo exacta después de tu próxima versión. El cumplimiento se rompe cuando la página se desvía de lo que se distribuye.

Las puertas de publicación (revisión antes de publicar) evitan que los equipos afirmen un cumplimiento que no han verificado. Las exportaciones (JSON, archivos de atribución, paquetes de divulgación) deben coincidir con el mismo inventario revisado que la URL pública.

• Un responsable identificado aprobó la publicación de este producto y versión.
• La URL de la página de cumplimiento es estable, pública y accesible sin autenticación.
• Las exportaciones y los paquetes de versión coinciden con el inventario publicado.
• Las comprobaciones de deriva o de pipeline señalan los paquetes nuevos antes de la próxima auditoría de un cliente.
• Tienes un proceso documentado para actualizar la página de licencias cuando cambian las dependencias.
• No das a entender una aprobación legal a menos que tu asesoría la haya revisado. La página es un registro operativo.

Abre la página de cumplimiento de licencias en una ventana de incógnito. Confirma que carga, identifica el producto, y comprueba al azar cinco componentes contra tu inventario interno. Si compras pide pruebas, esto es lo que hará.

Cuando se supera la lista de verificación, envía el formato que hayan pedido (URL, exportación o adjunto) a partir de la misma instantánea de publicación revisada. Indica el producto y la versión o fecha que refleja. El tipo de archivo importa menos que si el inventario se revisó y aprobó antes de enviarlo.

No. Una lista de verificación de SBOM confirma la identidad de componentes en un formato legible por máquina. Una de cumplimiento de licencias confirma licencias revisadas, texto completo, atribución y un estado de publicación que estás dispuesto a compartir. A menudo necesitas ambas, en ese orden.

Vuelve a ejecutarla antes de cualquier compartición externa, y de nuevo cuando cambien las dependencias en una rama de release vigilada. La deriva entre la última publicación aprobada y el lockfile actual es el modo de fallo habitual.

Elige un propietario responsable por producto, normalmente engineering con revisión legal en licencias de alto riesgo. La propiedad compartida sin una puerta de publicación es cómo las URL obsoletas terminan en archivos de proveedores.