Invertiste 60.000 dólares en un sistema. Dos años después quieres cambiar de proveedor, o contratar a alguien interno, o simplemente que otro equipo le agregue un módulo. Y descubres que no tienes el código fuente. O que lo tienes pero el contrato dice que no puedes modificarlo. O que la licencia se vence si dejas de pagar el mantenimiento.
Es uno de los problemas más caros del desarrollo de software a medida, y se previene con tres o cuatro cláusulas. Esta guía explica cuáles.
Primero: qué significa “a medida” legalmente
Pagar por el desarrollo de un software no implica automáticamente ser dueño de él. En materia de derechos de autor, el software es una obra protegida, y la titularidad depende de lo que diga el contrato.
Sin una cesión expresa por escrito, el desarrollador puede conservar derechos sobre lo que construyó, aunque tú lo hayas financiado por completo. No es mala fe necesariamente: es el estado por defecto cuando nadie lo pactó.
Este artículo es orientación general sobre qué negociar, no asesoría legal. Un contrato de desarrollo de cierto monto merece revisión de un abogado.
Las cuatro capas de propiedad que hay que separar
Un sistema no es una sola cosa. Cada capa se negocia distinto:
| Capa | Qué es | Qué esperar |
|---|---|---|
| Código desarrollado a medida | Lo que se escribió específicamente para ti | Debería cederse en propiedad a tu empresa |
| Componentes propios del proveedor | Librerías internas que reutiliza en varios clientes | Normalmente licencia de uso, no propiedad |
| Software de terceros | Librerías de código abierto o comerciales | Se rigen por su propia licencia; deben listarse |
| Tus datos | La información que carga tu operación | Siempre tuyos, sin discusión posible |
La confusión más común es exigir propiedad total de todo. No es realista ni conveniente: si el proveedor tiene un framework interno que acelera el desarrollo, obligarlo a cederlo encarece el proyecto sin beneficio para ti. Lo razonable es propiedad del código a medida y licencia perpetua e irrevocable sobre los componentes reutilizables.
Las cláusulas que debes exigir
1. Cesión de derechos patrimoniales
Debe decir explícitamente que los derechos patrimoniales sobre el código desarrollado a medida se transfieren a tu empresa, sin límite de tiempo ni de territorio, y que puedes modificarlo, adaptarlo y encargar su modificación a terceros.
Ese último punto es el que suele faltar: sin él, puedes ser dueño del código pero no poder contratar a otro para tocarlo.
2. Entrega del código fuente
Propiedad sin entrega no sirve de nada. El contrato debe fijar:
- Qué se entrega: código fuente completo, scripts de base de datos, archivos de configuración, documentación técnica.
- Cómo: en un repositorio de control de versiones al que tengas acceso desde el inicio, no en un archivo comprimido al final.
- Cuándo: idealmente de forma continua durante el proyecto, no como entrega única.
El acceso continuo al repositorio es la mejor protección que existe. Si el proyecto se cae a mitad de camino, al menos tienes lo construido.
3. Licencia sobre componentes reutilizables
Para lo que el proveedor no cede, exige una licencia perpetua, irrevocable, no exclusiva y transferible, que no dependa de mantener un contrato de soporte vigente. Sin ese detalle, dejar de pagar el mantenimiento podría dejarte sin derecho a usar tu propio sistema.
4. Inventario de dependencias
El proveedor debe entregar la lista de librerías de terceros usadas y su licencia. Importa por dos razones: hay licencias de código abierto con obligaciones que podrían afectarte, y necesitas saber qué componentes tienen costo recurrente.
Qué más debería quedar por escrito
| Cláusula | Por qué |
|---|---|
| Titularidad de infraestructura | Dominio, hosting y servicios en la nube a nombre de tu empresa |
| Documentación técnica | Arquitectura, despliegue y decisiones de diseño |
| Procedimiento de salida | Cómo se entrega todo si termina la relación |
| Confidencialidad | Tus datos y tu lógica de negocio no se reutilizan con terceros |
| Garantía por defectos | Periodo en que los errores se corrigen sin costo |
| No dependencia de personas | Que el proyecto no dependa de un solo desarrollador |
El depósito de código: cuándo tiene sentido
Existe la figura del depósito en custodia: el código se deposita ante un tercero neutral, que lo libera si ocurren ciertos supuestos, como que el proveedor cese operaciones o incumpla gravemente.
Tiene sentido cuando el proveedor no acepta entregar el código durante el proyecto, o cuando el sistema es crítico para tu operación y quieres una garantía adicional. Para proyectos medianos con acceso continuo al repositorio, suele ser innecesario.
Señales de alerta en un contrato
- No menciona propiedad intelectual. El silencio no te favorece.
- “Licencia de uso” sin especificar plazo. Una licencia que caduca te deja sin sistema.
- La licencia está condicionada al pago del soporte. Te amarra indefinidamente.
- Prohíbe que terceros modifiquen el código. Cautiverio con otro nombre.
- El hosting queda a nombre del proveedor. Control real de tu operación en manos ajenas.
- No hay procedimiento de salida. El día que quieras irte, empieza la negociación desde cero.
Y si ya firmaste sin esto
Es más común de lo que parece. Opciones, en orden de facilidad:
- Pídelo por escrito ahora. Muchos proveedores serios acceden a firmar un anexo de cesión: no tienen intención de retenerte.
- Negócialo en el próximo cambio. Cuando necesites un módulo nuevo, condiciona esa contratación a regularizar la propiedad.
- Asegura al menos la infraestructura. Aunque el código sea discutible, dominio, hosting y datos deberían pasar a tu nombre ya.
- Documenta lo que tienes. Si no consigues el código, al menos ten claro qué hace el sistema, para poder reconstruirlo si hace falta.
Si el proveedor desapareció y estás en el peor escenario, revisa nuestra guía de rescate de proyectos abandonados, que aplica también a sistemas.
Preguntas frecuentes
¿Ser dueño del código encarece el proyecto?
Puede tener un efecto en el precio cuando implica que el proveedor ceda componentes que reutiliza con otros clientes. La fórmula equilibrada —propiedad de lo hecho a medida más licencia perpetua de lo reutilizable— normalmente no encarece nada y te da todo el control práctico que necesitas.
¿Qué pasa con las librerías de código abierto?
Se rigen por su propia licencia y nadie puede cederte su propiedad. Lo importante es que estén inventariadas y que sus licencias sean compatibles con el uso que le vas a dar. Un proveedor serio te entrega esa lista sin que se la pidas.
¿Debo pedir el código aunque no sepa qué hacer con él?
Sí. No es para que lo leas: es para no depender de una sola empresa. El día que necesites cambiar de proveedor, ampliar el sistema o simplemente auditar cómo está construido, tenerlo es la diferencia entre una transición ordenada y empezar de cero.
¿Y si el proveedor se niega a ceder el código?
Es información valiosa sobre con quién estás tratando. Puede haber razones legítimas para no ceder componentes propios, pero negarse a entregar el código hecho específicamente para ti, financiado por ti, es una señal para revisar la relación antes de firmar.
Artículos relacionados
- Cómo se cotiza un proyecto de software: qué es el discovery
- Cómo escribir los requerimientos antes de pedir cotizaciones de software
- Cuánto tarda desarrollar un sistema empresarial: plazos reales por fase
Desarrollo de software a medida
¿Tienes un proyecto de sistema en mente?
Hacemos el diagnóstico sin costo: levantamos el problema, te decimos qué se necesita de verdad y entregamos una propuesta escrita con alcance y precio cerrados en 3 a 5 días hábiles.
Conversemos tu proyecto
Ver portafolio
64 clientes en 14 verticales · proyectos@bluenova.com.ec · +593 96 949 8704
Sigue leyendo
Comentarios y opiniones
0 comentarios · Moderación previa
Cuéntanos tu experiencia, dudas o casos similares. Revisamos cada comentario antes de publicarlo para mantener conversaciones de calidad. También puedes suscribirte para recibir nuevos artículos.