Es la pregunta que casi nadie hace al firmar y todo el mundo hace al segundo año, normalmente cuando ya quiere hacer algo distinto con quien se lo construyó.
Y llega tarde: para entonces la respuesta ya está escrita en un contrato que se firmó sin leer esa parte.
¿Qué significa que «el código es tuyo»?
Que puedes leerlo, copiarlo, modificarlo y dárselo a otro equipo sin pedir permiso a nadie. Si falta cualquiera de esas cuatro cosas, el código no es tuyo del todo.
Y es importante porque muchos contratos dicen que el software es del cliente y a la vez impiden tres de las cuatro. No por mala fe siempre: por plantillas heredadas que nadie ha revisado. Pero el efecto es el mismo.
Hay una diferencia que conviene tener clara: una cosa es que la aplicación sea tuya —que puedas usarla— y otra que lo sea el código fuente, que es lo que te permite cambiarla. Se puede tener lo primero sin lo segundo, y ahí es donde aparece la dependencia.
Las tres cosas que hay que mirar en el contrato
La cesión de derechos, el acceso al repositorio y qué pasa con lo que no es vuestro. Con esas tres claras, el resto es detalle.
La cesión de derechos de explotación. Que aparezca por escrito, en exclusiva, sin límite de tiempo y sin límite territorial. Si el contrato solo dice «licencia de uso», no te están cediendo nada: te están dejando usarlo.
El acceso al repositorio, desde el primer día. No al entregar, no al terminar de pagar: desde el principio. Si el código vive en una cuenta del proveedor a la que no entras, da igual lo que diga el papel — el día que haya un desacuerdo, no tienes nada en la mano. Lo normal y sano es que el repositorio esté a nombre de tu empresa y el proveedor sea un colaborador más.
Lo que no es de nadie de los dos. Ningún desarrollo se hace desde cero: por debajo hay librerías de terceros, casi siempre de código abierto. Eso no se te cede porque no es del proveedor tampoco. Lo que sí debes exigir es la lista de qué se ha usado y con qué licencia, para saber que no hay nada que te obligue a algo que no quieres.
Esto no es asesoramiento legal y no lo pretende: es lo que conviene mirar antes de llevárselo a quien sí puede darlo.
¿Y si dejo de trabajar con vosotros?
Te llevas el repositorio, la documentación y las claves. Y si hace falta, una sesión con el equipo que venga detrás para explicarles cómo está montado.
Esa última parte importa más de lo que parece. Un código al que nadie te explica nada es técnicamente tuyo y prácticamente inservible durante los primeros dos meses. Por eso documentamos las integraciones por escrito: no es por ordenados, es porque quien venga detrás tiene que poder trabajar sin nosotros.
¿Por qué hay proveedores que no lo hacen así?
Porque la dependencia es un modelo de negocio. Si eres el único que puede tocar el código, la renovación está garantizada aunque el trabajo no sea bueno.
Es legítimo decirlo en voz alta: retener el código funciona. Pero funciona a costa de que tu cliente se quede porque no puede irse, no porque quiera quedarse. Nosotros preferimos la segunda, y no por bondad: un cliente atrapado no te recomienda a nadie.
Cómo lo hacemos nosotros
El repositorio va a nombre de tu empresa desde el primer commit. Nosotros somos colaboradores. Los derechos de explotación se ceden en el contrato, en exclusiva y sin límite.
Y las claves de los servicios que use la aplicación —correo, base de datos, alojamiento— se dan de alta en cuentas tuyas, no nuestras. Es la parte que más gente descubre tarde: puedes tener todo el código del mundo y seguir sin poder desplegarlo porque el servidor está en una cuenta ajena.
Si estás valorando un desarrollo y quieres que revisemos contigo estas tres cláusulas del presupuesto que tienes encima de la mesa —aunque sea de otro—, escríbenos. Media hora y sales sabiendo qué estás firmando.