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://ourproject.org "Why should I be worried about dying? It's not going to happen in my lifetime!” [Raymond Smullyan]
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@s 2009/1/6 Vicente J. Ruiz Jurado <[email protected]>
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 [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/kune-devel
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 <[email protected]>
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@s
2009/1/6 Vicente J. Ruiz Jurado <[email protected]>
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 [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/kune-devel
_______________________________________________ kune-devel mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/kune-devel
dani escribió:
creo que la decisión la tendremos que tomar entre GPL y LGPL, no?
yo me decantaría por la LGPL para las libs. Después de las explicación del Samer... creo que es la que mejor permitiría que la gente usara nuestro trabajo pero que no abusara...es Copyleft: permite que otros linken la librería y la usen (incluso en proyectos comerciales), y si la mejoran, pues tienen que compartir, que me parece lo justo. Gracias Samer!!!! -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org "Desgraciado el país que necesita héroes." [Bertolt Brecht]
completamente de acuerdo (óle!) si, gracias, samer! 2009/1/6 Vicente J. Ruiz Jurado <[email protected]>
dani escribió:
creo que la decisión la tendremos que tomar entre GPL y LGPL, no?
yo me decantaría por la LGPL para las libs. Después de las explicación del Samer... creo que es la que mejor permitiría que la gente usara nuestro trabajo pero que no abusara...es Copyleft: permite que otros linken la librería y la usen (incluso en proyectos comerciales), y si la mejoran, pues tienen que compartir, que me parece lo justo.
Gracias Samer!!!! -- Vicente J. Ruiz Jurado
http://homes.ourproject.org/~vjrj/blog<http://homes.ourproject.org/%7Evjrj/blog> http://ourproject.org
"Desgraciado el país que necesita héroes." [Bertolt Brecht]
_______________________________________________ kune-devel mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/kune-devel
Okis, el único contra de la LGPL es el ya explicado en el link de GNU. Por lo demás es perfectamente válida, libre y copyleft. 2009/1/6 dani <[email protected]>
completamente de acuerdo (óle!) si, gracias, samer!
2009/1/6 Vicente J. Ruiz Jurado <[email protected]>
dani escribió:
creo que la decisión la tendremos que tomar entre GPL y LGPL, no?
yo me decantaría por la LGPL para las libs. Después de las explicación del Samer... creo que es la que mejor permitiría que la gente usara nuestro trabajo pero que no abusara...es Copyleft: permite que otros linken la librería y la usen (incluso en proyectos comerciales), y si la mejoran, pues tienen que compartir, que me parece lo justo.
Gracias Samer!!!! -- Vicente J. Ruiz Jurado
http://homes.ourproject.org/~vjrj/blog<http://homes.ourproject.org/%7Evjrj/blog> http://ourproject.org
"Desgraciado el país que necesita héroes." [Bertolt Brecht]
_______________________________________________ kune-devel mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/kune-devel
_______________________________________________ kune-devel mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/kune-devel
-- Samer http://ourproject.org "No son tiempos para hacer cualquier cosa"
Je, qué gracioso... hace unos meses mandé un resumen de mi visión del rollo de licencias de software libre... y hoy publican en Barrapunto una clasificación de éstas. Hacen la misma división que yo hacía, pero las explican de forma más didáctica: http://softlibre.barrapunto.com/article.pl?sid=09/03/15/1643216 Aunque no me gusta la proliferación de licencias (¿para qué una European Public License, una Microsoft Public License, etc, etc? Es la manía de colocar la marca diciendo exactamente lo mismo... igual que con la proliferación de distribuciones de Linux, como en las comunidades autonómas...), me parece un poco absurdo querer reducir todas a 4. Una cosa es clasificar, otra muy distinta elegir un representante de cada tipo y destruir el resto (hay diferencias sutiles en algunos casos, que pueden adaptarse a determinadas necesidades). Por otro lado, los representantes citados están muy bien elegidos. 2009/1/6 dani <[email protected]>
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 <[email protected]>
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@s
2009/1/6 Vicente J. Ruiz Jurado <[email protected]>
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 [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/kune-devel
_______________________________________________ kune-devel mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/kune-devel
_______________________________________________ kune-devel mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/kune-devel
-- Samer http://ourproject.org "No son tiempos para hacer cualquier cosa"
Samer escribió:
Je, qué gracioso... hace unos meses mandé un resumen de mi visión del rollo de licencias de software libre... y hoy publican en Barrapunto una clasificación de éstas. Hacen la misma división que yo hacía, pero las explican de forma más didáctica: http://softlibre.barrapunto.com/article.pl?sid=09/03/15/1643216
Aunque no me gusta la proliferación de licencias (¿para qué una European Public License, una Microsoft Public License, etc, etc? Es la manía de colocar la marca diciendo exactamente lo mismo... igual que con la proliferación de distribuciones de Linux, como en las comunidades autonómas...), me parece un poco absurdo querer reducir todas a 4. Una cosa es clasificar, otra muy distinta elegir un representante de cada tipo y destruir el resto (hay diferencias sutiles en algunos casos, que pueden adaptarse a determinadas necesidades).
Por otro lado, los representantes citados están muy bien elegidos.
Guuuay, guay, entonces, ¿creamos nuestra licencia con un nombre rimbombante? jejejeje... es broma, es broma... Abrazos, Vicente
participants (3)
-
dani -
Samer -
Vicente J. Ruiz Jurado