Si estás buscando cómo registrar un software, el punto clave es este: el programa puede inscribirse en el Registro de Propiedad Intelectual del Departamento de Derechos Intelectuales, pero la protección útil no depende solo de subir código y pagar un arancel. También importa quién figura como titular, qué documentación acompaña el depósito, qué contratos ordenan la cadena de derechos y qué parte del valor del producto seguirá protegida mediante NDA y secreto industrial.
/ Qué protege realmente la propiedad intelectual de un software
¿Qué se considera software para efectos legales?
En Chile, la Ley 17.336 sobre Propiedad Intelectual protege expresamente los programas computacionales. La regla legal no se limita al archivo principal del proyecto: alcanza al programa fuente o programa objeto y también a la documentación preparatoria, su descripción técnica y los manuales de uso.
Esto importa porque, en la práctica, un producto digital no vive solo en el repositorio. Su valor también puede estar en la arquitectura documentada, en los manuales de funcionamiento, en los flujos internos y en la forma en que el software se entrega o licencia. Por eso, cuando se habla de registrar un software, conviene pensar en un conjunto ordenado de materiales y no solo en “subir el código”.
También conviene despejar una confusión habitual: esta vía corresponde a derechos de autor, no al registro de marca ni a una patente. Si tu preocupación principal es el nombre comercial del producto, el problema es otro. Si tu foco es el programa y su documentación, el marco de análisis parte aquí.
¿Autor y titular son lo mismo?
No siempre. En software es muy común que la persona natural que creó el código no coincida con quien explota comercialmente el producto. Puede haber un fundador que desarrolla, una empresa que encarga el proyecto, un equipo dependiente o varios colaboradores externos. Por eso conviene distinguir entre autoría y titularidad desde el principio.
La propia información oficial del DDI exige una declaración adicional cuando autor y titular no son coincidentes, individualizando a las personas naturales que participaron en la creación de la obra. Esa exigencia no es un mero formalismo: obliga a ordenar quién desarrolló qué y bajo qué relación jurídica se hará valer la titularidad al momento de inscribir.
Además, la inscripción sirve principalmente como una presunción de titularidad, no como una prueba absoluta de autoría. Dicho simple: el registro ayuda mucho, pero no reemplaza los antecedentes contractuales ni corrige por sí solo una cadena de derechos mal documentada.
¿Para qué sirve inscribirlo si ya está protegido?
La utilidad práctica del registro está en fortalecer la posición del titular frente a terceros y ordenar la explotación del activo. Cuando el software va a licenciarse, levantará inversión, será parte de una due diligence o se integrará a una empresa con varios contribuyentes, contar con una inscripción clara suele evitar discusiones posteriores sobre quién puede usarlo, transferirlo o autorizar su uso.
El material fuente y las referencias oficiales coinciden en un punto importante: el titular del derecho patrimonial puede usar el software, transferir total o parcialmente sus derechos y autorizar a terceros para utilizarlo. Eso vuelve especialmente relevante dejar bien documentado quién aparece como titular desde el inicio.
Por lo mismo, registrar no es una obsesión burocrática. Para equipos tech y founders, suele ser una forma de convertir un desarrollo que hoy está “funcionando” en un activo mejor preparado para crecer, licenciarse o negociarse.
Dato clave
Inscribir un software no reemplaza la estrategia completa de protección. El registro ayuda a acreditar titularidad, pero la seguridad real también depende de contratos, licencias de terceros, controles internos y confidencialidad bien redactada.
/ Cómo registrar un software paso a paso
¿Dónde se hace hoy el trámite ante el DDI?
Hoy el canal oficial parte en el servicio “Inscribe obras” del Departamento de Derechos Intelectuales, usando la plataforma CRIN. La lógica del sistema es completar los datos del titular, depositar la obra y luego pasar al pago. También existe atención presencial para consultas y entrega de documentación, pero el flujo base ya está pensado para operar digitalmente.
Para software, el propio DDI tiene una pregunta frecuente específica que remite a ese mismo procedimiento general y aclara qué antecedentes deben acompañarse. Esa referencia es importante porque el material viejo sobre el trámite puede quedarse corto o desactualizado en detalles operativos como tamaños de carga, medios admitidos o formatos auxiliares.
En términos prácticos, el consejo es simple: antes de entrar a la plataforma, ordena desde fuera la versión que vas a depositar, la documentación de soporte y la información de titularidad. El error frecuente no es solo llenar mal un campo, sino llegar al sistema sin haber definido qué se va a registrar exactamente.
¿Qué documentos hay que acompañar?
Según el DDI, para inscribir un programa de computación o software se debe acompañar al menos:
- copia del código fuente;
- manual de funcionamiento del programa;
- copia simple de las licencias de uso, si el software se desarrolló con componentes de terceros; y
- una declaración en la que el titular individualice a las personas naturales que participaron en la creación, cuando autor y titular no coinciden.
Este punto es especialmente sensible en startups y equipos híbridos. Si hubo freelancers, empleados, socios técnicos o proveedores externos, la documentación que respalda la titularidad debería estar cerrada antes del ingreso, no después. De lo contrario, el trámite se transforma en la primera vez que el proyecto descubre que la cadena de derechos estaba incompleta.
También conviene leer la exigencia sobre licencias de terceros con una mirada práctica. Si tu software depende de librerías, frameworks o componentes externos, no basta con “saber que existen”: debes poder identificar bajo qué licencias fueron incorporados y cómo eso afecta la explotación del producto.
¿Cómo funcionan la carga digital, el pago y el certificado?
La operación actual del DDI permite cargar la obra en formato digital con un tamaño máximo de 500 MB. Si el archivo supera ese peso, el sistema indica que debe enviarse en soporte físico permitido, como DVD o disco duro; además, el servicio advierte expresamente que no se aceptan pendrives. La “documentación adicional” puede adjuntarse aparte con un máximo total de 20 MB.
En cuanto al costo, la regla legal sigue siendo la del artículo 76 de la Ley 17.336: los programas computacionales pagan el 35% de una UTM. Por eso, en vez de memorizar un valor en pesos que cambia mes a mes, lo más útil es revisar la UTM vigente al momento de presentar la solicitud.
El pago puede hacerse en línea, por transferencia, depósito o presencialmente según el canal escogido. Si además se solicita certificado y la obra no presenta observaciones, el sitio oficial informa que ese certificado puede emitirse dentro de cinco días hábiles luego de asignado el número de inscripción.
Lo relevante aquí es que el trámite no parte con la pasarela de pago: parte mucho antes, cuando decides qué versión vas a depositar, cómo documentarás el software y qué respaldos mostrarán que el titular que aparece en la solicitud es jurídicamente correcto.
/ Titularidad, contratos y explotación del software
¿Qué pasa si lo desarrolló un trabajador dependiente?
La regla oficial que recuerda hoy el DDI es clara: tratándose de programas computacionales, serán titulares del derecho de autor las personas naturales o jurídicas cuyos dependientes, en el desempeño de sus funciones laborales, los hubiesen producido, salvo estipulación escrita en contrario.
Esto tiene una consecuencia práctica inmediata: si una empresa desarrolla su software mediante trabajadores dependientes dentro de sus funciones, la discusión no debería quedar librada a interpretaciones informales del tipo “el código lo hizo tal desarrollador”. Lo que conviene revisar es si el desarrollo efectivamente formaba parte de sus labores y si existe o no alguna cláusula escrita que altere esa regla.
La misma referencia del DDI agrega otro dato que suele olvidarse: en ese supuesto, cuando el empleador es una persona jurídica, la protección corre por 70 años desde la primera publicación. No es un detalle menor para proyectos que luego pasan a holdings, sociedades operativas o procesos de inversión más formales.
¿Qué pasa si fue hecho por encargo?
La ley también trata expresamente el software producido por encargo. La regla es que, respecto de los programas computacionales desarrollados para un tercero, se reputan cedidos a éste los derechos del autor, salvo estipulación escrita en contrario.
Eso cambia bastante la conversación en proyectos de outsourcing, desarrollo white-label, MVP encargados a agencias o trabajos técnicos levantados por freelancers. Si no se entiende bien cómo opera esa titularidad y qué se pactó por escrito, después aparecen conflictos justamente cuando el producto empieza a tener valor comercial.
Por eso conviene no confiarse en una intuición de negocio del tipo “como yo pagué, entonces todo es mío” o, en sentido inverso, “como yo programé, entonces el cliente solo me arrendó horas”. En software por encargo, los detalles del vínculo y de la redacción contractual son demasiado importantes como para dejarlos al supuesto.
¿Qué contratos conviene ordenar antes de vender o licenciar?
Si el software se va a comercializar, licenciar o integrar a una empresa, hay un mínimo documental que conviene dejar limpio cuanto antes. En la práctica, suelen ser especialmente relevantes:
- contratos con desarrolladores externos o proveedores técnicos, dejando clara la titularidad y el alcance de la entrega;
- cláusulas laborales coherentes con las funciones de quienes desarrollan el software como dependientes;
- licencias y autorizaciones de terceros cuando el producto incorpora software ajeno;
- contratos de cesión o licencia cuando el titular quiere transferir o autorizar el uso del software a otra empresa o cliente.
El valor de este orden no es solo probatorio. También permite explotar el activo con menos fricción: licenciarlo, cederlo, pactar uso limitado, abrir nuevas líneas comerciales o responder mejor ante una revisión de inversión o auditoría.
Cuando esa base contractual no existe, el registro deja de ser una solución integral y pasa a ser solo una parte bien hecha de un problema más grande. Y ese es justamente el escenario que conviene evitar.
Dato clave
Si autor y titular no coinciden, no conviene descubrirlo recién al momento de la due diligence o de la venta del producto. En software, la cadena documental pesa tanto como el código mismo.
/ NDA y secreto industrial en productos digitales
¿Cuándo conviene firmar un NDA para software?
El glosario de INAPI define el acuerdo de confidencialidad como el contrato que regula las condiciones de la relación jurídica entre quien divulga información confidencial y quien la recibe. En el material fuente, además, se explica que en el mundo de negocios suele hablarse de NDA para referirse a ese acuerdo en contextos de negociación, inversión o colaboración comercial.
Para software, esa herramienta suele ser especialmente útil antes de:
- mostrar el producto o su arquitectura a potenciales inversionistas o compradores;
- abrir conversaciones de licencia o integración con terceros;
- compartir documentación sensible con proveedores o desarrolladores externos;
- dar acceso a información interna de roadmap, pricing o funcionamiento que todavía no debería circular libremente.
El punto práctico no es firmar NDA por reflejo, sino usarlo cuando realmente vas a compartir información que todavía quieres mantener fuera del mercado. Mientras más clara quede la información protegida, el objeto del acuerdo y las consecuencias del incumplimiento, más útil será en serio.
¿Qué puede protegerse como secreto industrial en un producto digital?
El secreto industrial funciona sobre una lógica distinta del registro: no depende de inscribirse, sino de mantener reservada información que entrega una ventaja competitiva y que ha sido efectivamente protegida. En la práctica, la propia literatura técnica de INAPI considera dentro de este campo elementos como algoritmos, procesos aplicados en programas informáticos, listas de clientes, información financiera, documentación de I+D y planes comerciales.
Traducido al mundo SaaS o de producto digital, eso puede abarcar aspectos como:
- lógica de negocio no visible para el usuario final;
- criterios internos de entrenamiento, despliegue o seguridad;
- roadmaps de producto, pricing o métricas comerciales sensibles;
- bases de datos estratégicas, flujos internos y documentación operativa.
La ventaja del secreto industrial es que puede durar mientras la información siga siendo secreta y valiosa. Su desventaja práctica es evidente: si la empresa no toma medidas reales para mantener la reserva, esa protección se debilita muchísimo. No basta con llamar algo “confidencial” en una conversación informal.
¿Cómo combinar registro, confidencialidad y controles internos?
La estrategia sensata no es escoger solo una herramienta, sino combinarlas. El registro ante el DDI sirve para ordenar la titularidad del software y reforzar su explotación como obra protegida. El NDA sirve cuando vas a divulgar información sensible a un tercero determinado. Y el secreto industrial exige medidas jurídicas y fácticas permanentes: restricciones de acceso, rotulado de confidencialidad, protocolos internos, cifrado y segmentación de personas con acceso.
En otras palabras, el registro responde a una parte del problema, pero no convierte automáticamente el negocio en una fortaleza de resguardo. Si el equipo comparte código, documentación o know-how sin criterio, la empresa puede quedar muy expuesta aunque tenga una inscripción correcta en el Registro de Propiedad Intelectual.
Para founders y equipos técnicos, la pregunta útil no suele ser “¿registro o confidencialidad?”, sino más bien: qué parte del valor quiero depositar como obra inscrita y qué parte debe seguir protegida mediante reserva, contratos y controles internos.
/ Errores frecuentes y estrategia práctica
¿Qué errores cometen founders y equipos tech?
El error más repetido es desarrollar durante meses y dejar para el final la pregunta por la titularidad. Cuando el producto ya está funcionando, aparecen los apuros: hubo empleados, freelancers, socios técnicos, herramientas de terceros y versiones distintas del código, pero nadie ordenó bien quién participa como autor, quién será titular y qué documentos respaldan esa posición.
También se repite mucho la falsa seguridad de creer que el historial del repositorio o un chat de coordinación reemplazan un contrato. Sirven como antecedentes, pero no cumplen la misma función que una cláusula clara de encargo, una licencia bien delimitada o una declaración que permita al DDI entender por qué el titular que se presenta es jurídicamente correcto.
A eso se suma otro error clásico: mostrar demasiado antes de tiempo. Demos, conversaciones comerciales, pilotos o integraciones tempranas pueden ser parte normal del crecimiento, pero si se hacen sin criterio sobre confidencialidad, después cuesta mucho más sostener que cierta información debía mantenerse reservada.
¿Qué no resuelve por sí solo el registro?
Registrar un software no resuelve por sí solo todos los frentes de protección del producto digital. No reemplaza el registro de marca si el problema es el nombre del software. No corrige una cadena de cesiones mal documentada. No ordena automáticamente el uso de componentes de terceros. Y tampoco vuelve confidencial información que la empresa ya divulgó sin control.
Por eso, cuando el Excel de esta fusión advierte que no conviene canibalizar una página transaccional genérica de derechos de autor, la lectura editorial correcta es esta: este artículo debe funcionar como guía práctica para software y producto digital, no como una explicación abstracta de todo el sistema autoral chileno.
La mejor decisión suele ser más concreta: registrar cuando el software y su titularidad están suficientemente ordenados, documentar bien las relaciones jurídicas y mantener en reserva aquello que da ventaja competitiva y no debería exponerse innecesariamente.
¿Cuándo conviene pedir ayuda legal?
Conviene pedir apoyo cuando el caso deja de ser lineal. Por ejemplo, si el software fue creado por varias personas bajo vínculos distintos, si la titularidad quedará en una sociedad y no en los autores, si hubo encargos a terceros, si se está negociando licencia o inversión, o si el producto combina código propio con componentes cuya licencia puede afectar su explotación futura.
También conviene actuar con asesoría cuando el proyecto necesita decidir qué información se inscribe, qué se mantiene bajo reserva y cómo se estructura el set de contratos que acompañará la comercialización. Ahí ya no basta con “hacer el trámite”, porque la decisión afecta valor, riesgo y capacidad de negociación.
Mientras antes se ordene ese mapa, mejor. En propiedad intelectual de software, corregir tarde suele costar mucho más que planificar bien desde el comienzo.
Cuando el desafío no es solo inscribir el código, sino también ordenar licencias, contratos, reserva y explotación dentro del negocio, conviene revisar además nuestro enfoque de gestión de intangibles.
/ Conclusión
Registrar un software es un paso útil, pero no aislado. El trámite ante el DDI ayuda a ordenar la titularidad y a respaldar el activo, pero su efecto real mejora mucho cuando se combina con una cadena contractual limpia, revisión de licencias de terceros y medidas serias de confidencialidad.
Para founders y equipos tech, la pregunta correcta no es solo cómo registrar un software, sino cómo protegerlo de forma integral: registro para acreditar titularidad, contratos para ordenar derechos y explotación, y NDA o secreto industrial para resguardar la información que no conviene exponer.
Si primero necesitas una base general sobre protección autoral de obras y software, revisa también nuestra página sobre derechos de autor.
Si necesitas ayuda para revisar la titularidad de tu software, preparar la documentación del registro o diseñar una estrategia de protección compatible con tu modelo de negocio, contáctanos.
¿Te pareció útil este artículo? Compártelo:
