Re: [kune-devel] Repesando Affero en las librerías

Tue Jan 6 14:46:54 CET 2009

alto y claro, si señor
pedazo de explicación (por fin pongo nombre a las diversas opciones)
yo, personalmente, aunque antes era más de LGPL ahora mismo no me importa en
absoluto que sea una GPL
también me parece muy razonable lo de que es más difícil subir que bajar y
que hay que tener cuidado
en fin, abierto a cualquier opinión

bárbara explicación, samer, muchas gracias
creo que la decisión la tendremos que tomar entre GPL y LGPL, no?
besos

2009/1/6 Samer <samer2004 en gmail.com>

> Veamos. [WARNING: rollo-coñazo approaching]
>
> En primer lugar, sí soy favorable a relajar emitelib y suco. Como bien ha
> dicho Vicente, no tiene tanto sentido una Affero para unas librerías que no
> son servicios web.
>
> Pero por otro lado: ¿seguro que una Apache? ¿Por qué?
>
> Como ya puse hace mucho:
> - Affero: que exige liberar a los que extiendan el programa y a los
> que usen el servicio
> - GPL: que exige liberar a los que extiendan el programa, no a los que
> usan el servicio
> - LGPL: que exige liberar a los que extiendan el programa modificando
> su código, pero no a los que lo usen como módulo independiente (como
> al enlazar una librería), ni a los que usen el servicio
> - BSD: que no exige liberar a quien extienda o use el programa de
> cualquier modo. La Apache License es similar.
>
> Entiendo vuestra preocupación para que las librerías se extiendan.
> Mejoraría su calidad cuanto más aumentara su base de usuarios. Bien. Cuanto
> más bajas en la escala de licencias, más base de usuarios tienes porque
> menos libertad fuerzas. Las grandes corporaciones de software privativo que
> se han asomado un poco al software libre (Google, Yahoo, Apple) siempre usan
> licencias del final de la escala, por la simple razón de que una Apache o
> una BSD pueden cerrarse: es decir, emite podría tomarse, modificarse y
> cerrar el resultado en un paquete que forme parte de un programa comercial
> privativo. Como el Mac OS X de Apple (basado en un Unix BSD), así pueden
> aprovechar las sinergias del software libre sin verse obligados a liberar
> nada de lo que puedan sacar tajada (es decir, no usan GPL o AGPL, que son
> copyleft, víricas), y en cualquier momento pueden continuar el desarrollo de
> uno de esos proyectos libres de forma cerrada y no transparente, sin que
> repercuta en la comunidad pero aprovechando su trabajo (es decir, son de
> tipo BSD/Apache y no tipo LGPL).
>
> Evidentemente, cuando más abajo se está en la escala, más usarán tu
> proyecto los de software privativo. El resultado es que arriba sólo ayudas
> al software libre, y abajo "ayudas" a todos, los libres y los no libres. Hay
> que tener claro que cuanto más abajo esté un proyecto, más posibilidades hay
> de que una corporación "privativa" done dinero al proyecto, claro (no hablo
> de Novell o Red Hat, sino de las citadas antes...  Novell/Red Hat/IBM
> liberan mucho con GPL y donan a proyectos GPL por interés propio).
>
> Entonces, ¿qué licencia usar? A mí personalmente no me gustaría usar una
> BSD/Apache. La única diferencia con una LGPL es que puede ser desarrollada
> de forma cerrada, y entonces no mejoraría la calidad de la librería. Una
> LGPL ya permite que pueda usarse en software privativo, así que atraerá a
> desarrolladores de ese mundillo que la puedan necesitar. Y si se quiere que
> GWT la use, puede (aunque tenga licencia Apache unos y LGPL emite).
>
> La mayoría de las librerías libres están bajo LGPL: de hecho en lugar de
> Lesser GPL antes se llamaba Library GPL... hasta que la FSF, GNU y Stallman
> cambiaron de opinión sobre este tema. Ahora recomiendan la GPL para las
> librerías: recomiendo leer http://www.gnu.org/licenses/why-not-lgpl.htmlque es cortito y directo, con ejemplos. Copio un trocito:
>
> (...) Using the ordinary GPL for a library gives free software developers
> an advantage over proprietary developers: a library that they can use, while
> proprietary developers cannot use it.
>
> Using the ordinary GPL is not advantageous for every library. (...) The
> most common case is when a free library's features are readily available for
> proprietary software through other alternative libraries. In that case, the
> library cannot give free software any particular advantage, so it is better
> to use the Lesser GPL for that library.
> (...)
> Proprietary software developers, seeking to deny the free competition an
> important advantage, will try to convince authors not to contribute
> libraries to the GPL-covered collection. For example, they may appeal to the
> ego, promising "more users for this library" if we let them use the code in
> proprietary software products. Popularity is tempting, and it is easy for a
> library developer to rationalize the idea that boosting the popularity of
> that one library is what the community needs above all.
> (...)
>
>
> Es verdad que emite y suco proporcionan funcionalidades sin equivalente en
> software privativo, por lo que caería en el caso que se describe: supondría
> una ventaja para el mundillo del software libre que fuera GPL. Que sea AGPL
> es una limitación no necesaria en absoluto y que sí podría echar para atrás
> a desarrolladores. Ahora bien, entiendo que si se prefiere aumentar la
> popularidad se haga LGPL. La decisión no es trivial, porque una vez que se
> baja en los escalones de las licencias, retractarse es muy complicado. Bajar
> es fácil (todos los que usen la librería como AGPL no encontrarán
> incompatibilidades en usar las futuras versiones en GPL, LGPL o BSD) pero
> subir es muy difícil (los que usen una librería en LGPL que pasa a GPL sí
> pueden encontrar incompatibilidades para usar las nuevas versiones con la
> nueva licencia... y pueden acabar desarrollando un fork de la última versión
> LGPL o quedarse con la antigua y nunca actualizar).
>
> Resumiendo mi opinión: AGPL no hace falta, GPL guay, LGPL aceptable,
> BSD/Apache ¿por qué?
>
> Si me he confundido en algún razonamiento decidme, please.
>
> Un abrazo a tod en s
>
>
> 2009/1/6 Vicente J. Ruiz Jurado <vjrj en ourproject.org>
>
> Muy buenas:
>>
>> Estos días currando con Dani hemos estado hablando sobre una propu que
>> hice hace semanas, a saber:
>> - Seguir usando affero para kune y emiteui
>> - Usar otra licencia más "relajada" como la apache2 para las librerías:
>> emitelib, y suco.
>>
>> ¿Why? Bueno, pues creo que la Affero viene muy bien para todo lo que sea
>> servicios web (como kune y emiteui).
>>
>> Y la apache puede venir muy bien para las librerías, porque necesitamos
>> que se use mucho, que la gente las extienda, les añada XEPs, etc., y que
>> ande todo lo finas que puedan funcionar.
>>
>> Usando Affero en las librerías, el uso que hace la gente en mucho menor,
>> la librería van a estar menos madura, y al final, eso repercute en que
>> kune funcione peor.
>>
>> También es una pena que un trabajo tan fino como es emitelib o suco no
>> se aproveche más.
>>
>> Lo comento porque estamos poniendo a punto suco para darle difusión
>> (hasta ahora no lo hemos hecho), y vemos como la gente (incluso la gente
>> de GWT) está intentando resolver problemas que suco ya resuelve con
>> alegría. GWT usa la apache...
>>
>> ¿Opiniones a favor/en contra?
>>
>> Abrazos,
>>
>> --
>> Vicente J. Ruiz Jurado
>>
>> http://homes.ourproject.org/~vjrj/blog<http://homes.ourproject.org/%7Evjrj/blog>
>> http://ourproject.org
>>
>>  "Why should I be worried about dying? It's not going to happen in my
>>  lifetime!" [Raymond Smullyan]
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> kune-devel mailing list
>> kune-devel en lists.ourproject.org
>> https://lists.ourproject.org/cgi-bin/mailman/listinfo/kune-devel
>>
>
>
> _______________________________________________
> kune-devel mailing list
> kune-devel en lists.ourproject.org
> https://lists.ourproject.org/cgi-bin/mailman/listinfo/kune-devel
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: /pipermail/kune-devel/attachments/20090106/541ff416/attachment.html