Contrato de desarrollo de software: cláusulas esenciales que protegen al contratante

Esta página es una traducción del texto original en portugués, ofrecida para facilitar la lectura. Trata del derecho brasileño. En caso de divergencia, prevalece la versión en portugués. Leer el original en portugués

Los contratos de software a medida mueven cifras significativas en el mercado tecnológico, pero suelen guardar silencio sobre las cláusulas que más importan. La falta de una previsión expresa de cesión de derechos de autor puede dejar la titularidad del código en manos de quien lo desarrolló, aunque el contratante haya pagado el valor íntegro. A este riesgo se suman los vacíos sobre el mantenimiento posterior a la entrega, los plazos de corrección de fallas críticas, las penalidades por retraso y la protección de datos confidenciales.

Titularidad del código fuente y la propiedad de lo que se paga

El punto más sensible en un encargo de software es definir a quién pertenece el resultado. Muchos contratantes asumen que, al pagar por el desarrollo, se convierten automáticamente en dueños del programa. Esa premisa no siempre se confirma en el plano jurídico.

La Ley de Software (Ley 9.609 de 1998) y la Ley de Derechos de Autor (Ley 9.610 de 1998) tratan el programa de computación como una obra intelectual protegida. La consecuencia práctica es directa: sin una cláusula expresa de cesión, la empresa que contrató puede quedarse únicamente con una licencia de uso, mientras que la titularidad de los derechos patrimoniales permanece con el desarrollador.

Esta distinción entre licenciar y ceder define el futuro del negocio. Quien posee una licencia usa el programa dentro de los límites de lo autorizado. Quien posee la titularidad puede modificar, revender, sublicenciar e impedir que terceros exploten el mismo código.

Cesión de derechos de autor: por qué la cláusula debe ser expresa y detallada

La cesión de los derechos patrimoniales sobre el software exige una previsión escrita y específica. Una redacción genérica, del tipo «el contratante tendrá todos los derechos sobre el producto», da lugar a interpretaciones divergentes y a disputas posteriores.

Un contrato bien construido describe con precisión el objeto de la cesión: código fuente, código objeto, documentación técnica, bibliotecas propias desarrolladas para el proyecto y eventuales artefactos auxiliares. También aclara si la cesión es total o parcial, si rige en todo el territorio nacional y en el extranjero, y por cuánto tiempo.

Otra precaución relevante se refiere a los componentes de terceros. Buena parte de las aplicaciones modernas incorpora bibliotecas de código abierto, módulos licenciados y servicios externos. El contrato debe distinguir lo que efectivamente se cede de aquello que solo forma parte de la solución bajo licencia de terceros, para evitar que el contratante crea haber recibido derechos que el propio desarrollador no podía transferir.

Conviene, además, prever la entrega formal del código fuente y de las credenciales de acceso a los repositorios. Sin ello, el contratante puede tener la titularidad sobre el papel, pero depender técnicamente del desarrollador para cualquier evolución del producto.

La Ley de Software (Ley 9.609 de 1998) y la Ley de Derechos de Autor (Ley 9.610 de 1998) tratan el programa de computación como una obra intelectual protegida.

Alcance del mantenimiento y SLA de errores críticos: qué medir y qué exigir

Una vez entregado el software, comienza la vida real del producto. Es en ese momento cuando la ausencia de cláusulas de mantenimiento pasa factura. Aparecen fallas, cambian los entornos, se rompen las integraciones, y el contrato debe decir quién responde por ello y en cuánto tiempo.

El primer elemento es la separación entre garantía y mantenimiento evolutivo. La garantía cubre los defectos de lo contratado, dentro de un período definido y sin costo adicional. El mantenimiento evolutivo se ocupa de nuevas funcionalidades y mejoras, normalmente remuneradas aparte. Mezclar ambos conceptos genera fricciones y cobros inesperados.

El segundo elemento es el acuerdo de nivel de servicio, conocido por la sigla SLA. Establece plazos objetivos de respuesta y de solución según la gravedad del problema. Una falla que tumba todo el sistema no puede tener el mismo plazo que un ajuste estético.

Una clasificación útil distingue niveles de severidad. Las fallas críticas paralizan la operación y exigen atención inmediata. Las fallas graves comprometen funciones importantes, pero admiten una solución temporal. Las fallas leves afectan aspectos secundarios. Para cada nivel, el contrato fija el tiempo máximo de respuesta y de corrección, además de las consecuencias del incumplimiento.

Sin esta graduación, el contratante queda a merced de la buena voluntad del proveedor. Con ella, cuenta con parámetros medibles y exigibles, capaces de sustentar un eventual cobro de penalidades o la resolución del contrato por incumplimiento.

Plazos, penalidades por retraso y confidencialidad de los datos

Los retrasos en la entrega son frecuentes en los proyectos tecnológicos, y el contrato debe anticipar cómo tratarlos. La previsión de una multa por incumplimiento de plazo cumple una doble función: compensa al contratante por el perjuicio y desalienta la postergación indefinida del cronograma.

Una redacción eficaz vincula la penalidad a hitos verificables, y no a una única fecha lejana. Las entregas parciales, las homologaciones intermedias y las aceptaciones por etapa permiten detectar el retraso a tiempo y activar la cláusula sin esperar al colapso de todo el proyecto.

La confidencialidad merece un capítulo propio. En el desarrollo a medida, el proveedor suele acceder a información estratégica, bases de datos, reglas de negocio y, con frecuencia, datos personales de los clientes del contratante. La circulación de ese contenido exige una protección contractual sólida.

La Ley General de Protección de Datos (Ley 13.709 de 2018) refuerza esta preocupación. Cuando el software trata datos personales, el contrato debe definir roles, responsabilidades y medidas de seguridad, además de obligaciones de notificación en caso de incidente. La omisión expone al contratante a sanciones administrativas y a reclamaciones de reparación por parte de los titulares de los datos.

Las cláusulas de confidencialidad bien diseñadas sobreviven a la terminación del contrato. Establecen el plazo de vigencia de la obligación, los supuestos de excepción, el destino o la destrucción de la información tras el cierre y penalidades específicas por la violación del secreto, sin perjuicio de los daños y perjuicios que correspondan.

Lista práctica de revisión contractual antes de firmar

Antes de suscribir un contrato de software a medida, conviene seguir una guía objetiva de verificación. El examen previo evita que puntos decisivos queden abiertos y reduce el riesgo de litigio.

• Cesión de derechos de autor prevista de forma expresa, con descripción del objeto, alcance territorial y plazo.
• Entrega formal del código fuente, de la documentación y de las credenciales de repositorios y entornos.
• Distinción clara entre los componentes propios cedidos y las bibliotecas de terceros bajo licencia externa.
• Separación entre el período de garantía y el mantenimiento evolutivo remunerado.
• Acuerdo de nivel de servicio con severidades graduadas y plazos objetivos de respuesta y solución.
• Penalidades por retraso vinculadas a hitos verificables, y no a una fecha final aislada.
• Cláusula de confidencialidad con vigencia posterior al contrato y destino de la información.
• Tratamiento de datos personales conforme a la legislación de protección de datos, con roles definidos.
• Supuestos de resolución, consecuencias y reglas de transición hacia otro proveedor.

Esta guía no sustituye el análisis individual de cada caso, pero funciona como filtro inicial. Los contratos que fallan en varios de estos puntos tienden a trasladar riesgo y poder al desarrollador, en perjuicio de quien invierte en el producto.

La revisión jurídica especializada, realizada antes de la firma, suele costar una fracción de lo que se gasta para resolver un conflicto después. Cuando el software se convierte en un activo central de la operación, cada cláusula descuidada pasa a ser un punto de vulnerabilidad.

Preguntas Frecuentes

¿Pagar por el desarrollo garantiza la propiedad del software?

No necesariamente. El pago remunera el servicio, pero la titularidad de los derechos patrimoniales sobre el programa depende de una cláusula expresa de cesión. Sin ella, el contratante puede quedar limitado a una licencia de uso, mientras que los derechos sobre el código permanecen con quien lo desarrolló. Por eso, la previsión escrita y detallada de la cesión es el elemento más importante del contrato.

¿Qué debe constar en un SLA de mantenimiento de software?

Un buen acuerdo de nivel de servicio clasifica las fallas por gravedad, define plazos objetivos de respuesta y de solución para cada nivel y establece las consecuencias del incumplimiento. También separa la garantía del mantenimiento evolutivo y describe los canales de atención, los horarios de cobertura y la forma de registro de las solicitudes, de modo que todo sea medible y exigible.

¿Cómo se relaciona la protección de datos con el contrato de software?

Cuando el sistema trata datos personales, el contrato debe cumplir la legislación de protección de datos, definiendo roles, responsabilidades y medidas de seguridad. Debe prever obligaciones de confidencialidad, reglas para la notificación de incidentes y el destino de la información al término de la relación. La ausencia de estas cláusulas expone al contratante a sanciones administrativas y a reclamaciones de reparación por parte de los titulares de los datos.

As informações deste artigo são de caráter informativo e não substituem consulta jurídica individualizada. Cada caso possui particularidades que exigem análise específica.