El sector de la automoción ya no compite solo en mecánica o diseño. Compite, sobre todo, en software. Los sistemas de asistencia a la conducción, las plataformas de conectividad, los módulos de diagnóstico remoto y el código embebido en unidades de control son hoy los activos más valiosos de cualquier fabricante o proveedor de componentes. Y son activos que, con frecuencia, se crean a través de encargos externos: contratos de desarrollo suscritos con proveedores tecnológicos, startups de ingeniería o integradores especializados. Un contrato mal redactado en ese momento puede costar a la empresa el control definitivo sobre el intangible más relevante de su modelo de negocio.
La cadena de suministro del automóvil moderno integra decenas de proveedores de software en distintas capas del vehículo. Cada capa genera código: código de propósito específico, a menudo crítico para la seguridad funcional del producto final. Esa cadena plantea una pregunta que el contrato debe responder antes de que se escriba la primera línea de código.
¿Quién es titular del resultado?
En nuestra experiencia asesorando a empresas del sector, esta pregunta se deja sin responder con más frecuencia de lo que cabría esperar. El cliente asume que, al pagar el desarrollo, adquiere automáticamente la propiedad del software resultante. El proveedor asume lo contrario. La legislación española no resuelve automáticamente la cuestión en favor del cliente: la propiedad intelectual del código corresponde al autor salvo cesión expresa. Si el contrato no regula la cesión, el cliente puede haber pagado millones de euros por un activo que no controla.
El problema se agrava en automoción por dos razones adicionales. Primera: los ciclos de desarrollo son largos y las especificaciones cambian. Un contrato que no prevé la gestión de cambios crea disputas sobre alcance, plazos y responsabilidad. Segunda: el software del vehículo interactúa con sistemas de terceros, con plataformas de datos y con infraestructuras de actualización remota. Cada punto de contacto genera preguntas de titularidad, licencia y responsabilidad que el contrato debe anticipar.
El software se protege en España a través de la legislación de propiedad intelectual, que lo equipara a una obra literaria. La protección nace con la creación y no exige registro. Pero esa protección automática es insuficiente para una empresa que quiere controlar cómo se usa, modifica, licencia o transfiere el código que ha encargado.
Los instrumentos jurídicos relevantes se articulan en tres niveles.
El primero es el contrato de desarrollo en sí. Es el documento central. Debe regular la cesión de derechos o, en su defecto, el régimen de licencia de explotación. En el sector de la automoción, la práctica dominante es la cesión plena al cliente: el fabricante o tier-1 no puede depender de una licencia que el proveedor puede renegociar. Sin embargo, la cesión debe estar redactada con precisión técnica: qué versiones, qué módulos, qué actualizaciones futuras y en qué territorio.
El segundo nivel es el secreto empresarial. El código fuente, las arquitecturas de software, los algoritmos propietarios y los modelos de datos que utiliza el sistema son, con frecuencia, secretos empresariales en el sentido de la normativa aplicable. La legislación sobre secretos empresariales exige que la empresa haya adoptado medidas razonables para preservar la confidencialidad. Un contrato de desarrollo que no incluya un régimen sólido de confidencialidad y restricciones de uso puede hacer que la empresa pierda esa protección.
El tercer nivel es la interacción con la normativa sectorial europea. El Reglamento de Ciberseguridad del Automóvil (UNECE WP.29) y el Reglamento de Actos sobre Datos (Data Act) de la Unión Europea imponen obligaciones sobre cómo se gestiona el software embebido, quién puede acceder a los datos generados por el vehículo y cómo se documentan las actualizaciones. Estas normas no son opcional: inciden directamente sobre qué debe regular el contrato de desarrollo para que el producto final sea homologable.
Hemos observado que empresas del sector que redactan sus contratos de desarrollo sin considerar el marco regulatorio europeo se encuentran, en el momento de la homologación, con que determinadas cláusulas contractuales son incompatibles con las obligaciones de transparencia y acceso a datos que impone la normativa vigente.
El error más frecuente no es firmar un mal contrato. Es empezar a desarrollar sin contrato, o con un documento provisional que nadie revisa hasta que surge el primer problema. En automoción, ese problema suele materializarse cuando el vehículo ya está en producción.
Antes de iniciar cualquier trabajo, la empresa debe completar cuatro acciones.
La primera es la diligencia debida (due diligence) sobre el proveedor de software. Conviene verificar que el proveedor tiene título limpio sobre las herramientas, librerías y metodologías que usará en el desarrollo. Si el proveedor utiliza software de código abierto, el contrato debe regular el régimen de licencias de ese código abierto: algunas licencias abiertas imponen condiciones que pueden afectar al producto final.
La segunda es el acuerdo de confidencialidad (NDA) previo. Antes de revelar especificaciones técnicas, arquitecturas de sistema o datos de flota, la empresa debe tener firmado un NDA sólido. En nuestra práctica, este documento suele ser el más descuidado: se firma en formato estándar, sin adaptar las definiciones de información confidencial a la realidad técnica del proyecto.
La tercera es la definición del alcance técnico antes de negociar el precio. Un contrato de desarrollo cuyo alcance técnico es impreciso es un contrato litigioso. Las especificaciones funcionales y no funcionales, los criterios de aceptación y los entregables intermedios deben estar incorporados como anexo al contrato, no como documento posterior.
La cuarta es la verificación de la cadena de titularidad. Si el desarrollo involucra a subcontratistas del proveedor, el contrato debe regular cómo fluye la cesión de derechos desde el subcontratista hasta el proveedor y, de ahí, hasta el cliente. Una laguna en esa cadena puede dejar al cliente sin título sobre parte del código.
Un contrato de desarrollo de software para automoción tiene una estructura mínima que conviene respetar. Lo que sigue no es una lista exhaustiva, sino las cláusulas cuya ausencia genera los conflictos más graves.
Cesión de derechos de propiedad intelectual. Debe identificar con precisión qué derechos se ceden: derecho de reproducción, distribución, modificación, comunicación pública y transformación. Debe incluir las versiones futuras si el contrato prevé desarrollos incrementales. Debe precisar si la cesión es exclusiva, si incluye el derecho a sublicenciar y en qué territorios opera. La legislación de propiedad intelectual española exige que la cesión sea expresa; la interpretación restrictiva juega en contra del cliente si la cláusula es ambigua.
Régimen del código fuente. El cliente debe recibir el código fuente, no solo el binario compilado. En automoción, la dependencia del proveedor para futuras actualizaciones o reparaciones es un riesgo operativo de primer orden. El contrato debe prever el depósito del código fuente en custodia o su entrega directa.
Garantías de originalidad y no infracción. El proveedor debe garantizar que el software entregado no infringe derechos de terceros y que no incorpora elementos cuya licencia sea incompatible con el uso previsto. Esta garantía debe ir acompañada de una indemnización específica para el caso de reclamaciones de terceros.
Confidencialidad y secreto empresarial. Las obligaciones de confidencialidad deben extenderse más allá de la vigencia del contrato. Deben identificar con precisión qué información tiene carácter confidencial, incluyendo el propio código fuente, las especificaciones técnicas y los datos de prueba. Deben incluir restricciones sobre el uso de la información para proyectos de terceros, especialmente competidores.
Cláusula de no competencia (non-compete) y no captación. En proyectos de alta especialización, es habitual incluir restricciones para que el proveedor no desarrolle productos funcionalmente equivalentes para competidores directos durante un período determinado. La legislación española admite estas cláusulas si son razonables en su alcance temporal y territorial.
Mecanismos de entrega y aceptación. El contrato debe definir cómo se acredita que el software cumple las especificaciones. Los criterios de aceptación deben ser objetivos y medibles. Sin esta cláusula, el debate sobre si el software «funciona» o no puede prolongarse durante meses.
Responsabilidad y limitación de daños. En automoción, los daños derivados de un fallo de software pueden ser de magnitud extraordinaria. El contrato debe regular con precisión los límites de responsabilidad del proveedor, las exclusiones y los supuestos en que esos límites no operan.
Actualizaciones y mantenimiento postlanzamiento. Un vehículo moderno recibe actualizaciones de software durante toda su vida útil. El contrato de desarrollo debe prever si el proveedor tiene obligación de mantener el código, en qué condiciones y durante qué plazo. La ausencia de esta previsión genera dependencia indefinida.
En la industria del automóvil, es frecuente que el software no sea desarrollado íntegramente por un proveedor externo, sino en colaboración entre el equipo interno del cliente y el equipo del proveedor. Esta modalidad, conocida como codesarrollo, plantea un problema de titularidad que el contrato debe resolver de forma explícita.
La regla general de la legislación española es que la titularidad de una obra creada conjuntamente corresponde a todos los coautores en proporción a su contribución. En la práctica de la automoción, esta regla es operativamente inmanejable: el fabricante no puede tener un activo estratégico en cotitularidad con un proveedor que mañana puede ser adquirido por un competidor.
Existen dos soluciones habituales. La primera es la cesión previa: en el contrato de codesarrollo, el proveedor cede anticipadamente al cliente todos los derechos que le corresponderían sobre los resultados conjuntos. La segunda es la asignación por módulos: cada parte retiene la titularidad de los componentes que desarrolla de forma autónoma, y los componentes conjuntos se atribuyen al cliente mediante cesión expresa.
¿Cuál es la mejor opción? Depende de la estructura del proyecto, del peso relativo de las contribuciones y de la posición negociadora de las partes. Lo que sí es cierto, en nuestra experiencia, es que dejar esta cuestión sin resolver es el error más costoso que comete una empresa en este tipo de proyectos.
Conviene recordar también que la titularidad sobre el software no resuelve por sí sola la cuestión de la protección. El registro de marca de los nombres comerciales asociados al software, la posibilidad de solicitar una patente ante la Oficina Española de Patentes y Marcas (OEPM) para los métodos técnicos protegibles, y la protección como secreto empresarial del código fuente y de los algoritmos son instrumentos complementarios que la empresa debe considerar de forma integrada.
Un contrato bien redactado puede fracasar en la ejecución si no se gestiona de forma activa. En proyectos de automoción, cuyo ciclo de desarrollo puede extenderse durante varios años, la gestión contractual es tan importante como la redacción inicial.
Los puntos críticos de gestión son los siguientes.
El control de cambios (change control) es el primero. En automoción, los cambios de especificaciones son inevitables. El contrato debe prever un procedimiento formal para gestionar cada cambio: quién los propone, quién los aprueba, cómo afectan al precio y al plazo y cómo se documenta el impacto sobre los entregables. Sin este procedimiento, cada cambio se convierte en un conflicto latente sobre quién asume el coste.
El segundo es el seguimiento de los hitos de entrega. El contrato suele articularse en fases con entregables intermedios. La empresa debe verificar en cada hito que el entregable cumple los criterios de aceptación definidos. Aceptar un entregable deficiente sin dejar constancia escrita puede tener consecuencias sobre la responsabilidad del proveedor en fases posteriores.
El tercero es la gestión de la propiedad intelectual de terceros. A lo largo del desarrollo, el proveedor puede incorporar librerías de terceros, componentes de código abierto o herramientas con licencia comercial. La empresa debe exigir un inventario actualizado de estos componentes y verificar que sus licencias son compatibles con el uso previsto.
El cuarto es la documentación de la confidencialidad. Si la empresa quiere proteger el software como secreto empresarial frente a terceros, necesita poder demostrar que ha adoptado medidas razonables de protección. Eso incluye registros de acceso, acuerdos de confidencialidad con el personal involucrado y controles sobre la transferencia de información técnica.
La cadena de suministro del automóvil es global. Es frecuente que el proveedor de software esté domiciliado en Alemania, en la India o en el Reino Unido. En esos casos, el contrato plantea preguntas adicionales: ¿qué ley rige el contrato? ¿Qué tribunal es competente para resolver disputas? ¿Cómo se ejecuta una sentencia en la jurisdicción del proveedor?
La elección de la ley aplicable y del foro de resolución de disputas no es una cláusula menor. En nuestra experiencia, es una de las decisiones más relevantes del contrato, y una de las que con más frecuencia se adopta sin el análisis adecuado.
Para contratos de importancia estratégica, el arbitraje internacional puede ser preferible a la jurisdicción ordinaria. Permite elegir un árbitro con conocimiento técnico del sector, ofrece confidencialidad y facilita la ejecución del laudo en múltiples jurisdicciones a través del Convenio de Nueva York de 1958. Para proyectos en los que la rapidez es prioritaria, puede ser más adecuado el sometimiento a los tribunales españoles con un acuerdo de mediación previa.
Cuando el contexto transfronterizo lo exige, coordinamos con abogados locales de confianza en la jurisdicción correspondiente para garantizar que la estructura contractual sea ejecutable en todos los territorios relevantes.
La protección de la marca asociada al software merece atención específica en el contexto internacional. La marca de la Unión Europea, gestionada ante la Oficina de Propiedad Intelectual de la Unión Europea (EUIPO) con sede en Alicante, ofrece cobertura en los veintisiete estados miembros con una sola solicitud. Para proyectos con vocación global, puede ser necesario extender la protección a través del sistema de Madrid. La titularidad de la marca debe coincidir con la del software: una disociación entre ambas titularidades crea vulnerabilidades que los competidores pueden explotar.
En nuestra práctica hemos identificado un conjunto de errores que aparecen con regularidad en contratos de desarrollo de software del sector de la automoción. Algunos son errores de redacción. Otros son errores de proceso. Todos son evitables.
El primero es confundir el pago con la adquisición de derechos. Pagar el desarrollo no transfiere automáticamente la propiedad del software. La cesión debe estar expresamente pactada.
El segundo es usar plantillas genéricas. Un contrato de desarrollo de software genérico no está diseñado para las particularidades del software embebido en vehículos, para los requisitos de ciberseguridad del sector o para la gestión de actualizaciones over-the-air. La plantilla puede dar una falsa sensación de seguridad.
El tercero es no regular el código abierto. El uso de librerías bajo licencia GPL o similares puede obligar a publicar el código fuente del producto final. En automoción, esta obligación puede ser incompatible con la protección de secretos empresariales.
El cuarto es omitir el régimen de datos. El software del vehículo genera datos de uso, de comportamiento y de diagnóstico. El contrato debe regular quién es titular de esos datos, quién puede acceder a ellos y bajo qué condiciones. El Reglamento de Actos sobre Datos de la UE ha introducido obligaciones nuevas en este ámbito que el contrato debe reflejar.
El quinto es dejar sin regular la terminación anticipada. ¿Qué ocurre si el proyecto se cancela a mitad del desarrollo? ¿Qué derechos tiene el cliente sobre el código parcialmente desarrollado? ¿Qué obligaciones de confidencialidad subsisten? Sin respuesta contractual a estas preguntas, la terminación anticipada puede convertirse en un litigio prolongado.
El sexto es subestimar el valor del secreto empresarial como instrumento de protección. El registro de patentes es lento y revela el contenido técnico de la invención. Para muchos algoritmos y arquitecturas de software en automoción, la protección como secreto empresarial es más eficaz, más rápida y más económica. Pero exige un contrato que la respalde.
Antes de suscribir un contrato de desarrollo de software en el sector de la automoción, la dirección jurídica o el asesor externo debe verificar que el documento responde afirmativamente a las siguientes preguntas.
Si alguna de estas preguntas obtiene una respuesta negativa o incierta, el contrato no está listo para ser firmado.
La protección contractual del software se integra en una estrategia más amplia de gestión de intangibles tecnológicos. En Velarde & Vidal asesoramos en la protección de marcas, patentes y secretos empresariales, en la estructuración de operaciones de propiedad intelectual en contextos de inversión y en el diseño de políticas de cumplimiento tecnológico. Si su empresa está en fase de crecimiento o de captación de inversión, le recomendamos revisar también nuestro análisis sobre startups y venture capital, donde abordamos cómo la protección de intangibles influye en la valoración y en la negociación con inversores.
Para una visión de conjunto de nuestra práctica de propiedad intelectual y tecnología, puede consultar nuestra área de práctica de propiedad intelectual y tecnología, donde describimos los instrumentos de protección disponibles y cómo los articulamos para empresas del sector industrial y tecnológico.
Si su empresa también opera en el sector del turismo o la hostelería y necesita orientación sobre la protección de sus activos de marca, puede encontrar información complementaria en nuestra guía sobre registro de marca en turismo y hostelería.
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.