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

Samer samer2004 at gmail.com
Tue Jan 6 14:23:15 CET 2009 

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.html que
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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: /pipermail/kune-devel/attachments/20090106/aabfd58b/attachment.html

More information about the kune-devel mailing list