De quién es el software que encargas: propiedad del código

Una promotora paga durante dieciocho meses el desarrollo de una plataforma de comercialización. Cambia de proveedor. Pide el código. Y descubre que el contrato que firmó habla de "licencia de uso", no de cesión de derechos; que el repositorio está en la cuenta de GitHub del proveedor; y que el módulo de firma de contratos de reserva, el más caro de todos, es un producto propio del proveedor que se licencia aparte. Lo que compró fue el derecho a usar un software durante el tiempo que dure la relación comercial.

Esto no es mala fe en la mayoría de los casos. Es que la propiedad del código en desarrollo a medida casi nunca se negocia: se asume. El cliente asume que paga y por tanto es suyo. El proveedor asume que reutiliza su base de código de siempre y por tanto es suyo. Nadie lo escribe, hasta que hay que escribirlo deprisa.

Pagar un desarrollo no te convierte en su propietario

En España, la Ley de Propiedad Intelectual trata el software como obra protegida. Los derechos nacen en quien lo crea. Si el desarrollador es empleado de tu empresa y lo programa en el ejercicio de su trabajo, los derechos de explotación se presumen cedidos a la empresa. Si el desarrollador es un proveedor externo, no hay presunción equivalente: hace falta un contrato que ceda esos derechos de forma expresa.

La diferencia práctica es grande. Sin cláusula de cesión, lo que tienes es una licencia implícita para usar aquello para lo que se encargó. No necesariamente para modificarlo, ni para que lo modifique otro, ni para revenderlo, ni para que el proveedor no se lo venda mañana a la promotora de al lado con otro logo.

Las cuatro preguntas que hay que hacer antes de firmar

¿Se ceden los derechos de explotación y con qué alcance?

La cláusula útil menciona explícitamente reproducción, distribución, transformación y comunicación pública; en exclusiva; para todo el mundo; por el plazo máximo legal. Si falta "transformación", no puedes contratar a otro equipo para que evolucione el producto. Si falta "en exclusiva", el proveedor puede explotarlo en paralelo.

¿Qué partes quedan fuera de la cesión?

Casi todos los proveedores serios tienen componentes reutilizables: un sistema de autenticación, un motor de permisos, una capa de integración con portales. Es razonable que no cedan eso. Lo que no es razonable es descubrirlo después. Pide un anexo con la lista de componentes preexistentes y la licencia con la que se te entregan: perpetua, irrevocable, transferible y sin coste recurrente, o al menos con el coste explícito.

¿Dónde vive el código y quién tiene las llaves?

El repositorio debe estar en una organización de la que tu empresa sea propietaria, con el proveedor invitado como colaborador. Lo mismo para la cuenta de la nube, el registro del dominio, las claves de las APIs de terceros y el acceso a la base de datos de producción. Un contrato de cesión perfecto no sirve de nada si el día que se rompe la relación nadie de tu lado puede entrar a ningún sitio.

¿Qué se entrega exactamente al final?

Código fuente no es solo código fuente. Es el historial de commits, los scripts de despliegue, las variables de entorno documentadas, los diagramas de modelo de datos y la documentación mínima para que un equipo nuevo levante el entorno sin llamar por teléfono. Define esa entrega como un hito contractual, no como un favor de despedida.

El software libre que hay dentro de tu software

Cualquier aplicación moderna incorpora decenas o cientos de librerías de terceros. La mayoría usa licencias permisivas (MIT, Apache 2.0, BSD) que no condicionan nada relevante para un uso interno. Algunas usan licencias copyleft fuertes que, en determinados escenarios de distribución, obligan a publicar el código derivado.

Para una plataforma interna de gestión de obra esto rara vez importa. Para un producto que piensas licenciar a otras promotoras, o para una app que vas a distribuir, importa mucho. Exige al proveedor un inventario de dependencias con sus licencias. Es un fichero que se genera automáticamente; si se resisten a entregarlo, el problema no es el fichero.

Cuándo pelear la propiedad del código no compensa

Hay proyectos donde exigir la cesión completa encarece el presupuesto sin aportar nada. Conviene reconocerlo antes de convertir la negociación en un pulso.

Si lo que necesitas es una configuración de una herramienta que ya existe —un CRM inmobiliario de mercado, un ERP de promotora, un portal montado sobre un CMS—, no hay código propio que poseer. Lo que posees son tus datos y tus configuraciones, y eso es lo que hay que blindar: exportación en formato abierto, sin penalización y a demanda.

Si el desarrollo es una integración puntual entre dos sistemas de terceros, con una vida útil de dos o tres años y una complejidad baja, el coste de mantener tú ese código puede superar el de rehacerlo cuando toque. Una licencia perpetua y el acceso al fuente en depósito suele bastar.

Y si el proveedor te está vendiendo acceso a un producto suyo ya construido, con una hoja de ruta que comparte entre varios clientes, pedir la propiedad del código es pedir que deje de ser ese producto. El precio subirá hasta igualar el de un desarrollo desde cero, y te quedarás además sin las mejoras que paguen los otros clientes. Esa es una decisión legítima, pero hay que tomarla sabiendo qué se compra.

Existe un coste menos evidente: poseer el código implica responsabilidad sobre él. Actualizaciones de seguridad, versiones de lenguaje que quedan obsoletas, dependencias que dejan de mantenerse. Una organización sin perfil técnico interno que reclama la propiedad de un sistema complejo acaba, con frecuencia, con un repositorio en una cuenta que nadie abre y un sistema en producción que nadie se atreve a tocar.

El escenario real que hay que anticipar: la salida

La propiedad del código importa, sobre todo, el día que quieres cambiar de proveedor. Ese día se mide la calidad de todo lo anterior. Una forma práctica de prepararlo es pactar un periodo de transición remunerado —semanas, no días— con un alcance definido: sesiones de traspaso con el equipo entrante, resolución de incidencias críticas y entrega documentada del entorno.

Otra medida barata y poco habitual: hacer una prueba de reversibilidad a mitad de proyecto. Que alguien ajeno al proveedor intente levantar el entorno completo a partir de la documentación entregada. Si no lo consigue en un par de días, la entrega final tampoco va a funcionar.

Qué pedimos nosotros cuando entramos en un proyecto

Cuando construimos software a medida para una promotora o una agencia, el repositorio se abre desde el primer día en la organización del cliente y la infraestructura se contrata a su nombre. Los componentes propios que reutilizamos van listados en un anexo, con licencia perpetua e irrevocable. Parece una concesión y es lo contrario: elimina de la conversación el argumento de que la relación se sostiene por dependencia técnica. Si el cliente se queda, es porque el trabajo le compensa.

La propiedad del código también cambia el modo en que se escribe. Un equipo que sabe que otro va a leer su trabajo documenta mejor, nombra mejor y acumula menos atajos. La transparencia sobre la titularidad acaba siendo un control de calidad indirecto.

Antes de firmar, formula una sola pregunta y exige que la respuesta esté en el contrato: si mañana cambiamos de proveedor, ¿qué nos llevamos, dónde está y quién puede modificarlo?

Una lista corta para revisar mañana

Localiza los contratos de tus tres desarrollos a medida más relevantes y busca la palabra "cesión". Comprueba en qué cuenta está cada repositorio y a nombre de quién figuran los dominios y los servidores. Pide a cada proveedor el inventario de dependencias y la lista de componentes preexistentes. Son tres correos. El coste de enviarlos ahora es ridículo comparado con el de descubrir la respuesta el día que ya no hay margen de negociación.

En GU Studio trabajamos esto en propiedad del código desarrollo a medida. Si quieres ver cómo encajaría en tu caso, cuéntanoslo.