Una empresa puede invertir meses en desarrollar una aplicación, una plataforma SaaS o una herramienta interna y descubrir demasiado tarde que no tiene documentada la titularidad del código. El problema suele aparecer en una ronda de inversión, una venta de la sociedad, una salida conflictiva de un socio técnico o una reclamación de un desarrollador externo.
El problema es que cuando se encarga el desarrollo del programa, app, etc. a un tercero (a un informático autónomo, a una empresa de software, etc.) este mantendrá la propiedad intelectual a menos que nos e haya pactado lo contario (aunque la aplicación haya costado una fortuna). Lo que quiere decir que, salvo que haya acordado algo, ese desarrollador puede vender la misma aplicación a tu próxima competencia.
En el ámbito de la empresa la regla específica para el software creado por trabajadores asalariados: es la siguiente: si el programa se crea en el ejercicio de sus funciones o siguiendo instrucciones del empresario, los derechos de explotación corresponden exclusivamente al empresario, salvo pacto en contrario.
Pero esa regla no soluciona todos los casos. No cubre igual a freelancers, agencias externas, socios fundadores sin contrato claro, becarios, colaboradores internacionales, contribuciones open source o desarrollos realizados antes de constituir la empresa. Para asegurar que el código pertenece realmente a la empresa, hay que combinar contratos, trazabilidad técnica y una política interna de propiedad intelectual.
¿Qué se entiende por software protegido por propiedad intelectual?
La Ley de Propiedad Intelectual define el programa de ordenador como una secuencia de instrucciones o indicaciones destinada a ser utilizada, directa o indirectamente, en un sistema informático para realizar una función, tarea o resultado. La protección alcanza cualquier forma de expresión del programa, sus versiones sucesivas y los programas derivados, pero no las ideas y principios que sirven de base al programa o a sus interfaces.
Esto significa que la propiedad intelectual protege la forma concreta en la que se expresa el software, no la idea empresarial en abstracto.
| Elemento | ¿Puede estar protegido? | Comentario práctico |
|---|---|---|
| Código fuente | Sí | Es el activo principal que debe quedar documentado. |
| Código objeto | Sí | La ley menciona expresamente programa fuente y programa objeto en el contexto laboral. |
| Documentación preparatoria | Sí | Puede incluir análisis funcional, arquitectura o documentación técnica vinculada al desarrollo. |
| Manuales de uso | Sí | Tienen la misma protección que el programa en el marco del título dedicado al software. |
| Versiones sucesivas | Sí | Conviene documentar releases, ramas y contribuciones. |
| Programas derivados | Sí | Hay que revisar si derivan de código propio, ajeno u open source. |
| Ideas, métodos o principios | No por copyright | Pueden tener otra protección contractual o, en ciertos casos, industrial, pero no como derecho de autor sobre software. |
¿A quién pertenece el código creado por empleados?
En el caso de trabajadores asalariados, la regla clave está en el artículo 97.4 de la Ley de Propiedad Intelectual. Cuando un trabajador crea un programa de ordenador en el ejercicio de las funciones que le han sido confiadas o siguiendo instrucciones del empresario, los derechos de explotación sobre el programa, tanto fuente como objeto, corresponden exclusivamente al empresario, salvo pacto en contrario.
La empresa parte, por tanto, de una posición favorable cuando el desarrollo encaja claramente dentro de las funciones del trabajador. Aun así, no conviene depender solo de la presunción legal. En una auditoría, una due diligence o un conflicto, la empresa deberá poder probar que el código fue creado dentro del marco laboral, con medios de la empresa, instrucciones de la empresa y para un proyecto de la empresa.
Qué debe revisar la empresa en los contratos laborales
| Punto del contrato | Por qué importa |
|---|---|
| Descripción del puesto | Debe reflejar que el trabajador desarrolla, mantiene, documenta o participa en software. |
| Cláusula de propiedad intelectual | Debe confirmar la titularidad empresarial de los derechos de explotación sobre el software creado en el marco de la relación laboral. |
| Confidencialidad | Protege código, arquitectura, repositorios, credenciales, documentación técnica y roadmap. |
| Uso de herramientas | Debe regular GitHub, GitLab, Jira, Notion, Figma, entornos cloud, cuentas corporativas y dispositivos. |
| Proyectos personales | Conviene separar claramente proyectos propios del empleado y desarrollos de la empresa. |
| Entrega de materiales | Debe prever la devolución o entrega de código, documentación, accesos y credenciales al finalizar la relación. |
| No incorporación de código ajeno | Reduce el riesgo de que el empleado introduzca librerías, snippets o código de terceros sin autorización. |
¿Qué pasa con el software creado por freelancers o agencias externas?
Aquí está uno de los errores más frecuentes. La regla del artículo 97.4 se refiere al trabajador asalariado. Un freelance, una agencia de desarrollo o un proveedor tecnológico no son trabajadores asalariados de la empresa. Si no hay una cesión de derechos clara, la empresa puede haber pagado por el desarrollo, pero no necesariamente tener todos los derechos de explotación necesarios.
El artículo 43 de la Ley de Propiedad Intelectual exige que la cesión de derechos de explotación quede limitada a los derechos cedidos, las modalidades de explotación, el tiempo y el ámbito territorial. Además, la ley indica que la transmisión no alcanza modalidades de utilización o medios de difusión inexistentes o desconocidos al tiempo de la cesión.
En contratos con proveedores, esto obliga a redactar con precisión. No basta con una factura que diga “desarrollo web”, “app móvil” o “servicios de programación”.
Cláusulas mínimas en contratos con freelancers y proveedores
| Cláusula | Qué debe cubrir |
|---|---|
| Cesión de derechos | Reproducción, transformación, adaptación, distribución, comunicación cuando proceda y explotación del software. |
| Alcance territorial | España, Unión Europea o mundial, según el proyecto. |
| Duración | Preferiblemente por todo el plazo legal permitido, cuando sea coherente con el acuerdo. |
| Exclusividad | Si la empresa necesita que el código sea exclusivo, debe indicarse expresamente. |
| Código fuente | Obligación de entregar repositorio, documentación, dependencias, claves de despliegue y versiones. |
| Garantía de originalidad | El proveedor debe declarar que el código no infringe derechos de terceros. |
| Open source | Inventario de librerías, licencias y restricciones. |
| Subcontratación | Identificación y cesión de derechos de subcontratistas. |
| IA generativa | Declaración sobre uso de herramientas de IA y revisión de derechos, confidencialidad y trazabilidad. |
| Soporte y mantenimiento | Separar titularidad del código de servicios posteriores de mantenimiento. |
¿Qué derechos necesita realmente la empresa sobre el software?
El titular de derechos sobre un programa de ordenador puede autorizar o realizar actos esenciales como la reproducción total o parcial, la traducción, adaptación, arreglo o transformación, y la distribución pública del programa. La Ley de Propiedad Intelectual también regula límites para el usuario legítimo, como ciertos actos necesarios para utilizar el programa, incluida la corrección de errores, salvo disposición contractual en contrario.
Para una empresa tecnológica, esto se traduce en una pregunta práctica: ¿puede la empresa usar, modificar, escalar, vender, licenciar, integrar, migrar, auditar y transmitir el software sin pedir autorización adicional?
| Necesidad empresarial | Derecho o protección necesaria |
|---|---|
| Usar el software internamente | Derecho de uso y reproducción técnica. |
| Comercializar un SaaS | Derechos suficientes de explotación, adaptación y mantenimiento. |
| Modificar el código | Derecho de transformación y acceso completo al código fuente. |
| Vender la empresa | Cadena de titularidad documentada y transmisible. |
| Levantar inversión | Contratos laborales, cesiones de freelancers y auditoría open source. |
| Licenciar a clientes | Derechos para conceder licencias o sublicencias si procede. |
| Integrar código de terceros | Licencias compatibles y documentación de dependencias. |
| Defenderse ante copias | Prueba de autoría, fecha, repositorios, contratos y registros. |
Diagrama: cómo debe fluir la titularidad del código hacia la empresa
¿Qué ocurre con el código creado por socios fundadores?
En startups y empresas tecnológicas, una parte relevante del código puede nacer antes de que exista una estructura jurídica ordenada. Un fundador puede haber programado el MVP antes de constituir la sociedad, desde su cuenta personal de GitHub, con herramientas propias y sin pacto de socios.
Este punto debe resolverse cuanto antes. Si el software fue creado antes de la constitución de la sociedad, la empresa no debería asumir automáticamente que el código ya le pertenece. Lo correcto es documentar una aportación o cesión de derechos a favor de la sociedad, alineada con el pacto de socios y con la realidad fiscal y mercantil de la operación.
Riesgos habituales en startups
| Situación | Riesgo |
|---|---|
| MVP creado antes de constituir la sociedad | El fundador puede seguir siendo titular si no hay cesión documentada. |
| Código en repositorio personal | Dificulta probar control empresarial y continuidad del activo. |
| Salida de CTO o socio técnico | Puede bloquear mantenimiento, venta o inversión si no hay pacto claro. |
| Desarrollo por amigos o colaboradores informales | Riesgo de reclamaciones futuras por autoría o remuneración. |
| Uso de snippets, plantillas o librerías sin control | Riesgo de infracción o incompatibilidad de licencias. |
| Ausencia de pacto de socios | Falta de reglas sobre titularidad, dedicación, salida y no competencia. |
¿Es suficiente registrar el software?
El registro puede ayudar como prueba, pero no sustituye a una buena cadena contractual. La Ley de Propiedad Intelectual permite inscribir derechos sobre programas de ordenador, versiones sucesivas y programas derivados en el Registro de la Propiedad Intelectual.
El registro puede ser útil para acreditar una fecha, una versión y una titularidad declarada. Sin embargo, si el código fue creado por un proveedor que nunca cedió los derechos, o por un socio que no aportó formalmente el activo a la sociedad, el registro por sí solo no elimina el problema de fondo.
La estrategia correcta suele combinar:
| Herramienta | Función |
|---|---|
| Contratos laborales | Alinear funciones, propiedad intelectual y confidencialidad. |
| Contratos mercantiles | Obtener cesión expresa de freelancers, agencias y consultores. |
| Pacto de socios | Regular aportación del software, salida de fundadores y no uso posterior. |
| Registro de propiedad intelectual | Reforzar prueba sobre versiones relevantes. |
| Repositorios corporativos | Probar trazabilidad técnica, commits y control de accesos. |
| Inventario open source | Detectar licencias, restricciones y obligaciones de atribución. |
| Auditoría legal y técnica | Preparar inversión, adquisición o venta. |
Checklist para asegurar que el código pertenece a la empresa
Antes de una ronda de inversión, una venta de la sociedad o el lanzamiento de un producto digital, conviene revisar estos puntos:
| Área | Pregunta de control | Estado |
|---|---|---|
| Empleados | ¿Los desarrolladores tienen contrato laboral con funciones técnicas claras? | Pendiente / Revisado |
| Propiedad intelectual | ¿Existe cláusula específica de software y derechos de explotación? | Pendiente / Revisado |
| Freelancers | ¿Todos los externos han firmado cesión de derechos suficiente? | Pendiente / Revisado |
| Subcontratistas | ¿Los proveedores garantizan la cesión de sus propios colaboradores? | Pendiente / Revisado |
| Fundadores | ¿El código preexistente fue cedido o aportado formalmente a la sociedad? | Pendiente / Revisado |
| Repositorios | ¿El código está en cuentas corporativas y no personales? | Pendiente / Revisado |
| Open source | ¿Hay inventario de librerías y licencias? | Pendiente / Revisado |
| IA generativa | ¿Se ha documentado si se usó IA para generar código? | Pendiente / Revisado |
| Documentación | ¿Hay documentación técnica suficiente para mantener el software? | Pendiente / Revisado |
| Registro | ¿Conviene registrar una versión relevante del software? | Pendiente / Revisado |
| Due diligence | ¿La empresa puede demostrar la cadena completa de titularidad? | Pendiente / Revisado |
¿Cómo afecta el uso de software open source?
El uso de librerías open source es normal en cualquier proyecto tecnológico. El problema no es usar open source, sino no saber qué se está usando y bajo qué condiciones.
Algunas licencias son permisivas y permiten un uso amplio, incluso comercial. Otras imponen obligaciones de atribución, publicación de modificaciones o distribución bajo la misma licencia. En una empresa SaaS, marketplace, fintech, healthtech o plataforma digital, una dependencia mal controlada puede generar problemas en contratos con clientes, auditorías de seguridad, due diligence o venta de la compañía.
La empresa debería mantener un inventario actualizado de dependencias, revisar licencias y documentar qué componentes son propios, cuáles son de terceros y cuáles están sujetos a obligaciones específicas.
¿Qué pasa si un trabajador desarrolla código fuera del horario laboral?
La respuesta depende de los hechos. Si el software se creó fuera del horario laboral, con medios propios, sin instrucciones de la empresa y para un proyecto ajeno a las funciones del trabajador, la empresa tendrá más difícil sostener que le pertenecen los derechos de explotación.
En cambio, si el desarrollo se relaciona con las funciones del empleado, responde a instrucciones del empresario, usa recursos corporativos o se integra en productos de la empresa, la posición empresarial será más sólida.
Para evitar conflictos, conviene regular por escrito:
| Situación | Recomendación |
|---|---|
| Proyectos personales del empleado | Declararlos y separarlos del trabajo de la empresa. |
| Uso de equipos corporativos | Prohibir o limitar desarrollos ajenos en dispositivos y cuentas de la empresa. |
| Repositorios personales | Evitar que código corporativo se aloje en cuentas personales. |
| Side projects relacionados | Exigir comunicación previa cuando puedan competir o solaparse con la actividad de la empresa. |
| Invenciones o desarrollos internos | Documentar instrucciones, tareas y entregables. |
¿Qué debe revisar una empresa antes de comprar software o contratar un desarrollo a medida?
Antes de pagar por un desarrollo relevante, la empresa debe saber si está comprando una licencia de uso, una cesión de derechos o un servicio de desarrollo con entrega de código. Son figuras distintas y tienen consecuencias distintas.
| Modelo | Qué recibe la empresa | Riesgo si no se define bien |
|---|---|---|
| Licencia de uso | Derecho a usar el software bajo condiciones | Puede no poder modificar, revender o sublicenciar. |
| Desarrollo a medida sin cesión clara | Un entregable funcional | El proveedor puede conservar derechos relevantes. |
| Desarrollo con cesión de derechos | Derechos de explotación pactados | Es el modelo más adecuado si el software será activo estratégico. |
| SaaS externo | Acceso a un servicio | La empresa no adquiere el código, solo usa la plataforma. |
| Compra de activo tecnológico | Código, documentación, derechos y garantías | Requiere due diligence jurídica y técnica. |
Errores frecuentes que conviene evitar
- Pensar que pagar una factura equivale a adquirir todos los derechos sobre el código.
- Contratar freelancers sin cláusula de cesión de propiedad intelectual.
- Usar repositorios personales para proyectos corporativos.
- No regular la salida de un socio técnico.
- No inventariar librerías open source.
- No documentar el código creado antes de constituir la sociedad.
- Mezclar código de clientes, proyectos anteriores o plantillas sin autorización.
- No revisar contratos antes de una inversión o venta.
- No exigir entrega de documentación técnica.
- No controlar credenciales, accesos y entornos cloud.
Recomendaciones legales para empresas tecnológicas
Para asegurar la titularidad del software, la empresa debería adoptar una política interna sencilla y constante:
- Contratos laborales con funciones técnicas claras.
- Cláusulas específicas de propiedad intelectual para desarrolladores, product managers, diseñadores técnicos y perfiles que creen documentación funcional.
- Contratos mercantiles con cesión expresa para freelancers, agencias y consultores.
- Pacto de socios que regule aportación del software y salida de fundadores.
- Repositorios corporativos con control de accesos.
- Inventario de dependencias open source.
- Procedimiento de revisión cuando se use IA generativa para código.
- Registro de versiones relevantes cuando tenga sentido probatorio.
- Auditoría legal antes de rondas, compraventas, licencias estratégicas o integraciones con grandes clientes.
Conclusión
El software puede ser uno de los activos más valiosos de una empresa, pero su titularidad no debe darse por supuesta. La regla legal es favorable para el software creado por trabajadores asalariados dentro de sus funciones, pero los principales riesgos aparecen en zonas menos ordenadas: freelancers, agencias, socios fundadores, repositorios personales, librerías de terceros y desarrollos previos a la constitución de la sociedad.
La empresa que documenta bien la cadena de titularidad del código gana seguridad para operar, vender, licenciar, levantar inversión y defender su producto frente a terceros.
En Conesa Legal revisamos contratos laborales, contratos mercantiles, pactos de socios y documentación de propiedad intelectual para empresas tecnológicas, startups y compañías que desarrollan software propio.
Explíquenos su caso y revisaremos si la titularidad del software está correctamente protegida.
Preguntas frecuentes sobre propiedad intelectual del software
¿El software pertenece automáticamente a la empresa si lo crea un empleado?
Si el trabajador asalariado crea el programa en el ejercicio de sus funciones o siguiendo instrucciones del empresario, los derechos de explotación corresponden exclusivamente al empresario, salvo pacto en contrario. Aun así, es recomendable que el contrato laboral lo regule expresamente.
¿Una factura de un freelance demuestra que el código pertenece a la empresa?
No necesariamente. La factura prueba un pago, pero no siempre una cesión completa de derechos de explotación. Para evitar dudas, el contrato debe especificar qué derechos se ceden, con qué alcance, durante cuánto tiempo y en qué territorio.
¿Puede la empresa modificar el código desarrollado por un proveedor externo?
Solo si tiene derechos suficientes para hacerlo. La modificación del software forma parte de los derechos de explotación regulados por la Ley de Propiedad Intelectual, por lo que debe estar cubierta por contrato cuando el desarrollo lo realiza un tercero.
¿Conviene registrar el software?
Puede ser recomendable para versiones relevantes, especialmente si el software es un activo estratégico. El registro ayuda como prueba, pero no sustituye a contratos bien redactados ni a una cadena clara de cesión de derechos.
¿Qué pasa si un socio fundador programó el MVP antes de crear la sociedad?
Debe documentarse una cesión o aportación del software a favor de la sociedad. Sin ese paso, puede haber dudas sobre si la sociedad es realmente titular del código.
¿El uso de código open source impide que el software sea de la empresa?
No necesariamente. Depende de la licencia aplicable. Lo importante es inventariar las librerías, revisar sus condiciones y comprobar que son compatibles con el modelo de negocio.
¿Qué documentación pide un inversor sobre propiedad intelectual del software?
Normalmente revisará contratos laborales, cesiones de freelancers, pacto de socios, titularidad de repositorios, licencias open source, documentación técnica, historial de versiones y posibles reclamaciones de terceros.
Fuentes legales principales
- Real Decreto Legislativo 1/1996, de 12 de abril, Texto Refundido de la Ley de Propiedad Intelectual.
- Artículos 43, 51, 95, 96, 97, 99, 100, 101 y 102 de la Ley de Propiedad Intelectual.
- Directiva 2009/24/CE sobre la protección jurídica de programas de ordenador.
Abogados para proteger la propiedad intelectual del software y crear contratos de cesión de código
-
Si vuestra startup, SaaS o agencia de desarrollo no tiene claro quién es dueño del código, el mejor momento para corregirlo es antes de la próxima ronda, del próximo contrato enterprise o de la salida de un developer clave.
En Conesa Legal podemos ayudaros a:
- crear contratos de desarrollo de software, contratos con freelancers, acuerdos con agencias y cláusulas de cesión de derechos adaptadas a vuestro modelo de negocio;
- revisar contratos de empleados, freelancers y agencias para blindar la cesión de derechos sobre el código fuente;
- preparar una due diligence de software antes de una inversión, venta de empresa o entrada de nuevos socios;
- auditar riesgos de open source, repositorios y aportaciones de terceros;
- diseñar la estrategia jurídica y probatoria en conflictos por copia de código, salida de fundadores o apropiación de software.
- a negociar y formalizar contratos para recuperar la titularidad del producto
