Propiedad del código y de los datos en software a medida
Qué debe recoger el contrato sobre el código fuente, los datos, las bibliotecas, el acceso, la entrega y la continuidad de un proyecto de software a medida.
Por Η ομάδα της Argonstack, TechIns Group
La frase «el software será nuestro» no es suficiente. En un proyecto a medida hay que distinguir el código fuente, los datos, el diseño, la documentación, las bibliotecas preexistentes, las licencias de terceros, la infraestructura y el derecho a continuar el desarrollo con otro equipo.
Si esto no se define antes de empezar el proyecto, el desacuerdo suele aparecer cuando el cliente pide acceso al repositorio, un cambio de proveedor o la exportación de datos. El asunto no se resuelve por el hecho de que alguien haya pagado el desarrollo. Se resuelve mediante el contrato y el derecho aplicable.
Este artículo es una guía empresarial y no un dictamen jurídico. El contrato definitivo debe revisarlo un abogado con conocimiento de propiedad intelectual y tecnología.
Qué significa la propiedad del código fuente
El código fuente es el material que usan los desarrolladores para crear y modificar la aplicación. El acceso al código no equivale necesariamente a la cesión de todos los derechos. Una empresa puede tener una copia del repositorio pero un derecho de uso limitado. También puede tener una licencia de uso exclusiva sin haber adquirido cada elemento utilizado.
La Directiva 2009/24/CE europea protege los programas de ordenador mediante la propiedad intelectual. El contrato debe definir con precisión qué derechos se ceden, cuándo se ceden, para qué territorio y si existe alguna limitación de uso o de modificación.
Cuatro categorías de código
El código de un proyecto normalmente no es un elemento único. Incluye código nuevo escrito específicamente para el cliente, herramientas preexistentes del proveedor, bibliotecas de código abierto y servicios comerciales de terceros.
El nuevo código específico puede cederse al cliente o licenciarse. Los frameworks preexistentes del proveedor suelen permanecer en manos del proveedor, con derecho de uso dentro del entregable. Las bibliotecas de código abierto siguen sus propias licencias. Los servicios de terceros, como la nube, mapas, correo o APIs de IA, se rigen por los términos de sus respectivos proveedores.
Si el contrato se limita a decir que «el cliente adquiere todo el código», sin estas excepciones, puede estar prometiendo algo que técnica o legalmente no es posible.
Los datos del cliente
El contrato debe establecer que los datos empresariales del cliente permanecen bajo su control. Debe definir cómo se importan, dónde se almacenan, quién tiene acceso, cómo se hacen las copias de seguridad y cómo se exportan tras finalizar la colaboración.
Para los datos personales se necesita además una definición de roles conforme al RGPD y, cuando el proveedor actúe como encargado del tratamiento, un Acuerdo de Tratamiento de Datos adecuado. La «propiedad de los datos» no sustituye las obligaciones de protección de datos personales.
Qué debe entregarse
La posibilidad real de continuar un proyecto requiere más que un zip con el código fuente. Se necesita acceso al repositorio, instrucciones de instalación, variables de entorno sin revelar secretos no transferibles, el esquema de la base de datos, la documentación de la API, la lista de dependencias, el proceso de despliegue, el proceso de copias de seguridad y el listado de cuentas de terceros.
También debe definirse quién controla el dominio, la cuenta en la nube, las cuentas de las tiendas de aplicaciones, las herramientas analíticas, los servicios de correo y las claves de firma. Cuando sea posible, las cuentas críticas deben pertenecer al cliente y el proveedor debe obtener un acceso controlado.
Cuándo se ceden los derechos
Una lógica comercial habitual es ceder los derechos acordados tras el pago completo. Esto debe ser explícito. Al mismo tiempo, debe definirse qué ocurre si el proyecto se interrumpe antes de finalizar, qué entregables se han pagado y qué derecho de uso obtiene el cliente sobre el trabajo ya entregado. Las condiciones comerciales relacionadas se describen en los Términos y Condiciones de Argonstack.
Dependencia del proveedor y derecho de salida
La dependencia del proveedor no siempre es mala. Todo sistema complejo requiere especialización. Sin embargo, se vuelve peligrosa cuando el cliente no puede obtener los datos, la documentación o el acceso a cuentas críticas.
Un contrato serio incluye un plan de salida. Define el formato de exportación, el plazo de entrega, el periodo de transición, el coste del soporte adicional y la eliminación de las copias tras finalizar las obligaciones legales de conservación.
Depósito de código fuente (escrow)
En sistemas críticos puede acordarse un depósito de código fuente (escrow). Una copia actualizada del código y de la documentación se custodia en manos de un tercero independiente y se libera solo en casos concretos, como el cese de actividad del proveedor o una incapacidad grave de dar soporte.
El escrow no sustituye la documentación ni una arquitectura correcta. Si el material no se actualiza o no se puede instalar, su existencia tiene un valor limitado.
Qué debe pedir el cliente antes de firmar
El cliente debe pedir una definición clara de los entregables, de los derechos sobre el código específico, de las excepciones, de las licencias de terceros, del acceso al repositorio, de la propiedad de las cuentas, de la exportación de datos, de la documentación, del mantenimiento y del plan de salida.
Argonstack organiza cada proyecto a medida con un alcance y una arquitectura técnica claros. Las condiciones de propiedad y entrega deben recogerse en el contrato específico del proyecto y reflejar el modelo real de colaboración.
Siguiente paso
Defina el alcance, los derechos, el acceso y el plan de salida antes de que empiece el desarrollo.
Preguntas frecuentes
Si pago el desarrollo, ¿me pertenece el código automáticamente?
No necesariamente. El pago y la cesión de derechos son cuestiones distintas. El contrato debe definir exactamente qué adquiere el cliente.
¿Pueden pertenecerme las bibliotecas de código abierto?
No en el sentido de propiedad exclusiva. Se usan conforme a sus propias licencias. El proveedor debe declarar las dependencias críticas y las obligaciones correspondientes.
¿Debe estar la cuenta en la nube a nombre del cliente?
Para infraestructura a medida crítica suele ser la opción más segura, siempre que exista una gestión correcta de los accesos. En un producto SaaS normalmente no es aplicable, porque la infraestructura compartida pertenece al proveedor.
¿Qué es más importante que la frase «el código me pertenece»?
La capacidad real de funcionamiento, exportación de datos, mantenimiento y transición. Sin documentación, cuentas y proceso de despliegue, la propiedad teórica puede tener escaso valor práctico.
