Copyleft: Idealismo Pragmático

por Richard Stallman

[imagen de un Ñu Filosófico] [ Russian | English ]

Toda decisión hecha por una persona proviene de los valores y metas de la persona. La gente puede tener muchas metas y valores; fama, ganancias, amor, sobrevivencia, diversión y libertad, son solo algunas de las metas que una buena persona puede tener. Cuando la meta es ayudar a los demás tanto como a uno mismo, lo llamamos idealismo.

Mi trabajo en el software libre está motivado por una meta idealista: difundir la libertad y la cooperación. Quiero alentar la difusión del software libre, reemplazando el software privativo que prohibe la cooperación, y así mejorar nuestra sociedad.

Esa es la razón básica por lo cual la Licencia Pública General del GNU está escrita como esta --como un copyleft. Todo el código añadido a un programa cubierto por la GPL debe ser software libre, incluso si es puesto en un archivo separado. Yo hago todo mi código disponible para el uso en software libre, y no para uso en sofware privativo, con el fin de alentar a otra gente que escribe software para que lo haga libre también. Supongo que como los desarrolladores de software privativo utilizan el copyright para evitar que compartamos, nosotros los cooperadores podemos utilzar el copyright para darle a otros cooperadores una ventaja comparativa: ellos pueden utilizar nuestro código.

No todo aquel que utiliza GNU GPL tiene esta meta. Hace muchos años, a un amigo mio le pidieron que re-publicara un programa con-copyleft bajo términos no-copyleft, y el respondió con algo más o menos así:

A veces trabajo en software libre, y a veces trabajo en software privativo --pero cuando trabajo en software privativo, espero que me paguen.
El estaba dispuesto a compartir su trabajo con una comunidad que comparte software, pero no veía la razón de darle un prospecto a un comerciante para hacer productos que estuvieran fuera de los limites de nuestra comunidad. Su meta era distinta a la mía, pero el decidió que la GPL GNU era útili para su meta también.

Si quieres lograr algo en el mundo, el idealismo no es suficiente --necesitas desarrollar un método que funcione para alcanzar la meta. En otras palabras, necesitas ser "pragmático". ¿Es la GPL pragmática? Veamos sus resultados.

Consideremos el GNU C++. ¿Por qué tenemos un compilador C++ libre? Sólo porque la GPL GNU decía que debia ser libre. GNU C++ fue desarrollado por un consorcio industrial, MCC, comenzando a partir del compilador C de GNU. MCC normalmente hace su trabajo tan privativo como sea posible. Pero ellos crearon la fachada (front end) del C++ como software libre, porque la GPL GNU decía que era la única manera de publicarlo. La fachada (front end) del C++ incluía muchos archivos nuevos, pero como estaban diseñados para estar enlazados con GCC, la GPL aplicaba a estos también. El beneficio para nuestra comunidad es evidente.

Consideremos el GNU ObJective C . NeXT queria hacer esta fachada (front end) propietaria; propusieron publicarla como archivos .o, y dejar que los usuarios los enlazaran con el resto del GCC, pensando que esta podría ser un escape a los requerimientos de la GPL. Pero nuestro abogado dijo que esto no evadiría los requerimientos, que no estaba permitido. Por lo tanto hicieron la fachada (front end) de ObJective C un software libre.

Estos ejemplos sucedieron hace años, pero la GPL GNU continua trayendonos más software libre.

Muchas librerias GNU están cubiertas por la Licencia Pública General GNU (GPL por sus siglas en inglés), pero no todas. Una librería que está cubierta por GPL GNU ordinaria es Readline, la cual implementa edición en la línea de comando. Hace un mes, me enteré de un programa no-libre que fue diseñado para utilizar Readline, y le dije al desarrollador que esto no estaba permitido. El pudo haber eliminado la edición de línea de comandos del programa, pero lo que hizo fue publicarlo de nuevo bajo GPL. Ahora es software libre.

Los programadores que escriben sus mejoras a GCC (o Emacs, o Bash, o Linux, o cualquier programa cubierto por la GPL) por lo general son contratados por compañías o universidades. Cuando el programador quiere enviar sus mejoras a la comunidad y ver su código en la próxima publicación, el jefe puede decir, "Alto ahí --su código nos pertenece! No queremos compartirlo; hemos decidido que convierta su versión mejorada en un producto de software privativo."

Aquí es donde la GPL GNU viene al rescate. El programador le muestra al jefe que este producto de software privativo podría ser una transgresión del derecho de copia, y el jefe se da cuenta que solo tiene dos opciones: publica el nuevo código como software libre, o no lo hace. Casi siempre el deja que el programador haga lo que quería en un principio, y el código sale en la próxima publicación.

La GPL GNU no es el Sr. Amable. Le dice "no" a algunas cosas que la gente a veces quiere hacer. Existen usuarios que dicen que esto es algo malo --que la GPL "excluye" algunos desarrolladores de software privativo quienes "necesitan ser traídos a la comunidad del software libre".

Pero nosotros no los estamos excluyendo de nuestra comunidad; ellos escogen no entrar. Su decisión de hacer software privativo es una decisión de quedarse fuera de nuestra comunidad. Estar en nuestra comunidad significa unirse en cooperación con nosotros; no podemos "traerlos a nuestra comunidad" si ellos no quieren unirse.

Lo que podemos hacer es ofrecerles un incentivo para que se unan. La GPL GNU está diseñada para hacer todo nuestro software existente un incentivo: "si usted hace su software libre, usted puede utilizar este código." Por supuesto, no ganará a todos siempre, pero ganará algunas veces.

El desarrollo de software privativo no contribuye a nuestra comunidad, pero sus desarrolladores a veces quieren información nuestra. Los usuarios de software libre pueden ofrecer a los desarrolladores de software libre una caricia para el ego --reconocimiento y gratitud-- pero puede ser muy tentador que una compañía le diga, "solo dejenos añadir su paquete en nuestro programa privativo, y su programa será utilizado por muchos miles de personas!" La tentación puede ser poderosa, pero a largo plazo estaremos mejor si nos resisitimos.

La tentación y la presión son más difícles de reconocer cuando vienen de manera indirecta, através de las organizaciones de software libre que han adoptado la política de proveer software privativo. El X Consortium (y su sucesor, el Open Group), ofrece un ejemplo: creados por compañías que hacían software privativo, ellos se han esforzado toda una década persuadiendio a los programadores a que no usen el copyleft. Ahora que el Open Group ha hecho X11R6.4 software no-libre, aquellos de nosotros quienes resistimos la presión estamos alegres de haberlo hecho.

[En Septiembre de 1998, varios meses después de que X11R6.4 fuera publicado con términos de distribución no-libre, el Open Group cambió su decisión y lo publicó de nuevo bajo la misma licencia de software libre no-copyleft utilizada para X11R6.3.  Gracias, Open Group --pero éste revés sucesivo no invalida las conclusiones que sacamos del hecho que añadir restricciones era posible.]

Pragmáticamente hablando, pensando en las más grandes metas a largo plazo fortalecerá su voluntad de resistir ésta presión. Si enfoca su mente en la libertad y la comunidad que se puede construir manteniéndose firme, usted conseguirá la fuerza para hacerlo. "Mantengase en pie por algo, o caerá por nada".

Y si los cínicos ridiculizan la libertad, ridiculizan la comunidad... si los "realistas cara-dura" dicen que las ganancias son el único ideal... solo ignórelos y utilice el copyleft de todos modos.


Otros textos para leer


Volver a la página principal del GNU.

Por favor envíar dudas y preguntas sobre la FSF y GNU a gnu@gnu.org. También existen otras maneras de contactar a la FSF.

Por favor enviar comentarios sobre estas páginas web a webmasters@www.gnu.org, enviar otras preguntas a gnu@gnu.org.

Todos los derechos reservados (C) 1997, 1998, 1999 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA

Copia y distribución literalmente traducida de este artículo entero, está permitida en cualquier medio, siempre y cuando se mantenga esta nota.

Actualizado: 27 de Noviembre de 1999 jonas.

Traductor: 28 de Diciembre de 1999 Carlos Maldonado (Venezuela) cmaldo@unet.edu.ve
Revisor(es): Holman Romero (Colombia) deifo@usa.net

Coordinador: Hugo Gayosso hgayosso@gnu.org