MadridBarcelonainfo@velardevidal.com
Firma Legal & Tax
España · desde 2023
V&V Velarde & VidalLegal & Tax
InicioAnálisisFiscal
Inicio · Recursos · Guias · Cómo licenciar software con código abierto
Propiedad intelectual y tecnología

Cómo licenciar software con código abierto

Por Inés Castaño, Asociada — Propiedad intelectual, tech y datosActualizado: 2027-10-04

El software con código abierto es, hoy, el tejido invisible de la mayoría de los productos digitales que las empresas españolas comercializan o integran en sus operaciones. Ignorar las obligaciones que imponen sus licencias no es solo un riesgo teórico: es una fuente concreta de pérdida de control sobre intangibles que pueden valer más que el inmovilizado material de la compañía. El marco regulatorio vigente en España y en la Unión Europea ha madurado considerablemente, y los juzgados de lo mercantil admiten cada vez con mayor frecuencia reclamaciones basadas en incumplimientos de contratos de licencia de código abierto.

En breve: Licenciar software con código abierto exige identificar qué tipo de licencia rige cada componente utilizado o distribuido, cumplir sus condiciones de atribución y publicación, y formalizar los acuerdos que preserven el control de la empresa sobre su propiedad intelectual. La normativa de propiedad intelectual española, articulada en torno al texto refundido de la Ley de Propiedad Intelectual, y el Reglamento General de Protección de Datos (RGPD) cuando el software trata datos personales, conforman el marco de referencia. La oportunidad perdida más costosa es distribuir producto sin haber analizado la cadena de dependencias.

Qué es realmente una licencia de código abierto y por qué obliga a la empresa

Una licencia de software de código abierto es un contrato. No una recomendación, no una cortesía del autor original: un contrato en toda regla, con obligaciones que vinculan a quien utiliza, modifica o distribuye el código.

La confusión más extendida que observamos en nuestra práctica es creer que «código abierto» equivale a «sin restricciones». Nada más alejado de la realidad. Las licencias de código abierto imponen condiciones que varían enormemente según su tipo, y cuyo incumplimiento puede suponer la pérdida del derecho a utilizar el código, la obligación de liberar código propietario o una reclamación por infracción de derechos de autor ante los tribunales.

Existen dos grandes familias de licencias que la dirección jurídica de cualquier empresa tecnológica debe conocer:

  • Licencias permisivas: imponen condiciones mínimas, generalmente limitadas a la conservación del aviso de copyright y la mención del autor. Permiten integrar el código en productos privativos sin obligación de liberar el código propio.
  • Licencias copyleft: exigen que cualquier obra derivada o que incorpore el código se distribuya bajo los mismos términos. Esta condición puede obligar a publicar código que la empresa considera su secreto empresarial más valioso.

Dentro del copyleft existen gradaciones relevantes. El copyleft fuerte afecta a cualquier obra que enlace o incorpore el código protegido. El copyleft débil solo activa la obligación de publicar si el módulo protegido se modifica, lo que permite integrarlo en un producto mayor sin abrir el resto del código. La distinción no es trivial: hemos asesorado a compañías que, por no haberla analizado en la fase de arquitectura del producto, se encontraron ante la disyuntiva de liberar su núcleo tecnológico o retirar el producto del mercado.

¿Cuál es el impacto real para la empresa? Que la elección de componentes de código abierto no es solo una decisión técnica. Es una decisión jurídica y de negocio que debe tomarse con la misma deliberación que la elección de un proveedor estratégico.

Cómo se articula el marco jurídico aplicable en España

El derecho de autor es el fundamento legal de toda licencia de software. En España, la protección del software como obra del intelecto nace de forma automática con su creación y se extiende durante toda la vida del autor y setenta años más. No es necesario registrar el software para que exista protección. Lo que sí conviene hacer, y lo explicamos más adelante, es adoptar medidas que faciliten la prueba de la titularidad y la fecha de creación.

La normativa de propiedad intelectual española atribuye al autor o titular de los derechos un control exclusivo sobre la reproducción, distribución, comunicación pública y transformación del software. Cuando la empresa utiliza código de terceros bajo una licencia de código abierto, está ejerciendo derechos que le han sido cedidos contractualmente bajo condición. Si no cumple las condiciones, la cesión no opera y cualquier uso del código constituye una infracción.

El contrato de licencia – ya sea permisiva o copyleft – es, desde el punto de vista del Derecho español, un contrato de cesión limitada de derechos. Su interpretación, en caso de litigio, seguirá las reglas generales de interpretación contractual del Código de Comercio y del Código Civil, además de la normativa especial de propiedad intelectual.

Un elemento adicional que las empresas suelen subestimar es la interacción con la protección del secreto empresarial. La normativa española de secretos empresariales protege el know-how técnico siempre que sea secreto, tenga valor comercial derivado de su carácter secreto, y haya sido objeto de medidas razonables de protección. Cuando el código copyleft obliga a publicar parte del código, la empresa debe analizar con antelación si esa publicación compromete información que protegía como secreto. La pérdida del secreto es irreversible.

En operaciones transfronterizas, especialmente cuando el software se distribuye en mercados fuera de España, coordinamos con abogados locales de confianza en la jurisdicción correspondiente para analizar la aplicación de la legislación local sobre software y propiedad intelectual, que puede diferir del marco europeo en aspectos relevantes como la patentabilidad del software o los plazos de prescripción.

¿Qué decisiones críticas debe gestionar la dirección antes de distribuir?

La distribución de software que incorpora código abierto activa obligaciones que, si no se han preparado con antelación, imponen costes de remediación significativos. Hemos identificado cuatro decisiones que no pueden dejarse para el momento de la distribución:

Primera decisión: el inventario de dependencias

Antes de distribuir cualquier versión del producto, la empresa debe disponer de un inventario completo de los componentes de código abierto que incorpora, incluyendo la versión exacta y la licencia aplicable a esa versión. Esta práctica, conocida en el sector como gestión de la lista de materiales de software (Software Bill of Materials), no es solo una buena práctica: empieza a ser un requisito en contratos con clientes corporativos y en licitaciones públicas europeas.

El inventario debe mantenerse actualizado. Las actualizaciones de dependencias pueden cambiar la licencia aplicable, y algunos proyectos de código abierto han cambiado su modelo de licenciamiento en versiones sucesivas, pasando de licencias permisivas a modelos más restrictivos.

Segunda decisión: el análisis de compatibilidad

No todas las licencias de código abierto son compatibles entre sí. Distribuir en un único producto código bajo licencias incompatibles constituye una infracción de los términos de al menos una de ellas. Este análisis de compatibilidad es técnico en su forma pero jurídico en su sustancia: requiere un criterio sobre la interpretación de los términos de cada licencia y sobre el tipo de integración que realiza el producto.

Tercera decisión: los avisos y atribuciones

Prácticamente todas las licencias de código abierto, incluidas las permisivas, exigen conservar los avisos de copyright y, en muchos casos, incluir el texto íntegro de la licencia en la documentación o en la propia distribución. El incumplimiento de esta obligación es la infracción más frecuente que detectamos en los proyectos de diligencia debida (due diligence) tecnológica que realizamos en operaciones de M&A.

Cuarta decisión: la documentación interna y la política de uso

La empresa debe disponer de una política interna aprobada por la dirección que regule qué tipos de licencias pueden incorporarse al producto y bajo qué condiciones. Esta política reduce el riesgo de que un equipo de desarrollo incorpore inadvertidamente un componente copyleft en el núcleo propietario del producto.

El contrato de licencia outbound: cuando la empresa licencia su propio software

Hasta aquí hemos analizado el escenario en que la empresa es usuaria o distribuidora de software de terceros. Pero la pregunta del H1 incluye también el escenario inverso: la empresa que ha desarrollado software propio y quiere licenciarlo bajo un modelo de código abierto.

Esta decisión tiene implicaciones estratégicas y jurídicas que merecen un análisis separado.

¿Por qué una empresa licenciaría su software como código abierto? Las razones de negocio son variadas: construir una comunidad de usuarios y desarrolladores, acelerar la adopción del estándar tecnológico propio, facilitar la integración con ecosistemas existentes o mejorar la reputación técnica de la compañía. Ninguna de estas razones es jurídicamente incorrecta. Pero la elección de la licencia determina qué control retiene la empresa sobre su código.

El proceso de licenciamiento outbound implica, al menos, las siguientes etapas:

  1. Verificación de la titularidad completa: la empresa solo puede licenciar lo que le pertenece. Si el código fue desarrollado por empleados, la normativa laboral española atribuye a la empresa los derechos de explotación cuando el desarrollo se ha realizado en el marco de la relación de trabajo. Pero si han intervenido terceros (freelancers, proveedores externos, contribuidores de otros países), es indispensable disponer de contratos de cesión de derechos que cubran todos los territorios y modalidades de explotación previstas.
  2. Selección de la licencia adecuada: la elección no es técnica sino estratégica. Una licencia permisiva maximiza la adopción pero renuncia al control sobre los usos que terceros hagan del código. Una licencia copyleft puede proteger un modelo de negocio basado en servicios asociados (soporte, consultoría, versiones empresariales), pero puede reducir la adopción en entornos corporativos que no pueden asumir las obligaciones del copyleft.
  3. Formalización del modelo de doble licenciamiento: algunas empresas optan por un modelo que combina una licencia copyleft para el uso gratuito y una licencia comercial privativa para quienes no quieran asumir las obligaciones del copyleft. Este modelo requiere que la empresa mantenga la titularidad íntegra sobre el código, lo que excluye la aceptación de contribuciones externas sin un acuerdo de cesión de derechos (Contributor License Agreement).
  4. Registro y prueba de titularidad: aunque el derecho de autor nace sin registro, depositar el código en el Registro de la Propiedad Intelectual o en una notaría proporciona una prueba con fecha cierta que puede ser decisiva en un litigio. La Oficina Española de Patentes y Marcas (OEPM) no registra software directamente como tal, pero el código puede protegerse también como secreto empresarial si no se divulga, o su interfaz puede tener interés en el análisis de diseños industriales.

En nuestra experiencia asesorando a empresas tecnológicas en España, la fase de verificación de titularidad es la que más sorpresas depara. Es frecuente descubrir, en el contexto de una operación de M&A o de una ronda de inversión, que parte del código del producto principal fue desarrollado por terceros sin un contrato de cesión de derechos en regla. El coste de regularización en ese momento es considerablemente más alto que el de haberlo hecho en el origen.

Diligencia debida tecnológica en operaciones de M&A: el código abierto como riesgo de valoración

Cuando una empresa tecnológica es objeto de una operación de adquisición o de inversión, la revisión del portfolio de código abierto es un elemento central de la diligencia debida (due diligence) tecnológica. Los compradores e inversores sofisticados saben que un producto con dependencias de código abierto mal gestionadas puede obligar a la empresa adquirida a liberar su código propietario o a incurrir en costes de remediación significativos.

Hemos participado en procesos de due diligence en los que el hallazgo de componentes copyleft integrados en el núcleo del producto ha generado ajustes en la valoración o condicionantes específicos en el contrato de compraventa. La parte compradora suele exigir una declaración y garantía específica sobre el cumplimiento de las obligaciones de código abierto, respaldada por un mecanismo de indemnización en caso de reclamación posterior.

Para la empresa objetivo, el mensaje es claro: el inventario de dependencias y el análisis de cumplimiento deben estar listos antes de iniciar el proceso de venta, no durante la due diligence. Presentar un informe de cumplimiento de código abierto en el dataroom desde el primer día transmite confianza y reduce la posibilidad de ajustes negativos en la valoración.

La conexión con el área de propiedad intelectual y tecnología de nuestra firma es aquí evidente: el mismo equipo que asesora en la protección del portfolio tecnológico es el que revisa la situación de código abierto en el contexto de una operación corporativa.

¿Cómo afecta el código abierto a la protección de la marca y del nombre del producto?

Una dimensión que las empresas suelen pasar por alto es la relación entre el software de código abierto y la protección de la marca del producto. Cuando una empresa licencia su software como código abierto, mantiene el control sobre el nombre comercial y la marca del producto mediante el Derecho de marcas, con independencia de los términos de la licencia de software.

Es perfectamente posible que el código de un producto sea libre y que su nombre sea una marca registrada de la empresa, impidiendo que terceros comercialicen el software con ese nombre sin autorización. Algunas de las licencias de código abierto más utilizadas incluyen disposiciones expresas que excluyen la concesión de derechos sobre la marca del titular.

La protección de la marca debe abordarse de forma paralela a la gestión de las licencias de software. En España, el registro de marca se gestiona ante la Oficina Española de Patentes y Marcas (OEPM) para el ámbito nacional, y ante la Oficina de Propiedad Intelectual de la Unión Europea (EUIPO) para la cobertura comunitaria. Una marca nacional tiene una duración de diez años renovables desde la fecha de solicitud.

La estrategia de protección de intangibles de una empresa tecnológica debe ser coherente: la licencia de software determina quién puede usar el código; el registro de marca determina quién puede usar el nombre. Ambos instrumentos se complementan y, mal coordinados, generan vulnerabilidades. Para una visión detallada sobre la protección de marcas en el entorno internacional, puede consultar nuestro análisis sobre preguntas frecuentes sobre marcas internacionales.

Errores frecuentes que detectamos en empresas tecnológicas

En nuestra práctica hemos observado que los errores más costosos no derivan de la ignorancia del Derecho, sino de supuestos implícitos que nunca se cuestionan. Los más frecuentes son los siguientes:

  • Asumir que el código generado por herramientas de inteligencia artificial es titularidad libre de cargas: las herramientas de generación de código pueden haber sido entrenadas con código bajo licencias que condicionan el uso del código generado. Esta es una cuestión en evolución activa, pero la empresa que distribuye el producto asume el riesgo hasta que exista un pronunciamiento regulatorio o judicial claro.
  • No actualizar el inventario de dependencias tras cada versión: el inventario que se hizo para la versión 1.0 no cubre la versión 2.3. Las dependencias cambian, las licencias de los proyectos upstream cambian, y el análisis debe repetirse.
  • Confundir la licencia del repositorio con la licencia del componente: algunos repositorios de código contienen componentes con licencias distintas a la que figura en el fichero principal de licencia del repositorio. Una revisión superficial no detecta estas discrepancias.
  • No regular las contribuciones externas al código: cuando la empresa acepta contribuciones de terceros a su proyecto de código abierto sin un acuerdo de cesión de derechos o de licencia de contribuidor (Contributor License Agreement), pierde la capacidad de cambiar la licencia del proyecto en el futuro, incluyendo la posibilidad de crear una versión comercial privativa.
  • Creer que el secreto empresarial y el código abierto son incompatibles: pueden coexistir si la empresa diseña cuidadosamente qué partes del sistema se abren y cuáles se mantienen privadas. La arquitectura del sistema puede ser una decisión tanto técnica como jurídica.

Checklist operativo: pasos para licenciar software con código abierto de forma segura

El siguiente esquema resume las actuaciones que, en nuestra experiencia, deben completarse antes de distribuir software que incorpora o constituye código abierto:

  1. Inventario de dependencias: identificar todos los componentes de código abierto, sus versiones y sus licencias. Documentar el inventario con fecha.
  2. Clasificación por tipo de licencia: agrupar las dependencias en permisivas, copyleft débil y copyleft fuerte. Identificar los componentes de riesgo elevado.
  3. Análisis de compatibilidad: verificar que las licencias de los distintos componentes son compatibles entre sí y con la licencia del producto distribuido.
  4. Verificación de atribuciones: comprobar que todos los avisos de copyright y textos de licencia exigidos se incluyen en la documentación de la distribución.
  5. Verificación de titularidad del código propio: revisar los contratos con desarrolladores, freelancers y proveedores para confirmar que todos los derechos se han cedido a la empresa.
  6. Selección y formalización de la licencia outbound: si la empresa va a licenciar su propio software como código abierto, seleccionar la licencia adecuada a la estrategia de negocio y publicarla en todos los canales de distribución.
  7. Política interna de código abierto: aprobar y comunicar a los equipos de desarrollo una política que regule qué licencias pueden incorporarse y bajo qué condiciones.
  8. Protección de la marca del producto: verificar que el nombre del producto está registrado como marca ante la OEPM y, si la distribución es internacional, ante la EUIPO.
  9. Registro o depósito del código propietario: adoptar medidas que acrediten la titularidad y la fecha de creación del código propietario, especialmente si se combina con la protección como secreto empresarial.
  10. Actualización periódica: establecer un proceso de revisión del inventario vinculado a cada versión del producto.

Este checklist no sustituye el análisis jurídico específico del caso concreto, pero permite a la dirección de la empresa identificar con rapidez las áreas de exposición más relevantes.

Cómo el asesoramiento temprano reduce el coste y el riesgo

La pregunta que más frecuentemente plantean los directores de producto y los responsables técnicos cuando iniciamos este tipo de análisis es: ¿cuánto cuesta arreglarlo si no lo hemos hecho bien?

La respuesta honesta es: depende del momento en que se detecte el problema. Hemos protegido marcas, software y secretos empresariales de compañías tecnológicas e industriales, y la experiencia indica que el coste de remediación se multiplica cuando el problema aflora en el contexto de una due diligence, de una reclamación de un tercero o de un proceso de certificación de producto.

Si la empresa descubre en la due diligence de una adquisición que tiene dependencias copyleft integradas en su código propietario, las opciones son limitadas: reescribir el módulo afectado, publicar el código (con las implicaciones competitivas que ello conlleva) o renegociar los términos de la operación. Ninguna de estas opciones es gratuita ni cómoda.

Si la misma situación se detecta en la fase de arquitectura del producto, la solución suele ser tan simple como elegir una dependencia alternativa bajo una licencia permisiva o diseñar la integración de forma que active el copyleft débil en lugar del fuerte. El coste es mínimo.

El asesoramiento temprano tiene también un valor defensivo frente a reclamaciones de terceros. La existencia de una política de código abierto documentada, de un inventario actualizado y de un análisis de cumplimiento formalizado permite a la empresa demostrar que ha actuado de buena fe, lo que es relevante tanto en negociaciones extrajudiciales como en procedimientos ante los juzgados de lo mercantil.

En el ámbito de la vigilancia tecnológica, la prevención activa de conflictos sobre intangibles es tan importante como la reacción ante ellos. Para comprender cómo la vigilancia de intangibles puede anticipar conflictos antes de que se materialicen, puede consultar nuestro análisis sobre vigilancia de marcas como prevención.

Servicios relacionados

El análisis del código abierto y la protección del portfolio tecnológico están estrechamente vinculados a otras áreas de nuestra práctica. En operaciones de M&A con componente tecnológico, la revisión del cumplimiento de código abierto forma parte de la diligencia debida del activo adquirido, en coordinación con nuestra práctica de Derecho societario y operaciones. Cuando el producto tecnológico opera en entornos que tratan datos personales, la interacción con la normativa de protección de datos y compliance añade una capa adicional de análisis que abordamos de forma integrada.

Preguntas frecuentes

¿Qué implica cómo licenciar software con código abierto para una empresa?
Licenciar software con código abierto implica asumir un conjunto de obligaciones contractuales que varían según el tipo de licencia. Las licencias permisivas exigen, como mínimo, conservar los avisos de copyright y atribuir la autoría. Las licencias copyleft pueden obligar a publicar el código derivado bajo los mismos términos. Para la empresa, esto significa que la elección de componentes de código abierto es una decisión jurídica y estratégica, no solo técnica, con consecuencias directas sobre el control de la propiedad intelectual del producto.
¿Qué plazos y costes conlleva cómo licenciar software con código abierto?
No existen plazos legales predeterminados para el proceso de análisis y cumplimiento de código abierto: la empresa debe completarlo antes de distribuir el software. Los costes son muy variables y dependen de la complejidad del inventario de dependencias y del grado de cumplimiento previo. Lo que sí puede afirmarse es que el coste del análisis preventivo es sistemáticamente inferior al coste de la remediación cuando el incumplimiento se detecta durante una due diligence o una reclamación judicial. Conviene verificar con la normativa vigente cualquier plazo específico aplicable al sector o a la distribución prevista.
¿Qué riesgos hay que evitar en cómo licenciar software con código abierto?
Los riesgos principales son la pérdida del control sobre el código propietario por obligaciones copyleft no previstas, la infracción de derechos de autor por incumplimiento de los términos de atribución, la incompatibilidad entre licencias de distintos componentes integrados en el producto, y la exposición en due diligence. Un riesgo específico y frecuentemente ignorado es la aceptación de contribuciones externas sin acuerdos de cesión de derechos, lo que puede impedir a la empresa cambiar el modelo de licenciamiento del producto en el futuro.
¿Cuándo conviene contar con asesoramiento en cómo licenciar software con código abierto?
El momento ideal es la fase de diseño arquitectónico del producto, antes de que las dependencias queden integradas en el código. También es crítico antes de cada versión de distribución, antes de iniciar un proceso de due diligence como empresa objetivo, y en el momento de definir la política de aceptación de contribuciones externas. En nuestra práctica, el asesoramiento en fase temprana permite evitar prácticamente todos los problemas recurrentes que encontramos al revisar portfolios tecnológicos en operaciones de M&A o en reclamaciones.

Hablemos de su caso

Para una primera valoración, escríbanos a info@velardevidal.com.

Plantear mi caso

Este contenido es informativo y no constituye asesoramiento jurídico. Para un análisis de su situación, contacte con info@velardevidal.com.