Propiedad del código: cómo no quedar amarrado a un proveedor
Propiedad del código fuente en software a medida: diferencia entre ser dueño, tener licencia y acceder a tus datos, y qué pedir por escrito para evitar lock-in.
En resumen: Que te entreguen un sistema no significa que sea tuyo. Ser dueño del código, tener una licencia de uso y poder sacar tus datos son tres cosas distintas. Para no quedar amarrado a un proveedor, pide por escrito la cesión de derechos del código, el repositorio y las cuentas de infraestructura a nombre de tu empresa, documentación y exportación de datos en formatos abiertos.
Muchas empresas descubren que no son dueñas de su software el día que quieren cambiar de proveedor. El sistema funciona, lo pagaron y lo usan todos los días, pero el código está en la cuenta de otro, el servidor está a nombre de otro y los datos solo salen en un formato que nadie más entiende. Esta guía explica qué significa ser dueño de un software a medida y qué pedir para no llegar a esa situación.
Una aclaración antes de empezar: esto es orientación práctica, no asesoría legal. Las condiciones exactas dependen de tu contrato y de la ley aplicable, así que antes de firmar conviene que un abogado lo revise.
¿De quién es el código de un software hecho a medida?
Es de quien diga el contrato. No lo define quién pagó ni quién lo usa, sino lo que quedó por escrito. En Colombia el software se protege por derecho de autor y la ley tiene reglas para las obras hechas por encargo, pero depender de interpretaciones es mala idea: lo sano es que el contrato lo diga de forma explícita.
En la práctica, lo que se negocia son los derechos patrimoniales: los que permiten explotar el código, como copiarlo, modificarlo y distribuirlo. Si el contrato dice que se ceden a tu empresa, puedes contratar a otro equipo para que modifique el sistema sin pedirle permiso a nadie.
¿Qué diferencia hay entre propiedad del código, licencia de uso y acceso a los datos?
Son tres derechos distintos, y un proveedor puede darte uno sin darte los otros.
| Concepto | Qué significa | Qué puedes hacer | Riesgo si no lo tienes |
|---|---|---|---|
| Propiedad del código (cesión) | El código fuente es de tu empresa | Modificarlo, llevarlo a otro proveedor, instalarlo donde quieras | Todo cambio depende del proveedor original |
| Licencia de uso | Te autorizan a usar el software, que sigue siendo del proveedor | Usarlo en las condiciones pactadas | Si la licencia termina o sube de precio, no tienes salida rápida |
| Acceso a los datos | Puedes consultar y exportar la información que registraste | Sacar tus datos y llevarlos a otro sistema | Tu historial queda atrapado |
Una licencia no es mala por sí misma. Todo el software comercial funciona así: usas Excel, Google Workspace o un CRM en la nube con licencia, y está bien. El problema es pagar un desarrollo hecho para ti creyendo que es tuyo, cuando en realidad es una licencia.
El matiz de los componentes del proveedor
Algunos proveedores construyen sobre una base propia que reutilizan en todos sus proyectos. Es razonable: no tienen por qué cederte algo que usan con todos sus clientes. Lo importante es que el contrato diga qué parte es tuya, qué parte es licenciada y en qué condiciones. Idealmente, una licencia perpetua, sin costo adicional y que permita que otro equipo modifique el sistema.
Lo mismo pasa con las librerías de código abierto. Casi todo software moderno las usa y cada una tiene su propia licencia. No son del proveedor ni tuyas, pero puedes usarlas en las condiciones que esa licencia establece.
¿Qué es el vendor lock-in y cómo se reconoce?
El vendor lock-in, o dependencia del proveedor, es la situación en la que cambiar de proveedor es tan caro o tan difícil que en la práctica no puedes hacerlo. No siempre viene de mala fe; muchas veces es simple descuido al inicio del proyecto.
Señales de que estás en riesgo:
- El código está en un repositorio a nombre del proveedor y tú no tienes acceso.
- El servidor, la base de datos o el dominio están en cuentas del proveedor, pagadas por él y cobradas en tu factura.
- El sistema está construido sobre una plataforma propietaria del proveedor que solo él puede operar.
- No existe documentación técnica, o todo "está en la cabeza" de una persona.
- Para sacar un reporte con tus propios datos tienes que pedírselo al proveedor.
- El contrato no dice nada sobre qué pasa cuando la relación termina.
El dominio merece mención aparte. Si el dominio de tu empresa está registrado a nombre de un tercero, tu página web y tu correo dependen de esa persona.
¿Qué pedir por escrito para no quedar amarrado?
Pide que el contrato o sus anexos digan estas siete cosas, con esas palabras o parecidas:
- Cesión de los derechos patrimoniales del código desarrollado para ti, y una licencia clara para cualquier componente propio del proveedor.
- Repositorio a nombre de tu empresa, por ejemplo en GitHub, GitLab o Bitbucket, con el proveedor como colaborador invitado. Acceso desde el primer día, no una copia al final.
- Cuentas de infraestructura a nombre de tu empresa: nube, base de datos, dominio, correo y servicios de terceros. Pagadas con tu medio de pago o, al menos, con un traspaso definido.
- Credenciales bajo control de tu empresa, en un gestor de contraseñas o un documento que administre alguien de tu equipo.
- Documentación técnica suficiente para que otro equipo retome el sistema: cómo está armado, cómo se publica una nueva versión, qué servicios usa.
- Exportación de datos en formatos abiertos (CSV, Excel, JSON o un respaldo completo de la base de datos), que puedas pedir en cualquier momento y sin costos desproporcionados.
- Condiciones de salida: plazo de acompañamiento para la transición, entrega de accesos y qué pasa con los respaldos.
Si el proveedor se resiste a alguno de estos puntos, pregunta por qué. A veces hay una razón válida, como un componente licenciado. Si la respuesta es vaga, es una señal. Por eso este tema encabeza nuestra lista de preguntas antes de contratar una empresa de software.
¿De quién son los datos?
Los datos que genera tu operación deberían ser siempre tuyos, sin importar de quién sea el software. Clientes, ventas, inventario, historial: esa información es tu negocio.
Pero ser dueño de los datos solo sirve si puedes sacarlos. Verifica tres cosas:
- Que puedas exportar todo, no solo algunos reportes.
- Que el formato sea legible fuera del sistema: una tabla que se abre en Excel o un respaldo estándar de base de datos.
- Que la exportación conserve las relaciones. De nada sirve una lista de facturas si no sabes a qué cliente corresponde cada una.
Si esos datos incluyen información personal de clientes o empleados, además aplica la Ley 1581 de 2012 de protección de datos personales. Conviene que el contrato diga cómo trata el proveedor esa información y qué hace con ella cuando la relación termina.
¿Qué pasa con las plataformas no-code?
Con no-code, los datos pueden ser tuyos aunque la plataforma no lo sea. Si construyes una app en AppSheet sobre una hoja de Google Sheets, o en Power Apps sobre una lista de SharePoint, la información vive en tu cuenta y te la puedes llevar. La app, en cambio, existe dentro de la plataforma: si te vas, hay que reconstruirla en otra parte.
Eso no hace malo al no-code. Para muchos procesos es la opción más rápida y económica, como explicamos en cuándo convienen el no-code y el low-code. Lo que sí debes cuidar es que la app y los datos estén en la cuenta de tu empresa, no en el correo personal de quien la construyó.
| Qué | Software a medida con cesión | Plataforma no-code | Software comercial (SaaS) |
|---|---|---|---|
| Código o lógica de la app | Tuyo | Vive en la plataforma | Del fabricante |
| Datos | Tuyos, en tu base de datos | Tuyos si están en tu cuenta | Tuyos, según la exportación que ofrezca |
| Si cambias de proveedor | Otro equipo retoma el código | Rehaces la app, conservas los datos | Migras los datos a otra herramienta |
| Dependencia principal | Conocimiento del sistema | Precio y reglas de la plataforma | Precio y decisiones del fabricante |
¿Cuándo no vale la pena exigir la propiedad del código?
No siempre necesitas ser dueño del código. Si la herramienta es estándar, como contabilidad, nómina, correo o facturación electrónica, lo lógico es usar un software comercial con licencia. Ahí lo que debes cuidar es la exportación de datos, no el código. Lo comparamos en software a medida vs. software comercial.
Tampoco tiene sentido exigir la cesión de algo que el proveedor usa con todos sus clientes; ahí basta una buena licencia.
Y ser dueño del código no es gratis. Implica que alguien lo mantenga. Si nadie lo atiende, el código envejece igual: dependencias desactualizadas, parches de seguridad pendientes, integraciones que se rompen. Lo contamos en cuánto cuesta mantener un software a medida.
Cómo lo manejamos nosotros
En CodeLess Co el código y los datos son del cliente, y cada sistema se entrega documentado y con el equipo capacitado. Preferimos que un cliente se quede porque le sirve el trabajo, no porque no pueda irse. Si estás evaluando un proyecto, así funciona nuestro desarrollo de software a medida.
Si quieres, revisamos contigo qué tan amarrado estás hoy a tu proveedor actual. La primera conversación es gratis: cuéntanos qué sistema te preocupa.
Preguntas frecuentes
¿El código es mío si pagué por un software a medida?
No necesariamente. Pagar el desarrollo no garantiza la propiedad: depende de lo que diga el contrato. Si no hay una cláusula de cesión de derechos, el proveedor puede sostener que solo te dio una licencia de uso. Revisa tu contrato con un abogado si tienes dudas y, para proyectos nuevos, pide que la cesión quede por escrito desde el inicio.
¿Cómo recupero el código si mi proveedor no me lo entrega?
Primero revisa qué dice el contrato sobre propiedad y entrega. Luego pide formalmente, por escrito, el acceso al repositorio, las credenciales y la documentación. Si hay desacuerdo, lo recomendable es buscar asesoría legal. Mientras tanto, asegúrate de tener una exportación completa de tus datos, porque son lo más difícil de reconstruir.
¿Qué es un depósito de código fuente o escrow?
Es un acuerdo en el que un tercero neutral guarda una copia del código fuente de un software licenciado y la entrega al cliente si ocurre algo pactado, como el cierre del proveedor. Se usa sobre todo con software crítico que no se cede. Para desarrollos a medida suele ser más simple pedir el repositorio a nombre de tu empresa desde el primer día.
¿En qué formato debo pedir la exportación de mis datos?
En un formato abierto que otro sistema pueda leer: CSV o Excel para tablas, JSON para información con estructura, o un respaldo estándar de la base de datos. Lo importante es que incluya todas las tablas y cómo se relacionan entre sí, y que puedas pedirla en cualquier momento sin depender de la buena voluntad del proveedor.