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/