Usar bibliotecas open source no es gratis ni libre de obligaciones: la licencia que acompaña cada componente define qué podés hacer. Lo que determina si tenés un problema son tres cosas: la licencia específica, cómo integraste el código y cómo lo redistribuís. Primer paso: hacé un inventario completo de dependencias y revisá las licencias asociadas.
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
No existe una respuesta única; lo que decide si hay incumplimiento son tres factores principales:
Si fallás en cualquiera de estos puntos —por ejemplo, no reconocés una licencia copyleft en un paquete crítico— podés estar en incumplimiento.
1) Inventario y auditoría de dependencias. Hacé una lista exhaustiva de paquetes, submódulos y fragmentos de código de terceros. Incluí dependencias transitorias que entran a través de gestores de paquetes. Usá herramientas automáticas de escaneo y completá con revisión manual. Guardá versiones exactas.
2) Identificá la licencia de cada elemento. Para cada dependencia, copiá la cabecera de la licencia o el archivo LICENSE que la acompaña. Si no encontrás licencia, tratá ese componente como de riesgo: sin licencia expresa no tenés permiso legalmente claro para usarlo.
3) Clasificá por obligaciones. Separá componentes permisivos (permiten modificar y redistribuir con atribución) de componentes con copyleft (imponen que el derivado se distribuya bajo la misma licencia) o con cláusulas específicas (patentes, cláusulas de red). Esto te permitirá entender qué impacto tiene en tu producto.
4) Revisá el modo de integración. Si el componente está embebido en tu repo, documentá exactamente en qué archivo y quién lo incorporó. Si lo llamadas por API o lo usás como servicio, tomá nota de esa arquitectura: la diferencia puede cambiar las obligaciones.
5) Tomá decisiones técnicas y legales: reemplazar, aislar o cumplir. Reemplazar el componente por uno con licencia permisiva o por código propio minimiza riesgos. Aislarlo mediante contenedores o separación clara de módulos puede ayudar a argumentar que tu código no es un derivado. Cumplir implica añadir atribuciones, incluir archivos de licencia en tu distribución y, si corresponde, liberar código bajo la misma licencia.
6) Documentá y actualizá tus repositorios de derecho. Incluí archivos NOTICE o LICENSE según exijan las dependencias, y mantené un registro de decisiones para defensas futuras.
7) Si recibís una comunicación de incumplimiento, respondé con la documentación técnica: inventario, licencia y la solución adoptada (reemplazo, retiro, cumplimiento). Si el reclamante pide medidas, considerá negociar un acuerdo técnico o de atribución.
Qué hace un abogado: interpretar cláusulas conflicts (p. ej., interacción entre múltiples licencias), negociar con reclamantes y redactar la estrategia de cumplimiento.
1) Se arregla con una corrección técnica o aviso. Muchas disputas terminan porque el proyecto ajusta la atribución, añade la licencia requerida o sustituye la dependencia. Es la salida más rápida y menos costosa.
2) Acuerdo o conciliación. Si el titular del componente entiende que su licencia fue vulnerada, puede proponerte un acuerdo que incluya correcciones, atribuciones, e incluso una licencia comercial. Un acuerdo puede ser atractivo porque evita litigio y la publicidad negativa.
3) Reclamo judicial. En casos de infracción grave o cuando se cuestiona la titularidad del código, puede iniciarse un procedimiento para impedir la distribución y reclamar responsabilidad. Si perdés, además de medidas de cese, podrías afrontar costas y la obligación de corregir el incumplimiento. Y aun ganando, la ejecución práctica (por ejemplo, obligar a detener una distribución) depende de la situación económica del adversario.
Y si ganás, ¿cobrás? En acciones por licencias, el remedio más habitual es cesar la conducta y ajustar la situación; el cobro de indemnizaciones depende de la magnitud del daño y de la demostración de lucro obtenido.
Podés empezar con la auditoría técnica y la clasificación de licencias por tu cuenta, usando herramientas de escaneo. Contratá un abogado si la licencia es compleja, si te piden cumplimiento o si te ofrecen un acuerdo: un abogado revisa incompatibilidades, redacta las atribuciones que necesitás y negocia soluciones. Si tu empresa depende comercialmente del software y te ofrecen un arreglo económico, buscá asesoramiento profesional; probablemente calificás para asistencia jurídica si tu proyecto es de bajos recursos.
Otros problemas frecuentes en derecho informático y nuevas tecnologías
No. El hecho de que el código esté en GitHub no significa que sea libre para cualquier uso. Tenés que identificar la licencia. Si no tiene licencia explícita, no tenés permiso claro para usarlo en un producto comercial.
Depende cómo integrés la biblioteca. En general, la LGPL permite enlazar bibliotecas sin forzar la licencia del resto, pero si modificás la propia librería o la integrás de forma que el conjunto sea un derivado, pueden surgir obligaciones. Revisá la forma de vinculación técnica.
A veces la licencia exige más: incluir el archivo de licencia completo en la distribución, mantener notas de copyright y, en ciertos casos, otorgar el mismo régimen de licencia a los derivados. Seguí lo que la licencia exige textualmente.
Tratá ese componente como riesgo: buscá alternativas con licencia clara o contactá al autor para obtener permiso por escrito. Sin licencia explícita, no tenés un permiso legal claro para usar o distribuir el código.
Puede ayudar: exponer la funcionalidad vía API o ejecutar el componente en un servicio separado reduce la posibilidad de que se considere un derivado. Pero la arquitectura técnica no garantiza por sí sola la ausencia de obligaciones; conviene documentar y, si es necesario, pedir opinión legal.
Te conectamos con los mejores abogados especializados. Consulta gratuita y sin compromiso.
