Contrato de desarrollo de software freelance en España: guía completa

El código como obra protegida: lo que todo programador debe saber

En España, el código fuente está protegido por la Ley de Propiedad Intelectual (Real Decreto Legislativo 1/1996) como obra literaria. Esto significa que el programador que escribe el código es su autor y titular de los derechos de explotación desde el momento en que lo crea, sin necesidad de registro.

Las consecuencias prácticas son importantes:

• Si no existe una cesión de derechos por escrito, el desarrollador conserva todos los derechos sobre el código aunque el cliente haya pagado el desarrollo.
• El cliente que usa ese código sin una cesión válida está cometiendo una infracción de la LPI.
• La cesión puede ser total o parcial, limitada en el tiempo o indefinida, exclusiva o no exclusiva.

Un contrato de desarrollo de software que no regula la propiedad intelectual del código es un contrato incompleto.

En qué se diferencia el contrato de software del contrato web

Aunque comparten elementos, el contrato de desarrollo de software tiene particularidades propias:

Mayor complejidad técnica: los proyectos de software pueden tener componentes de backend, APIs, integraciones con terceros, bases de datos, aplicaciones móviles y lógica de negocio compleja. Los criterios de aceptación son más elaborados que en un proyecto web.

SLA y mantenimiento post-entrega: en software empresarial, el cliente puede necesitar garantías de disponibilidad, tiempo de respuesta ante incidencias y mantenimiento continuo. Esto no suele estar en un contrato web estándar.

Licencias de terceros más complejas: el software hace un uso intensivo de librerías, frameworks y APIs de terceros con condiciones de licencia muy distintas. El cliente necesita entender qué usa y en qué condiciones.

Mayor exposición en limitación de responsabilidad: si el software falla en producción, el impacto para el negocio del cliente puede ser muy alto. Sin una cláusula de limitación de responsabilidad, la exposición del desarrollador es potencialmente ilimitada.

Las cláusulas esenciales del contrato de desarrollo de software

Descripción del proyecto y criterios de aceptación

Esta es la cláusula más importante para evitar conflictos. Define:

• Las funcionalidades incluidas en el proyecto (puede ser un documento de especificación técnica adjunto al contrato)
• Las plataformas y entornos soportados (navegadores, sistemas operativos, versiones de lenguaje)
• Los criterios de aceptación: ¿cómo se mide que el software funciona correctamente?
• El proceso de revisión y aprobación: quién valida, en qué plazo, cuántas rondas de feedback están incluidas

Sin criterios de aceptación objetivos, el cliente puede alegar indefinidamente que el software "no funciona como esperaba" sin que haya un baremo claro para resolverlo.

Propiedad intelectual y cesión de derechos sobre el código

Las opciones más habituales en desarrollo de software:

Cesión total al cliente: el cliente adquiere todos los derechos sobre el código. El desarrollador no puede reutilizarlo ni mostrarlo como referencia. Este modelo justifica un precio más alto.

Cesión con reserva de componentes reutilizables: el cliente adquiere los derechos sobre el código específico del proyecto, pero el desarrollador conserva los derechos sobre los componentes y librerías propias que usa habitualmente. Esto es razonable y habitual, pero debe quedar explícitamente redactado.

Licencia de uso: el cliente tiene derecho a usar el software para su actividad, pero el código sigue siendo del desarrollador. Menos habitual para proyectos a medida, pero puede tener sentido para productos SaaS o software basado en una plataforma propia del desarrollador.

Derechos condicionados al pago completo: hasta que el cliente no haya pagado el 100% de los honorarios, el código entregado no puede ser usado ni desplegado en producción. Esta cláusula es especialmente efectiva en proyectos de tamaño medio-grande.

Licencias de componentes de terceros

El contrato debe incluir una declaración de los componentes de terceros utilizados y sus licencias:

• Librerías open source (MIT, Apache, BSD, LGPL, GPL): cada una tiene condiciones distintas
• APIs y servicios de terceros (Google Maps, Stripe, Twilio): tienen sus propios términos de servicio
• Frameworks y herramientas de desarrollo: algunos tienen restricciones de uso comercial

El desarrollador debe informar al cliente de las implicaciones de cada licencia, especialmente en el caso de licencias copyleft (GPL, AGPL) que pueden exigir que el software derivado también sea open source.

El cliente debe asumir la responsabilidad de mantener las suscripciones y licencias necesarias para el funcionamiento continuado del software.

Garantía post-entrega y corrección de errores

Define un período de garantía (habitualmente 30 a 90 días desde la entrega en producción) durante el cual el desarrollador corregirá gratuitamente los errores detectados en el software entregado, siempre que:

• Sean errores del trabajo ejecutado (no nuevas funcionalidades)
• No hayan sido causados por modificaciones del cliente o terceros
• Sean notificados dentro del período de garantía

Fuera del período de garantía, la corrección de errores es un nuevo encargo facturado aparte.

Limitación de responsabilidad

Esta cláusula es crítica en software, especialmente en aplicaciones críticas para el negocio del cliente. El contrato debe limitar la responsabilidad del desarrollador:

• Al importe de los honorarios facturados por el proyecto
• Excluir expresamente daños indirectos, pérdida de beneficios, pérdida de datos o daños consecuenciales
• Excluir responsabilidad por fallos causados por infraestructura del cliente, modificaciones de terceros o uso incorrecto del software

Sin esta cláusula, un fallo en producción puede exponer al desarrollador a reclamaciones por daños que superen ampliamente lo que cobró.

SLA y soporte post-entrega (si aplica)

Para proyectos con mantenimiento continuo, define:

• Niveles de servicio: tiempo máximo de respuesta ante incidencias críticas, altas, medias y bajas
• Horario del soporte (horario laboral, 24/7, etc.)
• Número de horas de desarrollo incluidas al mes en el servicio de mantenimiento
• Precio mensual del mantenimiento y condiciones de revisión anual

Confidencialidad y acceso a sistemas

El desarrollador normalmente accede a entornos de desarrollo o staging del cliente, APIs con credenciales, y puede ver datos de negocio o incluso de usuarios finales. El contrato debe incluir:

• Cláusula de confidencialidad sobre toda la información a la que accede el desarrollador
• Lista de accesos necesarios y propósito de cada uno
• Obligación de devolver o eliminar todas las credenciales al finalizar el proyecto
• Si el software maneja datos personales, un Acuerdo de Tratamiento de Datos (DPA) conforme al RGPD

Gestión de cambios (change management)

En desarrollo de software el scope creep es endémico. El cliente inevitablemente pedirá funcionalidades adicionales que "debería incluir" el proyecto. Define un proceso claro:

1. El cliente solicita el cambio por escrito
2. El desarrollador evalúa el impacto en tiempo y precio
3. Si hay impacto, se firma un addendum antes de empezar
4. Sin addendum, el cambio no se desarrolla

Este proceso protege al desarrollador y, paradójicamente, también al cliente: obliga a priorizar y a tomar decisiones conscientes sobre el alcance.

Genera tu contrato de desarrollo de software personalizado en minutos con Firmia — gratis para empezar.