Casi todos los productos de software comerciales contienen componentes de código abierto, generalmente cientos, seleccionados por desarrolladores en lugar de abogados. Esto se convierte en un problema cuando nadie puede determinar qué licencias se aplican, qué requisitos tienen ni si el producto cumple con ellos. Este artículo explica cómo funcionan las licencias de código abierto según la legislación neerlandesa y de la UE, dónde reside el riesgo y qué medidas se deben tomar.
Qué es una licencia de código abierto, en términos legales.
An open source licence is a copyright licence granted subject to conditions. It is not a waiver, not a dedication to the public domain, not an abandonment of rights, and in that respect it works like any other software licence under Dutch law. The author retains copyright under art. 1 Aw and art. 10 Aw, which protects computer programs as works, and the licence permits acts that would otherwise infringe the exclusive rights under art. 12 Aw and art. 13 Aw.
La consecuencia importa más que la definición. Si cumples, tu copia y distribución son legales. Si no cumples, el permiso no cubre lo que hiciste: tu uso constituye una infracción de derechos de autor, no un incumplimiento de contrato. La mayoría de las licencias copyleft refuerzan esto al rescindir automáticamente el contrato en caso de incumplimiento: la GPLv2 no contempla ningún período de subsanación, mientras que la GPLv3 y la AGPLv3 restablecen los derechos si el incumplimiento se subsana dentro de un plazo definido tras la notificación.
Los tribunales holandeses aplican este razonamiento. En Rb. Amsterdam El 22 de septiembre de 2020, ECLI:NL:RBAMS:2020:4717, se dictaminó que un distribuidor que eliminó el texto de la licencia y el aviso de derechos de autor de un código fuente bifurcado había perdido su autorización y estaba infringiendo los derechos de autor. La adición de un gran volumen de código nuevo no creó una obra independiente: el código original seguía presente de forma reconocible, por lo que las obligaciones se transmitían con él.
Las dos familias: permisiva y copyleft
Las licencias permisivas —MIT, las licencias BSD, Apache 2.0— permiten el uso, la modificación y la redistribución, incluso dentro de productos de código cerrado, siempre que se conserven los avisos de derechos de autor y el texto de la licencia.
Las licencias Copyleft exigen que, al distribuir el software o cualquier producto derivado del mismo, se utilice la misma licencia y se ponga a disposición el código fuente correspondiente. Su alcance difiere.
| Family | Licencias típicas | Obligación fundamental | Desencadenado por | Combinación patentada |
|---|---|---|---|---|
| Permisivo | MIT, BSD-2/3, Apache 2.0 | Conservar avisos, texto de licencia, exenciones de responsabilidad; Apache agrega avisos de cambios. | Distribución en formato fuente o binario | Sí: |
| Copyleft débil | MPL 2.0, LGPL 2.1/3, EPL 2.0 | Fuente de los archivos o biblioteca cubiertos; LGPL añade reemplazabilidad | Distribución de los archivos o biblioteca cubiertos | Sí, teniendo cuidado con el límite. |
| Copyleft fuerte | GPLv2, GPLv3, EUPL 1.2 | Misma licencia para toda la obra combinada; fuente correspondiente completa | Distribución; EUPL también acceso a funcionalidades esenciales | No, a menos que sean genuinamente separados. |
| Copyleft de red | AGPLv3 | Como GPLv3, además del código fuente para usuarios remotos a través de una red. | Distribución o ejecución de una versión modificada como servicio | No |
El desencadenante del copyleft y la cuestión del enlace
Las obligaciones de copyleft se aplican a la distribución, no al uso. Una empresa que utiliza software GPL internamente, por muy modificado que esté, no distribuye nada ni tiene ninguna obligación. La primera pregunta siempre es: "¿Hemos distribuido?", y por eso los contenedores, los dispositivos, el firmware y los SDK son más importantes que las herramientas internas.
La segunda pregunta es más compleja. La GPL habla de una «obra basada en el Programa», tomando prestado el concepto estadounidense de obra derivada. La legislación neerlandesa no contempla dicho término: el análisis se centra en los derechos de reproducción y adaptación, determinando si se ha reproducido la expresión protegida del original.
El caso práctico es el enlace. Si enlazar un módulo propietario a una biblioteca GPL crea una obra sujeta a copyleft nunca ha sido decidido por un tribunal neerlandés, y no existe una autoridad vinculante de la UE. La opinión de la Free Software Foundation de que el enlace crea una obra combinada es una interpretación del administrador de la licencia, no una ley, y la opinión contraria tampoco ha sido contrastada. La respuesta favorita en internet —enlace dinámico seguro, enlace estático no— no tiene fundamento en la legislación neerlandesa sobre derechos de autor, que no se pregunta cómo se comporta un compilador. Un análisis más sólido se pregunta cuán íntimamente se combinan los componentes: ¿comparten un espacio de direcciones y estructuras de datos?, ¿se distribuye la combinación como un solo producto?, ¿podría funcionar cualquiera de ellos por separado?, ¿reproduce la parte propietaria encabezados, macros o código en línea de la parte copyleft? Estas preguntas suelen resolver el riesgo. Cuando no lo hacen, aísle el componente tras un límite de proceso, reemplácelo o adquiera una licencia comercial.
AGPL y uso de la red
La licencia AGPL existe porque el copyleft se activa con la distribución, y los proveedores de SaaS no distribuyen. Su cláusula de red exige que, si modificas el software y lo pones a disposición de los usuarios que interactúan con él de forma remota, les ofrezcas el código fuente correspondiente de tu versión modificada.
Se suelen pasar por alto tres puntos. La obligación recae sobre los usuarios del servicio, lo cual, en un producto de registro abierto, no ofrece mucha tranquilidad. Se activa con la modificación, por lo que un componente sin modificar no la activa, pero una versión parcheada sí. Además, plantea la misma cuestión de la colaboración interlaboratorio que la GPL para el resto de la infraestructura, razón por la cual muchas empresas prohíben la AGPL en el código de producción.
Compatibilidad de licencias
La compatibilidad es el problema de combinar componentes cuyas licencias imponen obligaciones que no pueden cumplirse simultáneamente en una misma distribución: las licencias permisivas son compatibles con casi todo, mientras que las licencias copyleft solo lo son con lo que permiten sus propios términos. El caso típico es Apache 2.0 y GPLv2. La Apache Software Foundation y la Free Software Foundation coinciden en que la combinación no está permitida, ya que las cláusulas de rescisión de patentes e indemnización de Apache 2.0 constituyen restricciones adicionales que GPLv2 no permite. GPLv3 se redactó para aceptarlas. La compatibilidad también es direccional: el código de Apache puede integrarse en un proyecto GPLv3, pero no al revés. Un componente GPL mal ubicado puede obligar a elegir entre cambiar la licencia, rediseñar el código o eliminarlo, lo cual resulta mucho más económico antes del lanzamiento que después.
Obligaciones de atribución y notificación
Las obligaciones que se incumplen con mayor frecuencia son las menos graves: reproducir los avisos de derechos de autor, los textos de licencia, las exenciones de responsabilidad y, según Apache 2.0, el contenido de NOTICE en los materiales que acompañan a la distribución. Todas las familias de distribuciones las imponen, incluidas MIT y BSD. Se incumplen porque nadie es el propietario y son las más fáciles de solucionar: normalmente, mediante un archivo de atribución generado automáticamente y distribuido con el producto. El caso holandés mencionado anteriormente se basó precisamente en este fallo.
Concesión de patentes y represalias por patentes
MIT y BSD no mencionan las patentes, y aún no está claro si se puede inferir una licencia de patente. Apache 2.0 añadió una licencia de patente expresa y libre de regalías para cada colaborador, junto con una cláusula de represalia: si se inicia un litigio por infracción de patentes, la licencia se extingue. GPLv3 contiene una concesión similar y sus propias disposiciones sobre patentes.
Dos implicaciones para las empresas con carteras de patentes. Si sus ingenieros contribuyen a proyectos con licencia Apache o GPLv3, están otorgando licencias bajo sus propias patentes. Y si alguna vez hacen valer sus patentes contra una empresa que depende de los mismos componentes con licencia Apache que usted utiliza, las represalias podrían costarle una licencia de la que depende.
La EUPL y el sector público neerlandés
La Licencia Pública de la Unión Europea versión 1.2, aprobada por la Comisión Europea mediante decisión de ejecución en mayo de 2017, es una licencia copyleft aprobada por la OSI con tres características distintivas.
- Idioma. Existe en los idiomas oficiales de la UE, y todas las versiones aprobadas tienen el mismo valor, por lo que una autoridad holandesa puede contratar en neerlandés.
- Compatibilidad. Un apéndice enumera las licencias compatibles —entre ellas GPLv2 y v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL y CeCILL— y permite que una obra derivada que combine código EUPL con código bajo una licencia enumerada se distribuya bajo esa licencia.
- Alcanzar. Su definición de distribución abarca poner la obra a disposición en línea o fuera de línea. o proporcionando acceso a sus funcionalidades esencialesy el art. 5 de la EUPL extiende la obligación del copyleft a la interacción remota en la que se ofrece esa misma funcionalidad. Por lo tanto, abarca el software entregado como servicio, de una manera que la GPL no lo hace.
Un cliente del sector público neerlandés puede requerir la licencia EUPL por política, no por ley. La Ley de Interoperabilidad Europea, Reglamento (UE) 2024/903, ordena a los organismos del sector público que prioricen las soluciones de interoperabilidad sin condiciones de licencia restrictivas, como el código abierto, cuando sea equivalente; a nivel nacional, el principio de código abierto, tenzij, se basa en decisiones del gabinete y líneas políticas, no en la ley: la Ley de la Administración Pública facilita la infraestructura de identidad digital, pero no impone ninguna obligación exigible de publicar todo el código fuente. Lea los documentos de la licitación: un requisito de EUPL vincula su entregable y puede ser incompatible con el código propietario que pretendía reutilizar.
Aplicación práctica
¿Quién puede demandar? El titular de los derechos: los colaboradores individuales, o la fundación o empresa que posee los derechos de autor cedidos. La autoría fragmentada constituye el principal obstáculo: el demandante debe probar la propiedad del código en cuestión. Esto invalidó el caso más conocido de la GPL europea, en el que la demanda de un desarrollador de kernel contra un proveedor de virtualización fracasó por falta de prueba de autoría (LG Hamburgo, 8 de julio de 2016, 310 O 89/15; confirmada por la OLG Hamburgo, 28 de febrero de 2019, 5 U 146/16).
Lo que establece la jurisprudencia. Los tribunales alemanes han aceptado repetidamente que las licencias de código abierto son válidas y que su incumplimiento hace que la distribución sea ilegal, comenzando con la primera medida cautelar contra la GPL (LG München I 19 May 2004, 21 O 6123/04). El Tribunal Federal de Circuito de los Estados Unidos llegó a la misma conclusión en Jacobsen contra Katzer, 535 F.3d 1373 (Fed. Cir. 2008): los términos de la licencia son condiciones sobre el alcance de la concesión, no meros pactos, por lo que el incumplimiento da lugar a una reclamación de derechos de autor y a una medida cautelar. Los litigios en EE. UU. están explorando si un receptor posterior puede hacer cumplir la GPL como beneficiario tercero. Esa es la cuestión central en Software Freedom Conservancy contra Vizio before the Superior Court of California: whether consumers, as third-party beneficiaries, can demand release of the source code under GPLv2. On 23 December 2025 the court decided one point on summary adjudication, holding that GPLv2 and LGPLv2.1 require source that can be obtained and reworked for use elsewhere rather than source that can be reinstalled on the device with its functionality intact. The third-party beneficiary question itself was left over for the bench trial, which has been postponed more than once. It is a Californian contract law question in any event, so it binds nothing in the Netherlands; what it would change is the number of people able to complain.
Cómo lo abordaría un tribunal neerlandés. En el caso de infracción de derechos de autor según la Ley de Autor (Auteurswet), el demandante prueba la titularidad y la reproducción o comunicación; el demandado alega la existencia de la licencia; el demandante responde que no se cumplieron sus condiciones, por lo que la defensa fracasa. Las acciones contractuales previstas en el artículo 6:265 de la Ley de Autor (BW) se desarrollan en paralelo, pero los derechos de autor constituyen la vía más sólida.
Recursos. Una orden judicial según el art. 3:296 BW, generalmente con una multa y disponible en procedimientos sumarios; daños y perjuicios según el art. 27 Aw y una rendición de cuentas de los beneficios según el art. 27a Aw; retirada, entrega o destrucción según el art. 28 Aw; y recuperación total de los gastos legales razonables y proporcionales según el art. 1019h Rv. Cuando el software se distribuyó gratuitamente, la pérdida es difícil de cuantificar, y un tribunal de apelación alemán se negó a otorgar daños y perjuicios si bien confirmó la orden judicial (OLG Hamm 13 de junio de 2017, 4 U 72/16). Lo que molesta rara vez son los daños y perjuicios: son la orden judicial, la retirada, la orden de costas y tener que publicar el código fuente que nunca se pretendió publicar.
Cuando descubres un problema de cumplimiento
El descubrimiento suele provenir de un cuestionario de seguridad del cliente, un análisis durante la debida diligencia o una carta del titular de los derechos. La remediación se lleva a cabo de la siguiente manera: Detener la distribución de la compilación afectada si la exposición es grave. Determinar qué componente, qué versión, qué licencia, qué productos y lanzamientos, y durante qué período. Determinar qué exige realmente la licencia, a menudo un archivo de atribución en lugar de un lanzamiento de código fuente. Preparar los artefactos: avisos, textos de licencia, código fuente completo correspondiente, incluidos los scripts de compilación, y una oferta por escrito cuando corresponda. Publicar un lanzamiento que cumpla con los requisitos y luego informar al titular de los derechos sobre lo que se ha hecho, en lugar de discutir sobre si era necesario hacerlo.
Bajo las licencias GPLv3 y AGPLv3, el plazo para subsanar problemas otorga valor legal a la velocidad; bajo la licencia GPLv2 no existe tal derecho, razón por la cual la mayoría de las demandas por incumplimiento terminan en un compromiso de cumplimiento negociado. Cabe señalar también que el privilegio se aplica al asesoramiento de su abogado, no a un informe de ingeniería interno.
Software abierto en fusiones y adquisiciones y en el proceso de diligencia debida.
En la adquisición de una empresa de software, el código abierto es un paso habitual en el proceso de diligencia debida, y un componente copyleft no revelado en el producto principal es uno de los pocos hallazgos que realmente influyen en el cierre de un acuerdo: si el producto no se puede distribuir sin liberar su código fuente, el comprador está adquiriendo un activo diferente al que se ha valorado.
Espere un análisis del código fuente, un inventario de componentes con licencias y preguntas sobre los acuerdos con colaboradores y contratistas. Los resultados típicos incluyen una indemnización específica, una retención pendiente de subsanación, una condición previa que exige la eliminación o una garantía de código abierto a medida. Los vendedores deben realizar el análisis primero: los hallazgos que revelen constituyen una negociación, mientras que los hallazgos del asesor del comprador representan una ventaja. Los compradores no deben buscar que «la empresa sea propietaria de su propiedad intelectual», sino una declaración de que ningún producto incorpora código abierto que requiera la divulgación de código fuente propietario.
La lista de materiales, el escaneo y la Ley de Resiliencia Cibernética
Una lista de materiales de software es un inventario de los componentes de un producto, con sus versiones y licencias. Hasta hace poco era puramente contractual, pero ahora también tiene carácter normativo.
The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024 and phases in. It sits alongside the Ley de Ciberseguridad de los Países Bajos, which addresses the organisation rather than the product. The reporting obligations for actively exploited vulnerabilities and severe incidents in art. 14 CRA apply from 11 September 2026; the provisions on notification of conformity assessment bodies from 11 June 2026; the Regulation in full from 11 December 2027 (art. 71 CRA). Annex I CRA requires manufacturers to identify and document the components in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies. It need not be published; market surveillance authorities may request it.
El software libre y de código abierto suministrado fuera de una actividad comercial queda fuera del ámbito de aplicación de la Ley de Resiliencia Cibernética (CRA). El Reglamento introduce la figura del gestor de software de código abierto —una persona jurídica que presta apoyo continuo al desarrollo de software de código abierto destinado a actividades comerciales— con obligaciones más leves en el art. 24 de la CRA: una política documentada de ciberseguridad, cooperación con las autoridades de vigilancia del mercado e informes. Si comercializa software de código abierto o financia un proyecto que otros comercializan, debe determinar su función. La Comisión adoptó su primera guía el 27 de julio de 2026: la guía de la Comisión sobre la aplicación de la Ley de Resiliencia Cibernética (CRA), anexa a la comunicación C(2026) 5252, que aborda, entre otras cosas, cuándo el software libre y de código abierto entra dentro de su ámbito de aplicación. No se ha adoptado ningún acto de ejecución que prescriba un formato para la lista de materiales del software, por lo que, por el momento, se sigue utilizando la norma del propio Reglamento —un formato legible por máquina de uso común—.
El análisis de composición de software ejecutado en CI genera un inventario que permite cumplir con los requisitos de cumplimiento, revisión de licencias y diligencia debida simultáneamente. Estas herramientas no detectan el código de proveedores externos, identifican erróneamente proyectos con doble licencia y no pueden leer las condiciones de una licencia: considere el resultado como el inicio de la revisión, no como la revisión en sí.
Si publicas tu propio código: CLA y DCO
Una empresa que publica código y acepta contribuciones externas debe tener la certeza de poseer los derechos sobre lo que integra. Un acuerdo de licencia de colaborador es un contrato entre el proyecto y el colaborador, que generalmente otorga una licencia de derechos de autor amplia y una licencia de patente expresa, con garantías de originalidad y autoridad. Este acuerdo permite a una empresa volver a licenciar su proyecto posteriormente u ofrecer licencias comerciales junto con una de código abierto. Su costo radica en la fricción.
El Certificado de Origen del Desarrollador , utilizado por el kernel de Linux y muchos otros proyectos, no es una concesión de licencia, sino una declaración sencilla, añadida como línea de firma a cada confirmación, que certifica que el colaborador puede enviar el código bajo la licencia del proyecto. Es menos engorroso y menos restrictivo: no requiere licencia de patente ni relicencia.
Si es posible una licencia dual o una futura relicencia, utilice un CLA; si el proyecto es un bien público genuino, el DCO suele ser suficiente. En cualquier caso, asegúrese de que sus contratos laborales y de contratistas asignen los derechos de autor del código que escriben sus empleados.
Una lista de verificación práctica de políticas
- Genera un inventario de componentes por producto y versión en el proceso de compilación, no manualmente.
- Publique una política interna: una lista de elementos permitidos, una lista de elementos prohibidos y un procedimiento de aprobación para todo lo demás.
- Defina por escrito qué se considera distribución: instalaciones locales, dispositivos, contenedores, SDK, aplicaciones móviles, firmware.
- Incluya un archivo de atribución generado con cada producto.
- Apruebe las opciones de licencia en la fase de diseño, cuando se selecciona un componente, no en el momento del lanzamiento.
- Decida si las contribuciones a proyectos externos requieren aprobación, teniendo en cuenta las concesiones de patentes involucradas, y elija un CLA o un DCO antes de la primera contribución externa.
- Alinear las garantías de propiedad intelectual, las indemnizaciones y los términos de depósito en garantía con el código abierto que realmente incorpora el producto.
- Realice la revisión antes del proceso de recaudación de fondos o de venta, no durante el mismo.
Law & More advises software companies and their investors from Eindhoven y Amsterdam on open source compliance, licence review, contributor arrangements and the open source workstream in a transaction.
¿El uso de software de código abierto implica que tenemos que publicar nuestro propio código fuente?
Solo si se aplica una licencia copyleft y usted la activa. Las licencias permisivas nunca la requieren. Las licencias copyleft la requieren cuando se distribuye una obra que contiene el código copyleft, y la AGPL extiende esto al software modificado ofrecido como servicio de red. El uso interno sin distribución no genera ninguna obligación.
¿Es exigible en los Países Bajos una licencia como la licencia MIT sin firma?
Sí. Se trata de una licencia de derechos de autor no exclusiva, por lo que no se aplica el requisito de la escritura pública del artículo 2 Aw; basta con la aceptación tácita. Un tribunal neerlandés consideraría el incumplimiento de las condiciones como un uso fuera del permiso otorgado, lo que constituiría una infracción de los derechos de autor.
¿El enlace dinámico evita la licencia GPL?
No existe ninguna autoridad fiable que lo confirme. Ningún tribunal neerlandés ni de la UE se ha pronunciado al respecto, y la distinción entre estático y dinámico carece de fundamento en la legislación neerlandesa sobre derechos de autor, que se centra en si se ha reproducido la expresión protegida. El análisis más prudente examina la intimidad con la que se combinan los componentes; cuando esto no está claro, conviene aislar o sustituir el componente.
We are a SaaS business: can we ignore copyleft?
No del todo. La mayoría de las obligaciones de distribución de la GPL quedan sin efecto, ya que el alojamiento no se considera distribución. Sin embargo, la AGPL se aplica al software modificado puesto a disposición de usuarios remotos, la definición de comunicación de la EUPL abarca el acceso a las funcionalidades esenciales de una obra, y cualquier agente local o cliente descargable se considera una distribución.
¿Qué ocurre si descubrimos que hemos estado incumpliendo la normativa durante años?
Repáralo y documenta la reparación. Bajo la GPLv3 y la AGPLv3, un plazo para subsanar el problema tras la notificación restablece los derechos. Bajo la GPLv2, la restitución depende del titular de los derechos, pero la mayoría de las medidas coercitivas se resuelven mediante un compromiso de cumplimiento. La exposición que importa es una orden judicial, la revocación del contrato según el art. 28 Aw y una orden de costas según el art. 1019h Rv, no generalmente una indemnización por daños y perjuicios.
¿Nos exige la Ley de Resiliencia Cibernética publicar nuestro SBOM?
No. El Anexo I del Reglamento CRA exige una lista de componentes de software en un formato legible por máquina y de uso común, que incluya al menos las dependencias de nivel superior. Las autoridades de vigilancia del mercado pueden solicitarla. No existe obligación de publicarla. El Reglamento se aplica íntegramente a partir del 11 de diciembre de 2027; las obligaciones de información del artículo 14 del Reglamento CRA, a partir del 11 de septiembre de 2026.
