// contratación · derecho · perú
El contrato de desarrollo de software en Perú (y quién se queda el código)
Hay una creencia extendida entre quienes mandan a construir software en Perú: que pagar por el desarrollo te convierte en dueño del código. No es así, y la sorpresa suele llegar en el peor momento — cuando quieres cambiar de proveedor, cuando pides el repositorio, o cuando el sistema hay que modificarlo y descubres que no tienes derecho a tocarlo.
D.L. 822
la norma que protege el software como obra
Cesión expresa
sin ella, el pago no transfiere los derechos
6 cosas
que hay que ceder además del código fuente
Inalienables
los derechos morales, que nadie puede firmar
¿Tienes este problema ahora mismo? Lo hemos resuelto en producción.
Ver cómo lo hacemos →Pagar el servicio no es comprar la obra
En Perú, el Decreto Legislativo 822 —la Ley sobre el Derecho de Autor— protege el programa de ordenador como obra, tanto en su versión de código fuente como de código objeto, siempre que sea original. Y protege la obra a favor de su autor.
Eso significa que el contrato de servicio y la titularidad de la obra son dos cosas distintas. Pagas por un servicio de desarrollo y recibes ese servicio. Los derechos patrimoniales sobre lo construido siguen siendo del autor mientras no se cedan, y la cesión se hace por un acto expreso, no por el hecho de haber pagado la factura.
No es una tecnicidad de abogados: decide si dentro de tres años puedes llevarte tu sistema a otro equipo, o si tienes que negociarlo con quien lo escribió.
Los que se ceden y los que no se pueden ceder
El derecho de autor peruano separa dos bloques. Los patrimoniales —reproducir, modificar, distribuir, explotar la obra— son los que se transfieren y los que necesitas.
Los morales —el reconocimiento de la autoría, entre otros— son irrenunciables e inalienables. Nadie puede cederlos aunque lo firme, y un contrato que pretenda hacerlo está prometiendo algo que la ley no permite. Que tu proveedor conserve la paternidad de la obra no te quita nada operativamente: puedes usar, cambiar y explotar el sistema igual.
La señal de alarma es la inversa: un contrato que no dice nada sobre derechos patrimoniales. El silencio no juega a tu favor — juega a favor del autor, que es lo que la norma protege por defecto.
Qué hay que ceder además del código fuente
Una cláusula que cede “el software” y nada más te deja con un repositorio que quizá no puedas ni desplegar. Esto es lo que hace falta para operar y cambiar el sistema de verdad.
| Qué | Por qué importa |
|---|---|
| Código fuente | Sin él no puedes cambiar nada sin volver a quien lo hizo. |
| Documentación técnica | Lo que permite que otro equipo entienda el sistema sin reconstruirlo. |
| Diseños y prototipos | También son obra protegida, y se olvidan casi siempre. |
| Modelo de base de datos | El esquema y las migraciones — tu data sin su estructura no se opera. |
| Scripts y pipelines | Lo que despliega el sistema. Sin esto tienes el código pero no cómo ponerlo en producción. |
| Infraestructura como código | La definición del entorno. Es la diferencia entre poder mudarte de proveedor o no. |
Conviene además que la cesión diga su alcance: si es exclusiva o no exclusiva, para qué territorio, por cuánto tiempo y para qué formas de explotación. “Cede los derechos” a secas deja demasiado abierto.
Las cláusulas que deciden el proyecto, no solo la propiedad
lo que sí debe estar escrito
- Alcance y entregables, con criterio de aceptación — qué se considera terminado y quién lo declara.
- Hitos y pagos atados a entregables, no a fechas del calendario.
- Garantía posterior a la entrega: cuánto dura y qué cubre exactamente.
- Confidencialidad, en ambos sentidos y con plazo.
- Qué pasa si el proyecto se detiene: quién se queda qué en ese punto.
- Ambientes, credenciales y acceso al repositorio desde el día uno, no al final.
- Cesión de derechos patrimoniales, expresa y detallada.
Si eres una entidad pública
El caso tiene una capa más. Las entidades del Estado suelen exigir la cesión en términos amplios —explotación no exclusiva, ilimitada, perpetua y para todo territorio, incluyendo reproducción, comunicación pública, distribución y modificación— y eso debe estar en las bases antes de la firma, no negociarse después.
Si estás preparando la contratación, la pieza previa es el documento de requerimientos. Lo desarrollamos en cómo elaborar un TDR de software a medida, que es donde se define qué se va a contratar antes de discutir bajo qué condiciones.
Los errores que vemos
El más común es el modelo descargado sin adaptar. Buena parte de las plantillas que circulan están escritas para Argentina, Colombia o España, y otra buena parte vive en sitios de apuntes universitarios sin ninguna garantía. Sirven para entender la estructura; no para firmar.
El segundo es dejar la cesión para el final, cuando el proyecto ya está entregado y la posición negociadora es la contraria. Y el tercero es confundir acceso con titularidad: que te den el repositorio no significa que tengas derecho a explotarlo.
Esto no sustituye a un abogado
Somos ingenieros, no abogados, y este artículo explica cómo funciona el terreno para que sepas qué preguntar — no reemplaza asesoría legal. Para redactar o revisar un contrato concreto, que lo vea un abogado peruano especializado en propiedad intelectual.
Lo que sí podemos decirte desde el lado técnico es qué debería entregarse para que el sistema sea realmente tuyo y operable. En nuestros proyectos el código es 100 % del cliente, y esa frase solo significa algo si el contrato lo dice con todas sus letras.
Fuentes
Preguntas frecuentes
Si pago por el software, ¿el código es mío?
No automáticamente. Bajo el Decreto Legislativo 822 el programa de ordenador es una obra protegida y sus derechos patrimoniales pertenecen al autor mientras no se cedan. Pagar por el servicio te compra el servicio; no transfiere por sí solo los derechos sobre el código. Esa transferencia tiene que estar escrita en el contrato.
¿Qué diferencia hay entre derechos patrimoniales y morales?
Los patrimoniales —reproducir, modificar, distribuir y explotar la obra— sí se ceden, y son los que una cláusula bien hecha te transfiere. Los morales, como que se reconozca la autoría, son inalienables en el derecho peruano: nadie puede renunciar a ellos y ningún contrato debería pretenderlo.
¿Qué debe abarcar exactamente la cesión?
No solo el código fuente. La documentación, los diseños, el modelo de base de datos, los scripts, los pipelines de despliegue y la infraestructura como código son parte de lo que necesitas para operar y cambiar el sistema después. Una cláusula que dice solo “el software” deja fuera justo lo que lo hace mantenible.
¿Basta con un modelo de contrato descargado?
Como punto de partida sí, como documento final no. Los modelos que circulan están escritos en su mayoría para otros países, y los que viven en sitios de apuntes universitarios no ofrecen ninguna garantía. Úsalo para entender la estructura y que un abogado peruano lo adapte a tu proyecto.
¿Vas a contratar un desarrollo?
Te decimos qué pedir y qué debería entregarse, en el lenguaje del proyecto. Hablas con el ingeniero, no con un comercial.