El riesgo de licencias de código abierto es el riesgo legal y comercial que surge del software que incorpora componentes de código abierto bajo licencias cuyos términos (obligaciones de copyleft, requisitos de atribución, cláusulas de terminación por patentes y restricciones de uso comercial) pueden no ser compatibles con la forma en que la empresa despliega el software, o pueden imponer obligaciones sobre el código propietario del proveedor que este no ha revelado. La adopción de la SBOM ha aumentado la visibilidad de los componentes de código abierto incluidos en el software de los proveedores. La gestión del riesgo de licencias exige entender no solo qué componentes están presentes, sino qué obligaciones imponen sus licencias en el contexto de despliegue específico.
El espectro del copyleft es el marco conceptual. Las licencias de código abierto van desde las permisivas (MIT, Apache 2.0, BSD), que imponen obligaciones mínimas (por lo general, solo la atribución), hasta las de copyleft fuerte (GPL-3.0, AGPL-3.0), que exigen que todo software que incorpore componentes con licencia copyleft se distribuya bajo la misma licencia copyleft. La AGPL-3.0 es la variante de copyleft más fuerte porque extiende la obligación de copyleft a los servicios en red: el software utilizado a través de una red se considera distribuido a efectos de la AGPL, lo que activa el requisito de divulgación del código fuente. Para un proveedor cuyo software propietario incluye componentes con licencia AGPL y se entrega como servicio en red, las disposiciones de copyleft de la AGPL pueden exigir la divulgación del código fuente propietario.
El problema de la compatibilidad de licencias es la dimensión técnica. Las distintas licencias de código abierto son compatibles o incompatibles entre sí de maneras que determinan si un producto de software que combina componentes bajo varias licencias es coherente desde el punto de vista legal. Combinar componentes con licencia GPL-2.0 y GPL-3.0 en un mismo binario crea una incompatibilidad; la cláusula “o posterior” de la GPL-2.0 lo resuelve, pero no todo el software con licencia GPL-2.0 la incluye. Combinar Apache 2.0 y GPL-2.0 crea una incompatibilidad porque Apache 2.0 incluye una cláusula de terminación por patentes que es incompatible con los requisitos de la GPL-2.0. El análisis de compatibilidad de licencias es una tarea legal especializada que la mayoría de los equipos de TPRM no pueden realizar sin asesoría jurídica.
Por qué es importante
El riesgo de licencias de código abierto es importante para TPRM porque el software que despliega su empresa puede imponer obligaciones legales que ni la empresa ni el proveedor han identificado, obligaciones que pueden surgir después del despliegue, cuando se evalúan las implicaciones legales de una combinación de licencias. Estas obligaciones pueden incluir requisitos de divulgación del código fuente, obligaciones de pago de regalías y disposiciones de terminación de licencias que afectan al derecho de la empresa a seguir usando el software.
- Riesgo de licencias no evaluado junto con la funcionalidad y la seguridad
- Componentes AGPL y de copyleft fuerte no identificados en el software de los proveedores
- Contexto de despliegue como servicio en red no aplicado al análisis de copyleft de la AGPL
- Compatibilidad de licencias no evaluada para las combinaciones de componentes
- SBOM utilizada para la seguridad, pero no para evaluar el cumplimiento de licencias
Cómo se ve una buena práctica
Los programas maduros de riesgo de licencias incluyen información sobre licencias en las solicitudes de SBOM, identifican los componentes de copyleft fuerte y AGPL en el software de los proveedores, evalúan la compatibilidad de licencias de las combinaciones de componentes y realizan una revisión legal del software que incluye componentes AGPL desplegados como servicios en red.
- Información sobre licencias en la SBOM: todas las licencias de los componentes identificadas
- Identificación de componentes copyleft, en especial AGPL en el contexto de servicios en red
- Análisis de compatibilidad de licencias para las combinaciones de componentes
- Revisión legal del software que contiene AGPL y se despliega como servicio en red
- Divulgación del cumplimiento de licencias por parte del proveedor como parte de la evaluación de seguridad del software
Herramientas
Análisis de licencias: FOSSA, Black Duck, Snyk License Compliance para el análisis de licencias de la SBOM
Las herramientas de análisis de licencias de código abierto pueden analizar las listas de materiales de software (SBOM) y los repositorios de código en busca de información sobre licencias: identifican componentes copyleft, señalan problemas de compatibilidad de licencias y generan informes de cumplimiento de licencias. FOSSA y Black Duck ofrecen análisis de riesgos de licencias de nivel empresarial. Para los profesionales de TPRM, solicitar los resultados del análisis de licencias junto con los resultados del análisis de vulnerabilidades de la SBOM ofrece un panorama completo del riesgo de código abierto.
Desafíos de gobernanza
El desafío de gobernanza del riesgo de licencias de código abierto es la necesidad de conocimientos jurídicos. El análisis del riesgo de licencias, en particular el análisis del copyleft de la AGPL y de la compatibilidad de licencias, exige conocimientos jurídicos que la mayoría de los equipos de TPRM y de seguridad no tienen. La solución de gobernanza es incluir el riesgo de licencias en la evaluación del software de los proveedores y remitir los componentes copyleft identificados a la asesoría jurídica para que evalúe sus implicaciones.
- Solicite información sobre licencias en la SBOM
- Identifique los componentes AGPL y de copyleft fuerte en el software de los proveedores
- Remita los hallazgos de AGPL a la asesoría jurídica para analizar las implicaciones de los servicios en red
- Incluya el cumplimiento de licencias en el contrato con el proveedor: garantías del proveedor respecto de las obligaciones de licencia
- Implemente el análisis de licencias del software proporcionado por los proveedores junto con el análisis de vulnerabilidades
Si usted forma parte de un equipo pequeño
La próxima vez que reciba una SBOM de un proveedor, procésela con el nivel gratuito de FOSSA o con una herramienta equivalente de análisis de licencias. El análisis tarda minutos y produce una clasificación de licencias para todos los componentes enumerados, identificando cualquier componente AGPL, GPL u otro de copyleft fuerte. Marque cualquier componente AGPL para revisión legal si el software se despliega como servicio en red. Ese análisis de quince minutos evita la revisión legal de seis meses que vivió la organización del caso inicial.
- Procese la SBOM del proveedor con una herramienta de análisis de licencias
- Identifique los componentes AGPL y de copyleft fuerte
- Marque los componentes AGPL para revisión legal en los despliegues como servicio en red
- Incluya una garantía de cumplimiento de licencias en los contratos con proveedores
Qué exigir
Pregunte directamente:
“¿Incluye su software algún componente con licencia AGPL-3.0 u otras licencias de copyleft fuerte? ¿Han completado una revisión legal de sus obligaciones de cumplimiento de licencias, en concreto respecto de la disposición sobre servicios en red de la AGPL, si su software se entrega como servicio?”
Evidencia que debe esperar
- SBOM con información sobre licencias para todos los componentes
- Resultados del análisis de licencias que identifican los componentes copyleft
- Evaluación del cumplimiento legal para los componentes AGPL y de copyleft fuerte
- Garantía de cumplimiento de licencias en el acuerdo con el proveedor
A un proveedor que entrega una SBOM se le debe pedir información sobre licencias junto con los datos de vulnerabilidades. Los análisis de vulnerabilidades de la SBOM abordan el riesgo de seguridad. La información sobre licencias aborda el riesgo legal. Ambos son necesarios para una gestión completa del riesgo de código abierto.
Cómo demostrarlo
- Registros de análisis de licencias del software de los proveedores
- Identificación de componentes copyleft
- Registros de revisión legal de los componentes AGPL
- Documentación de la garantía de cumplimiento de licencias
Conclusión clave
Plataforma de análisis desplegada. Componente AGPL: no revelado, no preguntado. Descubierto: 18 meses después, por el área legal. Posible obligación de la AGPL: divulgación del código fuente propietario por el despliegue como servicio en red. Revisión legal: 6 meses. El riesgo de licencias es un riesgo legal que existe desde el primer día del despliegue. Los componentes AGPL en software entregado como servicio en red pueden activar obligaciones de divulgación del código fuente que se aplican al código propietario del proveedor. El análisis de licencias los encuentra en minutos. La revisión legal evalúa las implicaciones. Ambas cosas ocurren antes del despliegue, no dieciocho meses después. Una SBOM sin información sobre licencias es visibilidad de seguridad sin visibilidad del riesgo legal.