Licencias diversas

[Lorenzo Gil Sanchez]

Ni RMS lo hubiera explicado mejor. Gracias por aclararnos, Rafael

Lorenzo

El jue, 08-07-2004 a las 13:04, Rafael Villar Burke escribió:
> 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
> 
> ______________________________________________________________________
> _______________________________________________
> Python-es mailing list
> Python-es en aditel.org
> http://listas.aditel.org/listinfo/python-es