¿De quién es el código de tu software? Qué pasa si tu proveedor desaparece

Casi nadie pregunta de quién es el código de su software hasta que lo necesita. Se da por hecho: si lo has pagado, es tuyo. Y luego llega el día en que el proveedor cierra, sube precios, deja de contestar o simplemente quieres cambiar de equipo, y aparece la sorpresa: el código está en su cuenta, los servidores a su nombre y el contrato no dice nada sobre la propiedad del software. Este artículo va de evitar esa sorpresa cuando encargas un software a medida, y de qué revisar si ya lo tienes.

Pagar el desarrollo no te hace dueño del código

En España, un programa de ordenador está protegido por la Ley de Propiedad Intelectual, igual que un libro o una canción, y los derechos sobre él nacen del lado de quien lo desarrolla. Cuando encargas un software a medida a una empresa de fuera, la propiedad intelectual que pasa a ser tuya es la que el contrato diga por escrito. Si no dice nada, en principio recibes lo imprescindible para usarlo, que no es lo mismo que poder modificarlo, encargar cambios a otro equipo o venderlo junto con tu negocio.

Hay dos detalles que casi nadie conoce. El primero: si el contrato cede los derechos pero no dice durante cuánto tiempo, la ley limita esa cesión a cinco años. El segundo: si no dice en qué territorio, la limita al país donde se firmó. Para un producto que quieres explotar durante años, o vender fuera, son dos líneas que conviene tener escritas.

No es asesoramiento jurídico, y si vas a firmar algo importante, que lo revise tu abogado. Pero sí es suficiente para saber qué pedir: que el contrato recoja la cesión de los derechos de explotación del código, con todas las palabras (usar, modificar, transformar y explotar), sin límite de tiempo y para todo el mundo. Si quien te lo vende pone pegas a eso, ya sabes algo importante de la relación.

Lo que no es de nadie en exclusiva

Ningún software se escribe desde cero del todo. Cualquier aplicación usa librerías de código abierto y servicios de terceros, y eso es bueno: no tiene sentido pagar por reinventar lo que ya está resuelto. Esas piezas no son tuyas ni de tu proveedor: se usan con su licencia. Lo razonable es saber cuáles son y que sus licencias permitan el uso comercial que vas a darles.

El caso delicado es otro: las empresas que construyen tu producto sobre una base propia que reutilizan con todos sus clientes. No es malo en sí, pero esa parte no te la van a ceder, porque también es de otros. Pregunta qué partes son suyas y con qué licencia las usas. La respuesta buena es una licencia perpetua e irrevocable, que no dependa de seguir pagándoles. La mala es descubrir, al irte, que tu aplicación no funciona sin una pieza que se quedó en su casa.

El código es solo una parte de lo que tiene que estar a tu nombre

Tener los archivos del código en un zip no sirve de mucho si todo lo demás está en cuentas ajenas. La propiedad real del software se reparte en varias piezas, y todas deberían estar a tu nombre:

El repositorio, que es donde vive el código fuente con todo su historial de cambios, en una cuenta de tu empresa y no en la del proveedor. La nube, es decir, los servidores y la base de datos, con la suscripción y la factura a tu nombre. El dominio y su configuración. Las cuentas de los servicios que usa la aplicación: la pasarela de pago, el envío de correos, las tiendas de aplicaciones. Los accesos de administrador de todo lo anterior. Y las copias de seguridad, guardadas donde tú puedas llegar sin pedir permiso.

Con eso, tus datos son tuyos de verdad. Sin eso, el código puede ser tuyo en el papel y tu negocio seguir dependiendo de que otro te abra la puerta.

Qué pasa si tu proveedor desaparece

Si todo lo anterior está a tu nombre, la desaparición del proveedor es un problema, pero se resuelve: contratas otro equipo, le das acceso y continúa donde lo dejó el anterior. Tardará algo en ponerse al día, y cuánto depende de lo bien documentado que esté el proyecto, pero no hay que empezar de cero.

Si no lo está, la conversación cambia por completo. Hay que negociar la entrega del código, los datos y el dominio con alguien que ya no tiene ningún interés en ayudarte, o que directamente ya no existe. En el peor caso, la única salida es reconstruir la aplicación desde fuera, que es pagar el proyecto dos veces. Lo explicamos con más detalle en desarrollo barato, mantenimiento caro: en una parte del sector, que irse sea más caro que quedarse no es un accidente, es el modelo de negocio.

Tener el código no basta si nadie lo entiende

Hay una segunda forma de quedarte atrapado, más sutil: que el código sea tuyo pero el conocimiento no. Nadie sabe por qué se hizo así, cómo se despliega o qué se rompe si tocas una pieza, y cada duda obliga a volver al proveedor original. La propiedad del código resuelve el problema legal; la documentación resuelve el práctico.

Por eso nosotros entregamos cada desarrollo con documentación completa y con una IA que conoce tu producto, montada sobre esa documentación y funcionando en tu propia suscripción. Un equipo nuevo puede preguntarle cómo funciona algo sin depender de nosotros, que es exactamente la idea.

Cinco preguntas sobre la propiedad antes de firmar

¿En qué cuenta estará el repositorio, y desde cuándo: desde el primer día o al terminar? ¿A nombre de quién irán la nube, el dominio y los servicios de terceros? ¿Qué dice el contrato sobre la cesión de derechos del código: modificar, explotar, plazo y territorio? ¿Qué partes no son tuyas y con qué licencia las vas a usar? Y si la relación termina mañana, ¿qué te entregan exactamente?

Son preguntas incómodas solo para quien tiene algo que esconder. Un buen proveedor las contesta en la primera reunión y sin rodeos, y suelen ir acompañadas de las que repasamos en cómo elegir equipo de desarrollo sin ser técnico.

Cómo lo hacemos nosotros

El código, el repositorio y la infraestructura van a tu nombre desde el primer día, no al terminar el proyecto: eres el dueño de tu software mientras se construye, no después. La nube también: pagas el consumo directamente a Microsoft, sin pasar por nosotros y sin margen, así que ves la misma factura que veríamos nosotros. Si mañana quieres seguir con otro equipo, les das acceso y continúan.

No lo hacemos por generosidad: es la forma de trabajar que nos parece honesta, y la que decidimos precisamente porque hemos estado al otro lado. Nuestro plan de salida empieza el primer día, y así es como planteamos cualquier desarrollo de software a medida. Si tienes un proyecto en marcha y no sabes de quién es el código, o quieres empezar uno sabiéndolo desde el principio, cuéntanos tu caso.