¿De quién es el código si contrato a un desarrollador en México?

Si contratas a un desarrollador para que haga software para ti y no firman un contrato por escrito, se presume que los derechos patrimoniales sobre el código son del autor: de quien lo escribió, no de quien pagó. Para que sean tuyos hace falta un contrato con términos claros y precisos que establezca una obra por encargo (artículos 83 y 83 bis de la LFDA) o una cesión de derechos por escrito (artículo 30). Por eso la pregunta no se resuelve al final del proyecto, sino al firmar.

¿Qué derechos hay sobre el código de una app?

En México el software es una obra protegida por derecho de autor. Los programas de cómputo son una de las ramas que reconoce la ley (artículo 13, fracción XI, de la LFDA) y se protegen en los mismos términos que las obras literarias, tanto en código fuente como en código objeto (artículo 102).

Sobre esa obra existen dos tipos de derechos, y conviene no confundirlos:

• Derechos morales. Pertenecen siempre a la persona física que escribió el código, porque autor es la persona física que crea la obra (artículo 12). Son inalienables e irrenunciables (artículo 19). No se venden ni se ceden.
• Derechos patrimoniales. Son los que importan para tu negocio. En un programa de computación incluyen autorizar o prohibir su reproducción, modificación, distribución, decompilación y comunicación pública, incluida la puesta a disposición del público (artículo 106).

Cuando alguien pregunta “¿de quién es el código?”, casi siempre pregunta quién es titular de los derechos patrimoniales.

¿Qué es una obra por encargo?

Es el régimen que normalmente conviene al software hecho a la medida, siempre que se pacte por escrito. El artículo 83 de la LFDA establece que, salvo pacto en contrario, la persona física o moral que comisiona la producción de una obra es titular de los derechos patrimoniales sobre ella y le corresponden las facultades de divulgación, integridad y colección. Pero el artículo 83 bis pone la condición: para que una obra se considere realizada por encargo, los términos del contrato deben ser claros y precisos, y en caso de duda prevalece la interpretación más favorable al autor. Sin ese contrato, no hay obra por encargo.

En la práctica significa que:

• Con el contrato firmado, los derechos patrimoniales son tuyos desde que se crea cada entrega, sin un acto posterior de transmisión.
• Las personas que participaron conservan el derecho a que se les mencione como autores de la parte que crearon (artículo 83, segundo párrafo).
• El contrato debe describir el encargo con claridad: qué se construye, con qué alcance y qué se entrega.

Este último punto es el que más se descuida. Un correo con “hazme una app de reservas” no es un contrato claro y preciso.

¿Cuándo se usa una cesión de derechos?

La cesión sirve cuando el software, o parte de él, ya le pertenece a alguien y esa persona te lo transmite. Por ejemplo, un módulo que el desarrollador creó antes por su cuenta o un producto que ya existía. Quien recibe los derechos se vuelve titular derivado (artículo 26).

La LFDA fija reglas estrictas para la cesión:

• Debe celebrarse invariablemente por escrito; de lo contrario es nula de pleno derecho (artículo 30).
• Es onerosa y temporal (artículo 30) y debe prever una participación proporcional en los ingresos o una remuneración fija y determinada a favor del autor o titular (artículo 31).
• En programas de computación, el plazo de la cesión no está sujeto a la limitación general del artículo 33 (artículo 103, segundo párrafo), así que conviene que el contrato fije el plazo pactado.
• Para que surta efectos contra terceros, debe inscribirse en el Registro Público del Derecho de Autor (artículo 32).

¿Y una licencia de uso?

Con una licencia, el titular conserva los derechos patrimoniales y te autoriza a usar el software en las condiciones del contrato: exclusiva o no exclusiva, territorio, plazo, número de usuarios y si puedes modificarlo. También debe constar por escrito (artículo 30). Si es exclusiva, debe otorgarse expresamente con ese carácter (artículo 35).

La licencia tiene sentido cuando prefieres un costo menor o cuando el proveedor ofrece el mismo producto a varios clientes. Lo importante es que sepas que la elegiste, porque no te hace dueño del código.

¿Y si el código lo escribe un empleado de mi empresa?

Para el software hay una regla específica. Salvo pacto en contrario, los derechos patrimoniales sobre un programa de computación y su documentación creados por uno o varios empleados en el ejercicio de sus funciones o siguiendo las instrucciones del empleador corresponden al empleador (artículo 103).

Aun así, conviene que el contrato de trabajo o un convenio aparte lo diga expresamente, y que describa qué funciones incluyen el desarrollo de software. Esa documentación facilita, por ejemplo, registrar el programa o presentarlo a un inversionista.

¿Qué debe decir el contrato de desarrollo?

Un buen contrato de desarrollo deja por escrito, como mínimo:

1. El régimen de titularidad: obra por encargo, cesión o licencia, y desde cuándo aplica.
2. La descripción del encargo: qué se construye, con suficiente detalle para que no haya duda.
3. Los materiales preexistentes: qué partes ya eran del desarrollador y con qué licencia las podrás seguir usando como parte de tu software.
4. La entrega del código fuente: cuándo, en qué repositorio y con qué documentación.
5. Los colaboradores externos: la obligación del proveedor de asegurar por escrito los derechos de cada subcontratista.
6. Los componentes de terceros y de código abierto: la obligación de identificarlos con sus licencias.
7. Las cuentas e infraestructura: a nombre de quién quedan el repositorio, la nube, el dominio y las cuentas de las tiendas de aplicaciones.
8. La confidencialidad: qué información se protege y por cuánto tiempo.

En RexDevs definimos el régimen de propiedad intelectual por escrito antes de empezar, y la parte legal la firma ANBEC Abogados, nuestro despacho aliado. Puedes ver cómo lo trabajamos en software a la medida.

¿Qué pasa con el código abierto dentro de mi app?

Casi toda app usa bibliotecas de código abierto. Esos componentes pertenecen a sus titulares y se rigen por sus propias licencias, no por tu contrato de desarrollo. Ser titular de tu app no te hace titular de las bibliotecas que usa.

Las licencias de código abierto no son iguales. Algunas solo piden conservar el aviso de derechos y el texto de la licencia. Otras, conocidas como copyleft, pueden obligar a distribuir el código fuente de las obras derivadas bajo la misma licencia cuando las distribuyes. Por eso conviene que tu proveedor te entregue una lista de los principales componentes y sus licencias, para que sepas qué obligaciones tienes antes de vender o licenciar tu software.

¿Qué señales de alerta debo revisar?

• No hay contrato, o el contrato no menciona la propiedad intelectual.
• El contrato habla de “licencia” cuando tú esperabas ser dueño del código.
• El proveedor no te da acceso al repositorio ni se compromete a entregar el código fuente.
• Las cuentas de App Store, Google Play, nube o dominio quedan a nombre del desarrollador.
• El encargo está descrito en una línea, sin alcance ni entregables.
• El proveedor usa subcontratistas y no garantiza que obtuvo sus derechos.
• Nadie puede decirte qué componentes de código abierto usa tu app.

Si ya tienes software hecho por otro proveedor, se puede revisar la cadena de derechos y, si está completa, registrarlo ante INDAUTOR.

Si vas a encargar una app o una plataforma y quieres dejar la titularidad resuelta desde el inicio, escríbenos y revisamos tu caso con el equipo de desarrollo y el legal en la misma conversación.