Es la creencia más común entre desarrolladores y fundadores de startups. Y es falsa en la práctica judicial. El razonamiento parece lógico: tengo el código en un repositorio privado, tengo commits con fechas, tengo historial de cambios. ¿No se supone que eso prueba que yo lo escribí?
En juicio, no. Y la razón es más compleja de lo que parece. Los escenarios que se repiten:
- Un exempleado se va con tu código, cambia variables, renombra funciones y lanza un producto similar. Demostrar que el código del otro es una copia requiere peritaje técnico y una construcción probatoria específica que va más allá de "yo lo tenía antes".
- Un competidor replica tu lógica funcional sin copiar el código literal. El derecho de autor protege la expresión, no la idea. Demostrar la similitud sustancial requiere análisis técnico especializado.
- Un freelance que trabajó para ti reclama la autoría del software y te exige condiciones económicas o te impide explotarlo. Si el contrato no incluyó cesión de derechos patrimoniales, el autor del software puede seguir siendo él, no la empresa.
- Un socio o inversionista con acceso al código lo registra a su nombre. Sin registro previo de tu parte, la posición probatoria se debilita significativamente.
En todos estos casos, la pregunta no es si tienes razón. Es si puedes probar con el estándar técnico que exige un tribunal que tú eres el autor, que la obra fue creada en cierta fecha, y que la titularidad te corresponde. Sin registro estratégico y sin contratos bien redactados, esa prueba se convierte en una reconstrucción cuesta arriba que puede llevar meses y no siempre termina a tu favor. Conviene revisar cómo se registra una marca ante el SENADI antes de dar el siguiente paso.
Las dos dimensiones que casi nadie separa: autoría y titularidad
El derecho de autor tiene una estructura particular que combina dos elementos que suelen confundirse. Separarlos es el primer paso para entender qué tan sólida es tu posición.
Autoría: quién creó la obra. El régimen andino de derecho de autor parte de una presunción: el autor es la persona cuyo nombre figura en la obra, salvo prueba en contrario. Pero esa presunción tiene límites en juicio: si el demandado impugna la autoría, hay que probarla con elementos que el tribunal reconozca como idóneos.
Titularidad patrimonial: quién tiene el derecho exclusivo de explotar económicamente la obra. En el caso de software desarrollado por terceros, la titularidad patrimonial puede haber sido cedida por contrato, y si esa cesión no consta por escrito con los requisitos específicos, el autor sigue siendo el titular del código, aunque haya sido pagado por la empresa.
La confusión entre autoría y titularidad es la causa más frecuente de conflictos tecnológicos silenciosos: empresas que creen tener el software, pero legalmente no lo tienen. Y exempleados que reclaman autoría sobre código desarrollado bajo relación de dependencia porque el contrato no especificaba la cesión de derechos.
| Dimensión | Qué se prueba | Consecuencia práctica |
|---|---|---|
| Autoría | Quién creó la obra y en qué fecha | Determina quién puede figurar como autor en el registro y a quién corresponden los derechos morales |
| Titularidad patrimonial | Quién tiene el derecho exclusivo de explotación | Determina quién puede licenciar, ceder, transferir o demandar por infracción |
Por qué esta protección es más compleja de lo que parece
Proteger software no es solo registrar el código. Es un ejercicio técnico que combina derecho de autor andino, contratos de cesión, estrategias de registro y análisis de riesgo. La complejidad real está en las dimensiones que no se ven a simple vista:
El régimen andino de derecho de autor tiene reglas específicas sobre obras por encargo. La Decisión 351 regula la titularidad originaria, la presunción de autoría y las obras derivadas. Aplicar esas reglas al caso concreto de software desarrollado por terceros requiere interpretación técnica del régimen andino, no solo del sistema ecuatoriano. La diferencia entre una obra por encargo con cesión expresa y una obra sin cesión determina quién puede registrar el software a su nombre.
La modalidad de registro es una decisión estratégica. El registro de software en el SENADI tiene distintas modalidades: presentación del código fuente completo, presentación de una parte representativa, presentación de documentación técnica. Cada una tiene implicaciones sobre qué se protege, qué se expone y qué tan útil es la prueba en un juicio. La elección depende del tipo de software, del interés del titular y del riesgo competitivo del sector. No es una decisión automática.
La prueba de similitud sustancial requiere peritaje especializado. Demostrar que el software del demandado es copia del tuyo no se resuelve comparando nombres de archivos o líneas de código. Requiere peritaje técnico que analice estructura, lógica, algoritmos, tratamiento de errores, comentarios residuales, y patrones de comportamiento comunes entre ambos códigos. Ese peritaje se construye con metodología específica y se presenta bajo los estándares procesales del COGEP. Para ese escenario, la referencia es las acciones por infracción de marca.
La cuantificación del daño es otro ejercicio técnico. Si vas a reclamar indemnización por daños y perjuicios, el daño emergente y el lucro cesante deben cuantificarse con metodología contable y prueba pericial. La pérdida de mercado, la dilución de la ventaja competitiva, el costo de reconstruir el producto. Cada uno requiere análisis técnico específico. Hay un desarrollo completo en qué pasa si elegiste mal la clase de Niza.
La coordinación con la vía penal es estratégica. El Código Orgánico Integral Penal tipifica la apropiación de obras protegidas como delito. La vía penal y la vía civil pueden tramitarse en paralelo, y la estrategia procesal debe coordinar ambas para maximizar la presión sobre el demandado y las probabilidades de recuperación.
El registro de software es distinto del registro de marca. El software puede tener nombre de producto que requiere registro marcario en el SENADI, mientras el código se registra por derecho de autor. Son dos activos distintos, con dos estrategias de protección distintas, y ambos pueden requerirse según el caso. La coordinación entre marca, derecho de autor y secreto industrial es parte de la estrategia técnica integral.
¿Tu software está realmente protegido?
Agenda la auditoría y el abogado revisa si el software está registrado, si los contratos con desarrolladores incluyen cesión de derechos, y qué tan sólida es tu posición procesal ante un eventual conflicto. Llegas sabiendo exactamente dónde tienes brechas y cómo se cierran.
Agendar auditoría · WhatsAppPor qué esta evaluación no se resuelve revisando el repositorio
Determinar si tu posición sobre el software es sólida no se resuelve mirando los commits, los correos o los contratos firmados. Es un análisis técnico que cruza dimensiones que el titular no puede evaluar por sí solo, aunque tenga acceso a todos los documentos.
El repositorio prueba desarrollo, no titularidad. Un repositorio muestra quién hizo commits, cuándo y con qué cambios. No prueba la titularidad patrimonial del software, ni la cesión de derechos por parte de terceros desarrolladores, ni la estrategia de registro. Es una herramienta de desarrollo, no de protección legal.
Los contratos con desarrolladores deben examinarse uno por uno. En un software con múltiples contribuyentes —fundadores, freelancers, agencias, empleados que rotaron— la titularidad puede estar fragmentada. Cada contrato debe revisarse para verificar si la cesión de derechos patrimoniales está correctamente redactada y si cubre la totalidad de las obras creadas.
La modalidad de registro define qué se protege y qué se expone. El código fuente completo, una parte representativa, o la documentación técnica: cada modalidad tiene consecuencias distintas en términos de qué puedes defender y qué queda potencialmente expuesto. La elección requiere análisis del tipo de software, del mercado y del interés del titular.
El análisis de similitud sustancial es un ejercicio técnico. Comparar código fuente, estructura, algoritmos, tratamiento de errores y patrones de comportamiento requiere peritaje especializado. No se resuelve con comparaciones manuales ni con análisis superficial.
La coordinación con marca y secreto industrial también es técnica. El software puede requerir registro marcario del nombre de producto, protección por derecho de autor del código, y protección por secreto industrial del algoritmo propietario. Los tres sistemas son independientes y cada uno requiere estrategia específica.
Casos reales de software y derecho de autor
Empresas tecnológicas que protegieron su activo más valioso antes de que fuera tarde.
Startup SaaS en Quito con software de gestión empresarial. Un exempleado, tras salir de la empresa, lanzó un producto con funcionalidad similar. La startup sospechaba que había copiado el código fuente.
Probar la copia requería peritaje técnico. Pero antes había que probar autoría y fecha con el estándar que exige el tribunal. Sin registro previo, esa prueba dependía de reconstrucción probatoria con repositorios y correos.
"Habíamos registrado el software cuando lo lanzamos, coordinando marca, derecho de autor y secreto industrial. No pensamos que lo necesitaríamos. Tres años después, ese registro salvó la empresa."
Tengo un caso similar →Fintech en Guayaquil con un algoritmo propietario para evaluación de riesgo crediticio. El fundador no quería registrar el software porque temía exponer el algoritmo al público, pero necesitaba prueba sólida de autoría para defenderse de eventuales copias.
Sin registro, el software quedaba sin prueba oficial de autoría. Con registro mal diseñado, el algoritmo podía exponerse innecesariamente.
"Pensaba que registrar era exponer el algoritmo. La estrategia nos permitió tener las tres cosas: protección legal, marca registrada y secreto industrial intacto."
Tengo un caso similar →Empresa de software en Cuenca con un producto consolidado en el mercado. Había sido desarrollado por cinco freelancers a lo largo de cuatro años. Ninguno de los contratos incluía cesión expresa de derechos patrimoniales de autor.
La empresa quería registrar el software y expandirse al extranjero, pero legalmente no podía acreditar ser la titular de los derechos patrimoniales. Los freelancers podían reclamar autoría en cualquier momento y bloquear la expansión internacional.
"Habíamos desarrollado el software con cinco freelancers sin cesión de derechos. Regularizamos todo en seis semanas y ahora podemos crecer sin miedo."
Tengo un caso similar →Preguntas frecuentes
¿Mi software está protegido automáticamente por derecho de autor?
Sí, el derecho de autor nace con la creación de la obra, sin necesidad de registro. Así lo establece el régimen andino de derecho de autor aplicable en Ecuador. Pero eso no significa que puedas probar fácilmente en un juicio que tú eres el autor y en qué fecha lo creaste. El derecho tiene dos dimensiones: la existencia (que nace con la creación) y el ejercicio (que requiere poder probar autoría, fecha y titularidad ante un tribunal). Sin registro previo, esa prueba es mucho más débil, más costosa y más lenta de construir.
¿Qué pasa si un exempleado copia mi código y lanza un producto similar?
Puedes demandar por infracción de derechos de autor, pero el juicio exige construir un caso técnico que va más allá de afirmar "yo lo tenía antes". La prueba de autoría, la fecha cierta de creación, la similitud sustancial del código y la conducta del exempleado se articulan en un estándar probatorio específico que no se resuelve con repositorios privados ni con correos. Y hay un factor agravante: si el contrato con el desarrollador no incluyó cesión expresa de derechos patrimoniales, el autor del software podría seguir siendo él, no la empresa.
¿Qué se registra exactamente en el SENADI cuando registro un software?
Se registra la obra de software como creación intelectual, conforme al régimen andino de derecho de autor aplicable en Ecuador. Existen modalidades de registro que permiten proteger el software sin exponer la totalidad del código fuente, y otras que requieren presentar una parte representativa o documentación técnica. La elección de la modalidad correcta depende del tipo de software, del interés del titular y de la estrategia de protección que se quiera construir. No es una decisión automática.
¿Cuánto tiempo dura la protección del derecho de autor de un software en Ecuador?
La protección dura toda la vida del autor más 70 años después de su fallecimiento, conforme al régimen andino de derecho de autor aplicable en Ecuador. Es un plazo considerablemente mayor que el de una marca (10 años renovables) o una patente (20 años). Pero la duración no es el problema: el problema es poder hacer valer ese derecho en juicio cuando el activo está en juego.
¿Qué pasa si el software lo desarrolló un freelance para mi empresa?
Depende de cómo se estructuró el contrato. En ausencia de una cláusula de cesión de derechos patrimoniales de autor a favor de la empresa, el autor del software sigue siendo el desarrollador. Esto es uno de los errores más comunes y más costosos del sector tecnológico. La empresa puede tener licencia de uso, pero no puede registrar el software a su nombre, ni defender la autoría como propia, ni oponerse a que el desarrollador lo licencie a terceros. La fórmula legal exacta importa: "el software es propiedad del cliente" no es lo mismo que "el cliente es el titular de los derechos patrimoniales de autor". Este punto se aborda por separado en la guía completa de oposición de marca ante el SENADI.
¿Cuánto cuesta registrar un software en el SENADI?
Las tasas oficiales del SENADI dependen del tipo de obra y del titular. Es considerablemente más económico que otras formas de protección de propiedad intelectual, y el beneficio en términos probatorios en un juicio es enorme. Pero el costo real no se mide solo en tasas: se mide en la diferencia entre un software con protección registral sólida y un software que depende de repositorios privados y correos para probar su autoría. El detalle de esto está en la guía de propiedad intelectual y marcas en Ecuador.
¿Sirve registrar el software si no pienso demandar a nadie?
Sí. El registro cumple dos funciones. Primero, sirve como prueba si alguna vez necesitas defender tu autoría en juicio. Segundo, tiene un efecto disuasivo: los terceros con acceso a la información pública del SENADI saben que la obra está registrada y que copiarla tiene consecuencias legales. Es prevención, no solo litigio. Y hay un tercer efecto que suele pasarse por alto: el registro facilita la cesión, licenciamiento o transferencia del software cuando el negocio escala o se vende.
¿Qué pasa si no tengo registro ni contrato de cesión de derechos?
La posición se debilita considerablemente. Sin registro, la prueba de autoría y fecha depende de reconstrucción probatoria: repositorios, correos, testigos, peritajes. Sin cesión de derechos, el autor del software puede seguir siendo el desarrollador, no la empresa que pagó por él. Cada uno de esos dos elementos tiene consecuencias distintas y ambos requieren evaluación técnica previa antes de iniciar cualquier acción. La evaluación determina si el caso es viable con lo que hay, o si conviene construir primero la prueba antes de demandar.
.png)