Muchas empresas encargamos proyectos de software sin un contrato que defina quién es propietario del código al terminar el trabajo. Ese vacío no es un tecnicismo: es la diferencia entre controlar el activo digital más valioso de la compañía o descubrir que pertenece al proveedor. La oportunidad de resolver esto desaparece en el momento en que el proyecto se lanza a producción sin un documento firmado.
La normativa española de propiedad intelectual parte de una premisa que sorprende a muchos directivos: el software es una obra intelectual protegida, y su autor –quien lo escribe– conserva los derechos desde el momento de la creación. No hace falta registro. No hace falta declaración. El derecho nace solo.
Esto significa que una empresa que encarga el desarrollo de un sistema de gestión, una aplicación móvil o una plataforma de comercio electrónico no obtiene automáticamente la titularidad del resultado. Obtiene, a lo sumo, una licencia de uso implícita y de alcance incierto. Cualquier explotación comercial adicional –vender el software a terceros, modificarlo, integrarlo en otro producto– puede quedar fuera del perímetro de lo que el cliente "compró".
La única forma de transferir esos derechos de forma válida es mediante una cesión escrita, específica y clara. En nuestra experiencia asesorando a empresas tecnológicas e industriales, este es el error más costoso que cometemos antes de llamar a un abogado: asumir que el pago implica la propiedad. No la implica.
El mismo principio se aplica a los trabajadores por cuenta ajena: cuando un empleado desarrolla software en el marco de sus funciones, los derechos se ceden por ley a la empresa empleadora. Pero cuando se contrata a un freelance, a una agencia o a una consultora externa, esa cesión automática no existe. El contrato debe crearla expresamente.
Un contrato de desarrollo de software no es un contrato de obra cualquiera. Combina elementos de la legislación de propiedad intelectual, del Código de Comercio y, cuando hay datos personales involucrados, del Reglamento General de Protección de Datos (RGPD). Cada bloque cumple una función distinta.
Esta es la cláusula más crítica. Debe especificar si el cliente adquiere la titularidad plena del código (cesión de derechos) o únicamente una licencia de uso. La cesión es preferible cuando el software es el activo central del negocio. La licencia puede ser suficiente cuando el cliente utiliza una plataforma estándar adaptada.
La cláusula debe indicar: el ámbito territorial, la duración, si la cesión es exclusiva o no exclusiva, y si incluye el derecho a modificar y sublicenciar. Omitir cualquiera de estos extremos genera una zona gris que, en la práctica, beneficia al cedente.
¿Qué entrega exactamente el desarrollador? Un contrato sin especificaciones técnicas adjuntas convierte cualquier disputa en una guerra de versiones: el proveedor dirá que entregó lo acordado; el cliente afirmará que no. Los criterios de aceptación –las pruebas concretas que el software debe superar– son la única forma objetiva de resolver ese conflicto.
El documento debe referenciar las especificaciones funcionales y técnicas como anexo contractual. Ese anexo tiene el mismo valor jurídico que el cuerpo del contrato. Si las especificaciones cambian durante el desarrollo –lo habitual en proyectos ágiles–, el contrato debe prever un mecanismo de modificación (el llamado change request) que quede documentado por escrito.
El desarrollador accede, necesariamente, a información sensible del cliente: arquitectura de sistemas, modelos de negocio, bases de datos de clientes, estrategia de producto. La normativa española de secreto empresarial protege esa información, pero solo si la empresa ha tomado medidas razonables para preservar su confidencialidad. Un contrato de confidencialidad (NDA, por sus siglas en inglés) es la medida más visible y exigible.
El acuerdo de confidencialidad (NDA) debe definir qué información queda protegida, durante cuánto tiempo y qué consecuencias tiene su divulgación. Hemos observado que muchas empresas firman NDA genéricos que no definen el perímetro de la información protegida. Esa vaguedad puede hacer el acuerdo ineficaz ante un juzgado.
El contrato debe fijar un calendario de entregas con hitos verificables. No basta con una fecha final. Los proyectos de desarrollo se dilatan; sin hitos intermedios, la empresa no tiene base contractual para actuar hasta que el retraso es irreversible.
Las cláusulas de penalización por retraso son legítimas y ejecutables en España, siempre que sean proporcionales. Una cláusula penal desproporcionada puede ser moderada judicialmente. La recomendación práctica es calibrar la penalización en relación con el perjuicio efectivo, no con el precio total del contrato.
El contrato debe distinguir entre la garantía de funcionamiento del software (generalmente, un período tras la aceptación en el que el proveedor corrige defectos sin coste) y los servicios de mantenimiento evolutivo y correctivo que, en su caso, se contratarán aparte. Sin esa distinción, el cliente puede creer que tiene soporte indefinido y el proveedor puede creer que su obligación terminó con la entrega.
La mayoría de los desarrollos modernos incorporan librerías de código abierto, componentes de terceros y herramientas con licencias propias. Algunas de esas licencias –las denominadas copyleft– imponen condiciones sobre cómo puede distribuirse el software resultante. Un contrato bien redactado exige al desarrollador declarar todo el software de terceros que incorpora y garantizar que las licencias son compatibles con el uso previsto por el cliente.
Esta cláusula es especialmente relevante si la empresa prevé comercializar el software o integrarlo en un producto que venderá a terceros. Es una de las áreas que analizamos con más detalle cuando realizamos una diligencia debida (due diligence) de activos de propiedad intelectual antes de una operación corporativa.
La negociación del contrato no es un trámite posterior al acuerdo comercial. Es parte del acuerdo. Las decisiones que se toman en esa fase determinan el control que la empresa tendrá sobre su propio producto digital.
La cesión plena de derechos da a la empresa la libertad máxima: puede modificar el software, sublicenciarlo, venderlo, integrarlo en otro producto. Es la opción adecuada cuando el software es el producto principal o cuando la empresa anticipa una venta de activos o una ronda de financiación en la que los inversores auditarán la titularidad del código.
La licencia exclusiva puede ser suficiente cuando el coste de la cesión es prohibitivo o cuando el proveedor es también el mantenedor y su motivación para mejorar el producto depende de conservar los derechos. Pero la licencia exclusiva no protege a la empresa si el proveedor quiebra: en ese caso, el código puede quedar en la masa del concurso de acreedores.
¿Cuál es la decisión correcta para su empresa? Depende de si el software es un activo estratégico o una herramienta operativa. Esa distinción vale la pena hacerla antes de negociar, no después.
Cuando la empresa obtiene solo una licencia –y el código fuente queda en manos del proveedor–, el escrow de código fuente es una herramienta de gestión de riesgos habitual. Consiste en depositar el código fuente en manos de un tercero neutral, que lo libera al cliente si el proveedor incumple ciertas condiciones (quiebra, incumplimiento del mantenimiento, desaparición del negocio).
El escrow no es costoso. Su ausencia, en cambio, puede paralizar operaciones si el proveedor deja de estar disponible.
Un contrato sin cláusula de resolución de conflictos remite a los juzgados ordinarios. En disputas de cierta complejidad técnica, el arbitraje –especialmente ante instituciones especializadas– puede ser más eficiente: confidencialidad del procedimiento, árbitros con conocimiento técnico, plazos más predecibles.
La cláusula de elección de ley y jurisdicción adquiere especial importancia en contratos con proveedores extranjeros. Sin ella, determinar qué tribunal es competente puede convertirse en el primer litigio antes del litigio principal.
El contrato de desarrollo es el primer eslabón. No es el único.
El software, como obra intelectual, queda protegido por la normativa de propiedad intelectual desde su creación, sin necesidad de registro formal. Sin embargo, el registro voluntario ante el Registro de la Propiedad Intelectual proporciona una fecha cierta que puede ser valiosa en caso de disputa sobre la autoría o la titularidad.
Más allá del registro, la empresa puede complementar la protección contractual con otros instrumentos. Si el software incorpora una innovación técnica susceptible de protección industrial, una patente ante la Oficina Española de Patentes y Marcas (OEPM) puede ser la vía adecuada. El nombre comercial del producto o la plataforma –la marca bajo la que se comercializa– puede registrarse tanto en España a través de la OEPM como en el ámbito de la Unión Europea a través de la Oficina de Propiedad Intelectual de la Unión Europea (EUIPO), con sede en Alicante.
El secreto empresarial, por su parte, protege el know-how que no se puede o no se quiere patentar: algoritmos, modelos de datos, arquitectura de sistemas. La condición es que la empresa haya adoptado medidas razonables de reserva. Sin esas medidas documentadas, la protección es teórica.
Hemos protegido marcas, software y secretos empresariales de compañías tecnológicas e industriales. La experiencia nos indica que la combinación de contrato sólido, registro de marca y política interna de secreto empresarial es lo que realmente define quién controla el intangible, no el registro aislado de ninguno de esos elementos.
Una empresa que crea valor en intangibles pero no ha registrado ni protegido su marca, su tecnología o su know-how es vulnerable. La creencia de que con tener la marca registrada en España ya está todo cubierto es uno de los errores más frecuentes que observamos. El alcance del registro, los contratos de licencia y la protección del secreto empresarial son los tres vectores que definen quién controla el intangible.
Para profundizar en la estrategia de protección de activos intangibles en el contexto de una operación corporativa, puede consultar nuestro análisis sobre la diligencia debida de propiedad intelectual en operaciones de M&A.
La práctica de nuestra firma indica que los problemas en contratos de desarrollo no suelen derivar de cláusulas mal redactadas. Suelen derivar de cláusulas que no existen.
Primer error: no incluir la cesión de derechos. Es el más común y el más costoso. La empresa paga el desarrollo y asume que es propietaria. No lo es hasta que hay un documento que lo dice.
Segundo error: no adjuntar las especificaciones técnicas. Sin especificaciones como anexo contractual, cualquier disputa sobre el alcance del proyecto es imposible de resolver objetivamente. La versión del proveedor y la del cliente divergen siempre.
Tercer error: prescindir del régimen de garantías post-entrega. El software no funciona perfectamente el día de la entrega. Siempre hay defectos que emergen en producción. Sin un período de garantía definido y con obligaciones claras, el cliente no tiene base contractual para exigir correcciones sin coste.
Cuarto error: no regular el tratamiento de datos personales. Cuando el software procesa datos de clientes, empleados o usuarios, el desarrollador actúa como encargado del tratamiento según el RGPD. El contrato debe incluir las cláusulas que exige la normativa de protección de datos: finalidad del tratamiento, medidas de seguridad, subcontrataciones, notificación de brechas. La ausencia de estas cláusulas expone a la empresa a sanciones de la Agencia Española de Protección de Datos (AEPD). El plazo para notificar una brecha de seguridad a la AEPD es de setenta y dos horas desde que la empresa tiene conocimiento de ella: sin la estructura contractual adecuada, ese plazo puede ser imposible de cumplir.
Quinto error: no prever la resolución anticipada del contrato. Los proyectos se abandonan. Las relaciones comerciales se rompen. El contrato debe regular qué ocurre con el código parcialmente desarrollado, con los pagos realizados y con las obligaciones de confidencialidad si el proyecto no llega a su fin.
La pregunta que recibimos con más frecuencia no es "¿necesitamos un contrato?", sino "¿cuándo debemos llamar al abogado?". La respuesta es: antes de compartir información sensible con el proveedor. No después.
El ciclo habitual de un proyecto de desarrollo sigue este esquema: la empresa busca proveedores, comparte las especificaciones del proyecto, recibe propuestas económicas y, solo cuando ha seleccionado proveedor, piensa en el contrato. Para entonces, ha compartido su modelo de negocio, su arquitectura de sistema y, en ocasiones, su código existente, sin ninguna protección contractual.
El acuerdo de confidencialidad debe firmarse antes de la primera reunión técnica de detalle. El contrato de desarrollo, antes del inicio del trabajo. El escrow de código, si procede, al mismo tiempo que el contrato.
En nuestra experiencia, el asesoramiento temprano no solo reduce el riesgo. Reduce el coste total. Un contrato bien negociado desde el inicio evita litigios cuyo coste supera con frecuencia el precio de todo el proyecto de desarrollo.
Si su empresa está evaluando cómo estructurar un contrato de desarrollo de software, puede consultar nuestra práctica de propiedad intelectual y tecnología para una visión completa del marco de protección disponible.
A modo de resumen operativo, estas son las verificaciones que recomendamos antes de firmar cualquier contrato de desarrollo de software:
Para empresas del sector industrial o manufacturero que desarrollan software como parte de su proceso productivo o de su producto, el análisis de la protección del intangible tecnológico tiene dimensiones adicionales que abordamos en nuestra guía sobre protección del intangible en industria y manufactura.
La redacción de contratos de desarrollo de software es una pieza de una estrategia más amplia de protección del intangible. En Velarde & Vidal también asesoramos en la negociación de contratos de licencia de software, en la estructuración de acuerdos de cesión de derechos en operaciones de fusión y adquisición, y en el diseño de políticas de secreto empresarial. Cuando el proyecto implica tratamiento masivo de datos o el desarrollo de sistemas de inteligencia artificial, la intersección con la normativa de protección de datos y con la legislación emergente sobre IA añade capas de complejidad que conviene anticipar.
Para una primera valoración, escríbanos a info@velardevidal.com.
Plantear mi casoEste contenido es informativo y no constituye asesoramiento jurídico. Para un análisis de su situación, contacte con info@velardevidal.com.