Registro de software en Argentina ante la DNDA: diferencias entre obra inédita y obra publicada

El registro de software ante la Dirección Nacional del Derecho de Autor (DNDA) en Argentina es una herramienta práctica para acreditar autoría y fecha de creación de un programa informático. Desde el punto de vista jurídico, el software se considera protegible como obra literaria en los términos de la normativa de derecho de autor, por lo que su inscripción tiene efectos probatorios relevantes aunque no es requisito para que exista la protección.

Marco jurídico aplicable en Argentina

La protección del software en Argentina se enmarca en la legislación de derechos de autor (la Ley de Propiedad Intelectual y la normativa aplicable), que reconoce la protección de la expresión de ideas y no de las ideas, métodos o principios en sí. La DNDA actúa como el registro público administrativo donde se pueden formalizar depósitos de obras (entre ellas programas informáticos). El registro administra constancias y expedientes que sirven como prueba ante terceros y en procesos judiciales, sin que la inscripción sea constitutiva del derecho.

¿Qué significa registrar software y qué valor jurídico tiene?

• Valor probatorio: la inscripción en la DNDA genera una constancia pública que facilita demostrar autoría y fecha de depósito. Esa constancia suele ser valorada por tribunales como prueba objetiva, pero no sustituye otras pruebas ni crea el derecho por sí misma.
• Protección automática: la obra (el código fuente, la documentación, la interfaz, etc.) goza de protección desde su creación, independientemente de la inscripción. Registrar refuerza la prueba frente a terceros.
• Alcance de la protección: lo protegido es la expresión concreta (código fuente, código objeto compilado, documentación técnica, manuales), no las ideas, algoritmos o métodos conceptuales subyacentes.
• Confidencialidad y reservas: existen mecanismos prácticos para preservar confidencialidad al depositar software (por ejemplo, depositar versiones acotadas, documentación técnica o soportes con restricción de acceso). Las modalidades concretas pueden variar; conviene verificar la política vigente de la DNDA al momento del trámite.

Diferencias jurídicas y prácticas entre obra inédita y obra publicada

La distinción entre obra inédita y obra publicada se relaciona con si la obra fue o no puesta a disposición del público. Para software, esa distinción incide en la forma de acreditar la fecha de divulgación, en la necesidad de preservar la confidencialidad del código y en la documentación que conviene adjuntar al registro.

Obra inédita

• Concepto práctico: software no divulgado públicamente —no subido a repositorios públicos, no distribuido a clientes sin acuerdo de confidencialidad ni comercializado en el mercado abierto.
• Finalidad del registro: fijar una fecha de creación y conservar evidencia sin divulgar el contenido íntegro. Útil cuando se requiere proteger secretos industriales o negociar cesiones/licencias posteriores.
• Documentación habitual a presentar: descripción técnica (memoria técnica), versión ejecutable o parcial del código, documentación de arquitectura, formulario de identificación de autor/es, información de titularidad y, en su caso, contratos o poderes. Muchas personas optan por depositar una copia reducida o documentación que permita identificar la obra sin revelar secretos.
• Confidencialidad práctica: se aconseja solicitar o coordinar mecanismos que eviten la publicación del código completo; conservar actas selladas, copias en soporte físico o electrónicas con acceso restringido y, si corresponde, adjuntar cláusulas de confidencialidad en contratos con desarrolladores.
• Riesgos frecuentes: divulgación inadvertida del código al adjuntar archivos completos, imprecisión en la identificación de autores, ausencia de contratos que aclaren titularidad entre empleados y contratistas.

Obra publicada

• Concepto práctico: software ya puesto a disposición del público o de una comunidad amplia (por ejemplo: repositorios públicos, comercialización, distribución a través de descargas sin restricción).
• Finalidad del registro: acreditar la fecha y condiciones de la divulgación, así como la versión registrada; sirve para demostrar prioridad y las condiciones de la publicación frente a reclamaciones de terceros.
• Documentación habitual a presentar: copia de la versión publicada (ejecutable o enlace y comprobante de publicación), información sobre el medio y la fecha de publicación, identificación de autor/es y titular, y documentación complementaria que acredite la puesta a disposición.
• Consecuencias prácticas: la inscripción de la obra publicada ayuda a documentar la primera divulgación y las versiones, lo que es relevante en disputas sobre antigüedad. Si la publicación implicó licencias (por ejemplo open source), conviene adjuntar la licencia aplicada y los términos de distribución.
• Riesgos frecuentes: no documentar correctamente la primera fecha de publicación, no indicar licencias sobre componentes de terceros, o no acreditar permisos en caso de incluir código licenciado.

Tabla comparativa: aspectos relevantes al registrar software

Requisitos y documentos habituales (orientativos)

Las exigencias formales y el procedimiento pueden variar; es recomendable confirmar las modalidades vigentes en la DNDA antes de iniciar el trámite. A modo orientativo, suelen solicitarse:

• Identificación del autor/es y del titular (nombre, tipo de documento, datos fiscales si corresponde).
• Título de la obra y breve descripción funcional y técnica (memoria técnica) que permita identificar la obra sin exponer detalles sensibles.
• Soporte de la obra: código fuente, ejecutable, manual de usuario, diagrama de arquitectura. Para obras inéditas, puede optarse por depositar versiones acotadas o documentación técnica en lugar del código íntegro.
• Documentación que acredite la transferencia de derechos o contratos (contratos de trabajo, contratos de desarrollo y cesión, poderes de representación).
• Comprobante de pago de aranceles si corresponde y formularios administrativos requeridos por la DNDA.

Problemas habituales y cómo abordarlos

Disputas sobre autoría y contribuciones

Frecuentemente se plantean controversias entre varios desarrolladores, entre empleador y empleado o entre contratista y contratante. Para reducir riesgos prácticos:

• Formalizar por escrito acuerdos de trabajo y cesión de derechos que especifiquen titularidad y alcance de las licencias.
• Registrar versiones intermedias con fechas claras (commits firmados, respaldos con sello de tiempo, registro en la DNDA) para documentar la evolución del desarrollo.
• En proyectos colaborativos, dejar constancia por escrito de la contribución de cada autor y de los acuerdos sobre explotación y licenciamiento.

Uso de terceros y componentes licenciados

El software suele incorporar bibliotecas y componentes con licencias distintas. Es esencial:

• Inventariar componentes de terceros y conservar sus licencias.
• Asegurar compatibilidad entre licencias (por ejemplo, entre componentes open source y software propietario).
• Adjuntar al registro la documentación que acredite permisos de uso o que establezca las restricciones aplicables.

Protección de secretos industriales

Cuando el código contiene información confidencial, la inscripción puede hacerse sin publicar íntegramente el contenido. Alternativas prácticas:

• Depositar una memoria técnica suficiente para identificar la obra sin revelar secretos.
• Depositar versiones reducidas o extractos representativos en vez del código completo.
• Complementar el registro con otras pruebas de antigüedad (repositorios privados con firmas, timestamps de servicios confiables, actas notariales).

Relación con otras figuras jurídicas

Es importante distinguir el registro de derechos de autor de otras formas de protección:

• Patentes: la patente protege invenciones técnicas. Muchos aspectos funcionales del software (algoritmos, métodos) pueden no ser patentables o requieren requisitos específicos; si existe una solución técnica novedosa, conviene consultar a un especialista en propiedad industrial.
• Secreto industrial: protege información confidencial mientras se mantenga en secreto y tenga valor comercial. Mantener acuerdos de confidencialidad y controles de acceso complementa el registro en la DNDA.
• Marcas y nombres comerciales: la protección de la marca del software se tramita en el organismo de marcas; son derechos distintos a los de autor.

Pasos prácticos recomendados antes de registrar

• Determinar si el software se considera inédito o publicado y elegir la estrategia de depósito acorde.
• Reunir documentación de identificación de autor/es y titular; formalizar contratos de cesión o de trabajo que aclaren titularidad.
• Preparar una memoria técnica clara y archivos de soporte adecuados (ejecutable, extractos de código, documentación). Considerar depositar una versión parcial si se quiere preservar confidencialidad.
• Mantener respaldo con firma de tiempo en repositorios privados o servicios que ofrezcan sello temporal y conservar logs de commits y respaldos.
• Verificar la modalidad de presentación vigente en la DNDA (presencial o electrónica), los formularios y aranceles aplicables, y conservar el comprobante de inscripción o expediente.

Preguntas frecuentes prácticas

¿Es obligatorio registrar el software para tener derechos?

No. La protección nace con la creación de la obra. El registro facilita la prueba de autoría y fecha ante terceros y en litigios.

¿Qué conviene registrar: el código fuente o el ejecutable?

Depende del objetivo. El código fuente constituye la expresión más completa; el ejecutable puede ser suficiente para demostrar existencia de la obra sin revelar código. Para proteger secretos, se suele depositar documentación técnica y, si es necesario, una versión parcial del código.

¿Cómo acreditar la fecha de una versión específica?

Registrar la versión concreta en la DNDA con documentación que la identifique (archivos con nombre, hash, comprobantes de publicación). Complementar con órdenes de trabajo, commits fechados y respaldos con sello temporal para fortalecer la cadena de prueba.

¿Qué hacer si varios desarrolladores reclaman autoría?

Revisar contratos, registros de commits y comunicaciones internas; buscar acuerdo entre las partes mediante cesión o reconocimiento de autoría; en ausencia de acuerdo, la evidencia documental y los registros públicos (como la inscripción en la DNDA) serán determinantes en un reclamo judicial.

Recomendaciones finales de actuación práctica

• Incluir cláusulas claras de propiedad intelectual en contratos laborales y de prestación de servicios.
• Registrar versiones clave del software (prototipos, versiones intermedias, lanzamientos) para construir un historial probatorio sólido.
• Evitar depositar código completo cuando existan secretos empresariales; emplear depósitos acotados y documentación descriptiva acompañada de mecanismos de timestamp o actas notariales si se requiere mayor seguridad probatoria.
• Consultar la normativa y requisitos vigentes de la DNDA antes del trámite, ya que modalidades y procedimientos administrativos pueden actualizarse.