Qué ocurre con el código fuente al contratar un desarrollo

En España los programas de ordenador se protegen por derechos de autor. El Texto Refundido de la Ley de Propiedad Intelectual (Real Decreto Legislativo 1/1996) los incluye entre las obras protegidas y les dedica un título propio, el Título VII del Libro I (artículos 95 a 104). Algunos puntos de ese régimen ayudan a entender por qué el contrato es tan importante:

• La protección alcanza al programa y también a su documentación preparatoria y técnica y a los manuales de uso (artículo 96.1). Las ideas y principios en los que se basa, incluidos los de sus interfaces, no se protegen por derechos de autor (artículo 96.4).
• Cuando un trabajador asalariado crea un programa en el ejercicio de sus funciones o siguiendo instrucciones de su empresa, los derechos de explotación corresponden al empresario, salvo pacto en contrario (artículo 97.4). Esta regla se refiere a la relación laboral: si contratas a una empresa externa, no eres su empleador y la regla no te atribuye esos derechos por sí sola.
• La cesión de derechos de explotación queda limitada a los derechos, modalidades, plazo y ámbito territorial que se pacten. Si el contrato no fija plazo ni territorio, la ley aplica límites supletorios, y las modalidades no especificadas se reducen a las necesarias para cumplir la finalidad del contrato (artículo 43).
• Toda cesión debe formalizarse por escrito (artículo 45).

La consecuencia práctica es clara: si el contrato con un proveedor externo no dice nada, o lo dice de forma vaga, lo que puedes hacer con el código puede ser bastante más limitado de lo que imaginas. Por eso la cláusula de propiedad intelectual merece una lectura atenta, y no solo la del precio y el plazo.

No existe una única fórmula correcta. La adecuada depende de si el software es estratégico para ti, de si piensas comercializarlo y de cuánto del sistema se apoya en piezas que el proveedor ya tenía antes de tu proyecto.

Además de la fórmula principal, conviene que el contrato precise qué se entiende por «entregables» (código, documentación, diseños, modelos de datos, scripts de despliegue) y si la cesión cubre también obras derivadas futuras hechas por ti o por otro proveedor.

Casi ningún equipo empieza de cero. Es habitual reutilizar bibliotecas internas, plantillas de proyecto, módulos de autenticación o utilidades de despliegue que el proveedor ha creado antes y usa en varios proyectos. Exigir la cesión exclusiva de todo eso suele ser inviable y encarece el proyecto; ignorarlo, en cambio, puede dejarte con un sistema que no puedes mantener sin el proveedor original.

Una solución equilibrada es distinguir entre el desarrollo específico del proyecto, que se cede, y los componentes previos, sobre los que el proveedor concede una licencia perpetua, irrevocable y suficiente para usar, modificar y mantener el sistema, también mediante terceros. Lo importante es que esos componentes estén identificados en un anexo: si no se listan, cualquier pieza podría acabar presentándose como previa.

El conocimiento general (técnicas, patrones de diseño, experiencia adquirida) no suele poder cederse ni restringirse de forma razonable. Lo que sí debe protegerse es tu información de negocio, que corresponde al acuerdo de confidencialidad.

Un sistema actual incorpora decenas o cientos de dependencias de terceros: frameworks, bibliotecas, controladores, componentes visuales. Ninguna cesión del proveedor puede darte más derechos de los que él tiene sobre esas piezas. Cada una se rige por su propia licencia, y el contrato debería obligar al proveedor a declararlas.

• Licencias permisivas (por ejemplo, MIT o Apache-2.0): permiten usar e integrar el componente en software propietario con obligaciones limitadas, normalmente conservar avisos de autoría y el texto de la licencia.
• Licencias con copyleft (por ejemplo, la familia GPL): pueden obligar a distribuir el código de las obras derivadas bajo la misma licencia si el software se distribuye. Algunas, como la AGPL, extienden obligaciones al uso a través de red, algo relevante para un SaaS.
• Componentes comerciales: requieren licencias de pago, a veces por desarrollador, por servidor o por usuario final. Hay que saber a nombre de quién están y si se transfieren.
• Servicios externos (mapas, pasarelas de pago, modelos de IA, envío de correo): no forman parte del código cedido; se usan bajo las condiciones del prestador y con cuentas que deberían estar a tu nombre.

Una carpeta comprimida con archivos fuente no es una entrega útil. El objetivo es que un equipo distinto pueda compilar, desplegar y mantener el sistema sin depender de nadie. Una lista razonable de entregables incluye:

• Repositorio completo con su historial de cambios, no solo la última versión.
• Instrucciones para preparar el entorno, compilar y ejecutar las pruebas automáticas.
• Scripts o definiciones de infraestructura, configuración de despliegue y procedimiento de migración de base de datos.
• Documentación técnica: arquitectura, modelo de datos, integraciones y decisiones relevantes.
• Inventario de dependencias y licencias, y de servicios externos con sus cuentas.
• Acceso administrativo a dominios, repositorios, nube, tiendas de aplicaciones y certificados, a nombre de tu organización.

Un ejemplo verificable: pide que otra persona, ajena al desarrollo, reconstruya el sistema en un entorno limpio siguiendo solo la documentación entregada. Si lo consigue, la entrega es real. Si necesita llamar al proveedor tres veces, hay huecos que conviene cerrar antes de dar el proyecto por terminado.

Otro caso habitual: una aplicación móvil publicada en la tienda con la cuenta de desarrollador del proveedor. Aunque tengas el código, publicar una actualización puede requerir transferir la aplicación entre cuentas, un proceso que depende de la plataforma. Es preferible que la cuenta sea tuya desde el principio.

1. ¿El contrato dice por escrito qué derechos se ceden o licencian, para qué usos, con qué duración y en qué territorio?
2. ¿Están listados en un anexo los componentes previos del proveedor y la licencia que te concede sobre ellos?
3. ¿Se obliga al proveedor a declarar las dependencias de terceros y sus licencias, y a no incorporar componentes incompatibles con el uso previsto?
4. ¿Está definida la entrega: repositorio con historial, documentación, scripts e instrucciones de compilación?
5. ¿Las cuentas de infraestructura, dominios y tiendas están a nombre de tu organización?
6. Si la fórmula es una licencia sin código, ¿hay depósito o mecanismo de continuidad y exportación de datos?

Si alguna respuesta es negativa, no siempre es un problema, pero sí algo que conviene decidir de forma consciente y no descubrir el día que quieras cambiar de proveedor. En un proyecto de software a medida lo razonable es plantear estas cuestiones ya en la propuesta, sabiendo que el texto que manda es siempre el del contrato que se firme, revisado por quien te asesore jurídicamente.