Usar código open source en tu producto comercial: riesgos legales y compliance
Cómo gestionar el riesgo del código abierto en tu empresa en Chile
Usar código open source en tu producto comercial: riesgos legales y compliance
Casi todo producto de software comercial se construye hoy sobre componentes de código abierto. Eso no es un problema en sí mismo: el problema aparece cuando una empresa integra esas librerías sin revisar sus licencias y descubre, ya con el producto en el mercado o frente a un inversionista, que arrastra una obligación que no anticipó. Este artículo explica los riesgos legales de usar código abierto en un producto comercial en Chile y cómo construir un programa de compliance para gestionarlos.
| 📍 Respuesta directa: Usar código abierto en un producto comercial es legal y habitual, pero cada componente trae condiciones que deben cumplirse: atribución, disponibilidad del código fuente o, en el caso de licencias con copyleft fuerte como la GPL, la obligación de liberar el producto que lo integra. En Chile, estos componentes están protegidos por la Ley 17.336 igual que cualquier software, y su gestión debe documentarse formalmente, especialmente si el producto será registrado ante el DDI o evaluado en un proceso de inversión. |
Por qué el código abierto no es “gratis” para tu producto comercial
El código abierto no cuesta dinero, pero sí impone obligaciones. Cada componente que tu equipo integra —un framework, una librería, un motor de base de datos— viene bajo una licencia específica que define qué puedes hacer con él y, sobre todo, qué debes hacer si lo distribuyes como parte de tu producto. → Si aún no tienes claro cómo se clasifican estas licencias, revisa primero nuestra guía sobre licencias open source: GPL, MIT, BSD y copyleft explicados para empresas, que es la base para entender los riesgos que se explican a continuación.
Los riesgos del código abierto según el Módulo 3 del DL-511 de la OMPI
El Módulo 3 del curso DL-511 “Concesión de licencias de programas informáticos, incluidos los programas de código abierto”, dictado por la Academia de la Organización Mundial de la Propiedad Intelectual (OMPI), dedica una sección completa a los riesgos de adoptar software FOSS en un contexto comercial, organizados en tres categorías:
- Riesgos técnicos: el módulo advierte sobre la inmadurez de ciertos proyectos y la falta de garantías de continuidad, ya que “colaborar en proyectos de programas FOSS es una actividad voluntaria en gran medida, y no hay garantías de desarrollo (ulterior). Muchos proyectos se abandonan o quedan en manos de unos pocos desarrolladores o incluso de uno solo, lo que puede poner en riesgo su progreso”.
- Riesgos económicos: el curso identifica el fracaso o discontinuación de un proyecto como el principal riesgo económico, que puede forzar una migración costosa: “la migración de un programa informático a otro implica también un cambio a nivel institucional y de gestión”, además de las repercusiones que puede generar “una infracción de los derechos de PI, como por ejemplo el incumplimiento de las condiciones de las licencias de código abierto en las obras derivadas”.
- Riesgos jurídicos: el módulo señala que determinar la titularidad de los derechos en un software de código abierto puede complicarse cuando “varios programas separados pueden combinarse” y el producto final “se convierte en un auténtico mosaico hecho a partir de un gran número de fragmentos de código cuya titularidad corresponde a desarrolladores distintos”. También advierte que las licencias FOSS se conceden generalmente “tal cual”, sin garantías sobre su conformidad o su situación frente a derechos de terceros, incluidas eventuales patentes.
El riesgo central: la “contaminación” de licencias copyleft
El riesgo más relevante para una empresa que comercializa software es integrar, sin advertirlo, un componente bajo una licencia con copyleft fuerte —como la GPL— dentro de un producto que se pretendía mantener cerrado. Dependiendo de cómo se integre ese componente, la obligación de liberar el código fuente puede extenderse a todo el producto, no solo al componente original. Esto no es una hipótesis remota: es una de las causas más frecuentes de conflictos legales en la industria del software, y suele descubrirse en el peor momento posible: durante una auditoría de un cliente corporativo, una due diligence de inversión o una demanda de un tercero.
Marco legal chileno: Ley 17.336 y gestión del riesgo de código abierto
En Chile, el software de código abierto está protegido por la Ley 17.336 sobre Propiedad Intelectual exactamente igual que cualquier programa computacional (art. 3° N° 16): su autor conserva la titularidad y las condiciones de su licencia son plenamente exigibles. No existe una excepción especial que permita ignorar esas condiciones por tratarse de código “libre”.
Esto tiene consecuencias prácticas concretas para las empresas chilenas:
- Registro ante el DDI: si tu producto será registrado ante el Departamento de Derechos Intelectuales, deberás declarar y adjuntar copia de las licencias de los componentes de terceros que incorpora, incluidos los de código abierto. → Revisa el detalle de esta exigencia en nuestro artículo sobre licencias open source y qué exige el DDI, y la guía completa de cómo registrar un software en Chile ante el DDI.
- Infracción y su prueba: si tu empresa incumple las condiciones de una licencia open source —por ejemplo, no liberando código que la licencia exigía liberar—, el titular del componente original puede accionar bajo las mismas reglas de infracción de derecho de autor que aplican a cualquier copia no autorizada. → Revisa cómo se prueba una infracción de este tipo en cómo se prueba el plagio de código en Chile.
- Dependencia de terceros: el código abierto es, jurídicamente, una categoría de software de terceros, con los mismos riesgos de continuidad y soporte que cualquier componente que tu empresa no desarrolla ni controla. → Profundiza en los riesgos legales del software de terceros en tu empresa.
Cómo construir un programa de compliance de código abierto
1. Inventario de componentes (SBOM)
Mantén un listado actualizado de cada componente de código abierto que integra tu producto, junto con su versión y su licencia específica. Sin este inventario, es imposible evaluar el riesgo real de tu producto.
2. Política de aprobación previa
Define qué licencias están preaprobadas para integrarse libremente (habitualmente las permisivas, como MIT o BSD) y cuáles requieren revisión legal previa antes de sumarse al desarrollo (habitualmente las de copyleft fuerte, como la GPL).
3. Revisión antes del registro DDI o de una ronda de inversión
Antes de registrar tu software o de someterlo a una due diligence, revisa que el inventario de componentes esté completo y que las licencias correspondientes estén documentadas. Un componente no declarado es una de las causas más comunes de observaciones en el trámite ante el DDI, y una señal de alerta para cualquier inversionista.
4. Capacitación al equipo de desarrollo
La mayoría de los incumplimientos de licencias open source no son intencionales: ocurren porque un desarrollador integra una librería sin revisar su licencia. Capacitar al equipo técnico sobre qué licencias requieren aprobación previa reduce significativamente el riesgo.
5. Auditoría periódica
Los productos de software evolucionan constantemente, y con ellos su lista de dependencias. Una revisión periódica del inventario de componentes evita que el riesgo se acumule sin ser detectado.
Preguntas frecuentes
¿Puedo vender un producto comercial que use componentes de código abierto?
Sí, es la práctica estándar de la industria. Lo que debes gestionar es qué licencia tiene cada componente y qué obligaciones impone, especialmente si alguna exige liberar el código de tu producto final.
¿Qué pasa si descubro tarde que mi producto integra un componente con licencia GPL?
Debes evaluar con asesoría legal si la integración generó obligación de liberar código, y en qué alcance. En algunos casos es posible reemplazar el componente por una alternativa con licencia permisiva antes de que el conflicto escale.
¿Un inversionista puede rechazar mi startup por el uso de código abierto?
El uso de código abierto no es en sí mismo un problema para un inversionista; la ausencia de un inventario y una gestión ordenada de licencias sí lo es. Un compliance de código abierto bien documentado transmite justamente lo contrario: control sobre los activos de propiedad intelectual del negocio.
¿Necesito declarar todos los componentes open source al registrar mi software ante el DDI?
Sí, si son componentes de terceros relevantes para el desarrollo. El DDI exige copia simple de esas licencias como parte de los antecedentes del trámite, y omitirlas genera observaciones que retrasan el registro.
¿Qué diferencia hay entre este compliance y el registro de software ante el DDI?
Son complementarios. El registro ante el DDI certifica la titularidad de tu software en un momento determinado; el programa de compliance de código abierto es un proceso continuo que gestiona el riesgo de las dependencias de terceros a lo largo de todo el ciclo de vida del producto.
¿Tu producto usa código abierto y necesitas gestionar el riesgo legal?
En von Marttens® contamos con experiencia específica en propiedad intelectual y registro de software. Nuestro fundador, Hans von Marttens, es abogado especialista en software con certificación de la Organización Mundial de la Propiedad Intelectual (OMPI) en el curso DL-511 “Concesión de licencias de programas informáticos, incluidos los programas de código abierto”, y ha participado en más de 47 actos ante el Departamento de Derechos Intelectuales entre registro de obras e inscripción de contratos. Como abogado especialista en software, te ayudamos a auditar los componentes open source de tu producto, documentar correctamente sus licencias y prepararlo para un registro ante el DDI o una due diligence de inversión sin sorpresas.
Coordina tu asesoría en protección y registro de software con von Marttens® — revisamos tu caso y te entregamos una cotización formal.
Información de uso de IA: Este artículo fue escrito por miembros de nuestro equipo, sin embargo se utilizaron herramientas de IA con el objeto de mejorar la legibilidad y estructurar los textos para motores de búsqueda.
Artículos relacionados
- Licencias open source: GPL, MIT, BSD y copyleft explicados para empresas
- Registro de software en Chile: guía paso a paso ante el DDI (2026)
- Software de terceros: qué es y qué riesgos legales implica usarlo en tu empresa
- ¿Copiaron tu software? Cómo se prueba el plagio de código y qué puedes hacer
- Checklist legal de propiedad intelectual para startups y empresas tech en Chile
- Contrato de desarrollo de software: cláusulas esenciales para proteger tu propiedad intelectual en Chile
- ¿Quién es el dueño de un software?