Encargar el desarrollo de un sistema informático o de una aplicación a medida sin un contrato sólido es una de las decisiones más costosas que puede tomar una empresa tecnológica o industrial en España. No lo decimos en términos teóricos: en nuestra experiencia asesorando a empresas en España, la ausencia de cláusulas precisas sobre titularidad de los derechos de autor, entrega, aceptación y garantía es la causa principal de los litigios que se generan entre clientes y proveedores de software. El daño no llega cuando el contrato se firma, sino cuando se ejecuta mal, y para entonces la oportunidad de haberlo prevenido ya ha pasado.
La propiedad intelectual que genera un proyecto de software no se crea en el momento del lanzamiento del producto. Se crea línea a línea durante el desarrollo, y la legislación española sobre propiedad intelectual atribuye esos derechos, en primera instancia, al autor o autores del código. Si el proveedor es una empresa externa, ese código le pertenece a ella, no al cliente que lo encarga, salvo que el contrato establezca lo contrario de forma expresa.
Este es el error más frecuente que hemos observado. Una empresa invierte recursos significativos en el desarrollo de una plataforma y asume que, por haberla pagado, le pertenece. No es así. La transmisión de derechos de autor en España exige que conste por escrito y con el alcance que las partes hayan pactado. Sin esa cláusula, el cliente puede tener la aplicación en producción pero carecer del derecho a modificarla, licenciarla o adaptarla sin autorización del proveedor original.
La pregunta que todo director general o director tecnológico debe formularse antes de firmar cualquier acuerdo de desarrollo es esta: ¿quién controla el software cuando termine la relación contractual con el proveedor? La respuesta a esa pregunta vale más que cualquier funcionalidad técnica que la plataforma ofrezca.
El desarrollo de software en España se rige por un conjunto de ramas normativas que interactúan de forma simultánea. La normativa de propiedad intelectual protege el código fuente como obra literaria desde el momento de su creación, sin necesidad de registro previo. Esto tiene una consecuencia directa: el autor de hecho del código ostenta los derechos de explotación desde el primer día de trabajo, independientemente de quién haya financiado el proyecto.
La legislación mercantil y el Código de Comercio rigen las obligaciones de entrega, los incumplimientos contractuales y los remedios frente a ellos. La legislación sobre secreto empresarial protege el conocimiento técnico, los algoritmos propietarios y la arquitectura interna del sistema cuando se cumplen los requisitos de confidencialidad que la norma exige. Y el Reglamento General de Protección de Datos (RGPD) y la Ley Orgánica de Protección de Datos (LOPDGDD) se aplican cuando el software procesa datos personales, lo que obliga a formalizar un contrato de encargo de tratamiento entre cliente y proveedor.
En nuestra práctica hemos observado que muchas empresas abordan el encargo de software como si fuera un contrato de compraventa simple. No lo es. Es un contrato de obra con componentes de licencia, de confidencialidad, de prestación de servicios y, potencialmente, de transmisión de derechos de autor. Cada uno de esos elementos requiere cláusulas específicas. Omitir cualquiera de ellos deja brechas que el proveedor puede aprovechar, a veces sin necesidad de actuar de mala fe.
La Oficina Española de Patentes y Marcas (OEPM) y la Oficina de Propiedad Intelectual de la Unión Europea (EUIPO) son los organismos de referencia para el registro de los activos de propiedad industrial asociados al proyecto: marcas del producto o servicio resultante, diseños de interfaz y, en algunos casos, elementos técnicos que puedan optar a protección como secreto industrial. El registro de marca en España tiene una duración de diez años renovables, y la marca de la Unión Europea se tramita ante la EUIPO, con efecto en todos los Estados miembros.
Un contrato de desarrollo de software empresarial debe articularse sobre, al menos, ocho ejes que describen el alcance real de la relación entre las partes.
El primero es la titularidad y cesión de derechos de autor. El contrato debe indicar con precisión si los derechos sobre el código desarrollado se ceden al cliente, en qué modalidades de explotación y si esa cesión incluye las versiones futuras o solo la entregada en el proyecto. La cesión parcial es perfectamente válida, pero debe estar delimitada.
El segundo eje es el código fuente. La entrega del código compilado sin el código fuente priva al cliente de la capacidad de modificar, corregir o auditar el sistema. Muchos proveedores ofrecen el ejecutable como estándar. Exigir la entrega del código fuente y el depósito en garantía (escrow) es una práctica habitual en proyectos de cierta envergadura.
El tercer elemento es el régimen de aceptación y pruebas. Sin un protocolo de aceptación formal, el proveedor puede considerar que su obligación termina con la entrega técnica, aunque el sistema presente deficiencias funcionales. Las cláusulas de aceptación deben definir los criterios de conformidad, los plazos para comunicar disconformidades y las consecuencias del silencio del cliente.
El cuarto eje es la gestión de componentes de terceros. El software desarrollado a medida incorpora, casi siempre, librerías de código abierto, herramientas de terceros y módulos licenciados. El contrato debe exigir al proveedor que identifique todos esos componentes y garantice que sus licencias son compatibles con el uso previsto por el cliente. Una licencia copyleft en un módulo interno puede obligar al cliente a publicar su propio código bajo las mismas condiciones.
El quinto elemento es la confidencialidad y el secreto empresarial. El proveedor accede, durante el desarrollo, a información sensible del cliente: arquitectura de sistemas, datos de negocio, procesos internos, algoritmos propietarios. El contrato debe establecer obligaciones de confidencialidad que sobrevivan a la terminación del acuerdo, con un régimen claro de devolución o destrucción de la información al concluir el proyecto.
El sexto eje es el de garantías y mantenimiento posentrega. ¿Durante cuánto tiempo el proveedor está obligado a corregir errores del código? ¿Quién responde si el sistema falla en producción? El contrato de desarrollo no debería confundirse con el contrato de mantenimiento, pero ambos deben existir y estar coordinados.
El séptimo es la responsabilidad por incumplimiento. La legislación mercantil permite pactar penalizaciones por retraso, por entrega no conforme o por incumplimiento de niveles de servicio. Sin esas cláusulas, el cliente queda sometido al régimen general de daños y perjuicios, cuya acreditación en juicio es compleja y costosa.
El octavo eje, cuando el sistema trata datos personales, es la formalización del encargo de tratamiento conforme al RGPD. Este documento no es optativo: su ausencia constituye un incumplimiento de la normativa de protección de datos que puede dar lugar a actuaciones de la Agencia Española de Protección de Datos (AEPD). El plazo de notificación de una brecha de seguridad a la AEPD es de 72 horas desde que la empresa tiene conocimiento de ella, lo que hace indispensable que el contrato defina el flujo de comunicación entre proveedor y cliente ante incidentes.
La modalidad del proveedor altera de forma relevante el análisis jurídico. Cuando el desarrollo lo realiza una empresa, el contrato regula la relación con esa persona jurídica, y la normativa mercantil es la aplicable en primera instancia. Cuando el desarrollo lo realizan personas físicas en régimen de autónomo, aparece el riesgo de que la relación se califique como laboral, con consecuencias fiscales y de Seguridad Social potencialmente significativas.
Además, los derechos de autor del programador autónomo no se presumen cedidos al cliente por el hecho de que exista una relación de prestación de servicios. La cesión requiere, también aquí, cláusula contractual expresa. En nuestra experiencia, este es un punto ciego frecuente en empresas que trabajan con desarrolladores independientes y que solo descubren el problema cuando intentan vender la empresa o cuando el desarrollador reclama.
Cuando el equipo de desarrollo está formado por empleados de la empresa cliente, la normativa sobre propiedad intelectual establece que los derechos sobre el software creado en el marco de una relación laboral corresponden a la empresa, dentro del ámbito de sus funciones habituales y salvo pacto en contrario. Esta regla, sin embargo, debe reflejarse en los contratos laborales para evitar cualquier controversia posterior.
El director general o el director de operaciones de una empresa que encarga un desarrollo de software debe tomar varias decisiones jurídicas antes de que empiece la primera línea de código. Dejarlas para cuando el proyecto esté en marcha incrementa el coste de corrección de forma exponencial.
La primera decisión es la elección de la estructura contractual. ¿Se firma un contrato de desarrollo puro? ¿Se combina con un acuerdo de soporte y mantenimiento? ¿El sistema incluirá componentes licenciados que requieran contratos de licencia separados? La estructura determina qué documentos son necesarios y en qué secuencia deben negociarse.
La segunda es la protección paralela del resultado. Si el software que se va a desarrollar sostiene un producto o servicio que se comercializará con una marca, esa marca debe registrarse antes de lanzarse al mercado, no después. El plazo de oposición a una solicitud de marca es de dos meses desde la publicación en el boletín de la OEPM, y durante ese tiempo pueden surgir oposiciones de titulares de marcas anteriores. Iniciar el proceso de registro con suficiente antelación es una decisión de gestión, no solo jurídica.
La tercera decisión es la elección del modelo de licencia si el software resultante va a distribuirse o cederse a terceros. Los contratos de licencia de software deben definir el ámbito de uso, el territorio, la duración, las restricciones de sublicencia y el régimen de auditoría. Un contrato de licencia mal redactado puede dar lugar a usos no autorizados del software o a reclamaciones de royalties por parte del licenciante.
¿Cuándo es demasiado tarde para negociar estas condiciones? La respuesta práctica es: cuando el proveedor ya ha entregado el producto y el cliente ya lo ha puesto en producción. En ese momento, las posiciones negociadoras de las partes se han invertido, y el cliente tiene poca palanca para exigir retroactivamente cesiones de derechos o protocolos de confidencialidad que no se pactaron al inicio.
La creencia extendida en muchas pymes tecnológicas es que el asesoramiento jurídico en contratos de software es un gasto que puede diferirse. Esta percepción es incorrecta y tiene un coste real.
Hemos protegido marcas, software y secretos empresariales de compañías tecnológicas e industriales, y en todos esos encargos hemos comprobado que el coste de intervenir al inicio de la relación contractual es una fracción del coste de intervenir cuando el conflicto ya ha surgido. Un litigio sobre titularidad de derechos de autor puede extenderse durante años en los juzgados de lo mercantil, con costes de representación y con la incertidumbre añadida de no poder comercializar o modificar libremente el software mientras el proceso está abierto.
El asesoramiento temprano permite, además, identificar oportunidades que la empresa no habría detectado por sí sola. El secreto empresarial, cuando se protege correctamente mediante medidas técnicas y contractuales adecuadas, puede ser más valioso que una patente en determinados sectores tecnológicos: no caduca a los veinte años, no requiere divulgación pública y es difícilmente replicable por la competencia si las medidas de protección son sólidas. Un contrato de desarrollo bien estructurado es la primera de esas medidas.
La protección del abogado especialista en propiedad intelectual también resulta determinante cuando la empresa necesita valorar sus activos tecnológicos para una ronda de inversión, una fusión o una adquisición. Sin contratos de cesión de derechos documentados, sin marcas registradas y sin acuerdos de confidencialidad firmados, la diligencia debida (due diligence) de cualquier inversor detectará los riesgos y los reflejará en una valoración menor o en condiciones de inversión más restrictivas.
Para profundizar en las cuestiones de propiedad intelectual aplicadas al entorno tecnológico y empresarial, puede consultar nuestra sección dedicada a la práctica de propiedad intelectual y tecnología en Velarde & Vidal.
El primero es que «con tener la marca registrada en España ya está todo protegido». Es un malentendido costoso. El registro de marca en la Oficina Española de Patentes y Marcas protege el signo en el territorio nacional, pero no otorga derechos sobre el código, sobre los secretos técnicos ni sobre los datos. Tampoco protege frente a infracciones que se producen en otros países de la Unión Europea o fuera de ella. El alcance del registro, los contratos de licencia y la protección del secreto empresarial son los instrumentos que, juntos, definen quién controla el intangible.
El segundo mito es que «el software es demasiado técnico para litigar sobre él». Los juzgados de lo mercantil cuentan con experiencia en conflictos sobre propiedad intelectual de software. La prueba pericial informática está consolidada como instrumento probatorio en estos procesos, y los tribunales españoles han resuelto con regularidad disputas sobre titularidad de código, incumplimiento de contratos de desarrollo y apropiación indebida de secretos empresariales.
El tercero es que «un acuerdo verbal entre partes que se conocen desde hace años es suficiente». La legislación española exige la forma escrita para la transmisión de derechos de autor. Un acuerdo verbal sobre la titularidad del software no es jurídicamente eficaz, con independencia de la confianza que exista entre las partes y de cuántos años lleven trabajando juntas.
Si su empresa trabaja con proveedores tecnológicos en sectores específicos y desea conocer las implicaciones concretas para su industria, le recomendamos revisar nuestro análisis sobre contratos SaaS y las cláusulas que importan en entornos sectoriales.
La dirección de una empresa que está a punto de suscribir un contrato de desarrollo de software puede utilizar las siguientes verificaciones como punto de partida. Este listado no sustituye al análisis jurídico del contrato concreto, pero permite identificar las lagunas más frecuentes antes de entrar en negociación.
Esta verificación es la que una empresa debería completar antes de iniciar cualquier negociación. Si alguna respuesta es negativa, es el momento de actuar. Para más información sobre las implicaciones de la propiedad intelectual en sectores específicos, puede consultar nuestras preguntas frecuentes sobre propiedad intelectual en entornos empresariales.
El asesoramiento en contratos de desarrollo de software se conecta de forma natural con la protección de marcas ante la OEPM y la EUIPO, el registro y gestión de patentes, la negociación de contratos de licencia de software y los procedimientos de diligencia debida tecnológica en operaciones de M&A. En Velarde & Vidal asesoramos de forma integrada en todos esos ámbitos, de modo que el cliente no tenga que coordinar a distintos asesores en aspectos que, desde la perspectiva jurídica, son inseparables.
Si su empresa está en proceso de estructurar una operación corporativa que incluye activos tecnológicos, puede ser relevante revisar conjuntamente la cobertura de nuestra práctica de Derecho societario y operaciones, dado que la valoración de los intangibles y la cadena de titularidad del software son elementos de primer orden en cualquier proceso de fusión o adquisición.
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.