¿Quién es dueño del software desarrollado por empleados en México?
En muchas empresas tecnológicas, la titularidad del software simplemente no se cuestiona.
Se asume que, por pagar el desarrollo o tener un equipo interno, el código pertenece automáticamente a la empresa.
Esa idea suele sostenerse… hasta que alguien la pone a prueba:
en una auditoría, cuando un developer se va, o en un proceso de inversión.
Y es ahí donde empiezan los problemas.
Dos reglas que se confunden
Aquí el problema no es que la ley sea confusa.
El problema es que se aplica mal.
La Ley Federal del Derecho de Autor (LFDA) establece una regla general para obras creadas en relación laboral.
El artículo 84 parte de una lógica bastante clara:
los derechos patrimoniales se dividen entre empleador y trabajador
y, si no hay contrato por escrito, esos derechos pueden quedar totalmente en el trabajador
Esta es la regla que muchos trasladan automáticamente al software.
Pero el software no funciona así.
La regla especial del software (artículo 103 LFDA)
El software tiene un tratamiento distinto.
Tanto en la legislación mexicana como en estándares internacionales (OMPI, ADPIC), se reconoce como una categoría particular dentro de los derechos de autor.
En México, el artículo 103 de la LFDA lo deja claro:
los derechos patrimoniales sobre programas de computación corresponden en su totalidad al empleador
Pero esto no ocurre por el simple hecho de pagar nómina.
Para que esa regla opere, se requiere que el desarrollo:
forme parte de las funciones del trabajador
o se realice siguiendo instrucciones del empleador
Es decir, la titularidad depende de cómo está estructurada la relación, no solo de que exista.
La ventaja clave: cesión sin límite de tiempo
Aquí hay un punto que rara vez se explica bien.
En general, la cesión de derechos de autor tiene límites.
El artículo 33 de la LFDA establece plazos que normalmente no exceden de 5 años (o 15 en ciertos casos).
Pero tratándose de software, el propio artículo 103 rompe esa lógica:
👉 la cesión no está sujeta a limitación temporal
En términos prácticos, esto significa que, si el esquema está bien diseñado desde el inicio:
la empresa no solo tiene el 100% de los derechos
sino que los mantiene sin restricción de tiempo
Para efectos de inversión o venta, esto cambia completamente la conversación.
El riesgo fuera de la relación laboral (artículo 83 LFDA)
Cuando el software no lo desarrolla un empleado —sino un freelance, una agencia o un proveedor— el análisis cambia.
Aquí entra el artículo 83 de la LFDA, que regula las obras por encargo.
En principio, quien paga puede explotar la obra.
Pero hay una condición que suele pasarse por alto:
👉 si el contrato no es claro, la interpretación favorece al autor
Esto en la práctica significa algo muy concreto:
si el contrato está mal hecho, el developer puede tener razón.
El software no es solo código
Otro error frecuente es pensar que el derecho de autor protege todo el sistema.
No es así.
El derecho de autor protege la expresión (el código), pero no la idea Tanto en México como en los tratados internacionales (como el Acuerdo sobre los ADPIC y el Tratado de la OMPI sobre Derecho de Autor), los programas de computación se protegen bajo la figura de derechos de autor como si fueran "obras literarias". Sin embargo, la ley es tajante al establecer que la protección del derecho de autor abarcará únicamente las expresiones, pero no las ideas, procedimientos, métodos de operación o conceptos matemáticos en sí.
Es decir, el derecho de autor protege el código como expresión, pero no:
la lógica del sistema
la arquitectura
los algoritmos
ni el conocimiento detrás
Por eso, estos elementos deben protegerse por otra vía:
como secretos industriales, conforme a la Ley Federal de Protección a la Propiedad Industrial.
Si no se hace, la empresa puede ser dueña del código… pero no de lo que realmente le da valor.
Implicaciones prácticas
Este tema se vuelve relevante cuando hay que probar titularidad, no asumirla.
Por ejemplo:
en un due diligence
en una ronda de inversión
al licenciar el software
o cuando hay un conflicto con un developer
En todos estos escenarios de alta presión, a los inversionistas o a los jueces no les importa quién ideó el proyecto, quién lo opera o quién pagó las facturas. El único punto de quiebre es quién puede demostrar la cadena de titularidad.
Y ahí, la legislación mexicana es implacable.
El artículo 30 de la Ley Federal del Derecho de Autor (LFDA) exige que toda transmisión de derechos patrimoniales debe celebrarse invariablemente por escrito.
👉 Sin ese papel, el contrato no solo es inválido, sino que es nulo de pleno derecho. Legalmente, la transmisión jamás existió y la empresa está operando un código del que no es dueña.
Riesgo real
Cuando esto no está bien estructurado, el escenario típico es este:
la empresa opera el software, pero no tiene control jurídico real sobre él.
Eso puede traducirse en:
problemas para vender o licenciar
bloqueos en procesos de inversión
disputas con ex desarrolladores
No es un problema técnico.
Es un problema de estructura legal. Y en la industria tecnológica la regla es clara: tener el mejor código del mercado no sirve de nada si, ante un inversionista o un juez, resulta que le pertenece a alguien más.
¿Qué hacer?
Desde un enfoque práctico, este punto no se resuelve con “tener contrato”, sino con tener el contrato correcto.
Primero, es necesario identificar bajo qué esquema se desarrolló el software:
empleados, freelancers, proveedores o socios técnicos.
A partir de ahí, el contrato debe reflejar esa realidad y dejar resuelto, sin ambigüedad:
la cesión de derechos patrimoniales
la relación del desarrollo con funciones o instrucciones
el alcance específico del software y sus entregables
En paralelo, es recomendable proteger la lógica del sistema —arquitectura, procesos y conocimiento técnico— como secreto industrial.
En la práctica, esto es lo que determina si el software realmente pertenece a la empresa o solo se está utilizando sin control jurídico pleno.
Error común
Pensar que pagar por el desarrollo implica ser dueño del software.
No es así.
El pago cubre el servicio.
La titularidad se define jurídicamente.
Y cuando ese punto no se documenta correctamente, el riesgo no es teórico: aparece en auditorías, conflictos o procesos de inversión.
La titularidad del software no es un tema accesorio.
Es lo que determina si puedes explotar, licenciar o escalar tu producto sin restricciones.
En empresas tecnológicas, este punto suele revisarse cuando ya es tarde:
cuando hay una inversión en curso, un conflicto o una salida de equipo clave.
Revisarlo antes cambia completamente el escenario.
👉 Visita lexgrid.mx
Fuentes.
EBOOK-Intellectual-Property-in-the-Digital-Age.pdf
Guía Sobre los Tratados de Derecho de Autor y Derechos Conexos Administrados por la OMPI - WIPO.
Ley Federal del Derecho de Autor (LFDA). Artículo 30, 33, 83, 84, 103.
Ley Federal de Protección a la Propiedad Industrial (LFPPI): Artículo 164.
Propiedad intelectual y software - WIPO.
Tratado de la OMPI sobre Derecho de Autor (WCT).
