Detectas incumplimiento de licencia de un tercero en tu software: ¿qué debes hacer?

¿Tienes razón?

Para saber si la otra parte está incumpliendo una licencia de software hay cuatro factores decisivos. Primero, cuál es la licencia que cubre el código: licencias permisivas y licencias copyleft imponen obligaciones distintas. Segundo, cómo se incorporó el código a su producto: enlace dinámico, copia directa, modificación o inclusión en un binario empaquetado cambia las obligaciones. Tercero, qué documentación existe sobre la adquisición o el uso de ese componente (contratos, facturas, correos, repositorios). Cuarto, quién controla las versiones desplegadas y si usted puede reemplazar el componente sin afectar al servicio. Si el componente es sólo una dependencia enlazada y la licencia exige avisos, corregir los avisos puede bastar; si la licencia exige que su código derivado se publique y usted lo considera inaceptable, la cuestión es más grave.

Ninguna de estas preguntas se soluciona a ojo: la respuesta será técnica y legal a la vez. Empiece por la comprobación técnica y por conservar todo lo que pruebe la inclusión y el origen del código. Esa es la base para decidir si procede una corrección técnica, una reclamación extrajudicial o una demanda por incumplimiento de licencia.

Cómo se soluciona

1. Identifique exactamente el componente y la licencia. Exporte la versión del repositorio, el hash del commit y cualquier archivo de licencia incluido. Si hay un gestor de dependencias (por ejemplo, un archivo de bloqueo), adjúntelo.

1. Reúna pruebas objetivas. Copie y exporte fragmentos de código, metadatos del repositorio, correos electrónicos o contratos que muestren cuándo y cómo entró ese código al proyecto. Haga capturas de pantalla y exporte historiales de commit. No confíe en que los cambios seguirán existiendo en el servidor remoto.

1. Valore la solución técnica inmediata. Si puede eliminar o sustituir la dependencia sin romper funcionalidades críticas, hágalo y documente los cambios. Mantenga una rama con la versión afectada para efectos probatorios.

1. Prepare una comunicación formal al tercero. Explique cuál es el problema, aporte la prueba técnica y proponga una o dos soluciones claras: corrección del aviso de licencia, reempaquetado del software, o liberación del código bajo la licencia requerida. Sea firme pero profesional.

1. Si el tercero no responde adecuadamente, decida la vía: negociación asistida por abogado o acción judicial. Antes de litigar, cuantifique el daño: coste de sustitución, riesgo reputacional y posibles ventas afectadas.

1. Si usted distribuye el producto a clientes, informe a los clientes según lo exija la práctica de mercado y la licencia. Evite acciones que generen más responsabilidad —por ejemplo, no retire parches sin documentarlo—.

Qué puede hacer usted solo y qué necesita profesional: usted puede identificar el componente, exportar commits, y preparar la comunicación inicial. Necesitará abogado cuando haya que interpretar obligaciones de licencias complejas, cuantificar daños o negociar acuerdos con cláusulas vinculantes.

Qué puede pasar

1. Se arregla con una carta y corrección técnica. El tercer desarrollador acepta, usted corrige los avisos o sustituye la dependencia y el conflicto termina sin mayores consecuencias. Esto es frecuente cuando la infracción es de forma (falta de atribución) y la solución técnica es sencilla.

1. Acuerdo o conciliación. Puede negociarse que la otra parte publique el código afectado bajo la licencia correspondiente, aporte una compensación por las medidas correctoras o firme un acuerdo de indemnidad. Un acuerdo está bien si evita un proceso largo y la compensación cubre los costes reales de solución.

1. Juicio. Si el incumplimiento es grave (por ejemplo, inclusión masiva de código con obligación de liberar su código fuente) y no hay acuerdo, la vía judicial es posible. Si pierde la acción, se arriesga a tener que hacer las correcciones ordenadas por la autoridad o el juez y posiblemente asumir costas procesales. Además, una sentencia favorable contra un tercero solo sirve si el tercero tiene capacidad económica para cumplir; una sentencia contra una persona jurídica insolvente puede quedarse en papel.

Y si gana, ¿cobra? Cobrar la indemnización es distinto de obtener la sentencia: si el demandado no tiene bienes líquidos, la ejecución puede ser compleja. La sentencias y la ejecución son dos pasos separados.

Errores que arruinan el caso

• No exportar commits y metadatos: perderá la prueba de la versión exacta y del autor.
• Borrar la rama afectada o limpiar repositorios antes de notificar: parece intento de ocultación y perjudica su credibilidad.
• Enviar comunicaciones improvisadas admitiendo responsabilidad técnica sin consultar: puede cerrar opciones de negociación.
• No separar la corrección técnica de la negociación legal: un cambio mal documentado dificulta reclamar más tarde.
• No valorar la capacidad de la otra parte para cumplir: pedir una indemnización que el otro no puede pagar es desperdiciar recursos.