Problemas con licencias open source en tu proyecto: ¿qué debes revisar?

¿Tienes razón?

No todas las licencias open source son iguales. Tres elementos claves definen si hay un incumplimiento: la naturaleza de la licencia (permisiva o copyleft fuerte), la forma en que el software se incorpora a su producto (biblioteca enlazada, modificación directa, o distribución combinada) y si cumplió las obligaciones de atribución y disponibilidad de código cuando la licencia lo exige. Si utilizó solo bibliotecas con licencias permisivas y cumplió las atribuciones en la documentación, su riesgo es bajo. Si integró código bajo una licencia copyleft fuerte en un producto que distribuye sin liberar el código, hay riesgo real. También importa si su proyecto es interno (uso interno sin distribución) o si entrega software a clientes; muchas obligaciones se desencadenan al distribuir.

Cómo se soluciona

1. Inventario y trazabilidad.

• Genere una lista completa de dependencias directas e indirectas. Use herramientas de análisis de composición de software (SCA) para detectar bibliotecas y versiones.
• Para cada dependencia anote la licencia exacta y la URL de la fuente.

1. Clasifique las licencias.

• Separe licencias permisivas (que solo piden atribución) de licencias copyleft (que exigen compartir el código derivado bajo la misma licencia) y de las que contienen condiciones adicionales (patentes, cláusulas de redeterminación).

1. Revise cómo integra el código.

• Si su producto enlaza bibliotecas de forma dinámica o hace llamadas a servicios, las obligaciones pueden ser distintas que si incorpora el código fuente completo o produce un binario combinado.
• Determine si su distribución activa obliga a poner a disposición el código objeto o fuente.

1. Regularice las obligaciones formales.

• Añada las atribuciones y avisos de licencia en la documentación, en los archivos apropiados (README, NOTICE) y en los instaladores o empaquetados.
• Si la licencia exige publicar código modificado, prepare un repositorio público o privado según corresponda y deje constancia del enlace en la documentación.

1. Negocie o reescriba componentes conflictivos.

• Si hay una biblioteca con licencia incompatible, busque sustitutos permisivos, negocie una licencia comercial con el titular o aísle el componente para que no cree un ‘work’ derivado que obligue a abrir su código.

1. Actualice procesos internos.

• Implemente revisión de licencias en el ciclo de desarrollo, políticas de aprobación de dependencias y formación para desarrolladores.

Qué puede hacer usted solo: inventariar dependencias y añadir atribuciones. Cuándo contratar a un abogado: cuando la licencia exige divulgación de código modificado y usted distribuye el software, o si recibió una notificación formal por incumplimiento: ahí conviene defensa y negociación.

Qué puede pasar

1) Se arregla con corrección documental: muchas situaciones se corrigen añadiendo las atribuciones y publicando el código que la licencia exige. El titular suele aceptar la remediación si no hubo lucro evidente ni intento de ocultación.

2) Acuerdo o licencia comercial: el titular puede proponer un acuerdo que permita seguir usando el software bajo condiciones comerciales o una licencia diferente a cambio de pago o de ciertos compromisos. Aceptar un acuerdo puede ser preferible si evita riesgos mayores y permite operaciones normales.

3) Reclamo y medida coercitiva: si no se subsana, el titular puede reclamar judicialmente la cesación de distribución del producto y, en ciertos casos, solicitar medidas de bloqueo. Si pierde, puede enfrentarse a la obligación de dejar de distribuir y a daños. Además, los tribunales pueden ordenar la publicación del código si la licencia exigía su apertura.

Y si gana, ¿cobro? En este ámbito el remedio más habitual es la cesación y, en su caso, la compensación por daños. Una sentencia favorable no asegura ingresos: protege la libertad de uso según la licencia, pero la ejecución depende del patrimonio del demandado.

Errores que arruinan el caso

• No auditar dependencias indirectas: a veces la obligación viene de una dependencia de segundo o tercer nivel.
• Eliminar avisos de licencia para ‘limpiar’ el producto: es una señal de mala fe que agrava el conflicto.
• Mezclar código con licencias incompatibles sin aislarlo técnicamente: crea obligaciones cruzadas difíciles de resolver.
• No conservar versiones y commits que prueben la procedencia del código: pierde la trazabilidad.
• Responder informalmente a un requerimiento sin asesoría: una respuesta mal calibrada puede cerrar puertas para negociar.