El código es de quien paga: lo que tiene que decir tu contrato

Si pagas por un programa hecho para ti, el contrato tiene que decir por escrito que los derechos de explotación del código pasan a tu empresa, que el código está en un repositorio a tu nombre y que las cuentas del servidor, el dominio y los servicios conectados también son tuyas. Si no lo pone, no des por hecho que lo tienes. Revísalo con un abogado antes de firmar.

Hace un año me llamó el dueño de un taller mecánico.

Su anterior desarrollador había dejado de contestar. El programa seguía funcionando, pero había un fallo en las facturas y nadie podía tocarlo. El servidor estaba contratado a nombre del desarrollador. Y el dominio, también. El código no lo había visto nunca nadie más que él.

"Pero si lo he pagado yo", me dijo.

Lo había pagado, sí. Pero en el papel que firmó no ponía nada de todo esto. Tardamos semanas en recuperar el acceso, y parte del trabajo hubo que rehacerlo.

Por eso, cuando alguien me encarga un programa, estas son las cosas que dejo escritas. Y son las que deberías pedir a cualquiera.

¿De quién es el código si el contrato no dice nada?

No lo des por resuelto. Que el cliente pague no convierte automáticamente al cliente en dueño de todos los derechos sobre el código, y la respuesta concreta depende del tipo de relación y de lo que se firmó.

Porque en España el software está protegido por la propiedad intelectual, igual que un libro o una foto. Cuando lo hace un empleado tuyo, la situación es una. Cuando lo hace un autónomo o una empresa externa, es otra, y ahí lo que manda es lo que diga el contrato.

Lo que no está escrito, en un contrato de software, es terreno para discutir. Y discutir sale caro.

Esto no es asesoramiento legal. Es lo que he aprendido en proyectos que salieron bien y en otros que heredé cuando habían salido mal. Para tu caso, abogado.

¿Qué tiene que decir la cláusula de cesión de derechos?

Que el desarrollador te cede los derechos de explotación del código hecho para ti, en exclusiva, sin límite de tiempo y para todo el mundo. Y que incluye poder modificarlo, copiarlo y encargar cambios a otra persona.

Lo que conviene que aparezca, con estas o parecidas palabras:

1. Qué se cede: el código fuente, la base de datos, los diseños y la documentación hechos para el proyecto.
2. En qué condiciones: en exclusiva, sin límite temporal ni territorial.
3. Qué puedes hacer: usarlo, modificarlo, reproducirlo y encargar su mantenimiento a quien quieras.
4. Cuándo pasa a ser tuyo: normalmente, al pagar cada entrega.

El último punto es justo para los dos. Si pagas por fases, como en un proyecto a precio cerrado con entregas, cada fase pagada es tuya. Así el desarrollador no se queda sin cobrar y tú no te quedas sin código.

¿Qué parte del código puede quedarse el desarrollador?

Las piezas genéricas que ya tenía antes y que reutiliza en todos sus proyectos. Es normal, y a ti te abarata el proyecto.

Un desarrollador con experiencia tiene su propia caja de herramientas: la forma de gestionar usuarios, de generar PDF, de mandar emails. Pero no tiene sentido que te las ceda en exclusiva, porque entonces no podría usarlas nunca más y cobraría cada proyecto como si empezase de cero.

Lo razonable es esto: esas piezas siguen siendo suyas, pero te da una licencia de uso gratuita, perpetua y que no se puede revocar. Con eso puedes seguir usando y modificando tu programa aunque no volváis a hablar nunca.

Lo que no es razonable es que lo específico de tu empresa, tu lógica de precios, tus pantallas o tu flujo de pedidos, se quede como suyo.

¿A nombre de quién tienen que estar el repositorio y las cuentas?

A nombre de tu empresa, desde el primer día. El desarrollador trabaja con acceso que tú le das, y que tú le puedes quitar.

Lista de lo que tiene que ser tuyo:

• El repositorio donde vive el código, en GitHub o similar.
• El servidor o el servicio en la nube donde funciona la aplicación.
• El dominio.
• La base de datos y sus copias de seguridad.
• Las cuentas de servicios conectados: correo transaccional, pasarela de pago, WhatsApp Business, servicios de IA.
• Las credenciales de acceso, guardadas en un gestor de contraseñas de la empresa.

Si el desarrollador te dice que es más cómodo ponerlo a su nombre "y luego te lo paso", no. Será cómodo para él. El día que haya un problema, lo que no está a tu nombre no lo puedes tocar. Más sobre esto en qué pasa con tu programa si el desarrollador desaparece.

¿Qué pasa con las licencias de programas de terceros?

Tienen que estar listadas. Casi todo programa usa piezas de otros, y cada pieza tiene sus normas.

Y la mayoría son de código abierto y gratuitas para uso comercial. Pero algunas tienen condiciones: obligan a publicar cambios, cobran a partir de cierto volumen o cambian de licencia con el tiempo. Y hay componentes de pago, como librerías de gráficos o de mapas, que exigen una licencia a nombre de alguien.

Pide en el contrato:

1. Una lista de los componentes de terceros que usa el programa y su licencia.
2. Que ninguno impida el uso comercial que tú le vas a dar.
3. Que las licencias de pago estén a nombre de tu empresa, no del desarrollador.

¿Qué tiene que decir sobre confidencialidad?

Que el desarrollador no puede contar, usar ni enseñar tus datos ni tu forma de trabajar fuera del proyecto. Y si el programa maneja datos personales, un contrato de encargado del tratamiento aparte.

Para mí es especialmente importante en clínicas, donde hay datos de salud. El desarrollador va a tener acceso a una base de datos con información muy delicada. Entonces eso tiene que estar regulado, con obligaciones concretas de seguridad y de borrado al terminar.

Un matiz. A veces pido permiso para enseñar el proyecto como caso de éxito, siempre anonimizado. Si te parece bien, que quede escrito. Y si no, también.

¿Qué hay que recibir al terminar el proyecto?

Todo lo necesario para que otra persona pueda seguir sin llamar al desarrollador original:

• Acceso completo al repositorio con todo el historial.
• Una guía corta de cómo instalar y poner en marcha el programa.
• Qué hace cada parte, a grandes rasgos.
• La lista de cuentas, servicios y licencias, todas a tu nombre.

Si esto se cumple, el programa es tuyo de verdad. Es una de las grandes diferencias con alquilar un programa estándar, y la explico en pagar licencias cada año o tener tu propio programa.

Antes de firmar, busca en el contrato la palabra "cesión". Si no aparece, pídela, y si quieres ver cómo lo dejo escrito yo, reserva una llamada de 30 minutos y te lo enseño.