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

¿Tienes razón?

Para saber si tienes base para reclamar o si estás en riesgo debes comprobar tres cosas principales. Primero, la licencia concreta de cada componente: algunas requieren sólo atribución, otras exigen que el código derivado se publique con la misma licencia. Segundo, cómo y dónde usas ese código: uso interno no distribuido suele plantear menos obligaciones que distribución pública o con fines comerciales. Tercero, la procedencia y la trazabilidad: si descargaste paquetes desde repositorios oficiales con historiales claros, tu posición es mejor; si el paquete fue copiado sin metadatos, la prueba de origen es más débil.

Si al revisar encuentras que un componente está bajo una licencia copyleft fuerte y tu distribución hace derivaciones, tu proyecto puede tener la obligación de publicar código fuente o cesar la distribución. Si el incumplimiento es por falta de atribución o por no incluir avisos de licencia, lo habitual es que haya una solución administrativa o de cumplimiento menos traumática que un litigio. En algunos casos la otra parte puede exigir una licencia comercial: eso cambia el balance económico del proyecto.

Cómo se soluciona

1. Identifica y documenta. Extrae la lista completa de dependencias (incluidas subdependencias) y registra su licencia tal y como aparece en el paquete o repositorio. Guarda capturas, hashes de los archivos y el URL de donde los descargaste. Exporta los manifiestos de dependencias y el historial de commits si procede.

1. Clasifica el riesgo. Separa componentes en tres grupos: los que sólo piden atribución, los que son copyleft (requieren redistribuir código bajo la misma licencia) y los dudosos (sin licencia o con licencia no estándar). Para cada componente indica si lo distribuyes o sólo lo usas internamente.

1. Remedia las faltas simples. Para problemas de atribución, añade los avisos de licencia, archivos LICENSE y notas en la documentación y empaques. Incluye en los binarios la referencia a la licencia y al repositorio original. Conserva evidencias del cambio (commits, timestamps).

1. Sustituye o aísla. Si un componente copyleft obliga a publicar código y no quieres hacerlo, sustituye por alternativa con licencia permisiva o reescribe la parte conflictiva. Otra opción técnica es encapsular el componente en un servicio separado que no distribuya el binario junto con tu software; evalúa con ingeniería si eso evita obligación de copyleft.

1. Negocia licencia comercial. Si la sustitución es inviable, contacta al titular y propón una licencia comercial o un acuerdo de uso. Lleva documentación del uso, el alcance y la versión exacta del componente.

1. Si ya hay notificación de incumplimiento. Responde con la documentación que demuestre correcciones o con una propuesta de remediación razonable. Si hay amenaza de demanda, busca asesoría especializada para valorar el riesgo y negociar.

1. Prevención: implementa escaneo continuo de dependencias, políticas de incorporación de OSS, revisión de licencias en pipelines y formación para desarrolladores sobre obligaciones de licencia.

En la práctica, muchas reclamaciones se resuelven con corrección de atribuciones o acuerdos; solo unas pocas llegan a litigio cuando hay implicaciones comerciales relevantes.

Qué puede pasar

1) Se arregla con una carta y corrección técnica: es lo más frecuente. El titular detecta un incumplimiento menor (falta de atribución, ausencia de LICENSE en empaques) y tu equipo añade los avisos y entrega pruebas. Se firma un acuerdo de rectificación y el asunto queda resuelto. Esta vía suele ser la más rápida y menos costosa.

2) Acuerdo o licencia comercial. Si la obligación es más seria (copyleft que exige publicar fuentes o usar el software en condiciones que afectan tu negocio), puedes negociar una licencia comercial o un acuerdo de conformidad. Aceptar un acuerdo por una suma o por obligaciones contractuales puede ser preferible a un litigio largo y a la obligación de publicar código fuente.

3) Litigio o reclamación formal. Si la otra parte insiste y hay daño económico importante, puede iniciar medidas extrajudiciales o judiciales. En un juicio pueden solicitar que dejes de distribuir el software, que publiques código, o compensación por daños. Si pierdes, el posible desenlace es cesar la distribución, retirar versiones, y en casos con sentencia firme cumplir con medidas correctivas; las costas y los gastos corren según lo que ordene el tribunal. También existe el riesgo de reputación y de interrupción de negocio. Importante: una sentencia contra una entidad insolvente puede ser difícil de cobrar.

Y si ganas, ¿cobras? Ganar un juicio no garantiza cobro si la parte contraria no tiene activos; además, el proceso cuesta tiempo y recursos. Por eso, en ocasiones negociar un acuerdo razonable es la solución práctica.

Errores que arruinan el caso

• No documentar el origen de los componentes: borrar historiales o no guardar manifiestos hace muy difícil probar la buena fe.
• Hacer cambios al código sin registrar commits y sin mantener la información de licencia en el repositorio.
• Ignorar subdependencias: un paquete aparentemente permisivo puede incluir internamente código con otra licencia.
• Responder mal a notificaciones: no responder o borrar comunicaciones eleva la probabilidad de medidas formales.
• Creer que todo es "uso interno": distribuir binarios en instalaciones de clientes o como parte de un producto empaquetado puede activar obligaciones que el uso interno no tiene.