Licencias diversas

[Rafael Villar Burke]

La LGPL se ha escrito para servir como licencia de librerías de 
plataforma. Por ello no pretende eliminar la posibilidad de que las usen 
programas cerrados e incluso lo permite, para favorecer la 
estandarización sobre ellas, pero a cambio incita a la colaboración y a 
la buena ciudadanía en la "comunidad". El proyecto Gnome, por ejemplo, 
exige que todo el código de la plataforma tenga licencia LGPL, para 
poder hacer desarrollos abiertos o cerrados sobre él.

El meollo de la cuestión está en saber si cuando se trata con código 
LGPL se trata de un "trabajo derivado" o de un "programa que hace uso de 
la librería" LGPL.

Por lo que yo sé, el "problema" de tener que liberar el código (nada 
prohibe vender el programa en ninguna licencia de la FSF) surge 
fundamentalmente cuando "incrustas" directamente parte o todo el código 
de una aplicación o librería con licencia LGPL.

Además, para evitar situaciones del tipo "embrace and extend" al estilo 
Microsoft que acaban haciendo inutilizables las librerías salvo para el 
que tiene capacidad para imponer y controlar las extensiones 
propietarias, para escaparse también de comportamientos incompatibles 
"no declarados", o para soslayar el problema de la pervivencia de 
versiones antiguas que no siguen las políticas de desarrollo de los 
creadores de la librería y la "desacreditan", etc, se pide que se haga 
enlazado dinámico, es decir, se pide que se haga un "uso de la 
librería", y que no se integre indisolublemente con el programa. El 
enlazado estático hace muy difícil saber si se ha manipulado una 
librería, facilita la aparición de los problemas anteriores y, en ese 
caso, son dificilmente auditables.

Si haces un programa cerrado se te pide que no te apropies del trabajo 
LGPL, si lo haces libre tienes todas las libertades.

En el caso de pyGTK no existen en principio esos problemas. Sin embargo, 
el problema surge cuando se usan programas como py2exe. En ese caso se 
produce la situación esa tan confusa sobre la que advierte el punto 5, 
es decir, un ejecutable que enlaza una aplicación que usa la librería 
con la librería misma, en la que se aclara que sí se trata de un trabajo 
derivado que debe someterse a la LGPL o usar otra librería.

Hay otros problemas sutiles de estas licencias cuando se piensa en 
términos de servicios web, códigos intermedios, etc que a lo mejor dan 
un poco de luz sobre los párrafos más enmarañados de la LGPL y la propia 
GPL. ¿Qué ocurre con un servlet derivado de código GPL? ¿Se considera 
distribución conectarse a ese servicio por la red?...

Un saludo,

Pachi
------------ próxima parte ------------
_______________________________________________
Python-es mailing list
Python-es en aditel.org
http://listas.aditel.org/listinfo/python-es