Usar software open source no es gratis en sentido legal: cada licencia impone condiciones que pueden afectar cómo distribuyes, modificas o integras código. Lo que determina si estás obligado a divulgar código o cumplir otras obligaciones son la licencia concreta y cómo integraste el software. Primer paso: inventaría qué dependencias y licencias hay en tu código y documenta si hiciste modificaciones o redistribuciones.
Cuéntanoslo y te lo analizamos gratis en un minuto: qué opciones tienes, qué urge y qué contarle al abogado.
Analizar mi caso gratis Sin compromiso · Gratis
Tres preguntas marcan si tienes un problema: cuál es la licencia concreta, cómo está integrado el software en tu producto y si has hecho redistribución o modificación. Algunas licencias son permisivas y su única obligación es atribuir autoría y mantener avisos; otras son copyleft y exigen que, si redistribuyes el software o lo combines de ciertas maneras, publiques el código derivado bajo la misma licencia. El uso interno sin redistribución tiene un tratamiento distinto: muchas obligaciones vinculadas a la divulgación no se activan si el software se usa solo dentro de la organización.
También importa si tu proyecto es comercial y si vendes el software o un servicio que depende de él. Integraciones que enlazan en tiempo de ejecución con librerías copyleft fuertes pueden implicar obligación de liberar código. Finalmente, las dependencias transitorias importan: un paquete que incorporaste puede traer librerías con licencias conflictivas.
Si no sabes qué licencias rigen tus dependencias o si tienes builds que agrupan todo, puedes estar en incumplimiento sin darte cuenta. La solución empieza por identificar y clasificar las licencias.
1) Inventario de dependencias y licencias: ejecuta herramientas de análisis (scanners de licencias) sobre tu repositorio para listar todos los paquetes y sus licencias. Exporta informes y guarda los resultados como prueba. Revisa también dependencias de desarrollo y de producción por separado.
2) Clasifica riesgos por licencia: separa licencias permisivas (por ejemplo, MIT, BSD, Apache) de las copyleft (por ejemplo, GPL y sus variantes). Para cada licencia anota obligaciones concretas: atribuciones que debes mantener, necesidad de incluir aviso de licencia, y si existe obligación de divulgar código al redistribuir.
3) Audita integraciones y distribución: define cómo entregas tu producto (binario, SaaS, contenedor, librería). Determina si hay redistribución o solo uso interno. Si haces distribución, comprueba si hay obligación de adjuntar código fuente o avisos.
4) Corrige lo que sea necesario: opciones prácticas incluyen sustituir dependencias problemáticas por alternativas permisivas, modularizar el producto para separar componentes con licencias conflictivas, o cambiar la forma de prestación (por ejemplo, ofrecer como servicio en lugar de redistribuir). Si ya has distribuido y olvidaste avisos, corrige contenidos en la próxima versión y notifica si corresponde.
5) Documenta y formaliza procesos: incorpora en tu flujo de trabajo una verificación de licencias antes de aceptar nuevas dependencias, y obliga a desarrolladores a reportar modificaciones a componentes open source. Mantén un fichero con atribuciones y copias de licencias en tus repositorios.
6) Negociación y cumplimiento: si un tercero reclama incumplimiento, responde documentando lo que hiciste y proponiendo medidas como publicar avisos, corregir empaquetado o liberar código cuando la licencia lo exija. Si la otra parte pretende una solución económica, evalúa coste/beneficio.
Qué puedes hacer sin abogado: inventariar, aplicar scanners y sustituir paquetes. Cuándo llamar a un abogado: si hay reclamaciones formales, demandas o la necesidad de interpretar la compatibilidad entre licencias para decisiones estratégicas (por ejemplo, incorporar una dependencia clave con licencia copyleft).
1) Se arregla con cambios técnicos y documentación: con frecuencia la solución es técnica y administrativa: incluir avisos, ajustar empaquetado o reemplazar dependencias. Esto evita escaladas y suele ser la salida más común.
2) Acuerdo o requerimiento: un titular de derechos puede notificar y pedir correcciones o acuerdos. Aceptar rectificar y documentar medidas suele ser razonable y menos costoso que litigar. Un acuerdo puede incluir publicar código o firmar compromisos sobre futuras distribuciones.
3) Demanda por infracción de derechos de autor: en los casos más graves, puede haber demandas civiles. Si pierdes, pueden dictarse medidas de cese, obligación de publicar código y eventualmente indemnizaciones. Si la contraparte es solvente, la ejecución de una sentencia puede resultar en pago; en ausencia de bienes, una sentencia puede quedar como título sin cobro inmediato.
Y si ganas, ¿cobras? Ganar una disputa sobre licencias no garantiza cobro si la otra parte no tiene activos. Además, una sentencia puede ordenar medidas que afectan tu producto (por ejemplo, exigir la divulgación de código).
Puedes iniciar la limpieza técnica y sustituir dependencias por tu cuenta. Contacta a un abogado cuando haya una reclamación formal, para negociar acuerdos que impliquen obligaciones continuas, o si necesitas una opinión sobre compatibilidad entre licencias que afecte la estrategia de negocio. Si reúnes pocos recursos, consulta la Corporación de Asistencia Judicial para evaluar cobertura.
Otros problemas frecuentes en derecho informático y nuevas tecnologías
Depende de cómo lo integres. La GPL impone condiciones de copyleft cuando redistribuyes software modificado o combinado según ciertos criterios. Si tu producto solo llama a un servicio remoto sin redistribuir el binario, la situación puede ser distinta. Evaluar la forma de integración es clave.
No. Las licencias permisivas como MIT o BSD normalmente solo exigen conservar avisos de autoría y la licencia original; no requieren liberar tu propio código fuente.
Un README puede formar parte de la documentación, pero la práctica correcta es incluir un archivo de atribuciones con las licencias completas en el paquete distribuido para garantizar cumplimiento ante terceros.
Valora el impacto técnico y comercial. A menudo puedes sustituir la dependencia o modularizar. Si no es viable, negocia con el proveedor o busca asesoría legal para entender el alcance de la reclamación.
Sí: empaquetar dependencias en un contenedor o instalador cuenta como redistribución para muchas licencias. Debes revisar las licencias de todo lo incluido en la imagen o paquete.
Te conectamos con los mejores abogados especializados. Consulta gratuita y sin compromiso.
