¿De quién es el código de tu software? Lo que hay que dejar por escrito

Es la cláusula que nadie lee hasta que la necesita, y para entonces ya no se puede negociar.

Pagaste un desarrollo. Funciona, está en producción, tu empresa opera con eso todos los días. Y un día querés cambiar de proveedor, o el proveedor cierra, o simplemente sube el precio del mantenimiento y no tenés alternativa. Ahí aparece la pregunta: ¿esto es mío?

La respuesta honesta es que depende de lo que firmaste, y que mucha gente descubre tarde que la respuesta es no.

Pagar no es lo mismo que ser dueño

Este es el punto que sorprende. En términos generales, y con variaciones según el país, los derechos sobre una obra de software quedan de quien la creó salvo que exista una cesión expresa. Contratar y pagar un desarrollo no transfiere automáticamente la propiedad intelectual.

Es la misma lógica que con un fotógrafo: le pagás por la sesión, pero los derechos sobre las fotos se rigen por lo que hayan acordado.

Con software casi nadie lo piensa así, y por eso conviene que esté por escrito, sin ambigüedad.

Lo que tiene que decir el contrato

No hace falta un texto largo. Sí que diga estas cosas sin vueltas:

1. Cesión de la propiedad intelectual. Que los derechos patrimoniales sobre el software desarrollado quedan del cliente, incluido el código fuente, una vez cancelado el pago. Fijate que diga código fuente y no sólo "el software": entregarte un ejecutable no es entregarte el código.

2. Entrega del repositorio con historial. No un ZIP con los archivos: el repositorio Git completo. El historial es parte del valor, porque explica por qué las cosas son como son.

3. Los accesos. Servidores, base de datos, dominio, servicios de terceros, cuentas de App Store y Google Play, pasarelas de pago. Como administrador, no como invitado.

4. Documentación técnica. Cómo se levanta el proyecto, cómo se despliega, qué variables de entorno necesita, qué integraciones tiene.

5. Qué pasa si la relación se corta. Un plazo concreto para entregar todo, sin condicionarlo a nada más que a los pagos pendientes.

El código sin los accesos no sirve

Un caso que se ve seguido: la empresa tiene el código, con eso se queda tranquila, y el día que quiere mover el sistema descubre que el dominio está a nombre del proveedor, el servidor en su cuenta personal de AWS, y la app publicada bajo la cuenta de desarrollador de él.

El código era propio. La operación seguía siendo ajena.

Pedí una lista escrita de todos los servicios que usa el sistema y a nombre de quién está cada uno. Si algo está a nombre del proveedor, que se transfiera. Es un trámite de minutos mientras la relación es buena, y una pesadilla cuando no lo es.

Las señales de que te están atando

No siempre es mala intención; a veces es sólo comodidad del proveedor. Pero el efecto es el mismo:

• "El código es nuestro, vos tenés licencia de uso." Modelo legítimo si te lo dicen de entrada y el precio lo refleja. Deja de serlo cuando aparece después.
• "Está en nuestro servidor, es más fácil así." Puede ser cierto, y tiene que ser tu servidor o al menos tu cuenta.
• "No hace falta que tengas el repositorio." Sí hace falta.
• No hay documentación. A veces es desprolijidad. A veces es estrategia: si nadie más entiende el sistema, nadie más lo puede mantener.
• Tecnologías raras sin explicación. Un framework propio del proveedor que no usa nadie más significa que sólo ellos pueden trabajar sobre eso.

La prueba de los cinco minutos

Preguntate: si mañana quisiera cambiar de proveedor, ¿podría hacerlo sin pedirle nada al actual?

Si podés bajar el código del repositorio, entrar a los servidores con tu usuario y darle todo a otro equipo, estás bien. Si la respuesta depende de que el proveedor colabore, estás atado.

Y ojo: el momento de resolverlo es cuando la relación está bien. Nadie negocia la salida en medio de una discusión.

Lo que es razonable del otro lado

Para ser justos, hay cosas que un proveedor puede retener con toda razón:

• Herramientas internas y librerías propias que usa en todos sus proyectos. Lo razonable es que te den una licencia de uso perpetua sobre esa parte y la propiedad completa de lo específico de tu proyecto.
• El know-how. Nadie puede pedirle que se olvide de lo que aprendió.
• Mostrar el trabajo en su portfolio, salvo que acuerden confidencialidad.

Lo que no es razonable es que lo específico de tu negocio —tus procesos, tus reglas, tus datos— quede en manos de otro.

Cómo lo planteamos nosotros

En Deepyze el código queda 100% del cliente, con el repositorio, los accesos y la documentación, y está escrito en la propuesta antes de empezar. No por generosidad: porque un cliente que se queda por conveniencia es mejor relación que uno que se queda porque no puede irse.

La otra cara es que si querés irte, te podés ir. Nos parece el trato correcto.

Una checklist para antes de firmar

• El contrato cede expresamente los derechos sobre el código fuente.
• Dice "código fuente", no sólo "el software".
• Se entrega el repositorio Git con historial completo.
• Hay una lista de servicios y a nombre de quién está cada uno.
• Los accesos son de administrador y a tu nombre.
• Hay documentación de despliegue.
• Hay un listado de dependencias y sus licencias.
• Está claro qué pasa y en cuánto tiempo si la relación termina.

Si algún punto genera resistencia, preguntá por qué. La respuesta te va a decir bastante sobre cómo va a ser trabajar juntos.

---

Si estás por firmar un desarrollo y querés que alguien lea la propuesta con ojo técnico antes, es exactamente el tipo de cosa que resolvemos en una consultoría puntual. Y si querés ver cómo redactamos nosotros el alcance, pedinos una propuesta.