Problemas con licencias open source en mi proyecto: cómo solucionarlo

¿Tienes razón?

Para saber si usted tiene un problema con licencias open source debe comprobar tres cosas: qué licencia rige cada componente; cómo se integró ese código en su proyecto (copiado en el repositorio, enlazado como dependencia, modificado o redistribuido); y si existen obligaciones incumplidas (atribución, inclusión de la licencia, compartir código fuente cuando convenga). Si usó componentes con licencia permisiva (como MIT o BSD) y respetó la atribución, su exposición suele ser baja. Si usó software con licencia copyleft fuerte (por ejemplo, licencias que exigen que obras derivadas se distribuyan bajo la misma licencia) y publicó su software bajo una licencia incompatible o sin liberar código fuente, el riesgo es mayor. Además, si hay código aportado por terceros sin licencia clara, puede haber reclamaciones por derechos de autor.

En Colombia las reglas de propiedad intelectual y contrato rigen la protección del software. No existe un régimen especial que anule las licencias open source: las licencias son contratos entre titular y usuario y pueden exigirse por la vía civil. También pueden entrar en juego reclamaciones por incumplimiento contractual o por competencia desleal si el uso indebido genera ventaja económica indebida.

Cómo se soluciona

1. Inventario y auditoría: haga un inventario completo de dependencias, paquetes y archivos. Use herramientas de escaneo para identificar licencias en dependencias y marque las incompatibilidades. Exporte versiones y rutas de cada componente y documente cuándo se añadieron.

1. Identifique las obligaciones incumplidas: para cada componente, anote si requiere atribución, inclusión de la licencia en redistribuciones, o si prohíbe usos comerciales o exige que el código derivado se publique bajo la misma licencia. Con esa lista podrá calcular las acciones necesarias.

1. Corrija la integración técnica: si el problema es la mezcla de código copyleft con código propietario, considere separar módulos, usar interfaces y servicios separados (por ejemplo, mantener componentes problemáticos como servicios independientes) o sustituir la dependencia por alternativas con licencia compatible. Documente los cambios en control de versiones.

1. Contacte a los titulares: si descubrió que incumplió una obligación, contacte a los autores con una propuesta de corrección: atribución retroactiva, publicación de código fuente conforme a la licencia, o pago por una licencia comercial si es posible. Muchas veces se soluciona con un acuerdo amistoso.

1. Asesoría y medidas legales: si el titular exige remedios y no hay acuerdo, puede reclamar por incumplimiento de licencia ante la jurisdicción civil. Antes de litigio, intente una conciliación extrajudicial en derecho. Si su producto depende comercialmente del componente conflictivo, consulte un abogado para valorar opciones estratégicas y riesgos.

Qué puede pasar

1) Se arregla con una corrección técnica y un acuerdo: lo habitual es que el titular acepte una solución práctica —inclusión de la atribución, liberación del código afectado o la compra de una licencia— y el conflicto quede resuelto sin juicio.

2) Conciliación o acuerdo con obligaciones: puede terminar en un acuerdo donde usted cumple con las obligaciones pendientes y, si hubo lucro, paga una compensación. Un acuerdo puede definir obligaciones de cumplimiento y auditorías futuras.

3) Litigio: el titular puede demandar por incumplimiento de la licencia y solicitar medidas cautelares (por ejemplo, prohibir distribuir el software) y reparación por daños. Si pierde, su producto podría quedar obligado a ajustarse a la licencia del componente o a cesar distribución hasta corregirlo. La efectividad de una sentencia depende de la capacidad del demandado para cumplir.

Y si gana, ¿cobro? En casos de titular que reclama indemnización económica, una sentencia puede condenar al pago; pero si el demandado es insolvente, la obtención real del dinero puede ser limitada.

Errores que arruinan el caso

• No llevar control de versiones ni del origen de cada dependencia: sin trazabilidad es difícil demostrar la buena fe.
• Ignorar licencias en paquetes transitorios: una dependencia puede traer otra con licencia incompatible.
• Hacer cambios irreversibles sin aislarlos: mezclar código copyleft en el core del producto complica la remediación.
• No documentar comunicaciones con autores: perder evidencia de intentos de solución amistosa resta opciones en caso de disputa.
• No considerar políticas de compliance: las empresas que venden software exportable deben tener auditorías periódicas de licencias.