El software de código abierto está presente en prácticamente todos los productos empresariales, pero pocos conocen los riesgos de licencia asociados. Desde el efecto copyleft de la GPL y las obligaciones SBOM del Cyber Resilience Act europeo hasta la due diligence en M&A, explicamos lo que importa en el cumplimiento OSS.
La dependencia invisible
Más del 90 por ciento de todos los productos de software modernos contienen componentes de código abierto. Lo que a primera vista parece una solución rentable e innovadora conlleva riesgos legales considerables. El software de código abierto (OSS) no es en absoluto "libre" en el sentido de "sin condiciones". Cada componente OSS está sujeto a una licencia que define obligaciones precisas, cuyo incumplimiento puede tener consecuencias graves.
Para las empresas que desarrollan, integran o distribuyen software, el conocimiento y cumplimiento de las licencias de código abierto no es una buena práctica opcional, sino una necesidad legal imperativa. Los riesgos van desde acciones de cesación y reclamaciones de daños hasta la pérdida de derechos de propiedad intelectual propios.
El panorama de las licencias: de permisivas a copyleft
Las licencias de código abierto se dividen fundamentalmente en dos categorías, cuya distinción es determinante para la evaluación de riesgos.
Licencias permisivas
Licencias como la licencia MIT o la licencia Apache 2.0 son relativamente sencillas. Permiten el uso, la modificación y la redistribución libres del software, incluso en productos propietarios. Las obligaciones esenciales se limitan a mantener el aviso de copyright y el texto de la licencia. La licencia Apache 2.0 incluye además una licencia de patente expresa que protege al usuario frente a reclamaciones de patentes del licenciante.
Licencias copyleft: el efecto "viral"
Las licencias copyleft son considerablemente más complejas, especialmente la GNU General Public License (GPL). La característica central de la GPL es el llamado efecto copyleft: quien integra código bajo licencia GPL en su propio programa y lo distribuye debe publicar toda la obra resultante también bajo la GPL, incluido el código fuente completo.
Esta obligación se denomina frecuentemente "efecto viral" porque la licencia se propaga a todas las partes del código conectadas. Para empresas cuyo modelo de negocio se basa en software propietario, esto puede ser existencialmente amenazante: la integración involuntaria de un componente GPL puede obligar a divulgar todo el código fuente propietario.
La LGPL (Lesser General Public License) atenúa este efecto. Permite la incorporación de bibliotecas LGPL en software propietario, siempre que la biblioteca se vincule dinámicamente y el usuario pueda sustituirla. Sin embargo, subsisten riesgos con la vinculación estática o la modificación de la propia biblioteca.
Hellwig contra VMware: una llamada de atención para la industria
La importancia del cumplimiento de la GPL fue ilustrada vívidamente por el caso Hellwig contra VMware. Christoph Hellwig, uno de los desarrolladores más prolíficos del kernel de Linux, demandó a VMware en 2015 ante el tribunal regional de Hamburgo por violación de la GPLv2.
La acusación era que VMware había integrado código del kernel de Linux en su hipervisor ESXi sin divulgar el código fuente de toda la obra derivada bajo la GPL. Aunque la demanda fue finalmente desestimada por razones probatorias -- Hellwig no pudo demostrar suficientemente qué líneas de código específicas eran de su autoría -- el caso sacudió a la industria.
La cuestión jurídica central, aún sin resolver hasta hoy, se refiere al concepto de obra derivada en el sentido de la GPL: ¿en qué momento la combinación de código propietario y código bajo licencia GPL se convierte en una obra unitaria sujeta en su totalidad a la GPL? Esta incertidumbre obliga a las empresas a extremar la cautela en la arquitectura de su software.
El Cyber Resilience Act europeo y la obligación SBOM
Con el Reglamento (UE) 2024/2847 -- el Cyber Resilience Act (CRA), el legislador europeo ha creado una nueva dimensión de obligaciones de transparencia. El CRA, que entró en vigor el 10 de diciembre de 2024 y será plenamente aplicable a partir del 11 de diciembre de 2027, obliga a los fabricantes de productos con elementos digitales a crear y mantener un Software Bill of Materials (SBOM).
¿Qué es un SBOM?
Un SBOM es un inventario legible por máquina de todos los componentes de software de un producto, comparable a una lista de ingredientes de productos alimenticios. Documenta todas las bibliotecas, frameworks y módulos utilizados, incluyendo sus versiones y licencias.
La NTIA definió ya en 2021 los requisitos mínimos para los SBOM, que desde entonces han sido actualizados por la CISA en una versión revisada de 2025.
Requisitos del CRA para el SBOM
El CRA exige que el SBOM:
- se cree en un formato común y legible por máquina
- liste como mínimo las dependencias de primer nivel del producto
- se conserve como parte de la documentación técnica
- se ponga a disposición de las autoridades de vigilancia del mercado cuando lo soliciten
Aunque el SBOM no necesita ser de acceso público, la obligación de crearlo y mantenerlo impone un registro sistemático de todos los componentes OSS y, por tanto, de sus licencias.
Tipos de licencia habituales y sus implicaciones
Una comprensión clara de los tipos de licencia más frecuentes es esencial para la práctica empresarial:
Licencia MIT
- Obligaciones: mantener el aviso de copyright y el texto de la licencia
- Riesgo: bajo
- Práctica: utilizable sin problemas en software propietario
Licencia Apache 2.0
- Obligaciones: mantener el aviso de copyright, el texto de la licencia y el archivo NOTICE; licencia de patente expresa
- Riesgo: bajo a medio
- Particularidad: cláusula de represalia en materia de patentes
GPL v2 / v3
- Obligaciones: colocar toda la obra derivada bajo la GPL; divulgar el código fuente
- Riesgo: alto
- Práctica: utilizable solo en módulos claramente separados o como herramienta puramente backend
LGPL
- Obligaciones: divulgar bajo LGPL las modificaciones a la propia biblioteca; vinculación dinámica requerida
- Riesgo: medio
- Práctica: utilizable en software propietario cumpliendo los requisitos de vinculación
AGPL (Affero GPL)
- Obligaciones: como la GPL, pero la obligación de divulgación se activa con la mera puesta a disposición a través de una red (SaaS)
- Riesgo: muy alto
- Práctica: especialmente crítica para aplicaciones SaaS comerciales
Due diligence en M&A para software de código abierto
En las transacciones empresariales, el cumplimiento OSS se está convirtiendo cada vez más en un factor decisivo. Los compradores deben asegurarse de que la empresa objetivo no esté cometiendo violaciones de licencia que puedan generar riesgos de responsabilidad tras el cierre de la transacción.
Áreas de auditoría clave
La due diligence OSS debe cubrir al menos los siguientes aspectos:
- Inventario: identificación completa de todos los componentes OSS utilizados y sus licencias
- Compatibilidad de licencias: verificación de que la combinación de diferentes licencias es admisible
- Contaminación copyleft: identificación de componentes GPL o AGPL en productos propietarios
- Cumplimiento de las condiciones de licencia: ¿se proporcionan correctamente los avisos de copyright, textos de licencia y, en su caso, el código fuente?
- Cumplimiento organizativo: ¿existen procesos internos y responsabilidades para la gestión de OSS?
Impacto en la valoración
Los riesgos OSS identificados pueden tener un impacto considerable en el precio de la transacción. En casos graves -- por ejemplo, cuando un producto principal está contaminado por la GPL -- esto puede significar el abandono de la transacción. Las garantías contractuales en forma de declaraciones (representations), garantías (warranties) e indemnizaciones (indemnities) son, por tanto, esenciales.
Programas de cumplimiento organizativos
Un programa de cumplimiento OSS eficaz se basa en varios pilares:
Estructura de gobernanza
- Establecimiento de una Open Source Program Office (OSPO) o al menos un responsable de cumplimiento dedicado
- Políticas claras para el uso de OSS (lista blanca/lista negra por tipo de licencia)
- Procesos de aprobación definidos antes de integrar nuevos componentes OSS
Herramientas técnicas
Las herramientas modernas permiten la detección y gestión automatizadas de componentes OSS:
- FOSSA: detección automatizada de licencias, generación de SBOM y aplicación de políticas
- Snyk Open Source: análisis combinado de seguridad y cumplimiento de licencias
- Black Duck (Synopsys): análisis integral de composición de software con inspección binaria profunda
ISO/IEC 5230 -- El estándar OpenChain
El estándar OpenChain de la Linux Foundation, estándar internacional como ISO/IEC 5230 desde 2020, define los requisitos fundamentales para programas de cumplimiento de código abierto de alta calidad. La certificación OpenChain genera confianza en la cadena de suministro y reduce la carga de auditoría con socios comerciales y en procesos de due diligence.
Recomendaciones prácticas
Para directivos
- Sensibilizar: incluir los riesgos OSS en la agenda de la dirección
- Asignar presupuesto: las herramientas y el personal de cumplimiento son una inversión, no un coste
- Definir responsabilidades: establecer atribuciones claras para el cumplimiento OSS
Para equipos de desarrollo
- Verificar antes de integrar: comprobar la compatibilidad de licencia de cada nuevo componente OSS
- Documentar dependencias: mantener y actualizar continuamente los SBOM
- Integrar en el pipeline de construcción: incorporar escaneos de licencias automatizados en el pipeline CI/CD
Para departamentos jurídicos
- Crear una política de licencias: directrices claras sobre qué licencias se aceptan y bajo qué condiciones
- Protección contractual: incluir garantías de licencia en los contratos con desarrolladores y proveedores
- Realizar formaciones: sensibilizar periódicamente a todas las partes interesadas sobre cuestiones jurídicas de OSS
Conclusión
El software de código abierto es una parte indispensable del desarrollo de software moderno, y eso es positivo. Sin embargo, los riesgos de licencia asociados requieren una gestión profesional. El Cyber Resilience Act europeo con su obligación SBOM incrementa aún más la presión para actuar. Las empresas que descuidan su cumplimiento OSS se arriesgan no solo a sanciones legales, sino también a daños económicos considerables, desde transacciones de M&A fracasadas hasta la divulgación forzosa de código fuente propietario.
En compleneo le apoyamos en la evaluación legal de su uso del código abierto, la implementación de programas de cumplimiento y la due diligence OSS en transacciones empresariales. Póngase en contacto con nosotros.
