Cumplimiento de licencias en M&A: lo que los equipos de diligencia realmente necesitan

El riesgo de licencia es riesgo de operación. Copyleft no declarado, atribución faltante, o una página pública que ya no coincide con el build pueden convertirse en holdbacks, recortes de precio o programas de remediation posteriores al cierre.

Los compradores preguntan porque heredan los productos que se entregan y las obligaciones que viajan con ellos. Los vendedores que ya mantienen un inventario revisado responden más rápido y con menos sorpresas.

• Confirma qué productos y líneas de release están en el alcance de la operación.
• Identifica pronto el copyleft, el copyleft de red y los términos de SDK propietarios.
• Separa los hallazgos de seguridad de la divulgación de licencias. La diligencia a menudo necesita ambos, pero no son el mismo entregable.
• Pregunta si el registro está vinculado a lo que realmente se entrega, no solo a un escaneo del sitio de marketing.

Una prueba lista para diligencia es un inventario revisado por cada producto en alcance, congelado en una publicación conocida, con texto completo de licencia y atribución cuando se requiere. Una página de atestación orientada al comprador más exportaciones coincidentes es la forma habitual.

Un lockfile pegado, un SBOM sin revisar, o un archivo NOTICE de hace tres años es entrada, no prueba. Prueba significa que alguien aprobó la representación antes de que saliera del edificio.

• Inventario acotado por producto (directo y transitivo según tu política).
• Identificadores de licencia revisados por humanos y texto completo adjunto.
• Una URL estable o una exportación generada desde la misma instantánea aprobada.
• Una declaración clara de qué release o fecha cubre el registro.

La mayoría de los apagafuegos parten de los mismos huecos. Detéctalos antes de que llegue la solicitud del data room.

Ninguna significa que la operación falle. Significan que alguien debe reconstruir un registro defendible bajo presión de tiempo.

• Componentes GPL, LGPL o AGPL no declarados o sin resolver en builds entregados.
• Archivos NOTICE o de atribución obsoletos que no coinciden con el lockfile actual.
• Un SBOM tratado como divulgación terminada, sin texto de licencia revisado.
• Una sola hoja de cálculo que cubre varios productos sin alcance por producto.
• Páginas públicas o exportaciones que no se pueden rastrear hasta una aprobación de publicación.

Construye el paquete desde el mismo bucle que ya deberías ejecutar para clientes: importa lo que se entrega, revísalo, publica y luego exporta. No inventes un proceso paralelo solo para diligencia la semana de la firma.

Cuando el comprador pide tanto una URL como archivos, genera ambos desde una misma instantánea congelada para que el data room no contenga versiones conflictivas.

Una página de cumplimiento mantenida y exportaciones coincidentes son infraestructura para la diligencia, no un sustituto del asesoramiento jurídico. Las licencias de alto riesgo, las preguntas de distribución saliente y las indemnidades específicas de la operación siguen necesitando revisión legal.

SourceTrust ayuda a los equipos a mantener el registro operativo al día para que los abogados discutan los pocos casos difíciles, no un inventario faltante.

Por lo general, no por sí solo. Un SBOM identifica componentes. La diligencia sigue necesitando licencias revisadas, texto completo y un alcance de producto claro. Trata el SBOM como la importación, y completa revisión y publicación antes de compartir.

Por producto: un inventario revisado actual, una URL de atestación o divulgación equivalente, y exportaciones de la misma instantánea. Saber qué release cubre cada archivo ahorra días cuando abre el data room.

Pide prueba acotada por producto y vinculada a los builds de la operación: una página mantenida o un paquete de divulgación, SPDX o CycloneDX coincidentes si se requiere, y confirmación de que las filas copyleft fueron revisadas. Evita aceptar una sola hoja de cálculo sin fecha como completa.