jueves, 8 de octubre de 2026

Post 1 El software también es una obra protegida por propiedad intelectual – 1 de 10

 


Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada


Cuando se habla de propiedad intelectual y software, todavía es frecuente pensar que el derecho protege únicamente una parte muy particular del producto tecnológico: el código fuente. Sin embargo, la mirada debe ser mucho más amplia.

La ley n.° 9.739, en la redacción dada por la ley n.° 17.616, incluye expresamente entre las obras protegidas a los programas de ordenador, tanto en código fuente como en código objeto. También comprende determinadas compilaciones de datos y la expresión de ideas, informaciones y algoritmos cuando se encuentran formuladas en secuencias originales ordenadas para ser utilizadas por dispositivos de procesamiento de información.

Esto es importante porque el software no debería analizarse desde el punto de vista jurídico como un simple conjunto de instrucciones técnicas. Detrás de esas instrucciones existe una actividad creativa susceptible de generar derechos de autor.

El derecho de autor uruguayo reconoce al titular facultades exclusivas de reproducción, distribución, publicación, traducción, adaptación, transformación, comunicación y puesta a disposición de la obra, entre otras. En un entorno digital, la reproducción comprende también determinadas formas de almacenamiento electrónico.

Por eso, copiar un programa, incorporar código ajeno a otro desarrollo, distribuir una aplicación o ponerla a disposición del público no son simplemente decisiones técnicas o comerciales. Pueden constituir actos de explotación de una obra protegida y, por tanto, requieren analizar quién es titular de los derechos y qué autorizaciones existen.

Hay que tener en cuenta, además, que la propiedad intelectual no protege las ideas en abstracto del mismo modo que protege su expresión. Una idea de negocio, una funcionalidad imaginada o una solución conceptual no se convierten automáticamente en un monopolio jurídico porque alguien las haya pensado primero. El problema jurídico aparece cuando esa idea se exterioriza en una creación protegible o cuando intervienen otros institutos, como el secreto empresarial, las patentes en los casos admitidos por la legislación o la competencia desleal.

Esto explica por qué dos desarrolladores pueden llegar independientemente a soluciones funcionalmente semejantes sin que necesariamente exista infracción de derechos de autor de uno al otro. La comparación jurídica deberá concentrarse en aquello que efectivamente está protegido y en la forma en que fue utilizado.

También conviene distinguir el software de otros activos que suelen acompañarlo. Una aplicación puede tener simultáneamente: código fuente, código objeto, documentación técnica, manuales, diseño gráfico, interfaz de usuario, bases de datos, contenidos, nombre comercial, marca, dominio, secretos empresariales, datos personales, componentes de terceros, bibliotecas de código abierto , así como algoritmos y conocimientos técnicos.

Cada uno puede estar sometido a un régimen jurídico diferente.

Por eso, para un desarrollador, proteger el software no significa simplemente registrar el código. Significa identificar correctamente todos los activos intelectuales que integran el proyecto y determinar quién es titular de cada uno, bajo qué título y con qué alcance.

La propiedad intelectual aparece así desde el primer momento del proyecto: antes de programar, durante el desarrollo, al contratar colaboradores, al incorporar componentes de terceros y, finalmente, al comercializar el producto.


Regla práctica

Antes de lanzar una aplicación, conviene poder responder documentalmente cuatro preguntas:

¿Qué creamos? ¿Quién lo creó? ¿Quién es su titular? ¿Con qué autorizaciones se incorporó cada componente? Si esas cuatro preguntas no tienen respuestas claras, existe un problema jurídico aunque el programa funcione perfectamente. Lo mejor es atenderlo cuando antes.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/



Post 2 ¿De quién es el código? Autor, desarrollador, empresa y cliente – 2 de 10

 


Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada



Uno de los problemas jurídicos más frecuentes en proyectos de software es la respuesta a la pregunta - aparentemente sencilla - “¿de quién es el programa?”, que recibe respuestas diferentes según la perspectiva de quién la formule.

El desarrollador puede pensar: “lo programé yo”.

La empresa puede responder: “lo pagamos nosotros”.

El cliente puede sostener: “fue desarrollado específicamente para nuestra empresa”.

Las tres afirmaciones pueden tener relevancia, pero no son desde el punto de vista jurídico equivalentes.Ni determinan por sí una relación de titularidad con la creación intelectual.

Hay que comenzar por definir qué sucede desde el punto de vista del derecho de autor. La ley n.° 9.739 reconoce como titulares al autor, sus sucesores, colaboradores y adquirentes a cualquier título, entre otros sujetos previstos por la norma.

En materia de programas de ordenador existe, además, una regla especialmente importante para quienes desarrollan software profesionalmente. La legislación uruguaya establece que, cuando las creaciones referidas a programas de ordenador y bases de datos son realizadas en el marco de una relación de trabajo, pública o privada, cuyo objeto total o parcial tenga una naturaleza similar, se presume que el autor ha autorizado al empleador o comitente, salvo pacto en contrario, en forma ilimitada y exclusiva respecto de los derechos patrimoniales y del ejercicio de los derechos morales. Esta previsión fue incorporada al derecho uruguayo por la ley n.° 19.858. La regla que establece aclara una de las situaciones que históricamente generaron más incertidumbre en materia de software, como lo es qué sucede cuando un programador desarrolla una creación dentro de una relación profesional.

Si bien la presunción legal sigue una lógica de razonabilidad, para el caso en que no haya manifestación alguna entre las partes, siempre es aconsejable que haya un contrato escrito que documente la relación. Cuanto más valioso sea el software, más importante resulta documentar la titularidad.

Un desarrollador contratado para crear una aplicación desde cero debería tener claramente establecido qué ocurre con el código fuente, el código objeto, documentación, bibliotecas propias, componentes preexistentes, herramientas de desarrollo, mejoras, actualizaciones, módulos reutilizables, desarrollos futuros así como derechos sobre versiones sucesivas, entre otras creaciones.

También debe distinguirse entre un empleado y un desarrollador independiente. Si una empresa contrata a un desarrollador externo para construir un sistema, no es prudente limitarse a escribir en una factura “desarrollo de software”. El contrato debería determinar expresamente qué derechos recibe el cliente, cuáles conserva el desarrollador y qué ocurre con los elementos preexistentes.

Especialmente importante es diferenciar el software desarrollado específicamente para el cliente de las herramientas generales que el desarrollador ya utilizaba.

Por ejemplo, un programador puede haber creado antes una biblioteca propia, un framework, una arquitectura reusable o determinados módulos genéricos. Si los incorpora al proyecto, la empresa cliente no debería recibir inadvertidamente derechos exclusivos sobre todo aquello que existía antes.

La solución contractual puede consistir en identificar:

a background IP: conocimientos, código, herramientas y componentes preexistentes;

b foreground IP: desarrollos realizados específicamente para el proyecto.

Esta distinción, muy utilizada en contratos tecnológicos, permite evitar conflictos posteriores.

También es conveniente establecer quién podrá reutilizar determinadas soluciones después de terminado el proyecto. Para un desarrollador independiente, esta cuestión puede ser decisiva: una cesión excesivamente amplia podría impedirle volver a utilizar conocimientos y herramientas generales que constituyen parte de su actividad profesional.

No solamente hay que saber quién pagó el software, sino cuáles con las creaciones realizadas, por quién, en qué relación contractual y qué se acordó respecto de ellos.


Regla práctica

Nunca entregar un software comercialmente relevante sin haber documentado previamente la titularidad de sus derechos. El contrato no es un mero complemento administrativo del desarrollo, desde el punto de vista jurídico la definición clara a nivel de derechos que documenta un contrato integra la estructura del negocio que se quiere desarrollar.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/



Post 3 Registrar el software en Uruguay, su verdadero alcance – 3 de 10

 


Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada



En Uruguay, la protección jurídica del software no depende para su existencia como obra protegida por derecho de autor de un registro constitutivo. No obstante, la inscripción registral, con documentación específica y un depósito – que como excepción cuando se trata de código fuente es reservado – le da una base de mayor certeza a los activos empresariales.

Por ello, se utilizó con frecuencia la herramienta registral en este caso, al punto que se instrumentó una dinámica específica, incluso traslando la competencia registral para dichas creaciones a la oficina típica de la propiedad industrial. La ley n.° 20.212 creó el Registro de Software, llevado por la Dirección Nacional de la Propiedad Industrial, y el Decreto N.º 39/025 reglamentó su procedimiento, y al consagrar esta nueva reglamentación se actualizaron algunos conceptos, dotando de mayor precisión a este régimen.

La normativa contempla, entre otros objetos, programas de ordenador en código fuente o código objeto, determinadas compilaciones de datos y expresiones originales de ideas, informaciones y algoritmos formuladas en secuencias ordenadas para ser utilizadas por dispositivos de procesamiento de información. También pueden inscribirse las transmisiones de derechos patrimoniales sobre esas obras.

La primera cuestión que debe quedar clara es que registrar no es lo mismo que crear el derecho.

El Decreto N.º 39/025 establece expresamente que la falta de inscripción no impide la protección de la obra conforme al régimen de derecho de autor.

Registrar es importante, fundamentalmente, para tener fecha cierta, presunción de autoría y de integridad de la obra y sobre determinadas situaciones jurídicas vinculadas con ella. En un conflicto, no es indiferente poder presentar una constancia oficial relativa a una determinada creación, su identificación, su solicitante y otros elementos del registro. Como dijimos, no es determinante de la existencia del derecho, pero desde el punto de vista probatorio es le da solidez a las afirmaciones de existencia por su fecha y referencia integral.

Esto adquiere particular importancia en software porque los desarrollos evolucionan constantemente.

Una aplicación puede tener una primera versión, luego una actualización, posteriormente una modificación sustancial y finalmente una nueva arquitectura. Mantener ordenada la documentación de las versiones puede ser tan importante como conservar el propio código.

El Decreto 39/025 establece un procedimiento específico, contempla la publicación de la solicitud en el Boletín de la Propiedad Industrial y regula, entre otras cuestiones, oposiciones, reivindicación y transferencias.

Hay además una consecuencia contractual muy interesante, porque el decreto dispone que la enajenación o transferencia de una obra debe realizarse por escrito para ser válida y produce efectos frente a terceros desde su inscripción.

Esto convierte al registro en una pieza particularmente relevante cuando el software constituye un activo empresarial que se vende, aporta, licencia, transfiere o utiliza como parte de una operación societaria.

De todas maneras, registrar tampoco sustituye otras medidas.

Una empresa tecnológica debería conservar los contratos suscriptos con desarrolladores, repositorios y control de versiones, la correspondiente documentación técnica, registros de cambios, identificación de autores en sentido material, los contratos de cesión o licencia, licencias de componentes de terceros que ha utilizado para elaboración de un software, documentación sobre software libre si es el caso, evidencia de las versiones, así como documentación de utilización de herramientas de IA, entre demás extremos de hecho que informen sobre el proceso de desarrollo del sotware.


Regla práctica

Cuando un software constituye un activo empresarial relevante, conviene pensar el registro como parte de una estrategia de gestión de activos intelectuales, y no como un trámite aislado.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/



Post 4 Software libre y código de terceros – 4 de 10

 


Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada




Uno de los errores más frecuentes consiste en tratar el código disponible en Internet como si fuera desde el punto de vista jurídico libre. Que un código pueda descargarse no significa que pueda utilizarse sin condiciones. Siempre hay que saber cuál es el régimen de titularidad y de explotación del código que se utilizará para el desarrollo del software.

La cuestión es especialmente importante respecto del software libre y de código abierto.

Uruguay posee incluso una definición legal de software libre. La ley n.° 19.179 establece que es aquel licenciado de modo que permita usarlo para cualquier propósito, acceder al código fuente para estudiarlo y modificarlo, copiarlo y distribuirlo, y mejorar el programa y liberar esas mejoras, bajo las condiciones previstas por la propia licencia.

Esto demuestra que software libre no equivale a software sin derechos. Por el contrario, precisamente porque existen derechos de propiedad intelectual, el titular puede establecer mediante una licencia determinadas condiciones para el uso, modificación y distribución del programa.

Por eso, antes de incorporar una biblioteca, framework, módulo o fragmento de código de terceros, a un desarrollador debería identificar:

b quién es el titular;

c cuál es la licencia;

d qué usos permite;

e si exige atribución;

f si exige conservar determinados avisos;

g si existen obligaciones respecto de modificaciones;

h si existen obligaciones de distribución del código fuente;

i si existen restricciones de combinación con otros componentes;

j si el uso comercial está permitido;

k qué ocurre con las versiones modificadas.

La cuestión es importante desde el punto de vista jurídico y empresarial.

Una startup puede estar desarrollando un producto con intención de captar inversión o ser adquirida. Si en su software existen componentes cuyas licencias generan obligaciones incompatibles con el modelo de negocio proyectado, el problema puede aparecer durante una due diligence, cuando modificar la arquitectura resulta costoso.

Lo mismo sucede con el código copiado de repositorios públicos. Un desarrollador puede encontrar una solución perfectamente funcional, incorporarla rápidamente y olvidarse de su procedencia. Meses después, la empresa puede descubrir que el código estaba sujeto a una licencia incompatible con la forma en que distribuye su producto.

La gestión profesional de software exige entonces una suerte de trazabilidad jurídica del código. No solamente debe saberse qué hace cada componente. Debe saberse de dónde proviene y bajo qué condiciones puede utilizarse. Esto también alcanza a los llamados “snippets” encontrados en páginas de programación, foros, repositorios y documentación técnica.


Regla práctica

Cada proyecto profesional debería tener un inventario de componentes de terceros - incluido software libre y open source - con indicación de su licencia y de las obligaciones que genera.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/


Post 5 Algoritmos, know-how y secretos empresariales, qué no conviene publicar – 5 de 10

 


Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada



No todo lo valioso de un software debería hacerse público. De hecho, en determinados proyectos, publicar demasiado puede ser desde el punto de vista jurídico contraproducente.

El código fuente puede estar protegido por derecho de autor, pero una empresa puede poseer además conocimientos técnicos, métodos de implementación, parámetros, procesos, documentación interna, arquitectura, información comercial y otros conocimientos cuyo valor depende precisamente de que permanezcan reservados. Aquí aparece el secreto empresarial como complemento de la propiedad intelectual. Para un desarrollador, esto puede comprender desde una determinada arquitectura técnica hasta la forma concreta de entrenar un modelo, optimizar una base de datos, procesar información o resolver un problema de rendimiento.

También puede comprender información que no sería apropiado considerar patentable o que la empresa sencillamente prefiere mantener fuera de la divulgación pública.

La decisión entre publicar, registrar, patentar - cuando corresponda - o mantener bajo secreto una determinada solución tecnológica requiere análisis previo. Esto es importante porque la ley n.° 17.164, artículo 13, excluye expresamente de la materia patentable a los programas de computación considerados aisladamente. Eso no significa que toda innovación tecnológica vinculada con software sea jurídicamente irrelevante para el sistema de patentes. El software relacionado con creaciones patentables integra un conjunto que en el sistema de la ley n.° puede merecer el registro como patente de invención. Dependerá del caso. La cuestión debe analizarse según el objeto concreto de la invención y la forma en que se presenta.

Por otra parte, publicar información técnica puede afectar una eventual estrategia de protección mediante patente cuando existe una invención patentable vinculada al desarrollo. La divulgación también puede destruir o debilitar el carácter reservado que una empresa pretende atribuir posteriormente a determinada información.

Por eso, antes de presentar una aplicación, publicar un repositorio o realizar una demostración técnica ante terceros, conviene preguntarse:

a ¿qué estoy mostrando?

b ¿qué información necesito proteger?

c ¿qué información debe conocer el cliente?

d ¿qué información puede conocer un proveedor?

e ¿qué información debería quedar sometida a confidencialidad?

El contrato de confidencialidad - NDA - puede ser importante, pero no debería ser la única medida. La protección de información reservada requiere también medidas organizativas y técnicas razonables.

Un repositorio privado, permisos diferenciados, autenticación, control de accesos, políticas internas y documentación sobre quién puede acceder a determinadas partes del proyecto forman parte de la protección jurídica del activo.


Regla práctica

Antes de publicar código, documentación o arquitectura técnica, identificar qué parte del conocimiento es pública, qué parte está protegida por derecho de autor y qué parte tiene valor precisamente porque permanece confidencial. Luego, que se decida si darla o no a conocimiento público, pero a sabiendas del alcance de la decisión.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/



Post 6 Marcas, interfaces, diseños y contenidos, mucho más qué código – 6 de 10

 


Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada



Una aplicación puede funcionar perfectamente y, sin embargo, estar desde el punto de vista jurídico mal protegida, porque el software comercial no se agota en el programa.

Supongamos una aplicación denominada NOVA, con un logotipo determinado, una interfaz gráfica característica, ilustraciones, textos, sonidos, tutoriales, personajes y una página web. Allí pueden existir varios activos intelectuales diferentes.

El nombre o signo distintivo puede ser susceptible de protección marcaria. La ley n.° 17.011 define la marca como un signo con aptitud para distinguir productos o servicios de una persona física o jurídica de los de otra.

Elegir el nombre de una aplicación no debería ser una decisión exclusivamente de marketing. Antes de invertir en publicidad, desarrollo de identidad visual y adquisición de usuarios, conviene realizar una búsqueda de disponibilidad y analizar las clases correspondientes.

De todas maneras, marca y software son activos diferentes. Una empresa puede ser titular del código de una aplicación y no tener adecuadamente protegido su nombre comercial ni los signos que utiliza como sus marcas. También puede suceder lo contrario, que puede tener una marca registrada, pero carecer de documentación suficiente sobre la titularidad del código.

También la interfaz gráfica merece atención, el llamado “look & feel”. Los elementos visuales de una aplicación pueden estar vinculados con diferentes formas de protección según su naturaleza concreta: derecho de autor, diseño industrial, marca u otras figuras.

Un desarrollador que incorpora fotografías, música, tipografías, ilustraciones, videos o textos de terceros no adquiere automáticamente el derecho de utilizarlos comercialmente porque haya comprado una licencia de uso de una plataforma. Hay que revisar qué licencia fue adquirida, para qué territorio, durante cuánto tiempo y con qué finalidad.

La misma lógica se aplica a los recursos visuales utilizados para diseñar interfaces.

Por eso, una buena auditoría de propiedad intelectual de una aplicación debería incluir por separado elementos tales como:

a código;

b diseño;

c contenido;

d marca;

e dominio;

f bases de datos;

g documentación;

h componentes de terceros, entre otros que pudieran identificarse al caso concreto.

Cada activo puede tener un titular diferente y, además, requerir un mecanismo de protección diferente.


Regla práctica

Cuando se comercializa una aplicación, no hay que proteger solamente “el software”. Hay que construir un mapa de todos los activos intelectuales que hacen reconocible y explotable al producto.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/



Post 7 Datos personales y software, un activo tecnológico con información de personas – 7 de 10

 


Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada



Una aplicación puede ser desde el punto de vista jurídico impecable desde la perspectiva del derecho de autor y, sin embargo, presentar problemas importantes respecto de los datos que procesa. Esto ocurre especialmente con plataformas, aplicaciones de salud, fintech, comercio electrónico, educación, recursos humanos, redes sociales y sistemas que utilizan perfiles de usuarios.

En Uruguay, la ley n.° 18.331 de protección de datos personales, reconoce la protección de los datos personales como un derecho fundamental y establece reglas sobre su tratamiento. La ley establece, como principio general, que el tratamiento es lícito cuando existe consentimiento libre, previo, expreso e informado, sin perjuicio de las excepciones legales. Además, cuando se recolectan datos personales deben proporcionarse determinadas informaciones al titular, entre ellas la finalidad del tratamiento, la existencia de la base de datos, la identidad del responsable y los derechos que puede ejercer. Para el desarrollador, esto genera una consecuencia importante, pues la estructura de software no debería diseñarse separadamente de la estructura jurídica de los datos. Esto tiene consecuencias técnicas.

Si una aplicación recoge datos que no necesita, almacena información durante más tiempo del necesario, permite accesos indiscriminados o mezcla bases de datos con finalidades distintas sin analizar previamente su legitimidad, el problema no se soluciona agregando posteriormente una cláusula de privacidad. La privacidad debe estar presente desde el diseño para que sea un desarrollo ajustado a derecho. El desarrollador debería recibir instrucciones claras sobre:

a qué datos se recogen;

b para qué se utilizan;

c quién puede acceder;

d dónde se almacenan;

e cuánto tiempo se conservan;

f con quién se comparten;

g qué medidas de seguridad se aplican;

h cómo se eliminan;

i cómo se atienden los derechos de los titulares.

La protección de datos también se conecta con la propiedad intelectual. Una base de datos puede contener información personal y, simultáneamente, presentar elementos de selección o disposición susceptibles de protección autoral. Pero los derechos sobre la estructura o sobre determinados elementos de una base de datos no significan que la empresa pueda apropiarse libremente de los datos personales contenidos en ella.

Son planos jurídicos diferentes. La empresa puede tener derechos sobre una base de datos y, al mismo tiempo, estar sometida a obligaciones respecto de las personas cuyos datos procesa.


Regla práctica

Cuando se desarrolla software que procesa datos personales, no alcanza con tener definido cómo programamos esta función, sino también qué tratamiento de datos implica esta función y bajo qué condiciones jurídicas puede realizarse.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/



Post 8 Inteligencia artificial y desarrollo de software: ¿quién responde por el código generado? - 8 de 10



Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada



La inteligencia artificial está modificando rápidamente la actividad de los desarrolladores, como la de todo el mundo. En este tema, una parte del código hoy puede ser escrita directamente por una persona y otra parte puede ser sugerida, completada, transformada o generada mediante herramientas de IA.

Esto ha introducido una nueva dimensión en la gestión de propiedad intelectual.

En primer lugar, hay que preguntarse quién es el autor de un código generado con inteligencia artificial. La respuesta no debería buscarse en una afirmación automática del tipo “si lo utilizó un programador, todo es suyo” ni en la contraria “si lo generó una IA, nadie tiene derechos”.

La cuestión depende de las circunstancias concretas de creación y del grado de intervención humana.

En Uruguay, la base de la respuesta se encuentra en la ley n.° 9.739 que, como hemos ya comentado en esta serie, protege las creaciones intelectuales por derecho de autor y contempla expresamente los programas de ordenador como obra protegida.

Sin embargo, el uso de IA introduce interrogantes adicionales, del tipo de las siguientes:

a ¿quién diseñó el problema que debía resolverse?

b ¿quién formuló las instrucciones?

c ¿quién seleccionó la respuesta?

d ¿quién modificó el código?

e ¿quién integró el resultado?

f ¿quién realizó la depuración?

g ¿qué elementos fueron creados autónomamente por la herramienta?

h ¿la herramienta fue autorizada para utilizar los datos introducidos?

i ¿qué condiciones contractuales tiene el proveedor de IA?, entre otras variables para considerar.

En segundo lugar, hay quepreguntarse si el código generado puede incorporar material protegido de terceros. Un desarrollador puede recibir una sugerencia aparentemente original que, sin saberlo, reproduzca una estructura o fragmento existente. Por eso, utilizar IA no elimina la necesidad de revisar el código. La empresa debería establecer políticas sobre el uso de herramientas generativas, especialmente cuando se incorporan al desarrollo profesional.

Conviene determinar, entre otros factores:

a qué herramientas están autorizadas;

b qué información puede introducirse;

c qué información está prohibido introducir;

d quién revisa el código generado;

e cómo se documenta su utilización;

f cómo se verifica la procedencia de componentes;

g cómo se gestiona la confidencialidad;

h quién asume las responsabilidades contractuales frente al cliente.

También hay que analizar especialmente cuando se introduce en una herramienta externa lo que puede ser código fuente confidencial o información de clientes. En este caso, el problema deja de ser exclusivamente de propiedad intelectual y puede involucrar también secreto empresarial, confidencialidad, protección de datos y obligaciones contractuales.

El desarrollador profesional debería adoptar, por tanto, como regla básica, que la IA puede ser una herramienta de desarrollo, pero no sustituye la trazabilidad jurídica del software.


Regla práctica

En proyectos profesionales conviene conservar evidencia de cómo se incorporaron elementos generados o asistidos por IA, especialmente cuando el software tiene valor económico relevante. Se trata de poder explicar a posteriori cómo se creó el activo y bajo qué condiciones.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/



 

Post 9 Vender, licenciar o entregar software, parecido no es lo mismo – 9 de 10



Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada



Una de las confusiones más habituales en el mercado tecnológico consiste en utilizar la expresión “vender software” en alusión a diversas operaciones que en realidad desde el punto de vista jurídico son diferentes. Siendo más específico, se puede afirmar que una empresa puede vender una copia, otorgar una licencia, desarrollar software a medida, prestar acceso mediante SaaS, ceder derechos patrimoniales, entregar código fuente, mantener el código bajo su control y permitir solamente el uso. Todas estas acciones no son lo mismo.

El derecho de autor reconoce al titular facultades exclusivas de explotación, entre las que se incluye reproducir, distribuir, adaptar, transformar y poner la obra a disposición del público. Por eso, un contrato tecnológico debe determinar qué está recibiendo realmente el cliente.

Imaginemos una empresa que contrata un sistema por cinco años. Hay mucha información que le conviene tener para la toma de decisiones al respecto en dicho plazo. Por ejemplo, es importante que sepa si puede copiarlo, modificarlo, contratar a otro desarrollador para mantenerlo, entregarlo a una empresa vinculada, sublicenciarlo, utilizarlo después de terminar el contrato, si recibe el código fuente y tiene derecho a realizarle modificaciones, quién será titular de las mejoras, entre varias interrogantes que derivan de la aplicación de claros principios del régimen legal.

Todas estas preguntas deberían estar respondidas.

El modelo SaaS agrega, como diferencia importante, que muchas veces el cliente no recibe una copia ni adquiere el código. Recibe un derecho contractual de acceso a una funcionalidad tecnológica. En ese caso, el contrato debe ocuparse de disponibilidad, seguridad, niveles de servicio, mantenimiento, continuidad, datos, confidencialidad, propiedad intelectual y terminación.

Cuando existe una cesión de derechos patrimoniales sobre una obra, la documentación adquiere especial importancia. El régimen registral uruguayo contempla expresamente las transmisiones de derechos patrimoniales sobre software y el Decreto N.º 39/025 establece requisitos para su transferencia y eficacia frente a terceros.

La diferencia entre licencia y cesión también es decisiva para ambas partes, no son negocios que resulten indiferentes entre sí. El desarrollador que concede una licencia conserva determinados derechos, mientras que el que cede derechos puede desprenderse de facultades patrimoniales mucho más amplias. El cliente que adquiere una licencia puede tener un excelente producto para utilizar, pero no necesariamente puede modificarlo, venderlo o transferirlo. Por eso, el precio de un proyecto no debería ser el único elemento negociado. También debe negociarse qué derecho recibe el cliente por ese precio.


Regla práctica

Nunca utilizar expresiones genéricas como “el software pertenece al cliente” sin definir exactamente qué significa “pertenece”. ¿Se trata de propiedad del soporte, licencia de uso, cesión de derechos patrimoniales, acceso al código, derecho de modificación o una combinación de estos elementos? Son todas situaciones distintas.



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/



Post 10 Contrato básico de desarrollo de software y cesión/licencia de derechos – 10 de 10



Serie PI para desarrolladores de software – Diez post de PI #BibliotecaPIAplicada


Modelo adaptable para desarrolladores independientes, empresas de software, startups y clientes empresariales. Cada caso concreto tendrá particularidades que, naturalmente, no están contempladas en este contrato que se transcribe con propósito didáctico.


CONTRATO DE DESARROLLO DE SOFTWARE, PROPIEDAD INTELECTUAL Y LICENCIA

En la ciudad de ____________, República Oriental del Uruguay, el día ___ de __________ de ______, comparecen:

POR UNA PARTE: ____________________________, con domicilio en ____________________________, RUT/C.I. Nº __________________, representada en este acto por ____________________________, en adelante “EL CLIENTE”;

POR OTRA PARTE: ____________________________, con domicilio en ____________________________, RUT/C.I. Nº __________________, en adelante “EL DESARROLLADOR”;

quienes acuerdan celebrar el presente contrato, sujeto a las siguientes cláusulas:

PRIMERA. Objeto. EL DESARROLLADOR se obliga a desarrollar para EL CLIENTE el software denominado provisionalmente ____________________________, destinado a ____________________________, de acuerdo con las especificaciones técnicas y funcionales que se incorporan como Anexo I.

El desarrollo comprenderá, según corresponda:

a) análisis y diseño;

b) programación;

c) código fuente;

d) código objeto o ejecutable;

e) documentación técnica;

f) documentación para usuarios;

g) pruebas y correcciones;

h) implementación;

i) capacitación;

j) mantenimiento y actualizaciones, únicamente cuando ello haya sido expresamente contratado.

Cualquier funcionalidad adicional deberá ser acordada por escrito y podrá implicar modificación del precio y del cronograma.

SEGUNDA. Plazo y entregas. El desarrollo se realizará conforme al siguiente cronograma:

Etapa 1: ____________________________.

Etapa 2: ____________________________.

Etapa 3: ____________________________.

Entrega final prevista: ____________________________.

Las partes podrán utilizar metodologías ágiles de desarrollo, en cuyo caso las funcionalidades podrán definirse y modificarse mediante historias de usuario, tickets, repositorios, documentos funcionales u otros instrumentos acordados.

TERCERA. Precio y forma de pago. EL CLIENTE abonará a EL DESARROLLADOR la suma de ____________________________, más los impuestos que correspondan.

El pago se realizará de la siguiente manera:

____________________________________________________.

Los trabajos adicionales no comprendidos en el objeto inicial serán presupuestados separadamente.

CUARTA. Propiedad intelectual del desarrollo. Las partes reconocen que el software constituye una creación susceptible de protección por la legislación uruguaya sobre derechos de autor, incluyendo la ley n.° 9.739 y sus modificativas. Respecto de los componentes desarrollados específicamente para EL CLIENTE en ejecución del presente contrato, las partes acuerdan lo siguiente:

[Elegir una de las siguientes alternativas y eliminar la que no corresponda]

Opción A - Cesión: EL DESARROLLADOR cede a EL CLIENTE los derechos patrimoniales de autor correspondientes a los desarrollos específicamente realizados en ejecución del presente contrato, con el alcance territorial y temporal permitido por la legislación aplicable, comprendiendo las facultades de reproducción, distribución, adaptación, modificación, transformación, comunicación y puesta a disposición, en la medida necesaria para la explotación del software objeto del contrato.

Opción B - Licencia: EL DESARROLLADOR conserva la titularidad de los derechos patrimoniales sobre el software y concede a EL CLIENTE una licencia de uso __________________ [exclusiva/no exclusiva], __________________ [transferible/intransferible], por __________________, para el territorio de __________________ y con las siguientes facultades: ____________________________.

QUINTA. Código fuente. Las partes acuerdan que el código fuente:

[Elegir]

a) será entregado a EL CLIENTE al finalizar el proyecto;

b) será entregado por etapas;

c) permanecerá bajo custodia de EL DESARROLLADOR;

d) será depositado en un repositorio accesible a EL CLIENTE;

e) será entregado únicamente bajo las circunstancias previstas en ____________________________.

La modalidad elegida deberá considerarse parte esencial del presente contrato.

SEXTA. Componentes preexistentes. EL DESARROLLADOR declara que determinados componentes, bibliotecas, frameworks, herramientas, módulos, metodologías, código reutilizable, conocimientos técnicos, plantillas o desarrollos preexistentes pueden ser utilizados en la ejecución del proyecto. Dichos elementos, identificados en el Anexo II, no se considerarán cedidos a EL CLIENTE salvo estipulación expresa. Cuando tales componentes sean necesarios para utilizar el software contratado, EL DESARROLLADOR otorgará a EL CLIENTE la licencia o autorización necesaria para su utilización dentro del alcance del presente contrato.

SÉPTIMA. Componentes de terceros y software libre. EL DESARROLLADOR podrá utilizar componentes de terceros y software libre u open source cuando ello resulte técnicamente adecuado, siempre que respete las condiciones de las licencias correspondientes. EL DESARROLLADOR informará a EL CLIENTE, cuando resulte relevante para la explotación del software, los principales componentes de terceros incorporados y las licencias aplicables. Cuando EL CLIENTE imponga restricciones respecto del uso de determinadas licencias o componentes, deberá comunicarlo previamente y por escrito a EL DESARROLLADOR.

OCTAVA. Derechos sobre modificaciones y versiones. Salvo pacto expreso en contrario, los derechos sobre nuevas versiones, actualizaciones, mejoras y desarrollos posteriores se regirán por lo siguiente: ____________________________________________________. Las partes procurarán diferenciar los desarrollos específicamente realizados para EL CLIENTE de las herramientas, conocimientos, métodos y componentes generales que EL DESARROLLADOR pueda utilizar en otros proyectos.

NOVENA. Confidencialidad. Las partes se obligan a mantener confidencial toda información técnica, comercial, financiera, estratégica, empresarial o de cualquier otra naturaleza que sea razonablemente identificada como confidencial o que por su naturaleza deba considerarse reservada. La obligación comprenderá, entre otros elementos, cuando corresponda: código fuente; credenciales; documentación técnica; arquitectura del sistema; bases de datos; información de clientes; información comercial; secretos empresariales; metodologías internas; información relativa al producto antes de su lanzamiento. La obligación de confidencialidad continuará vigente durante __________ años después de la finalización del contrato, sin perjuicio de aquellas informaciones que por su naturaleza deban permanecer confidenciales mientras conserven tal carácter.

DÉCIMA. Datos personales. Cuando el software implique tratamiento de datos personales, las partes cumplirán la legislación uruguaya aplicable en materia de protección de datos personales. EL CLIENTE determinará, cuando corresponda, las finalidades y condiciones del tratamiento que deba realizarse mediante el software. EL DESARROLLADOR implementará las medidas técnicas y organizativas que contractualmente le correspondan y no utilizará los datos para finalidades diferentes de las autorizadas. Cuando corresponda, las partes documentarán separadamente las funciones y responsabilidades relativas al tratamiento de datos personales.

DÉCIMA PRIMERA. Seguridad. EL DESARROLLADOR aplicará medidas razonables de seguridad adecuadas a la naturaleza del proyecto. Cuando existan requerimientos específicos de seguridad, estos deberán detallarse en el Anexo III. Las partes establecerán el procedimiento para comunicar incidentes de seguridad, pérdida de información, accesos no autorizados u otras situaciones relevantes.

DÉCIMA SEGUNDA. Uso de herramientas de inteligencia artificial. EL DESARROLLADOR podrá utilizar herramientas de inteligencia artificial como apoyo al desarrollo únicamente dentro de las condiciones acordadas por las partes. No podrá introducir en herramientas externas información confidencial de EL CLIENTE, datos personales o código cuya divulgación se encuentre restringida, salvo autorización previa y expresa. Cuando el uso de inteligencia artificial resulte material para la creación o modificación del software, EL DESARROLLADOR deberá observar las obligaciones de revisión técnica y jurídica que correspondan y responderá por el cumplimiento de las condiciones contractuales relativas al software entregado.

DÉCIMA TERCERA. Garantía y corrección de errores. EL DESARROLLADOR garantizará durante el plazo de __________ días desde la entrega la corrección de errores reproducibles que impidan el funcionamiento conforme a las especificaciones contractualmente acordadas. No quedarán comprendidas en esta garantía las modificaciones solicitadas por EL CLIENTE, los problemas derivados de terceros, modificaciones realizadas por personas no autorizadas, utilización incorrecta del software o cambios en sistemas externos no controlados por EL DESARROLLADOR.

DÉCIMA CUARTA. Mantenimiento. El mantenimiento posterior a la entrega: [Elegir]

a) se encuentra incluido durante __________;

b) será contratado separadamente;

c) estará sujeto al siguiente servicio de mantenimiento: ____________________________.

DÉCIMA QUINTA. Registro de software. Las partes podrán acordar la inscripción del software en el Registro de Software de la Dirección Nacional de la Propiedad Industrial. Cuando corresponda, determinarán quién estará encargado de realizar la solicitud, asumir los costos y aportar la documentación necesaria. La falta de inscripción no se interpretará, por sí misma, como renuncia a los derechos de propiedad intelectual sobre la obra.

DÉCIMA SEXTA. Créditos y reconocimiento. Las partes acuerdan que la identificación del desarrollador y de los restantes participantes del proyecto será realizada de la siguiente manera: ____________________________________________________. Esta cláusula se aplicará sin perjuicio de los derechos que legalmente correspondan a los autores.

DÉCIMA SÉPTIMA. Subcontratación y colaboradores. EL DESARROLLADOR podrá recurrir a colaboradores o subcontratistas cuando ello sea necesario para la ejecución del proyecto, manteniendo frente a EL CLIENTE la responsabilidad por las obligaciones asumidas. EL DESARROLLADOR se obliga a contar con los instrumentos contractuales necesarios para asegurar que los colaboradores involucrados hayan definido adecuadamente sus derechos sobre los desarrollos realizados.

DÉCIMA OCTAVA. Terminación anticipada. El contrato podrá finalizar:

a) por vencimiento del plazo;

b) por mutuo acuerdo;

c) por incumplimiento grave de cualquiera de las partes;

d) por las demás causas previstas legalmente.

En caso de terminación anticipada, las partes determinarán el estado de los desarrollos realizados, los pagos pendientes, la entrega de materiales y el alcance de los derechos adquiridos hasta ese momento.

DÉCIMA NOVENA. Efectos de la terminación. La terminación del contrato no afectará las obligaciones que por su naturaleza deban continuar vigentes, incluyendo, según corresponda, confidencialidad, protección de datos, propiedad intelectual, responsabilidad y solución de controversias.

VIGÉSIMA. Legislación aplicable y jurisdicción. El presente contrato se regirá por las leyes de la República Oriental del Uruguay. Para cualquier controversia derivada de su interpretación, cumplimiento o ejecución, las partes acuerdan someterse a ____________________________, sin perjuicio de los mecanismos de negociación, mediación o arbitraje que expresamente se establezcan.

VIGÉSIMA PRIMERA. Integridad contractual. El presente contrato y sus anexos constituyen el acuerdo entre las partes respecto del objeto contratado y sustituyen cualquier acuerdo previo, verbal o escrito, relativo al mismo objeto. Toda modificación deberá constar por escrito y ser aceptada por ambas partes. En señal de conformidad, se firman dos ejemplares de igual tenor en el lugar y fecha indicados.

EL CLIENTE

Firma: ____________________________

Nombre: ___________________________

Documento/RUT: ____________________

EL DESARROLLADOR

Firma: ____________________________

Nombre: ___________________________

Documento/RUT: ____________________


Anexos eventuales:


ANEXO I - Especificaciones del software

Descripción funcional:

Funcionalidades principales:


ANEXO II - Componentes preexistentes y componentes de terceros


ANEXO III - Requisitos de seguridad, datos y mantenimiento



Imagen: https://publicdomainreview.org/collection/bracelli-s-bizzarie-di-varie-figure-1624/