[ Favor mantener gulcr@... y proyecto_sl@... en el Cc: -- en la primera
lista se origin� esta discusi�n y la segunda es probable que tenga
inter�s en la misma ]
On Wed, Nov 13, 2002 at 04:56:10PM -0800, Ignacio Solis wrote:
> En el Art�culo 4�.- Definici�n de Software libre se listan las
> garant�as que el software libre debe brindar al usuario. [...] no
> dice que hay que garanziar que _todo_ trabajo derivado sea tambi�n
> software libre. El �ltimo punto del art�culo, que me parece trata de
> expresar algo parecido no me queda completamente claro.
De hecho el �ltimo punto del art�culo dice:
> [la licencia debe garantizar] modificaci�n del programa y
> distribuci�n libre tanto de las alteraciones como del nuevo programa
> resultante, bajo las mismas condiciones del programa original.
O sea, se debe poder modificar el programa, y se debe poder distribuir
bajo las mismas condiciones originalmente. No requiere que el programa
se *deba* redistribuir bajo las mismas condiciones originales, como
dices tu es nada m�s una opci�n para el usuario. Por supuesto, la
licencia puede o no puede _requerir_ esto, pero eso se deja a la
licencia. Lo que la licencia _no_ puede hacer es imponer condiciones
diferentes de redistribuci�n si el programa se modifica. Esto podr�a
ser un problema en casos como la licencia de LaTeX. Cito:
You may distribute a modified file of The Program if, and only if,
the following eight conditions are met:
[...]
3. You must not distribute the modified file with the filename of
the original file.
[...]
5. You must change any identification string in the file to
indicate clearly that the modified file is not part of The
Program.
[...]
7. You must distribute the modified file under a license that forbids
distribution both of the modified file and of any files
derived from the modified file with the filename of the
original file.
Es decir, la licencia que hay que usar para redistribuir el programa
debe imponer restricciones adicionales (el archivo "tal y cual" no
puede renombrarse a "esto otro"). Antes de proponer una soluci�n,
quisiera se�alar por qu� es necesario buscar una soluci�n en primer
lugar: este tipo de cl�sulas se aplican a programas que dependen de que
su funcionamiento no cambie, como es el caso de TeX. Si uno toma un
archivo de TeX y lo procesa utilizando TeX, el archivo debe producir
_exactamente_ el mismo resultado sin importar las condiciones en las
que opera. La salida del programa depende �nicamente de los datos de
entrada. Lo que el programa _hace_ est� preespecificado. TeX cuenta
con una suite de tests que verifican que la implementaci�n cumple con
la especificaci�n. Si el programa no pasa _todos_ los tests, el
programa _no puede_ se llamado TeX. Otro tipo de cosas que tienen este
tipo de licencias son los est�ndares (bueno, los pocos que tienen
licencias libres). Lo que el est�ndar especifica no se puede cambiar,
y si se cambia, se _debe_ necesariamente cambiar el nombre del
documento. Otro ejemplo son las implementaciones de referencia.
Debido a que la propuesta de ley dice que se debe garantizar al usuario
la redistribuci�n de una versi�n modificada bajo la mismas condiciones
originales, el extracto citado arriba no cumple con dicha condici�n.
Eso se puede solucionar permitiendo algo de esta clase:
4. Integrity of The Author's Source Code
The license may restrict source-code from being distributed in
modified form _only if the license allows the distribution of
"patch files" with the source code for the purpose of modifying
the program at build time. The license must explicitly permit
distribution of software built from modified source code. The
license may require derived works to carry a different name or
version number from the original software.
Si se necesita una traducci�n al espa�ol de esto, se puede obtener
f�cilmente del sitio web de Debian (http://www.debian.org/), en la
parte del Contrato Social (Social Contract). Debido a que el proyecto
Debian produce una distribuci�n de software, es importante la cl�usula
que dice que los binarios derivados de versiones modificadas deben
poder redistribuirse. Para los efectos de esta ley ese no es el caso.
Esta es una de las formas en las que se puede resolver este problema, y
por supuesto hay otras, pero la pregunta es cual es la intenci�n de la
cl�usula en cuesti�n.
> En otras palabras, parece como BSD. O sea, que permite que el producto
> final sea cerrado.
La cl�sula permite que se considere a las licencias del tipo BSD como
"libres".
> Si bien esto no me molesta, o sea, que usen c�digo con licencia BSD,
> yo preferir�a que lo que produzca el estado sea abierto. Por lo
> tanto, me gustar�a que hubiera una clausula que diga que lo producido
> se dara de manera abierta (aunque sea BSD) y no solo que diga que lo
> que se utiliza (como fuente) sea abierto. Me explico?
Si, te explicas. Pero ese es un camino un poco resbaloso. Est�s
pidiendo que lo que el gobierno produzca sea no solo libre bajo esta
definici�n, sino que sea tal que _siempre_ sea libre. Aqu� hay dos
formas de argumentar, y curiosamente las dos se basan en exactamente lo
mismo, a saber, que el software que produce el gobierno se produce con
el dinero de los contribuyentes, es decir con el dinero de todos. Una
escuela dice que si es producido con el dinero de todos, entonces dice
que debe ser de todos siempre. La otra dice que si se produce con
dinero p�blico, el p�blico debe poder beneficiarse econ�micamente de
ese trabajo, es decir, debe ser posible tomar ese software y utilizarlo
como base para software propietario. Las dos interpretaciones tienen
sentido. Yo no tengo preferencia por ninguna, en el sentido de que
admito que existen casos en los cuales una interpretaci�n o la otra
puede ser m�s apropiada. Personalmente creo que es _mejor_ dejar ese
tipo de requisito fuera de la ley, y si fuese del caso, incluirlo en un
reglamento. El �nico requisito que si debe estar en la ley es el de
que el software producido por el Estado debe ser libre, seg�n la
definici�n contenida en la ley.
Saludos,
Marcelo
--
Desuscripci�n: escriba a [EMAIL PROTECTED], tema 'unsubscribe'
Problemas a: [EMAIL PROTECTED] http://www.linux.or.cr/listas
