Contrato con desarrolladores: qué debes incluir

Si estás contratando a un desarrollador o agencia para crear tu software, la pregunta clave no es cuánto cuesta: es qué dice el contrato. Un contrato mal redactado puede dejarte sin la propiedad del código que pagaste, sin el código fuente, y sin herramientas legales cuando algo falla. Estas son las cláusulas que no pueden faltar.

Contrato con desarrolladores: qué debes incluir

Por qué el contrato con tu desarrollador es más importante que el precio

Cuando una empresa decide desarrollar un software a medida, la negociación suele girar en torno al precio, los plazos y las funcionalidades. El contrato se trata como un trámite secundario, cuando en realidad es el documento más importante de toda la relación.

En Chile, el derecho de autor nace en favor de quien crea la obra. Eso significa que si contratas a un desarrollador freelance o a una agencia y el contrato no establece expresamente la cesión de derechos patrimoniales, el código sigue siendo del desarrollador — aunque tú lo hayas pagado íntegramente. Esta es la regla general de la Ley N° 17.336 sobre Propiedad Intelectual, y sorprende a la mayoría de los clientes cuando ya es demasiado tarde.

Un contrato bien estructurado no solo protege tu propiedad intelectual: también define las reglas del juego para la entrega, los errores, la confidencialidad y la salida de la relación comercial. Este artículo desarrolla en detalle cada una de las cláusulas que debes exigir — o negociar — antes de firmar cualquier acuerdo con un desarrollador o agencia de tecnología.

Nota importante: Este artículo se enfoca en el contrato de desarrollo a medida, donde el cliente encarga la creación de un software específico para sus necesidades y tiene como objetivo obtener la titularidad del código resultante. Si lo que estás firmando es un contrato de licencia de software estándar, las reglas son distintas — te recomendamos revisar nuestro artículo sobre contrato de desarrollo de software y propiedad intelectual para entender esa distinción.

1. Cláusula de cesión de derechos patrimoniales: la más importante

Esta es la cláusula más crítica de todo el contrato. Sin ella, el desarrollador conserva la titularidad del código — aunque tú hayas pagado por su creación.

Una cláusula de cesión bien redactada debe hacer lo siguiente:

• Identificar precisamente la obra: debe describir el software que se está desarrollando con suficiente detalle. «El software de gestión de inventario descrito en el Anexo de Especificaciones Técnicas adjunto» es correcto. «El software» a secas puede generar disputas.
• Ceder todos los derechos patrimoniales: reproducción, distribución, transformación, comunicación pública y cualquier otra forma de explotación, presente o futura. Si la cláusula solo menciona algunos derechos, los no mencionados quedan en el desarrollador.
• Definir territorialidad: la cesión puede ser para Chile o para todo el mundo. Para un negocio con proyección internacional, es recomendable que sea mundial.
• Establecer duración: idealmente por toda la vigencia de los derechos (vida del autor más 70 años), no por un plazo limitado. Una cesión temporal puede implicar que el desarrollador recupere los derechos después de cierto tiempo.
• Incluir precio de la cesión: en Chile, la cesión de derechos patrimoniales debe ser onerosa para ser plenamente válida. Es recomendable que el precio total del contrato incluya explícitamente un monto por la cesión de derechos, aunque sea simbólico.

Un ejemplo de redacción adecuada:

«El Desarrollador cede al Cliente, con carácter exclusivo, irrevocable, a título oneroso y por toda la vigencia de los derechos, todos los derechos patrimoniales sobre el Software desarrollado en virtud del presente contrato, incluyendo sin limitación los derechos de reproducción, distribución, transformación, comunicación pública y cualquier otra forma de explotación, en todo el territorio del mundo. El precio por la cesión de derechos se incluye dentro del precio global del proyecto.»

Revisa que tu contrato tenga algo equivalente a esto. Si no lo tiene, agrega esa cláusula antes de firmar.

2. Cláusula de entrega del código fuente

Muchos clientes reciben el software funcionando, pero nunca obtienen el código fuente. Esto los deja en una posición de dependencia total respecto del desarrollador original: cualquier modificación, corrección o ampliación futura requiere contratar al mismo proveedor, quien sabe perfectamente que tiene el control.

El contrato debe establecer:

• Qué se entrega: el código fuente completo, documentado y comentado, incluyendo todos los módulos, scripts de base de datos, archivos de configuración y documentación técnica necesaria para operar, mantener y modificar el software de forma independiente.
• Cuándo se entrega: idealmente al finalizar cada hito o sprint, no solo al completar el proyecto. Si el proyecto se detiene a mitad de camino, el cliente debe poder recuperar lo que pagó.
• En qué formato: repositorio Git con historial de commits completo, o en su defecto un archivo comprimido con la estructura del proyecto documentada.
• Qué pasa si no se entrega: el contrato debe establecer una obligación exigible y una consecuencia concreta — por ejemplo, la retención de una parte del precio hasta la entrega efectiva del código fuente.

Sin esta cláusula, puedes terminar siendo dueño legal del software pero sin acceso real al activo que compraste.

3. Cláusula de declaración de originalidad y garantía de no infracción

El desarrollador debe garantizar que el código que te entrega es de su autoría original y que no incorpora material de terceros sin la debida autorización. Esta cláusula te protege frente a una situación que se da con más frecuencia de lo que parece: el desarrollador reutiliza código de proyectos anteriores, utiliza fragmentos copiados de internet, o integra librerías sin revisar la compatibilidad de sus licencias.

La garantía debe cubrir:

• Que el software no infringe derechos de autor de terceros.
• Que el desarrollador tiene plena facultad para ceder los derechos que está cediendo.
• Que no existen cargas, gravámenes ni derechos de terceros sobre el software entregado.

Y debe incluir una cláusula de indemnidad: si surge una demanda de infracción por parte de terceros, el desarrollador asume los costos de defensa y el pago de cualquier indemnización que se declare.

4. Cláusula de gestión de componentes open source

Hoy prácticamente todo el software incorpora componentes de código abierto: librerías, frameworks, módulos. Esto no es un problema en sí mismo, pero sí puede serlo si el desarrollador no gestiona correctamente las licencias de esos componentes.

El problema más común es el uso de componentes con licencia GPL (GNU General Public License) en un software comercial. La GPL tiene un efecto de «contagio»: si tu software incorpora código GPL, el software completo debe ser distribuido bajo GPL — es decir, con el código fuente disponible públicamente. Para un software comercial propietario, esto puede ser devastador.

El contrato debe exigir:

• Un inventario completo de todos los componentes de código abierto utilizados, con sus versiones y licencias.
• Una declaración de que ningún componente tiene licencia incompatible con el uso comercial propietario previsto.
• La obligación de reemplazar cualquier componente problemático que se detecte durante el proyecto o tras la entrega.

5. Cláusula de confidencialidad

Durante el desarrollo, el desarrollador tendrá acceso a información sensible de tu negocio: procesos internos, datos de clientes, estrategias comerciales, integraciones con otros sistemas. La cláusula de confidencialidad — o NDA (Non-Disclosure Agreement) integrado al contrato — establece que toda esa información es reservada y no puede ser divulgada ni usada para fines distintos al desarrollo.

Los elementos clave de una buena cláusula de confidencialidad son:

• Definición amplia de información confidencial: debe cubrir no solo los documentos marcados como confidenciales, sino toda la información del negocio compartida en el contexto del proyecto, salvo que sea de dominio público.
• Obligación de no usar para fines propios: el desarrollador no puede usar lo que aprende sobre tu negocio para desarrollar productos propios o asesorar a terceros.
• Plazo: la confidencialidad debe extenderse más allá de la vigencia del contrato. Un plazo razonable es 3 a 5 años después de la terminación del proyecto.
• Consecuencias del incumplimiento: debe establecerse una cláusula penal o la posibilidad de exigir indemnización de perjuicios por infracción.

6. Cláusula de no competencia

Esta cláusula restringe al desarrollador de usar el conocimiento adquirido durante tu proyecto para desarrollar productos similares o prestar servicios a tus competidores directos durante un período determinado.

Para que sea válida y efectivamente oponible en Chile, la cláusula de no competencia debe ser:

• Limitada en tiempo: un plazo razonable es entre 12 y 24 meses desde la terminación del proyecto. Cláusulas indefinidas son difíciles de sostener.
• Limitada en alcance: debe restringirse al rubro específico del negocio, no a toda actividad relacionada con software. Una restricción demasiado amplia puede ser impugnada.
• Compensada: para tener mayor solidez jurídica, conviene que la cláusula tenga una contraprestación económica, aunque sea parte del precio total.

7. Cláusula de desarrollos previos y componentes preexistentes del desarrollador

Los desarrolladores frecuentemente utilizan en proyectos nuevos componentes, módulos o librerías que han creado en proyectos anteriores. Esto es perfectamente legítimo, pero debe quedar bien regulado en el contrato.

El problema surge cuando la cesión de derechos se redacta de forma tan amplia que podría interpretarse como una cesión de esos componentes preexistentes también — lo que el desarrollador claramente no tenía intención de ceder. O, al revés, cuando el desarrollador incluye componentes de proyectos anteriores que legalmente son propiedad de otros clientes.

La solución es incluir un anexo que liste los componentes preexistentes del desarrollador que se incorporarán al software, estableciendo que:

• El cliente recibe una licencia de uso perpetua sobre esos componentes para los efectos del software desarrollado.
• La titularidad de esos componentes permanece en el desarrollador.
• El desarrollador garantiza que tiene plenas facultades para licenciarlos al cliente.

8. Cláusula de garantía de funcionamiento post-entrega

Una vez entregado el software, inevitablemente aparecerán errores que no fueron detectados durante las pruebas. La cláusula de garantía establece la obligación del desarrollador de corregir esos errores durante un período determinado sin costo adicional.

Los elementos que debe definir:

• Plazo: lo habitual es 3 a 6 meses desde la aceptación formal del software. Plazos menores son insuficientes; mayores son difíciles de negociar.
• Alcance: la garantía cubre errores de funcionamiento respecto de las especificaciones acordadas — no nuevas funcionalidades ni cambios de requerimientos.
• Tiempos de respuesta: el contrato puede establecer SLAs (niveles de servicio): errores críticos en X horas, errores menores en Y días hábiles.
• Exclusiones: qué no está cubierto por la garantía — por ejemplo, errores causados por modificaciones hechas por terceros sin autorización del desarrollador.

9. Cláusula de procedimiento de aceptación

Sin un procedimiento de aceptación claro, surge uno de los conflictos más frecuentes en proyectos de software: el desarrollador dice que entregó; el cliente dice que lo entregado no funciona conforme a lo acordado. Y no hay mecanismo para resolverlo.

Un buen procedimiento de aceptación define:

• Criterios objetivos: qué debe hacer el software para considerarse aceptado. Idealmente, esto se vincula a los casos de uso o requerimientos funcionales definidos en el anexo técnico.
• Período de pruebas: un plazo de X días hábiles para que el cliente evalúe el software y reporte observaciones.
• Proceso de correcciones: cómo se manejan las observaciones: el desarrollador tiene Y días para corregirlas, y luego hay un nuevo período de prueba.
• Aceptación tácita: qué ocurre si el cliente no reporta observaciones dentro del plazo — generalmente se entiende que el software fue aceptado.

10. Cláusula de subcontratación

¿Puede tu desarrollador subcontratar parte del trabajo a terceros? Esta es una pregunta que muchos clientes no hacen — y luego descubren que el software fue desarrollado en parte por personas o empresas que no tienen ninguna relación contractual con ellos y que nunca cedieron sus derechos.

El contrato debe regular:

• Si la subcontratación requiere autorización previa del cliente o simplemente notificación.
• Que el desarrollador es el único responsable ante el cliente por el trabajo de los subcontratistas.
• Que el desarrollador debe obtener la cesión de derechos de los subcontratistas antes de cedérselos al cliente. Sin esta cadena de cesiones, la titularidad del cliente puede ser cuestionada.

11. Cláusula de resolución de disputas

Cuando la relación se deteriora — y a veces ocurre — el mecanismo de resolución de disputas puede ser la diferencia entre un conflicto que se resuelve en meses y uno que se extiende por años.

Las opciones más comunes en Chile son:

• Mediación: proceso voluntario y confidencial. Permite llegar a acuerdos rápidamente si ambas partes quieren resolver. No es vinculante si alguna parte no quiere participar.
• Arbitraje: proceso privado con un árbitro elegido por las partes, cuya decisión es vinculante. Más rápido y técnico que los tribunales ordinarios para materias tecnológicas. Tiene costo, pero suele ser mucho más eficiente.
• Tribunales ordinarios: la opción por defecto si el contrato no establece otra cosa. Más lento, más público, y los jueces no siempre tienen conocimiento técnico en materia de software.

Para proyectos de software de cierta envergadura, el arbitraje suele ser la opción más recomendable. El contrato debe establecer el tipo de árbitro (árbitro de derecho o árbitro mixto), las reglas del procedimiento y la legislación aplicable.

12. Qué pasa cuando el proyecto se detiene antes de terminar

No todos los proyectos llegan a buen término. A veces el cliente decide pausar o abandonar el proyecto; otras veces es el desarrollador quien no puede o no quiere continuar. El contrato debe regular esta situación antes de que ocurra.

Las cláusulas que deben cubrir este escenario son:

• Condiciones de terminación anticipada: qué puede hacer cada parte para poner término al contrato antes de la entrega final, y con qué previo aviso.
• Pago proporcional: si el cliente termina el contrato antes de lo acordado, qué paga por el trabajo realizado hasta la fecha.
• Entrega de lo desarrollado hasta ese momento: ante una terminación anticipada, el desarrollador debe entregar el código y la documentación correspondiente al trabajo ya realizado, con la cesión de derechos sobre esa parte.
• Penalidades por incumplimiento: si el desarrollador abandona el proyecto sin causa justificada, el contrato debe establecer las consecuencias — devolución de anticipos, pago de diferencia de precio con nuevo proveedor, etc.

🧠 Checklist: lo que no puede faltar en tu contrato con desarrolladores

La relación entre el contrato y el registro de software

Un contrato bien redactado te da la titularidad del software. Pero hay un paso adicional que muchos empresarios no conocen: el registro de software en el Departamento de Derechos Intelectuales (DDI) del Ministerio de las Culturas, las Artes y el Patrimonio.

El registro no es obligatorio para que el derecho de autor exista — ya hemos dicho que nace automáticamente. Pero sí cumple funciones prácticas muy importantes:

• Genera una fecha cierta de titularidad: en caso de disputa, tienes un registro público que acredita que eras dueño del software en una fecha determinada.
• Facilita la oponibilidad frente a terceros: en caso de infracción, el registro es un elemento de prueba de primer orden.
• Es necesario para licenciar o vender el software de forma formal: muchos compradores o inversores exigen que el software esté registrado antes de cerrar una transacción.

Te recomendamos revisar nuestro artículo sobre cómo registrar un software en Chile y el de registro DDI para software SaaS si tu producto funciona en la nube.

Errores frecuentes que vemos en contratos revisados

En nuestra práctica revisamos regularmente contratos de desarrollo de software que presentan problemas recurrentes. Los más frecuentes:

• Confundir licencia con cesión: el contrato habla de «licencia de uso» del software en favor del cliente, cuando lo que el cliente quería era ser el dueño. Son figuras completamente distintas.
• Cláusula de propiedad intelectual de una línea: «Los derechos sobre el software corresponden al cliente» — sin definir qué derechos, qué software, en qué territorio, por cuánto tiempo. Genera disputas en todos los flancos posibles.
• Sin mención al código fuente: el contrato regula la entrega del software pero no del código fuente. El cliente recibe el ejecutable pero no tiene acceso al código.
• Sin procedimiento de aceptación: el contrato establece que el software «será entregado según las especificaciones», pero no define cómo se verifica ese cumplimiento.
• Jurisdicción extranjera sin negociación: el desarrollador incluye cláusulas de jurisdicción en otro país o bajo ley extranjera, lo que hace prácticamente imposible que el cliente ejerza sus derechos en Chile.

Conclusión

Un contrato con desarrolladores bien redactado es el instrumento que convierte tu inversión en un activo protegido. Sin él, puedes haber pagado por algo que legalmente no te pertenece, sin acceso al código, sin garantías y sin herramientas para resolver el conflicto cuando surge.

La buena noticia es que un contrato sólido no tiene por qué ser un documento intimidante ni imponer condiciones abusivas al desarrollador. El objetivo es simplemente que las reglas estén claras desde el inicio, para que ambas partes puedan enfocarse en lo que importa: construir buen software.

En von Marttens asesoramos a empresas y emprendedores que contratan desarrollo de software, revisando o redactando contratos que protejan su inversión y su propiedad intelectual desde el primer día.

Contáctanos en vonmarttens.cl

Información de uso de IA: Este artículo fue escrito por miembros de nuestro equipo, sin embargo se utilizaron herramientas de IA con el objeto de mejorar la legibilidad y estructurar los textos para motores de búsqueda.

Artículos relacionados

• Contrato de desarrollo de software y propiedad intelectual
• El rol del contrato en la propiedad del software
• Riesgos de no regular la propiedad de un software
• Software desarrollado por terceros: quién es el dueño legal del código
• Cómo registrar un software en Chile
• Registro DDI para software SaaS: cómo proteger tu código en la nube
• Dueño de un software: titularidad y propiedad intelectual en Chile
• Contratos para empresa de tecnología en Chile