Respuesta rápida

En España, quien crea un programa de ordenador es, como regla de partida, su autor, pero autoría y titularidad de los derechos de explotación no siempre coinciden. Si el software lo desarrolla un trabajador dentro de sus funciones o siguiendo instrucciones del empresario, el artículo 97.4 del TRLPI atribuye los derechos de explotación al empresario, salvo pacto en contrario. Si el desarrollo lo realiza un freelance, una agencia o un socio fundador, hay que reconstruir qué se creó, cuándo se creó y qué derechos se cedieron o licenciaron.

Por eso, haber pagado una factura, disponer de acceso de administrador o tener un repositorio no demuestra por sí solo que la empresa sea titular de todos los derechos necesarios. Cuando el software es el activo principal del negocio, la pregunta decisiva es si la empresa puede explotarlo, modificarlo, mantenerlo, licenciarlo, transferirlo y venderlo sin depender jurídicamente de quien lo programó. Puedes ampliar la base jurídica general en el servicio de Derechos de Autor y Copyright.

Capítulos del vídeo

Qué se explica en el vídeo

• Por qué no siempre coincide quien programa, quien paga y quien es titular jurídico del software.
• La protección de los programas de ordenador mediante propiedad intelectual.
• Qué cambia cuando el desarrollador es freelance.
• La regla especial aplicable al software creado por trabajadores asalariados.
• Los problemas de titularidad cuando una startup tiene varios fundadores.
• Qué debe negociarse cuando el desarrollo se encarga a una empresa tecnológica.
• Por qué una cadena de derechos defectuosa puede aparecer en una due diligence y dificultar una inversión o compraventa.
• Qué debe regularse respecto del código fuente, entregables, documentación, confidencialidad y continuidad del proyecto.

Conclusiones principales

• Pagar por desarrollar un software no equivale automáticamente a adquirir todos sus derechos de explotación.
• En software creado por empleados existe una regla específica: el artículo 97.4 TRLPI.
• Una startup no debe presumir que el código creado por sus fundadores pertenece automáticamente a la sociedad.
• Tener acceso técnico al software no equivale a ser titular jurídico.
• La exclusividad debe quedar expresamente regulada cuando se pretende impedir que el proveedor reutilice el desarrollo dentro del alcance pactado.
• Una due diligence tecnológica revisará contratos, repositorios, componentes de terceros y cadena de titularidad.
• El control jurídico del software es una parte esencial del control del negocio cuando el código constituye su principal activo.

Marco jurídico aplicable

1. El software está protegido por la Ley de Propiedad Intelectual

Los programas de ordenador cuentan con un régimen específico en los artículos 95 a 104 del Texto Refundido de la Ley de Propiedad Intelectual (TRLPI).

El artículo 96 define el programa de ordenador y exige originalidad, entendida como creación intelectual propia de su autor. La protección alcanza a las formas de expresión del programa y también a determinados materiales preparatorios, documentación técnica y manuales. El artículo 101 permite, además, la inscripción de programas, versiones y programas derivados en el Registro de la Propiedad Intelectual.

La inscripción no crea el copyright: el derecho nace con la creación. Sin embargo, la documentación de versiones, autores, repositorios y contratos puede ser muy relevante como prueba. Sobre esta cuestión resulta útil la guía de registro y prueba de autoría.

2. Autor y titular no son necesariamente lo mismo

El artículo 97 TRLPI regula específicamente quién puede ser considerado autor y quién controla los derechos sobre el software. Una persona natural puede ser autora del código y, sin embargo, los derechos de explotación corresponder a una empresa por aplicación de una regla legal o por una cesión válida.

Esta diferencia explica por qué no basta con preguntar «¿quién escribió el código?». En un proyecto tecnológico hay que identificar también quién puede reproducirlo, adaptarlo, modificarlo y distribuirlo, facultades que el artículo 99 atribuye al titular de los derechos de explotación, sin perjuicio de los límites legales del artículo 100.

3. Derecho europeo

El régimen español desarrolla la Directiva 2009/24/CE sobre la protección jurídica de programas de ordenador. Esta norma armoniza en la Unión Europea aspectos esenciales como la originalidad, la autoría, los derechos exclusivos y la posición del empresario cuando el programa se crea en el marco de una relación laboral.

Además, el Tribunal de Justicia de la Unión Europea ha aclarado que la funcionalidad de un programa, el lenguaje de programación y el formato de determinados archivos de datos no son, por sí mismos, una forma de expresión protegida por el copyright específico del programa. Esta doctrina aparece en la sentencia TJUE, asunto C-406/10, SAS Institute v. World Programming. Esto no autoriza a copiar código: obliga a distinguir entre la idea o funcionalidad y la expresión protegida.

4. Confidencialidad y secreto empresarial

Un contrato de desarrollo no debería analizar únicamente copyright. El código fuente, arquitectura interna, documentación, credenciales, roadmaps y determinados conocimientos técnicos pueden requerir también medidas de confidencialidad y, cuando se cumplan sus requisitos, protección conforme a la Ley 1/2019, de Secretos Empresariales.

Una prohibición de competencia, sin embargo, no debe añadirse de forma automática. Su validez y alcance dependen del contexto, de las partes, de su duración, territorio, actividad afectada y proporcionalidad. En muchos proyectos es más preciso regular confidencialidad, no uso de información reservada, exclusividad sobre determinados entregables y límites concretos a la reutilización.

Caso 1: software desarrollado por un freelance

Cuando una empresa contrata a un programador autónomo, la regla especial del trabajador asalariado no opera automáticamente. La cuestión central pasa a ser el contrato.

El artículo 43 TRLPI establece que una cesión queda limitada a los derechos, modalidades de explotación, tiempo y territorio pactados. Si las modalidades no se detallan, la transmisión se limita a las que se deduzcan necesariamente del contrato y sean indispensables para cumplir su finalidad. El artículo 45 exige formalización escrita y el artículo 48 dispone que una cesión exclusiva debe otorgarse expresamente con ese carácter.

Por ello, una factura que diga «desarrollo aplicación» puede demostrar un encargo y un pago, pero no resuelve por sí sola cuestiones como:

• si el cliente puede vender o sublicenciar el software;
• si puede permitir que otro equipo lo modifique;
• si la cesión es exclusiva;
• qué ocurre con código creado anteriormente por el freelance;
• qué componentes pertenecen a terceros;
• si el desarrollador puede reutilizar módulos en otros clientes;
• qué código, repositorios, documentación y credenciales deben entregarse.

La afirmación práctica correcta no es simplemente «si lo pagas es tuyo» ni «si no hay contrato no tienes ningún derecho». Lo jurídicamente prudente es decir que el pago no transmite por sí mismo una titularidad plena y que el alcance de cualquier cesión o autorización debe reconstruirse atendiendo al contrato y a la finalidad del encargo.

Si el proyecto tiene valor económico, conviene utilizar un contrato de cesión o licencia de derechos adaptado al desarrollo tecnológico.

Caso 2: software creado por un empleado

Aquí existe una regla legal específica. El artículo 97.4 TRLPI establece que, cuando un trabajador asalariado crea un programa de ordenador en el ejercicio de las funciones que le han sido confiadas o siguiendo instrucciones de su empresario, los derechos de explotación corresponden exclusivamente al empresario, salvo pacto en contrario.

La clave no es, por sí sola, dónde se programó ni qué ordenador se utilizó. Que el trabajador escribiera parte del código desde casa no convierte automáticamente el programa en suyo; y utilizar un portátil de empresa tampoco basta por sí solo para resolver la titularidad.

En un conflicto habrá que revisar especialmente:

• contrato de trabajo y descripción de funciones;
• instrucciones recibidas;
• tickets, tareas y documentación de proyecto;
• repositorios y commits;
• correos y mensajes de trabajo;
• relación entre el desarrollo y la actividad encomendada;
• fecha y circunstancias en las que se creó cada componente.

Si el empleado creó un producto completamente ajeno a sus funciones y sin seguir instrucciones empresariales, no debe presumirse automáticamente que el artículo 97.4 atribuye esos derechos a la empresa. Es un escenario que exige análisis concreto.

Caso 3: startup con varios fundadores

Una startup puede empezar con dos o cuatro fundadores que programan antes de constituir la sociedad. El error aparece cuando todos dan por hecho que, una vez creada la empresa, «el software ya es de la sociedad».

No tiene por qué ser así. Hay que separar al menos dos momentos:

Si el programa es resultado unitario de la colaboración de varios autores, el artículo 97.3 prevé propiedad común en la proporción que determinen. Pero no todo proyecto con varios fundadores es automáticamente una obra en colaboración: también puede ser necesario analizar la obra colectiva, aportaciones separables, desarrollos previos y contratos posteriores.

Esta cuestión adquiere especial importancia antes de una ronda de inversión. La empresa debería poder demostrar una cadena de titularidad coherente: acuerdos con fundadores, contratos laborales, cesiones, licencias, documentación técnica y derechos sobre componentes externos.

La guía sobre cómo proteger legalmente un SaaS o software amplía esta arquitectura de protección cuando el producto tecnológico es el núcleo de la empresa.

Caso 4: encargo a una empresa tecnológica

Contratar a una agencia o empresa de desarrollo no elimina el problema de titularidad. De hecho, los contratos profesionales suelen diferenciar entre:

Un buen contrato no debería limitarse a decir que «el software será propiedad del cliente». Hay que describir qué significa jurídicamente esa propiedad y cómo se materializa técnicamente la entrega.

El error legal que puede bloquear una inversión

Cuando una startup busca inversión o prepara una compraventa, la titularidad del software deja de ser una cuestión teórica. Una due diligence puede preguntar quién creó el código, con qué contratos, qué partes pertenecen a terceros y si la sociedad dispone de derechos suficientes para continuar explotando el producto.

Una cadena defectuosa no significa automáticamente que la inversión vaya a fracasar, pero puede provocar:

• regularizaciones de última hora;
• retenciones o condiciones al cierre;
• declaraciones y garantías adicionales;
• reducción de valoración;
• negociaciones con antiguos fundadores o proveedores cuando la empresa tiene menos margen;
• dependencia tecnológica de una persona o agencia.

La recomendación práctica es preparar la documentación de titularidad antes de que el inversor la solicite.

Qué significa realmente ser titular del software

El artículo 99 TRLPI atribuye al titular del software facultades exclusivas sobre la reproducción, transformación y distribución del programa, con los límites del artículo 100. En un modelo SaaS o de licencias, además, habrá que ordenar contractualmente quién accede, en qué condiciones y qué usos están permitidos.

Por eso conviene distinguir:

Cómo proteger la titularidad del código

La protección no consiste únicamente en registrar el programa. En un proyecto serio conviene coordinar contrato, prueba y entrega técnica.

1. Identificar qué código existe antes de empezar

Debe separarse el código previo del proveedor, el código que se desarrollará específicamente, los componentes de terceros y las librerías open source. Prometer al cliente una exclusividad absoluta sobre algo que incluye tecnología ajena puede generar problemas posteriores.

2. Regular expresamente cesión, licencia y exclusividad

El contrato debe concretar qué derechos se transmiten, con qué alcance, territorio, duración y exclusividad. Si la empresa necesita poder vender el producto, licenciarlo, permitir mantenimiento por terceros o transferirlo en una operación societaria, esas necesidades deben reflejarse jurídicamente.

3. Regular la entrega del código

Un acceso de administrador no es una entrega completa. Según el proyecto, pueden ser necesarios repositorios, ramas, paquetes, scripts de despliegue, credenciales, documentación técnica, dependencias, manuales y procedimientos para que otro equipo pueda continuar el desarrollo.

4. Documentar hitos, validaciones y mantenimiento

Los sprints, entregas parciales, aceptación, corrección de errores, garantía y mantenimiento deben quedar documentados. Esto protege tanto al cliente como al desarrollador y reduce discusiones sobre qué se entregó y qué quedaba pendiente.

5. Proteger información confidencial

Antes de revelar arquitectura, roadmap, modelos comerciales o know-how, puede ser necesario un NDA o cláusulas adecuadas de confidencialidad y no uso. La protección del secreto empresarial exige también medidas razonables en la práctica, no únicamente una frase genérica en el contrato.

6. Preparar prueba de autoría y cadena de derechos

Conservar commits, versiones, documentación, contratos, cesiones, facturas y archivos originales permite reconstruir la historia del software. Cuando el activo es importante, puede estudiarse además la inscripción en el Registro de la Propiedad Intelectual conforme al Real Decreto 611/2023, Reglamento del Registro de la Propiedad Intelectual.

Si ya existe una disputa sobre copia o utilización no autorizada, antes de reclamar conviene revisar titularidad y prueba. Puede ser útil la página sobre plagio y copia de software o la de reclamación por uso no autorizado de una obra.

Matiz y criterio práctico de Pablo Maza

El criterio central del vídeo puede resumirse así: el software debe tratarse como un activo empresarial y no como una simple factura de desarrollo. La titularidad jurídica, la entrega del código y la continuidad técnica deben estar coordinadas desde el inicio.

El vídeo insiste además en que una cadena de derechos mal ordenada puede aparecer justo cuando la empresa quiere crecer, venderse o captar inversión. El criterio práctico no es «adquirir todos los derechos posibles» de forma indiscriminada, sino obtener y documentar los derechos realmente necesarios para que el modelo de negocio pueda operar, evolucionar y transmitirse sin una dependencia innecesaria.

Hay dos matices jurídicos que conviene conservar en la versión escrita. Primero, con varios fundadores no debe afirmarse automáticamente que todo el software sea una obra en colaboración: hay que analizar cómo se creó. Segundo, las cláusulas de no competencia requieren un análisis específico; no deben utilizarse como fórmula estándar cuando bastan confidencialidad, no uso y una delimitación correcta de los derechos.

Errores habituales

• Error habitual	Problema que genera
  “Lo he pagado, así que es mío”	El pago acredita una relación económica, no necesariamente una cesión plena de derechos
  “Tengo el repositorio, por tanto tengo el copyright”	Control técnico y titularidad jurídica son cuestiones distintas
  “Lo hizo un empleado, así que cualquier código es de la empresa”	Hay que comprobar si se cumplen los requisitos del artículo 97.4 del TRLPI
  “Lo hizo desde casa, así que es del trabajador”	El lugar físico donde se creó el software no determina por sí solo la titularidad
  “Somos socios, por tanto el código es de la startup”	El código creado antes de constituir la sociedad debe transmitirse, licenciarse o aportarse correctamente
  No separar código previo y código nuevo	Puede generar disputas sobre qué elementos puede reutilizar posteriormente el proveedor
  No regular la exclusividad	La cesión exclusiva debe pactarse expresamente conforme al artículo 48 del TRLPI
  No pedir documentación y entregables	Puede dejar a la empresa técnicamente cautiva del proveedor
  No revisar componentes de terceros u open source	Sus licencias pueden limitar lo que la empresa puede ofrecer a clientes o inversores
  Esperar a la due diligence para ordenar la titularidad	Es un momento especialmente problemático para empezar a negociar con antiguos socios o desarrolladores

Qué debe hacer una empresa, startup o programador

1. Identificar quién creó cada módulo y en qué fecha.
2. Clasificar la relación jurídica de cada desarrollador: empleado, freelance, agencia, socio o proveedor.
3. Revisar contratos, anexos, facturas, emails y documentación de proyecto.
4. Separar código previo, código específico y componentes de terceros.
5. Comprobar qué derechos se cedieron o licenciaron y si existe exclusividad.
6. Revisar repositorios, commits, branches, releases y control de versiones.
7. Comprobar la entrega real de código fuente, documentación y credenciales.
8. Regular la continuidad: mantenimiento, sustitución del proveedor y acceso por un nuevo equipo.
9. Documentar la transferencia del software creado por fundadores a la sociedad.
10. Preparar un dossier de titularidad antes de una inversión, compraventa o licencia relevante.

Tabla de escenarios

Preguntas frecuentes

¿Si pago a un programador el software pasa a ser mío?

No automáticamente. El pago acredita el encargo, pero el alcance de la cesión o licencia debe analizarse conforme al contrato, los artículos 43 y siguientes del TRLPI y la finalidad del acuerdo.

¿De quién es el software creado por un empleado?

Si lo crea en el ejercicio de las funciones confiadas o siguiendo instrucciones del empresario, los derechos de explotación corresponden al empresario salvo pacto en contrario, conforme al artículo 97.4 TRLPI.

¿Si el empleado programó desde su casa puede decir que el código es suyo?

El lugar desde el que trabajó no decide por sí solo. Hay que estudiar sus funciones, instrucciones y la conexión del desarrollo con la relación laboral.

¿El código creado por un fundador pertenece automáticamente a la startup?

No. Si lo creó antes de constituir la sociedad, debe comprobarse cómo se han transmitido, licenciado o aportado los derechos. Si lo creó después como trabajador dentro de sus funciones, puede operar el artículo 97.4.

¿La cesión de derechos debe constar por escrito?

El artículo 45 TRLPI exige formalización escrita. Además, una cesión exclusiva debe otorgarse expresamente con ese carácter conforme al artículo 48.

¿Necesito registrar el software para tener derechos?

No. La protección nace con la creación si concurren los requisitos legales. La inscripción es voluntaria y puede ser útil como parte de una estrategia probatoria.

¿Puedo desarrollar un programa con la misma funcionalidad que otro?

La funcionalidad no está protegida por sí sola mediante el copyright específico del programa, según el TJUE en SAS Institute. Eso no autoriza a copiar código fuente, código objeto u otros elementos protegidos.

¿Qué debería recibir cuando termina un desarrollo?

Depende del proyecto, pero normalmente conviene definir código fuente, repositorios, documentación, credenciales, dependencias, scripts, manuales, entregables y la información necesaria para que otro equipo pueda continuar el mantenimiento.

Fuentes consultadas

• Real Decreto Legislativo 1/1996, Texto Refundido de la Ley de Propiedad Intelectual, especialmente artículos 7, 8, 43, 45, 48 y 95 a 104.
• Directiva 2009/24/CE, sobre la protección jurídica de programas de ordenador.
• TJUE, asunto C-406/10, SAS Institute Inc. v. World Programming Ltd.
• Ley 1/2019, de Secretos Empresariales.
• Real Decreto 611/2023, Reglamento del Registro de la Propiedad Intelectual.
• j  Google Search Central: datos estructurados de vídeo, VideoObject y Clip.

Autor

© Pablo Maza Correa
Abogado especializado en Propiedad Intelectual, Marcas, Competencia Desleal y Derecho Digital.

Asesorarme | Contactar | Sobre Pablo Maza Abogado

Pablo Maza Correa Abogado colegiado 6472 ICAIB

Abogado especialista en Propiedad Intelectual, Propiedad Industrial, Comercio Electrónico, Redes sociales y especialista en Delitos Informáticos. Es perito informático. Trabaja en España e internacionalmente.

Ver biografía completa

Propiedad Intelectual Propiedad Industrial Marcas Patentes Copyright