¿De quién es el código del software que te desarrollan?

Casi todos los proveedores de software dicen que el código es del cliente. Muy pocos contratos lo dicen. Y aún menos empresas descubren la diferencia antes del día en que quieren cambiar de proveedor — que es exactamente el peor momento para descubrirla.

Esta guía explica qué significa ser dueño del código en la práctica, qué revisar en el contrato antes de firmar y cuáles son las señales de que te están vendiendo dependencia disfrazada de servicio.

"El código es tuyo" puede significar cuatro cosas distintas

Cuando un proveedor dice esa frase, puede querer decir cualquiera de estas — y solo una te sirve:

1. Te entregamos una copia del código al final. Un ZIP, una vez, sin historial. Técnicamente cumple. Prácticamente es inútil: no sabes qué cambió, ni por qué, ni cómo desplegarlo.
2. Tienes acceso de lectura al repositorio. Puedes verlo, pero la cuenta es del proveedor. El día que se termina la relación, se termina el acceso.
3. Eres dueño de los derechos patrimoniales, pero el código vive en su infraestructura. Legalmente es tuyo; operativamente no lo puedes mover.
4. El repositorio está en tu organización, tú controlas los accesos y la cesión está por escrito. Esto sí es propiedad.

La diferencia entre la 3 y la 4 es la que cuesta dinero cuando quieres cambiar.

Lo que dice la ley en México (y por qué no basta)

En México el software se protege por derecho de autor, no por patente. La Ley Federal del Derecho de Autor distingue dos supuestos que conviene conocer:

• Obra por encargo (art. 83): cuando una empresa comisiona y paga un desarrollo, la ley presume que goza de los derechos patrimoniales — salvo pacto en contrario.
• Relación laboral (art. 103): el software que desarrolla un empleado dentro de sus funciones corresponde patrimonialmente al patrón.

Esas dos palabras — salvo pacto en contrario — son el punto. La presunción legal cede ante lo que diga el contrato, y muchos contratos de desarrollo dicen exactamente lo contrario en una cláusula de dos líneas que nadie lee. No te apoyes en la presunción: escríbelo.

Esto es orientación general, no asesoría legal. Antes de firmar, que lo revise tu abogado.

Las cinco cosas que sí tienes que pedir por escrito

La propiedad del código no es una cláusula, son cinco.

1. Cesión expresa de derechos patrimoniales

Que diga cesión de derechos patrimoniales de autor a favor del cliente, sin límite territorial ni temporal, y que incluya el derecho a modificar y a autorizar a terceros a modificar. Sin ese último punto puedes ser dueño de algo que solo el autor original puede tocar legalmente.

2. El repositorio en tu organización, desde el día uno

No al final: desde el primer commit. Si el repo vive en la cuenta del proveedor y "se migra al cierre", la migración es una negociación, y las negociaciones tienen precio. Lo correcto es al revés: la organización de GitHub, GitLab o Azure DevOps es tuya y tú invitas al proveedor.

Esto también te da algo que el ZIP final nunca da: el historial. Poder ver quién cambió qué y por qué es la mitad del valor de un código base.

3. Inventario de licencias de terceros

Ningún sistema moderno es 100 % código propio. Lleva librerías open source, y cada una tiene su licencia. La mayoría (MIT, Apache 2.0, BSD) no te causan ningún problema. Otras — las copyleft fuertes como AGPL — pueden obligarte a publicar tu propio código si lo distribuyes.

Pide una lista de dependencias con su licencia. Si el proveedor no la tiene a la mano, es señal de que nadie la revisó.

4. Credenciales y cuentas a tu nombre

El código sin acceso a dónde corre no sirve de mucho. Que estén a nombre de tu empresa:

• La nube (AWS, Azure, GCP, Vercel) y el dominio
• La base de datos y sus respaldos
• Las llaves de las APIs de terceros y las pasarelas de pago
• Las cuentas de las tiendas de apps

He visto empresas dueñas de su código que no podían publicar una actualización porque la cuenta de App Store estaba a nombre del proveedor.

5. Documentación mínima para arrancar sin ellos

Un README que permita a un desarrollador nuevo levantar el proyecto en local, un diagrama de arquitectura y las instrucciones de despliegue. Si sin el proveedor nadie puede compilar el sistema, la propiedad es teórica.

Cómo se ve el lock-in en la práctica

Señal	Lo que significa en realidad
El repo vive en la cuenta del proveedor	La migración se negocia, y se cobra
El sistema corre sobre una plataforma propietaria del proveedor	El código es tuyo, pero no corre en ningún otro lado
No hay documentación de despliegue	Solo ellos saben poner el sistema en producción
Las credenciales de nube están a su nombre	Controlan el interruptor
El contrato guarda silencio sobre propiedad intelectual	Aplica la presunción, hasta que alguien la discuta
"Te damos el código si terminamos bien"	La propiedad está condicionada a no tener un conflicto

Ninguna de estas es necesariamente mala fe. Muchas veces es inercia: nadie lo pidió, así se quedó. Pero el efecto es el mismo el día que quieres moverte.

Las preguntas que conviene hacer antes de firmar

Cuatro preguntas, y las respuestas dicen bastante:

1. ¿En qué cuenta va a vivir el repositorio durante el proyecto?
2. ¿Me pueden mandar hoy la lista de dependencias con sus licencias?
3. Si mañana quiero que otro equipo continúe el desarrollo, ¿qué necesitarían de ustedes y cuánto tardaría?
4. ¿La cesión de derechos está en el contrato o en un anexo?

Un proveedor que trabaja de forma abierta contesta las cuatro sin incomodarse. Si la tercera genera silencio, ya sabes lo que pasa el día que quieras irte.

Un matiz honesto: propiedad no es lo mismo que autonomía

Ser dueño del código resuelve el problema legal, no el operativo. Puedes tener todo en orden y aun así depender de un proveedor sencillamente porque nadie más conoce el sistema.

Por eso la propiedad del código va de la mano de dos cosas más: que el stack sea estándar (si está hecho con tecnología común, cualquier equipo puede continuarlo; si está sobre un framework propietario, no) y que exista documentación viva. La propiedad te da el derecho a irte; el stack estándar y la documentación te dan la capacidad.

Cómo lo hacemos en Newsoft

En nuestros proyectos de desarrollo de software a la medida el repositorio se crea en la organización del cliente desde el primer commit, no al cierre. La cesión de derechos patrimoniales está en el contrato, no en una promesa comercial, y trabajamos siempre sobre stack estándar y open source para que cualquier equipo pueda continuar el sistema.

Es la misma lógica detrás del modelo de engineering cells: si un cliente decide llevarse el desarrollo internamente, debe poder hacerlo. La relación se sostiene porque conviene, no porque no haya salida.

Si estás por firmar con un proveedor y quieres una segunda opinión sobre las cláusulas de propiedad intelectual, escríbenos — revisamos el punto aunque el proyecto no sea con nosotros.

Conclusión

"El código es tuyo" es una frase gratis. Lo que cuesta es la cesión por escrito, el repositorio en tu cuenta desde el día uno, el inventario de licencias, las credenciales a tu nombre y la documentación para arrancar sin ellos.

Revisa esos cinco puntos antes de firmar. Cuestan una conversación al inicio del proyecto y ahorran una negociación completa al final.