De quién es el código que te construyeron

Pasa casi siempre igual. El negocio quiere cambiar un precio en su propia página, o sacar un reporte de sus propios clientes, o mover el sitio a otro lado. Llama al que se lo construyó. Y ahí se entera de que no puede: el que contestaba ya no contesta, o contesta con un presupuesto, o contesta que sí y nunca lo hace. El software funciona bien. Las llaves no son suyas.

Casi nadie pregunta esto antes de firmar. Se pregunta cuánto cuesta y en cuánto tiempo está. No se pregunta de quién va a ser.

Qué es el lock-in, en cristiano

Lock-in quiere decir: puedes seguir usando lo que te hicieron, pero no puedes irte. No porque el contrato lo prohíba —casi nunca lo prohíbe— sino porque las llaves están en otras manos.

Son cuatro llaves distintas, y casi nunca están todas en el mismo lugar:

• El código — el repositorio donde vive lo que se escribió.
• El dominio — el nombre de tu negocio en internet.
• Los datos — tus clientes, tus pedidos, tu historial.
• Las cuentas — hosting, correo, pagos y cada servicio de terceros conectado.

Puedes tener una y que las otras tres estén a nombre de alguien más — es lo que nos encontramos casi siempre que revisamos un sistema ya construido.

Pagar no es lo mismo que ser dueño

Esta parte sorprende a casi todos. Si el trato se hace en Estados Unidos, la ley de derechos de autor dice que el derecho nace en quien creó la obra: el copyright, según 17 U.S.C. § 201(a), "vests initially in the author". El que escribió el código es el autor. Haberle pagado no mueve ese derecho por sí solo.

Hay una cláusula famosa que muchos creen que resuelve el asunto: work made for hire. Cuando quien construye es un contratista externo, esa figura solo aplica a nueve tipos de obra que la propia ley enumera —traducciones, compilaciones, material de examen, partes de una película, entre otras— y el software no está en esa lista (17 U.S.C. § 101; ver también la Circular 30 de la Oficina de Derechos de Autor de EE. UU.). Poner "work for hire" en un contrato de software puede no transferir nada.

Lo que sí transfiere es una cesión de derechos por escrito y firmada. La ley lo pide explícito: 17 U.S.C. § 204(a) exige que la transferencia conste "in writing and signed by the owner".

Las leyes cambian de país a país. Lo que no cambia es esto: sin un papel firmado, es tu palabra contra la del otro — y el que tiene el código en su cuenta gana esa discusión sin discutirla.

Las cinco preguntas

Hazlas antes de firmar y por escrito. Un correo basta. Lo importante es que quede la respuesta.

1. ¿A nombre de quién queda el repositorio del código?

Se ve bien: "En una organización de GitHub tuya, tú como owner, nosotros invitados como colaboradores." Se ve mal: "En el nuestro, y al final te damos una copia." Una copia al final es un archivo comprimido: no trae la historia del proyecto ni le sirve de mucho al que venga después.

2. ¿A nombre de quién queda el dominio?

Se ve bien: registrado en una cuenta tuya, con tu correo, contigo como titular. No es un detalle burocrático. Según la política de transferencias de ICANN, el titular registrado es quien puede autorizar mover un dominio a otro proveedor, y ante un desacuerdo su autoridad manda sobre la del contacto administrativo. Si el titular es tu proveedor, el dominio es de tu proveedor.

Se ve mal: "Nosotros te lo manejamos, no te preocupes por eso."

3. ¿A nombre de quién quedan la base de datos y el hosting?

Se ve bien: las cuentas facturadas a tu tarjeta, con tu correo como administrador, y una forma clara de exportar tus datos cuando se te antoje. Se ve mal: todo adentro de la cuenta del proveedor, "incluido en la mensualidad". Ese incluido es la correa.

4. ¿A nombre de quién quedan las cuentas de terceros?

Pagos, correo transaccional, WhatsApp Business, mapas, la API de inteligencia artificial. Cada una es una cuenta con un dueño. Se ve bien: todas a nombre del negocio, el proveedor invitado. Se ve mal: las llaves viviendo en la cuenta personal del que programó, en su tarjeta y con su correo.

5. Si mañana nos dejamos de hablar, ¿qué me llevo y cómo?

Es la pregunta incómoda y es la que más te dice. Se ve bien: una respuesta aburrida y concreta — "ya tienes todo; te quitamos nuestros accesos y sigues sin que se caiga nada". Se ve mal: silencio, una broma, o "eso no va a pasar". Que no vaya a pasar no es un plan.

La prueba que no se puede fingir

Cualquiera contesta bien esas cinco preguntas. Hay una prueba que no se contesta, se hace: pide que hoy mismo te agreguen como dueño del repositorio y de la cuenta de hosting. Si la invitación te llega al correo el mismo día, lo demás probablemente también es cierto. Si aparece un "cuando terminemos", ya sabes en qué tipo de relación estás entrando.

Y hay que decir la otra mitad, para no vender humo: que las llaves sean tuyas no significa que puedas operar el sistema solo. Vas a seguir necesitando a alguien que le dé mantenimiento y lo haga crecer. La diferencia es que a esa persona la eliges cada mes, en vez de estar amarrado a ella.

Cómo lo hacemos nosotros

El repositorio se crea en la cuenta del cliente desde el día uno, no el día de la entrega. El dominio y las cuentas de servicios se registran a nombre del negocio. Nosotros trabajamos adentro, invitados, mientras dure el trabajo.

No es generosidad. Es que un cliente que se puede ir cuando quiera y decide quedarse es la única señal honesta de que lo que construimos sirve.

Si ya tienes software funcionando y no sabes contestar las cinco preguntas de arriba, esa es la conversación que toca. Agenda un diagnóstico gratis: revisamos dónde están hoy tus llaves y qué haría falta para recuperarlas.