Mi cliente/empresa usa código open source sin respetar la licencia

¿Tienes razón?

Que la empresa haya tomado código marcado como open source no significa automáticamente que esté libre de obligaciones. Lo que determina si hay incumplimiento son, sobre todo: la licencia aplicada al código (por ejemplo, si exige que tu código derivado sea también abierto o solo reproduce créditos), la forma en que se integró el código (¿se incorporó en producto interno, se redistribuyó a clientes, o se subió a repositorios públicos?), y las pruebas de incorporación (commits, descargas, correos, licencias acompañantes). Si el código es copyleft—es decir, obliga a que las modificaciones se publiquen con la misma licencia—y tú lo redistribuyes sin cumplir esa exigencia, tu riesgo es mayor. Si el código es permissive (licencias que solo piden atribución), normalmente lo que hay que hacer es acreditar la atribución y conservar la nota de licencia.

Además, cuenta si la empresa firmó contratos con terceros que prohíben incorporar terceros componentes sin revisión. Un proveedor que entregó software con dependencias open source sin advertir puede haber incumplido sus obligaciones. Por último, evaluar la antigüedad y la trazabilidad del uso ayuda: que un componente lleve años sin reclamos no lo limpia automáticamente de obligaciones.

Cómo se soluciona

1. Identifica y documenta el código y la licencia. Localiza los ficheros de licencia, cabeceras en los archivos fuente, el package.json o manifiesto equivalente y los commits en el repositorio. Exporta y guarda esos archivos y registros en un lugar seguro.
2. Determina la naturaleza de la licencia. Clasifica si es permissive (p. ej., exige solo atribución), copyleft fuerte (exige publicar cambios y puede afectar binarios) o licencia con restricciones específicas. Si no reconoces la licencia textual, guarda la versión exacta y busca asesoría técnica para identificar la obligación real.
3. Revisa el uso concreto: ¿distribuyes el software a clientes o lo usas internamente? La obligación de publicar código derivado suele activarse con la redistribución. Si es uso interno, en muchos casos la exposición es menor, pero no es despreciable si hay obligaciones contractuales con terceros.
4. Remedia la omisión. Dependiendo de la licencia, la solución práctica puede ser: añadir las notas de atribución en la documentación, publicar el código derivado bajo la misma licencia, o reemplazar el componente por una alternativa con licencia compatible. Conserva evidencia de la corrección: comunicados, commits, pruebas de despliegue.
5. Comunica con proveedores y clientes. Si hay terceros afectados, prepara una comunicación escrita que explique la situación y las medidas tomadas. Evita admitir hechos sin consultar a un especialista: reconoce el hecho y ofrece correcciones.
6. Si la otra parte reclama, responde de forma fehaciente y guarda copias. Recopila todo: contratos con proveedores, versiones del repositorio, tickets de trabajo y ficheros de licencia. Esto es lo que un perito técnico necesitará.

Qué puedes hacer hoy sin abogado: localizar y guardar las licencias, exportar los commits del repositorio, y preparar un listado de dependencias. Qué necesita un profesional: valorar compatibilidad de licencias entre componentes, redactar comunicaciones limitadas y negociar remediaciones o acuerdos con titulares.

Qué puede pasar

1) Se arregla con una carta y corrección técnica. Es bastante habitual que el titular de derechos pida que se incluyan las atribuciones correctas o que se publique el código derivado. Si la corrección es aceptada, se firma un acuerdo que evita escaladas.

2) Acuerdo o conciliación. Puede terminarse en un acuerdo formal que incluya indemnización, obligaciones de corrección y garantías de no repetición. Un acuerdo menos oneroso pero más rápido a veces compensa frente al coste y la incertidumbre de un pleito. Si te ofrecen una solución, considérala en perspectiva: la negociación es valiosa.

3) Demanda o acciones judiciales. El titular de derechos puede iniciar acciones civiles por infracción de derechos intelectuales o reclamar incumplimiento contractual. En juicio puede pedirse que elimines la obra o se paguen daños; si la empresa pierde y es insolvente, ganar judicialmente no garantiza cobro efectivo. Además, en procedimientos complejos pueden solicitar medidas cautelares para que retires el producto del mercado mientras dura el proceso.

Y si ganas, ¿cobras? Una sentencia favorable puede ordenar medidas y pagos, pero su efectividad depende de la solvencia del demandado y de las medidas de ejecución que se puedan practicar. Por eso, a veces un acuerdo que garantice remedios reales resulta más útil que una sentencia teórica.

Errores que arruinan el caso

• Borrar o alterar el historial del repositorio que demuestra cuándo y cómo se incorporó el código. Eso destruye prueba clave.
• Firmar comunicaciones admitiendo hechos sin evaluar las implicancias legales y técnicas.
• No conservar las versiones originales de los ficheros de licencia y los manifiestos de dependencias.
• Ignorar acuerdos con proveedores que prohíben incorporar componentes sin autorización.
• Publicar el supuesto código “corregido” sin respaldo técnico que demuestre la compatibilidad de licencias.