summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/es/thegnuproject.html
diff options
context:
space:
mode:
Diffstat (limited to 'talermerchantdemos/blog/articles/es/thegnuproject.html')
-rw-r--r--talermerchantdemos/blog/articles/es/thegnuproject.html1157
1 files changed, 1157 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/es/thegnuproject.html b/talermerchantdemos/blog/articles/es/thegnuproject.html
new file mode 100644
index 0000000..f89e200
--- /dev/null
+++ b/talermerchantdemos/blog/articles/es/thegnuproject.html
@@ -0,0 +1,1157 @@
+<!--#set var="ENGLISH_PAGE" value="/gnu/thegnuproject.en.html" -->
+
+<!--#include virtual="/server/header.es.html" -->
+<!-- Parent-Version: 1.86 -->
+
+<!-- This file is automatically generated by GNUnited Nations! -->
+<title>Acerca del proyecto GNU - Proyecto GNU - Free Software Foundation</title>
+<meta http-equiv="Keywords" content="GNU, Proyecto GNU, FSF, software libre, Fundación por el Software Libre,
+Free Software Foudation, Historia" />
+
+<!--#include virtual="/gnu/po/thegnuproject.translist" -->
+<!--#include virtual="/server/banner.es.html" -->
+<h2>El Proyecto GNU</h2>
+
+<p>
+por <a href="http://www.stallman.org/"><strong>Richard Stallman</strong></a></p>
+
+<blockquote>
+<p>
+Publicado por primera vez en el libro <cite>Open Sources</cite>. Richard
+Stallman <a href="/philosophy/open-source-misses-the-point.html"> nunca ha
+apoyado el «código abierto» (<cite>«open source»</cite>)</a>, pero
+contribuyó con este artículo para que en el libro no estuvieran totalmente
+ausentes las ideas del movimiento del software libre.
+</p>
+<p>
+Por qué ahora es más importante que nunca <a
+href="/philosophy/free-software-even-more-important.html"> insistir en que
+el software que usamos debe ser libre</a>.
+</p>
+</blockquote>
+
+<h3>La primera comunidad que comparte software</h3>
+<p>
+Cuando empecé a trabajar en el Laboratorio de Inteligencia Artificial del
+<abbr title="Massachusetts Institute of Technology">MIT</abbr> (Instituto de
+Tecnología de Massachusetts) en 1971, pasé a formar parte de una comunidad
+que llevaba muchos años compartiendo software. El hábito de compartir
+software no se limitaba a nuestra comunidad en particular; es una práctica
+tan antigua como los ordenadores mismos, así como compartir recetas de
+cocina es tan antiguo como cocinar. Nosotros, sin embargo, lo hacíamos en
+mayor medida.</p>
+<p>
+En el laboratorio de inteligencia artificial se usaba un sistema operativo
+de tiempo compartido llamado <abbr title="Incompatible Timesharing
+System">ITS</abbr> (sistema de tiempo compartido incompatible), que había
+sido diseñado y escrito en lenguaje ensamblador por los hackers empleados
+del laboratorio(1) para el <abbr title="Programmed Data
+Processor">PDP</abbr>-10, uno de los ordenadores más grandes de la época
+fabricado por la empresa <cite>Digital</cite>. Como miembro de esta
+comunidad y hacker empleado del laboratorio, mi trabajo consistía en mejorar
+dicho sistema.</p>
+<p>
+No llamábamos «software libre» a nuestro software porque ese término todavía
+no existía, pero era exactamente eso. Cuando alguien de otra universidad o
+de una empresa quería adaptar un programa para utilizarlo, se lo permitíamos
+de buen grado. Si se veía a alguien usar un programa que era desconocido e
+interesante, siempre se le podía pedir que nos mostrara el código fuente
+para poder leerlo, modificarlo o tomar partes del mismo para hacer otro
+programa.</p>
+<p>
+(1) El uso del término «hacker» para referirse a un «violador de la
+seguridad» es un malentendido provocado por los medios de comunicación
+masiva. Nosotros los hackers rechazamos ese significado y continuamos usando
+la palabra para designar a alguien a quien le gusta programar, alguien que
+disfruta de la inteligencia lúdica, o la combinación de ambos. Veáse mi
+artículo <a href="http://stallman.org/articles/on-hacking.html"
+style="font-style:italic;" >On Hacking</a> (en inglés).</p>
+
+<h3>El colapso de la comunidad</h3>
+<p>
+La situación cambió drásticamente a comienzos de los años ochenta cuando la
+empresa <cite>Digital</cite> interrumpió la fabricación de la serie
+PDP-10. Su arquitectura, elegante y poderosa en la década de los sesenta, no
+podía adaptarse de forma natural a los amplios espacios de direccionamiento
+ya factibles en los años ochenta. Por consiguiente, casi todos los programas
+que integraban el sistema ITS resultaban obsoletos.</p>
+<p>
+La comunidad hacker del laboratorio de inteligencia artificial ya se había
+desintegrado no mucho antes. En 1981 la compañía derivada
+<cite>Symbolics</cite> contrató a casi todos los hackers del laboratorio, y
+la comunidad diezmada no pudo sobrevivir. (En el libro <cite>Hackers</cite>,
+Steve Levy describe estos hechos, a la vez que ilustra el esplendor de esta
+comunidad en sus comienzos). Cuando el laboratorio compró un nuevo PDP-10 en
+1982, en lugar de utilizar el sistema de uso compartido de ITS, los
+administradores optaron por el sistema de <cite>Digital</cite>, que no era
+libre.</p>
+<p>
+Los modernos ordenadores de aquella época, como el VAX o el 68020, tenían
+sus propios sistemas operativos, aunque ninguno de ellos era software libre:
+había que firmar un acuerdo de no divulgación incluso para obtener una copia
+ejecutable.</p>
+<p>
+En otras palabras, el primer paso para poder utilizar un ordenador era
+prometer que no se ayudaría al prójimo. Se prohibía la existencia de una
+comunidad cooperativa, y los dueños del software privativo establecieron la
+siguiente norma: «si compartes con tu prójimo, eres un pirata. Si quieres
+algún cambio, tendrás que rogarnos que lo hagamos».</p>
+<p>
+La idea de que el sistema social del software privativo &mdash;un sistema
+que impide la práctica de compartir o modificar el software&mdash; es
+antisocial, contrario a la ética, sencillamente incorrecto, puede sorprender
+a algunos lectores. Pero ¿qué otra cosa podríamos decir de un sistema cuyo
+fundamento es la disgregación y la indefensión de las personas? Es probable
+que estos lectores den por supuesto el sistema social del software
+privativo, o que lo juzguen en función de los términos planteados por las
+empresas que desarrollan software privativo. Los distribuidores de software
+se han esforzado mucho y durante mucho tiempo para convencernos de que no
+existe otra manera de abordar el tema.</p>
+<p>
+Cuando los distribuidores de software hablan de «ejercer» sus «derechos» o
+de «acabar con la &ldquo;<a
+href="/philosophy/words-to-avoid.html#Piracy">piratería</a>&rdquo;», lo que
+<i>dicen</i> es en realidad secundario. El verdadero mensaje se esconde en
+suposiciones tácitas que ellos dan por sentadas, y pretenden que el público
+las acepte sin cuestionamientos. Vamos a examinarlas.</p>
+<p>
+Una de las suposiciones es que las empresas de software tienen el derecho
+natural e incuestionable a poseer el software, y por lo tanto a detentar el
+poder sobre todos los usuarios (si se tratara de un derecho natural, no
+podríamos objetar nada, independientemente del perjuicio que esto causara al
+público). Lo interesante es que la Constitución de los Estados Unidos de
+América y el derecho tradicional rechazan este punto de vista. El
+<cite>copyright</cite> no es un derecho natural sino un monopolio artificial
+impuesto por el Estado que limita el derecho natural de los usuarios a
+copiar.</p>
+<p>
+Otra suposición no declarada es que la importancia del software reside
+únicamente en el tipo de tareas que nos permite realizar, que a nosotros los
+usuarios de ordenadores no nos tiene que importar el tipo de sociedad que
+nos permite construir.</p>
+<p>
+Una tercera suposición es que no dispondríamos de software útil (o que nunca
+tendríamos un programa para realizar tal o cual tarea en particular) si no
+le otorgáramos a una empresa la facultad de ejercer poder sobre los usuarios
+del programa. Esto puede haber sonado plausible antes de que el movimiento
+del software libre demostrara que se puede desarrollar muchísimo software
+útil sin necesidad de ponerle cadenas.</p>
+<p>
+Si decidimos no aceptar tales suposiciones y analizamos estas cuestiones
+según criterios morales corrientes y el sentido común, poniendo a los
+usuarios en primer lugar, llegaremos a conclusiones muy distintas. Los
+usuarios de ordenadores han de ser libres de modificar los programas para
+ajustarlos a sus necesidades y de compartir el software, porque la
+cooperación con los demás constituye la base de la sociedad.</p>
+<p>
+No se dispone aquí del espacio necesario para explayarnos en el razonamiento
+que hay detrás de esta conclusión, por ese motivo solicito al lector que
+consulte las páginas <a
+href="/philosophy/why-free.html">http://www.gnu.org/philosophy/why-free.html</a>
+y <a
+href="/philosophy/free-software-even-more-important.html">http://www.gnu.org/philosophy/free-software-even-more-important.html</a>.
+</p>
+
+<h3>Una dura elección moral </h3>
+<p>
+Al desaparecer mi comunidad, me resultó imposible continuar como antes. Tuve
+que enfrentar una dura elección moral.</p>
+<p>
+La opción más fácil era unirme al mundo del software privativo firmando
+acuerdos de no divulgación y prometiendo no ayudar de mis compañeros
+<cite>hackers</cite>. Es muy probable que también hubiera tenido que
+programar software que se entregaría bajo acuerdos de no divulgación,
+incrementando así la presión para que otras personas también traicionaran a
+sus compañeros.</p>
+<p>
+Podría haber ganado dinero de esa manera, y tal vez me hubiese entretenido
+escribiendo código, pero sabía que al final de mi carrera echaría la vista
+atrás y vería los muros que habría construido para dividir a las personas,
+sentiría que había usado mi vida para hacer del mundo un lugar mucho peor.</p>
+<p>
+Ya había estado del lado de los que padecen los efectos de los acuerdos de
+no divulgación. Fue cuando alguien se negó a entregarnos, a mí y al
+laboratorio de inteligencia artificial del MIT, el código fuente del
+programa de control de nuestra impresora (la ausencia de ciertas
+funcionalidades en ese programa convertía el uso de la impresora en una
+experiencia sumamente frustrante). De modo que no podía engañarme a mí mismo
+pensando que los acuerdos de no divulgación fuesen inofensivos. Monté en
+cólera cuando aquel individuo se negó a compartir con nosotros; no podía
+cambiar mi posición y hacerle lo mismo a todos los demás.</p>
+<p>
+Otra posibilidad, sencilla pero desagradable, era abandonar el campo de la
+informática. De esa manera no se usarían mis habilidades para mal, pero aún
+así quedarían desperdiciadas. Yo no sería culpable de dividir y restringir a
+los usuarios de ordenadores, pero sucedería de todos modos.</p>
+<p>
+Así que comencé a meditar sobre la manera en que un programador podría hacer
+algo para bien. Me pregunté: «¿Existe algún programa o programas que yo
+pueda escribir para resucitar a nuestra comunidad?».</p>
+<p>
+La respuesta fue clara: lo primero que se necesitaba era un sistema
+operativo. Ese es el software crucial para comenzar a usar un ordenador. Con
+un sistema operativo se pueden hacer muchas cosas; sin él, el ordenador ni
+siquiera funciona. Con un sistema operativo libre, podríamos armar una nueva
+comunidad de hackers e invitar a todos a unirse. Y cualquiera podría
+utilizar un ordenador sin tener que conspirar desde el principio para privar
+de esta posibilidad a sus amigos.</p>
+<p>
+Como programador de sistemas operativos tenía las aptitudes necesarias para
+esa labor, y aunque no podía estar seguro de lo que lograría, me di cuenta
+de que había sido elegido para realizarla. Opté por hacer el sistema
+compatible con Unix para que fuera portable, y para facilitar el cambio a
+los usuarios de Unix. Siguiendo una tradición de los <cite>hackers</cite>,
+se eligió el nombre «GNU» como acrónimo recursivo de «GNU No es Unix»
+(<cite>GNU's Not Unix</cite>). Se pronuncia <a
+href="/gnu/pronunciation.html">en una sola sílaba: <cite>ñu</cite></a>.</p>
+<p>
+Un sistema operativo no implica solo un núcleo, apenas suficiente para
+ejecutar otros programas. En los años setenta, todo sistema operativo digno
+de llamarse así incluía programas tales como procesadores de comandos,
+ensambladores, compiladores, intérpretes, depuradores, editores de texto,
+gestores de correo y muchos otros. ITS los tenía, Multics los tenía, VMS los
+tenía, y Unix los tenía. El sistema operativo GNU también los incluiría.</p>
+<p>
+Más adelante escuché estas palabras, atribuídas a Hillel (1):</p>
+
+<blockquote><p>
+ Si yo no me ocupo de mí, ¿quién lo hará?<br />
+ Y si sólo me ocupo de mí, ¿qué soy?<br />
+ Y si no es ahora, ¿cuándo?
+</p></blockquote>
+<p>
+La decisión de comenzar el Proyecto GNU se basó en un sentimiento similar.</p>
+<p>
+(1) Como ateo, no sigo a ningún líder religioso, pero a veces admiro algo
+que ha dicho uno de ellos.</p>
+
+<h3>«<cite>Free</cite>» en su acepción de «libertad»</h3>
+<p>
+La expresión «<cite>free software</cite>» a veces se malinterpreta, no tiene
+nada que ver con el precio <a href="#TransNote1"
+id="TransNote1-rev"><sup>[1]</sup></a>. Se trata de la libertad. He aquí la
+definición de software libre.</p>
+
+<p>Un programa es software libre para usted como usuario particular, si le
+ofrece las siguientes libertades:</p>
+
+<ul>
+ <li>La libertad para ejecutar el programa como usted desee y para cualquier
+propósito.</li>
+
+ <li>La libertad para modificar el programa con el fin de adaptarlo a sus propias
+necesidades (para poder ejercer esta libertad en la práctica, usted debe
+tener acceso al código fuente; si no se dispone del código fuente, la tarea
+de incorporar cambios en un programa resulta extremadamente difícil).</li>
+
+ <li>La libertad para redistribuir copias, ya sea gratuitamente, ya sea a cambio
+de una suma de dinero.</li>
+
+ <li>La libertad para distribuir versiones modificadas del programa, de modo que
+la comunidad pueda beneficiarse de las mejoras introducidas.</li>
+</ul>
+<p>
+Dado que nos referimos a la libertad y no al precio, no existe contradicción
+alguna entre la venta de copias y el software libre. De hecho, la libertad
+para vender copias es crucial: las colecciones de software libre que se
+venden en CD-ROM son importantes para la comunidad, y es una buena manera de
+recaudar fondos para el desarrollo de software libre. Por lo tanto, si no se
+tiene la libertad para incluir un programa en dichas colecciones, ese
+programa no es software libre.</p>
+<p>
+A causa de la ambigüedad del calificativo «<cite>free</cite>», la gente ha
+estado buscando alternativas durante mucho tiempo, pero nadie ha encontrado
+un término más adecuado. La lengua inglesa es de las más ricas en lo que a
+palabras y matices se refiere, pero carece de un término simple e inequívoco
+para «libre» en su acepción de «libertad». La palabra cuyo significado más
+se aproxima es «<cite>unfettered</cite>» (sin cadenas). Otras alternativas
+como «<cite>liberated</cite>» (liberado), «<cite>freedom</cite>» (libertad)
+y «<cite>open</cite>» (abierto) no significan lo mismo o presentan otros
+inconvenientes.</p>
+
+<h3>Software de GNU y el sistema GNU</h3>
+<p>
+El desarrollo de un sistema completo es un proyecto de gran
+envergadura. Para hacerlo más viable, decidí adaptar y utilizar partes de
+software libre ya existentes siempre que fuera posible. Por ejemplo, desde
+el principio decidí usar TeX como principal compaginador de texto, y unos
+años más tarde decidí usar el sistema X Window en lugar de escribir otro
+sistema de ventanas para GNU.</p>
+<p>
+Debido a estas decisiones y a otras similares, el sistema GNU no es lo mismo
+que la colección de todo el software de GNU. El sistema GNU incluye
+programas que no son software de GNU, programas que fueron desarrollados por
+otras personas y otros proyectos para sus propios fines, pero que nosotros
+podemos utilizar porque son software libre.</p>
+
+<h3>El inicio del proyecto</h3>
+<p>
+En enero de 1984 renuncié a mi empleo en el MIT y comencé a escribir
+software para GNU. Fue necesario abandonar el MIT para que la institución no
+interfiriera con la distribución de GNU como software libre. De haber
+continuado como parte del personal, el MIT habría podido reclamar la
+titularidad sobre la obra e imponer sus propios términos de distribución, o
+incluso transformarla en un paquete de software privativo. No tenía ninguna
+intención de hacer un trabajo enorme solo para que después resultara inútil
+para lograr mi objetivo: crear una nueva comunidad para compartir software.</p>
+<p>
+No obstante, el Profesor Winston, por entonces director del laboratorio de
+inteligencia artificial del MIT, tuvo la amabilidad de invitarme a que
+continuase utilizando las instalaciones del laboratorio.</p>
+
+<h3>Los primeros pasos</h3>
+<p>
+Poco antes de comenzar el Proyecto GNU, oí hablar del <cite>Free University
+Compiler Kit</cite> (Kit compilador de la universidad libre), también
+conocido como VUCK (la palabra holandesa equivalente a «libre» comienza con
+una <i>V</i>). Se trataba de un compilador diseñado para manejar múltiples
+lenguajes, entre ellos C y Pascal, y compatible con ordenadores de objetivos
+múltiples. Le escribí al autor para pedirle el permiso de utilizarlo en GNU.</p>
+<p>
+Me respondió burlonamente, diciendo que la universidad era
+<cite>free</cite>, pero no el compilador <a href="#TransNote2"
+id="TransNote2-rev"><sup>[2]</sup></a>. Por lo tanto, decidí que mi primer
+programa para el proyecto GNU sería un compilador multilenguaje y
+multiplataforma.</p>
+<p>
+Para evitar tener que escribir todo el compilador desde cero, obtuve el
+código fuente del compilador Pastel, que era multiplataforma y había sido
+desarrollado en el <cite>Lawrence Livermore Lab</cite>. El compilador
+soportaba y estaba escrito en una versión ampliada de Pascal, diseñada para
+usarse como lenguaje de programación de sistemas. Le agregué una interfaz
+para C y comencé a adaptarlo al ordenador Motorola 68000, pero tuve que
+abandonar la idea al descubrir que el compilador necesitaba demasiados
+megabytes de espacio, mientras el sistema Unix 68000 admitía solo 64k.</p>
+<p>
+Noté que el compilador Pastel analizaba por completo el fichero de entrada
+transformándolo en un árbol sintáctico, después convertía todo el árbol en
+una cadena de «instrucciones» generando luego todo el fichero de salida, sin
+liberar en ningún momento el espacio ocupado. Así, concluí que tendría que
+escribir un nuevo compilador desde cero. Se trata del compilador que se
+conoce ahora como <abbr title="GNU Compiler Collection">GCC</abbr>; no hay
+nada del compilador Pastel en él, pero logré adaptar y usar la interfaz para
+C que había escrito. Pero eso sucedió años más tarde, antes trabajé en el
+desarrollo de Emacs de GNU.</p>
+
+<h3>Emacs de GNU</h3>
+<p>
+Comencé a trabajar en Emacs de GNU en septiembre de 1984, y a principios de
+1985 ya comenzaba a ser utilizable. Esto me permitió empezar a utilizar
+sistemas Unix para las tareas de edición. Como nunca me interesó aprender a
+usar vi ni ed, hasta entonces había editado en otro tipo de máquinas.</p>
+<p>
+En aquel momento ya había personas que comenzaban a mostrarse interesadas en
+usar Emacs de GNU, lo que planteó la cuestión de cómo distribuirlo. Por
+supuesto, lo puse en el servidor anónimo ftp del ordenador del MIT que yo
+usaba (a raíz de ello, ese ordenador &mdash;el prep.ai.mit.edu&mdash; se
+convirtió en el principal sitio de distribución ftp de GNU, y cuando fue
+retirado unos años después, transferimos el nombre a nuestro nuevo servidor
+ftp). Pero en aquella época muchas de las personas interesadas no tenían
+acceso a Internet y por lo tanto no podían obtener copias por ese
+medio. ¿Qué decirles?</p>
+<p>
+Podría haberles dicho: «Busca un amigo que esté en la red y que te haga una
+copia». O podría haber hecho lo mismo que hiciera con el Emacs original para
+PDP-10, decirles: «Envíame una cinta y un sobre prefranqueado y con tu
+dirección, te lo devolveré por correo con una copia de Emacs». Pero como no
+tenía trabajo y estaba buscando la manera de ganarme la vida con el software
+libre, anuncié que enviaría la cinta a quien me la pidiera a cambio de
+ciento cincuenta dólares. Fue así que inicié una empresa de distribución de
+software libre, precursora de las que hoy en día distribuyen enteros
+sistemas GNU/Linux.</p>
+
+<h3>¿Un programa es libre para cualquier usuario?</h3>
+<p>
+Si un programa es software libre cuando sale de las manos del autor, esto no
+significa necesariamente que seguirá siendo software libre para todos los
+que posean una copia del mismo. Por ejemplo, el <a
+href="/philosophy/categories.html#PublicDomainSoftware">software de dominio
+público</a> (software que no está sujeto a copyright) es software libre,
+pero cualquiera puede tomarlo y hacer a partir de él una versión modificada
+privativa. Lo mismo ocurre con muchos programas libres que están sujetos a
+copyright pero se distribuyen bajo simples licencias permisivas que
+autorizan el desarrollo de versiones modificadas privativas.</p>
+<p>
+El ejemplo paradigmático de este problema es el sistema de ventanas
+X. Programado en el MIT y publicado como software libre con una licencia
+permisiva, fue rápidamente adoptado por varias empresas informáticas que
+añadieron X a sus sistemas Unix privativos &mdash;en formato binario
+únicamente&mdash; y lo pusieron bajo el mismo acuerdo de no
+divulgación. Así, estas copias de X pasaron a ser software privativo, tal
+como lo era Unix.</p>
+<p>
+Los desarrolladores del sistema de ventanas X no consideraban que esto fuese
+un problema, esperaban y buscaban que sucediese. Su meta no era la libertad
+sino solo el «éxito», medido en función del número de usuarios. No les
+preocupaba si esos usuarios tenían libertad o no, solo que fueran numerosos.</p>
+<p>
+Esto condujo a una situación paradójica: dos maneras distintas de medir el
+grado de libertad daban por resultado dos respuestas distintas a la pregunta
+«¿Es libre este programa?». Si se juzgaba en base a la libertad que
+otorgaban las cláusulas de distribución de la versión publicada por el MIT,
+se podía decir que X era software libre. Pero si se medía la libertad del
+usuario medio de X, se podía concluir que X era software privativo. La
+mayoría de los usuarios de X utilizaba las versiones privativas que venían
+con los sistemas Unix, no la versión libre.</p>
+
+<h3>El copyleft y la GPL de GNU</h3>
+<p>
+El objetivo de GNU era otorgar libertad a los usuarios, no simplemente
+alcanzar la popularidad. Para ello teníamos que aplicar términos de
+distribución que impidieran que el software de GNU pudiera ser convertido en
+software privativo. El método que empleamos se denomina «copyleft» (1).</p>
+<p>
+El copyleft hace uso de la ley de copyright, pero le da la vuelta de modo
+que sirva para una finalidad opuesta a la habitual: en lugar de ser un medio
+para restringir un programa, se transforma en un medio para preservarlo como
+software libre.</p>
+<p>
+La idea central del copyleft es que le otorgamos a todo el mundo el permiso
+para ejecutar el programa, copiarlo, modificarlo y redistribuir versiones
+modificadas; pero no le damos permiso para añadirle restricciones por su
+cuenta. De esta manera, las libertades cruciales que definen el «software
+libre» quedan garantizadas para todo aquel que posea una copia; estas
+libertades se transforman en derechos inalienables.</p>
+<p>
+Para que el copyleft sea efectivo, las versiones modificadas también deben
+ser libres. Esto garantiza que toda obra basada en la nuestra quedará
+disponible para la comunidad si llegara a publicarse. Cuando los
+programadores que trabajan como empleados en el campo de la programación se
+ofrecen como voluntarios para mejorar software de GNU, es el copyleft lo que
+impide que sus empleadores les digan: «No puedes compartir esos cambios
+porque los queremos usar para crear nuestra versión privativa del programa».</p>
+<p>
+La exigencia de que los cambios deben ser libres es esencial para preservar
+la libertad de todos los usuarios del programa. Las empresas que
+privatizaron el sistema de ventanas X, generalmente realizaron algunos
+cambios para adaptarlo a sus sistemas y a su hardware. Estos cambios fueron
+pequeños comparados con la envergadura de X, pero no triviales. Si hacer
+cambios fuera una excusa para denegar libertad a los usuarios, cualquiera
+podría fácilmente aprovecharse de esa excusa.</p>
+<p>
+La combinación de un programa libre con código que no es libre plantea un
+problema similar. Inevitablemente, tal combinación no será libre;
+cualesquiera sean las libertades que le falten a la parte que no es libre,
+le faltarán también al todo. Permitir tales combinaciones abriría un agujero
+lo suficientemente grande como para hundir un barco. Por consiguiente, una
+función crucial del copyleft es tapar ese agujero: cualquier cosa que se
+añada o se combine con un programa que esté cubierto por el copyleft, debe
+ser adecuada para que la versión combinada total también sea libre y también
+esté bajo copyleft.</p>
+<p>
+La implementación específica de copyleft que usamos para la mayoría del
+software de GNU es la Licencia Pública General de GNU (<cite>GNU General
+Public License</cite>) o GPL de GNU, para abreviar. Tenemos otros tipos de
+copyleft para circunstancias específicas. Los manuales de GNU también están
+bajo copyleft, pero es un copyleft mucho más simple, porque la complejidad
+de la GPL de GNU no es necesaria para los manuales (2).</p>
+<p>
+(1) En 1984 o 1985, Don Hopkins (un compañero muy imaginativo) me envío una
+carta. En el sobre había escrito varios dichos graciosos, entre ellos el
+siguiente: «Copyleft &mdash; todos los derechos reversados»<a
+href="#TransNote3" id="TransNote3-rev"><sup>[3]</sup></a>. Utilicé la
+palabra «copyleft» para denominar el concepto de distribución que estaba
+desarrollando en aquella época.</p>
+
+<p>
+(2) Ahora para la documentación usamos la <a
+href="/licenses/fdl.html">Licencia de documentación libre de GNU (FDL de
+GNU)</a>.</p>
+
+<h3>La <cite>Free Software Foundation</cite></h3>
+
+<p>A medida que crecía el interés por el uso de Emacs, otras personas se
+involucraron en el proyecto GNU, y decidimos que había llegado el momento de
+volver a conseguir fondos. Con ese objetivo, en 1985 creamos la <abbr
+title="Free Software Foundation">FSF</abbr>, una organización sin ánimo de
+lucro exenta de impuestos que se dedica al desarrollo de software libre. La
+FSF también se hizo cargo de la distribución de Emacs, y más adelante
+comenzó a añadir en las cintas otros programas libres de GNU (además de
+otros que no eran de GNU) y a vender manuales libres.</p>
+
+<p>La mayor parte de los ingresos de la FSF provenía de la venta de copias de
+software libre y otros servicios relacionados: CD-ROM con código fuente,
+CD-ROM con los binarios, elegantes manuales impresos (todos con la libertad
+para redistribuirlos y modificarlos) y distribuciones de lujo con toda la
+colección de software lista para usar en la plataforma preferida del
+cliente). Hoy en día la FSF continúa con la <a
+href="http://shop.fsf.org/">venta de manuales y otros artículos</a>, pero
+obtiene la mayor parte de su financiación de las cuotas de los socios. Puede
+unirse a la FSF en <a href="http://fsf.org/join">fsf.org</a>.</p>
+
+<p>Los empleados de la <cite>Free Software Foundation</cite> han escrito y se
+han encargado del mantenimiento de una serie de paquetes de GNU. Dos
+ejemplos significativos son la biblioteca C y la consola. Todo programa que
+se ejecuta en un sistema GNU/Linux utiliza la biblioteca C de GNU para
+comunicarse con Linux, el núcleo; fue programada por Roland McGrath, un
+miembro del personal de la <cite>Free Software Foundation</cite>. La consola
+que se usa en la mayoría de los sistemas GNU/Linux se denomina «BASH»,
+acrónimo de <cite>Bourne Again SHell</cite> (1), y fue desarrollada por
+Brian Fox, también empleado de la FSF.</p>
+
+<p>Financiamos el desarrollo de esos programas porque el Proyecto GNU no se
+limitaba únicamente a proveer herramientas o un entorno de
+desarrollo. Nuestra meta era construir un sistema operativo completo, y
+necesitábamos esos programas para alcanzarla.</p>
+
+<p>(1) «<cite>Bourne Again Shell</cite>» es un juego de palabras con
+«<cite>Bourne Shell</cite>», el nombre de la consola comúnmente utilizada en
+Unix.</p>
+
+<h3>Software libre y servicios relacionados</h3>
+
+<p>La filosofía del software libre rechaza una práctica empresarial específica
+y ampliamente difundida, pero no está contra el comercio. Cuando las
+empresas respetan la libertad de los usuarios, les deseamos mucho éxito.</p>
+
+<p>La venta de copias de Emacs es un ejemplo de actividad comercial con
+software libre. Cuando la FSF me sustituyó en esa actividad, tuve que buscar
+otro medio de vida. Lo encontré en la venta de servicios relacionados con el
+software libre que yo había programado. Esto incluía la enseñanza de temas
+tales como la programación de Emacs de GNU y la personalización de GCC, como
+así también el desarrollo de software, sobre todo la migración de GCC a
+nuevas plataformas.</p>
+
+<p>Hoy en día existen corporaciones que ponen en práctica cada uno de esos
+tipos de actividad comercial con software libre. Algunas distribuyen
+colecciones de software libre en CD-ROM; otras ofrecen asistencia técnica a
+varios niveles, desde responder a las preguntas de los usuarios y corregir
+errores en los programas, hasta añadir nuevas funcionalidades de cierta
+relevancia. Incluso vemos que están empezando a surgir empresas cuya
+actividad consiste en el lanzamiento de nuevos productos de software libre.</p>
+
+<p>Pero tenga cuidado: hay empresas que se asocian con el término «código
+abierto» («<cite>open source</cite>») cuyo negocio se basa en realidad en
+software que no es libre que funciona con software libre. No son empresas de
+software libre sino compañías de software privativo cuyos productos inducen
+a los usuarios a abandonar su libertad. Etiquetan esos productos como
+«paquetes con valor añadido», lo que demuestra cuáles son los valores que
+tales empresas desearían que adoptáramos: conveniencia antes que
+libertad. Si valoramos más la libertad, deberíamos denominarlos «paquetes
+con libertad sustraída».</p>
+
+<h3>Objetivos técnicos</h3>
+
+<p>El principal objetivo de GNU es ser software libre. Aun en el caso de que
+GNU no tuviese ventajas técnicas sobre Unix, tendría una ventaja social,
+permitir la colaboración entre los usuarios, y otra ventaja ética, respetar
+la libertad de los usuarios.</p>
+
+<p>Pero resultaba natural aplicar a nuestro trabajo los estándares conocidos de
+buenas prácticas; por ejemplo, la asignación dinámica de las estructuras de
+datos para evitar los límites de tamaño fijo arbitrarios y el empleo de
+todos los códigos de ocho bits posibles, cuando fuera apropiado.</p>
+
+<p>Además, rechazamos el enfoque de Unix sobre el uso de una memoria reducida,
+y así decidimos no dar soporte para máquinas de 16 bits (estaba claro que
+las máquinas de 32 bits serían la norma para cuando el sistema GNU estuviese
+terminado) y no hacer ningún esfuerzo para reducir el uso de memoria a menos
+que excediera un megabyte. En los programas en los que no fuera fundamental
+manejar ficheros muy grandes, animamos a los programadores a leer el fichero
+de entrada completo en el <cite>core</cite> y luego explorar su contenido
+sin tener que preocuparse del I/O.</p>
+
+<p>Estas decisiones hicieron posible que muchos programas de GNU superaran a
+los análogos de Unix en confiabilidad y velocidad.</p>
+
+<h3>Donación de ordenadores</h3>
+
+<p>A medida que crecía la reputación del Proyecto GNU, la gente comenzó a
+ofrecer al proyecto la donación de máquinas con Unix instalado. Fueron muy
+útiles, porque la manera más fácil de desarrollar componentes de GNU era
+hacerlo en un sistema Unix, reemplazando los componentes del sistema uno a
+uno. Pero esto trajo aparejado el dilema ético de si era correcto para
+nosotros poseer aunque fuera tan solo una copia de Unix.</p>
+
+<p>Unix era &mdash;y es&mdash; software privativo, y según la filosofía del
+Proyecto GNU no debíamos usarlo. Pero aplicando el mismo razonamiento que
+lleva a justificar la violencia en defensa propia, concluí que era
+igualmente legítimo usar un paquete privativo cuando ello resultara crucial
+para poder desarrollar un reemplazo libre que ayudara a los demás a dejar de
+usar el paquete privativo.</p>
+
+<p>Sin embargo, aun si se trataba de un mal justificable, no dejaba de ser un
+mal. En la actualidad ya no tenemos más copias de Unix porque las hemos
+reemplazado por sistemas operativos libres. Cuando no hemos podido
+reemplazar el sistema operativo de una máquina por uno libre, hemos
+reemplazado la máquina completa.</p>
+
+<h3>La lista de tareas de GNU</h3>
+
+<p>Mientras se proseguía con las labores en el Proyecto GNU, se desarrollaron o
+se encontraron componentes para el sistema en número cada vez mayor, por lo
+que eventualmente nos pareció útil elaborar una lista de las piezas que aún
+faltaban, que usamos luego para reclutar programadores que las
+desarrollaran. Esta es la lista que posteriormente se llamó «lista de tareas
+de GNU». Además de los componentes Unix faltantes, añadimos a la lista otros
+proyectos de software y documentación útiles que, en nuestra opinión, debía
+tener todo sistema verdaderamente completo.</p>
+
+<p>En la actualidad (1) ya no queda casi ningún componente Unix en la lista de
+tareas GNU; se concluyeron todas, excepto unas pocas que no son
+esenciales. Pero la lista contiene muchos proyectos que podrían considerarse
+«aplicaciones». Cualquier programa que despierte el interés de las personas
+&mdash;más allá del reducido grupo de usuarios de un cierto tipo&mdash; será
+algo útil para añadir a un sistema operativo.</p>
+
+<p>Incluso hay juegos en la lista de tareas y han estado allí desde el
+principio. Unix incluía juegos, así que naturalmente también tenían que
+estar en GNU. Los juegos no presentaban ningún problema de compatibilidad,
+así que no seguimos el modelo de juegos que tenía Unix. Decidimos en cambio
+incluir en la lista una gama de diferentes tipos de juegos que pueden
+resultar agradables para los usuarios.</p>
+
+<p>(1) El texto se escribió en 1998. En 2009 ya no tenemos una larga lista de
+tareas. La comunidad programa software libre con tanta rapidez que incluso
+no podemos seguir la pista de todos. En cambio tenemos una lista bastante
+más corta de <i>proyectos altamente prioritarios</i> y queremos animar a la
+gente a trabajar en ellos.</p>
+
+<h3>La GPL de GNU para bibliotecas</h3>
+
+<p>La biblioteca C de GNU usa un tipo especial de copyleft denominado <cite>GNU
+Library General Public License</cite> (1) (Licencia Pública General de GNU
+para Bibliotecas) que autoriza el enlace de software privativo con la
+biblioteca. ¿Por qué hacemos esta excepción?</p>
+
+<p>No es una cuestión de principios; no existe ningún principio que establezca
+el derecho de incluir nuestro código en productos de software privativo
+(¿por qué contribuir a un proyecto que se rehúsa a compartir con
+nosotros?). El uso de la LGPL para la biblioteca C, o para cualquier otra
+biblioteca, es más bien una cuestión de estrategia.</p>
+
+<p>La biblioteca C tiene una función genérica; todo sistema o compilador
+privativo incluye una biblioteca C. Por lo tanto, poner nuestra biblioteca a
+disposición únicamente para el software libre, no habría significado ninguna
+ventaja para este, pero sí hubiera desalentado el uso de nuestra biblioteca.</p>
+
+<p>Existe un sistema que es una excepción a lo anterior: en un sistema GNU
+(incluidos los sistemas GNU/Linux), la biblioteca C de GNU es la única
+biblioteca C. Por lo que los términos de distribución de la biblioteca C de
+GNU determinan si es posible o no compilar un programa privativo para el
+sistema GNU. No hay ninguna razón ética para autorizar la incorporación de
+aplicaciones privativas en el sistema GNU, pero estratégicamente pareciera
+que denegar dicha autorización desalentaría el uso del sistema GNU en lugar
+de incentivar el desarrollo de aplicaciones libres. Por esta razón, usar la
+GPL para bibliotecas (<cite>Library GPL</cite>) es una buena estrategia para
+la biblioteca C.</p>
+
+<p>Para otras bibliotecas, es necesario evaluar caso por caso la estrategia a
+adoptar. Cuando una biblioteca desempeña una función especial que puede
+facilitar el desarrollo de cierto tipo de programas, publicarla bajo la GPL
+&mdash;limitándola únicamente a programas libres&mdash; es una manera de
+ayudar a otros programadores de software libre, ya que se les otorga una
+ventaja con respecto al software privativo.</p>
+
+<p>Consideremos por ejemplo la biblioteca Readline de GNU, desarrollada para
+editar los comandos para BASH. Readline se publica bajo la GPL de GNU
+ordinaria, no bajo la GPL para bibliotecas. Es probable que de esta manera
+se reduzca el uso de Readline, pero ello no supone una pérdida para
+nosotros. Por otro lado, al menos una aplicación útil ha sido transformada
+en software libre específicamente para poder usar Readline, y esta es una
+conquista importante para la comunidad.</p>
+
+<p>Los desarrolladores de software privativo tienen las ventajas que
+proporciona el dinero; quienes desarrollan software libre tienen que generar
+ventajas entre sí. Tengo la esperanza de que algún día podremos contar con
+una amplia colección de bibliotecas cubiertas por la GPL que no tengan
+equivalentes como software privativo, bibliotecas que provean módulos útiles
+para constructir nuevos programas libres y que faciliten el desarrollo de
+software libre en el futuro.</p>
+
+<p>(1) Esta licencia ahora se llama <cite>GNU Lesser General Public
+License</cite> (Licencia Pública General Reducida de GNU), para evitar
+transmitir la idea de que se debe usar para todas las bibliotecas. Para más
+información, véase <a href="/philosophy/why-not-lgpl.html">Por qué en su
+próxima biblioteca no debería utilizar la GPL Reducida</a>.</p>
+
+<h3>¿Una necesidad personal?</h3>
+<p>
+Eric Raymond dice: «Todo buen trabajo de software comienza con el deseo del
+programador de satisfacer una necesidad personal». Puede que a veces sea
+cierto, pero muchos de los componentes esenciales del software de GNU se
+programaron con el fin de obtener un sistema operativo libre
+completo. Nacieron como resultado de una visión y de un plan, no a causa de
+un impulso.</p>
+<p>
+Por ejemplo, desarrollamos la biblioteca C de GNU porque un sistema similar
+a Unix necesita una biblioteca C, BASH porque un sistema de tipo Unix
+necesita una consola, y el tar de GNU porque un sistema similar a Unix
+necesita un programa tar. Lo mismo se aplica a mis propios programas, el
+compilador C de GNU, Emacs de GNU, GDB y Make de GNU.</p>
+<p>
+Algunos de los programas de GNU se desarrollaron para afrontar amenazas
+específicas a nuestra libertad. Por esta razón desarrollamos gzip para
+reemplazar Compress, programa que nuestra comunidad había perdido a causa de
+las patentes de <abbr title="Lempel-Ziv-Welch">LZW</abbr>. Buscamos personas
+para programar LessTif y, más recientemente, iniciamos <abbr title="GNU
+Network Object Model Environment">GNOME</abbr> y Harmony, para abordar los
+problemas que plantean ciertas bibliotecas privativas (véase más
+adelante). Estamos desarrollando Privacy Guard de GNU para reemplazar
+software popular de cifrado que no es libre, porque los usuarios no deben
+verse obligados a elegir entre privacidad y libertad.</p>
+<p>
+Por supuesto, la gente que escribía estos programas se interesó en el
+trabajo, y varias personas añadieron muchas funcionalidades para satisfacer
+sus propias necesidades e intereses. Pero ese no es el motivo por el cual
+existe el programa.</p>
+
+<h3>Situaciones inesperadas</h3>
+<p>
+Al comienzo del Proyecto GNU, mi idea era que desarrollaríamos el sistema
+GNU completo y luego lo publicaríamos como un todo. Pero no fue así.</p>
+<p>
+Debido a que cada uno de los componentes del sistema GNU se implementó en un
+sistema Unix, todos podían ejecutarse en sistemas Unix mucho antes de que el
+sistema GNU hubiera sido completado. Algunos de esos programas adquirieron
+popularidad, y los usuarios comenzaron a extenderlos y portarlos a las
+distintas versiones incompatibles de Unix y en ciertos casos también a otros
+sistemas.</p>
+<p>
+Como resultado de ese proceso, los programas adquirieron mayor potencia y
+atrajeron más fondos y colaboradores al Proyecto GNU. Pero probablemente eso
+también demoró por varios años la conclusión de un sistema mínimo funcional,
+dado que el tiempo de los desarrolladores de GNU se asignaba al
+mantenimiento de esas migraciones y a añadir funcionalidades a los
+componentes ya existentes en lugar de continuar, uno tras otro, con el
+desarrollo de los componentes que faltaban.</p>
+
+<h3>El Hurd de GNU</h3>
+<p>
+En 1990 el sistema GNU estaba casi terminado, el único componente importante
+que faltaba era el núcleo. Habíamos decidido implementar nuestro núcleo como
+una colección de procesos de servidor que se ejecutarían sobre Mach. Mach
+es un micronúcleo desarrollado en la <cite>Carnegie Mellon University</cite>
+y luego en la Universidad de Utah. El Hurd de GNU es una colección de
+servidores (por ejemplo, una «manada de ñus») que se ejecutan sobre Mach y
+se ocupan de las diversas tareas como en el núcleo Unix. El inicio del
+desarrollo se retrasó a la espera de que Mach se publicara como software
+libre, tal como se había prometido.</p>
+<p>
+Una de las razones por la que optamos por este diseño fue para evitar lo
+que parecía ser la parte más dura del trabajo: depurar un núcleo sin contar
+con un depurador de código fuente para hacerlo. Esta parte del trabajo ya
+había sido realizada en Mach, y esperábamos depurar los servidores de Hurd
+como programas de usuario, con GDB. Pero llevó mucho tiempo lograrlo, y los
+servidores multihilo que se intercambian mensajes resultaron ser muy
+difíciles de depurar. Conseguir que Hurd funcione sólidamente se ha
+demorado muchos años.</p>
+
+<h3>Alix</h3>
+<p>
+El núcleo de GNU originalmente no iba a llamarse Hurd. Su nombre original
+era Alix, por alusión a mi novia de aquel entonces. Ella era administradora
+de sistemas Unix y había hecho notar que su nombre seguía el esquema de
+nomenclatura que era común en las versiones de los sistemas Unix. A modo de
+broma, le dijo a sus amigos «alguien debería darle mi nombre a un
+núcleo». Yo no dije nada, pero decidí sorprenderla con un núcleo llamado
+Alix.</p>
+<p>
+El nombre no se conservó. Michael Bushnell (actualmente Thomas), el
+programador principal del núcleo, prefirió el nombre Hurd y redefinió Alix
+para referirse a cierta parte del núcleo, la parte que captura las llamadas
+del sistema y las administra mediante el envío de mensajes a los servidores
+de Hurd.</p>
+<p>
+Más adelante Alix y yo nos separamos y ella cambió su nombre.
+Independientemente de eso, el diseño de Hurd se modificó para que los
+mensajes a los servidores fueran enviados directamente por la biblioteca C,
+por lo que el componente Alix desapareció del diseño.</p>
+<p>
+Pero antes de que sucediera todo esto, un amigo de ella encontró el nombre
+Alix en el código fuente de Hurd, y se lo comentó. Así que al fin de cuentas
+Alix pudo ver su nombre en un núcleo.</p>
+
+<h3>Linux y GNU/Linux</h3>
+<p>
+El Hurd de GNU no está listo para el uso en producción, y no sabemos si
+alguna vez lo estará. El diseño basado en la capacidad
+[<cite>capability-based design</cite>] presenta dificultadades como
+consecuencia directa de la flexibilidad del diseño, y no está claro que
+existan soluciones.</p>
+
+<p>
+Afortunadamente, disponemos de otro núcleo. En 1991 Linus Torvalds programó
+un núcleo compatible con Unix y lo denominó Linux. Al principio era
+privativo, pero en 1992 lo convirtió en software libre; la combinación de
+Linux con el sistema GNU &mdash;que aún no estaba completamente
+terminado&mdash; dió como resultado un sistema operativo libre completo
+(claramente la combinación en sí misma supuso la realización de un trabajo
+fundamental). Es debido a Linux que en la actualidad podemos ejecutar una
+versión del sistema GNU.</p>
+<p>
+A esta versión del sistema la llamamos <a
+href="/gnu/linux-and-gnu.html">GNU/Linux</a> para manifestar el hecho de que
+el sistema está compuesto por una combinación del sistema GNU con el kernel
+Linux. Recomendamos no adoptar la costumbre de llamar «Linux» al sistema
+completo, ya que eso implica atribuir nuestro trabajo a otra persona. Tenga
+a bien <a href="/gnu/gnu-linux-faq.html">mencionarnos equitativamente</a>.</p>
+
+<h3>Desafíos en el futuro</h3>
+<p>
+Hemos demostrado nuestra capacidad para desarrollar un amplio espectro de
+software libre. Esto no significa que somos invencibles o que nada nos puede
+detener. Varios desafíos hacen que el futuro del software libre sea
+incierto. Afrontarlos requerirá esfuerzos firmes y mucha resistencia, a
+veces durante años. Se necesita mucha determinación, como la que demuestran
+quienes valoran su libertad y no dejan que nadie se las quite.</p>
+<p>
+En las cuatro secciones que siguen se analizan dichos desafíos.</p>
+
+<h3>Hardware secreto</h3>
+<p>
+Los fabricantes de hardware tienden cada vez más a mantener secretas las
+especificaciones de sus productos. Esto dificulta el desarrollo de
+controladores libres para que Linux y XFree86 puedan reconocer el hardware
+nuevo. Hoy disponemos de sistemas libres completos, pero mañana no los
+tendremos si no son compatibles con los ordenadores del futuro.</p>
+<p>
+Existen dos maneras de abordar este problema. Los programadores pueden
+recurrir a la ingeniería inversa para analizar de qué manera se puede
+soportar el hardware. El resto de nosotros podemos optar por usar hardware
+que sea compatible con el software libre. A medida que aumente el número de
+usuarios de software libre, mantener las especificaciones en secreto se
+transformará en una política contraproducente.</p>
+<p>
+La ingeniería inversa implica un trabajo enorme, ¿tendremos programadores
+con la suficiente determinación para realizarla? Sí, siempre que hayamos
+logrado construir un fuerte sentimiento de que el software libre es una
+cuestión de principios, y de que los controladores que no son libres son
+intolerables. ¿Seremos suficientes los que estaremos dispuestos a invertir
+dinero extra, o incluso algo de tiempo extra, para que podamos usar
+controladores libres? Sí, si se difunde la determinación de obtener nuestra
+libertad.</p>
+<p>
+(Aclaración de 2008: esta cuestión también se aplica al BIOS. Existe un BIOS
+libre llamado <a href="http://www.libreboot.org/">LibreBoot</a>, una
+distribución de coreboot; el problema es conseguir las especificaciones de
+las máquinas para que LibreBoot pueda reconocerlas sin tener que recurrir a
+paquetes binarios que no son libres).</p>
+
+<h3>Bibliotecas que no son libres</h3>
+<p>
+Una biblioteca que no es libre y que funciona sobre sistemas operativos
+libres actúa como una trampa para los programadores de software libre. Las
+características atractivas de la biblioteca son el cebo: si usted usa la
+biblioteca, cae en la trampa, porque su programa no puede integrarse de
+manera útil a un sistema operativo libre (estrictamente hablando, podríamos
+incluir su programa, pero no <em>funcionará</em> sin esa biblioteca). Peor
+aún, si se populariza un programa que utiliza una biblioteca privativa,
+puede hacer caer en la trampa a otros programadores incautos.</p>
+<p>
+La primera vez que se presentó este problema fue con el kit de herramientas
+Motif, allá en los años ochenta. Aunque en aquel entonces no había todavía
+sistemas operativos libres, el problema que Motif iba a causarles más
+adelante estaba claro. El Proyecto GNU respondió de dos maneras: solicitando
+a los proyectos individuales de software libre que admitiesen tanto los
+widgets del kit libre de herramientas de X como Motif, y solicitando el
+desarrollo de un reemplazo libre para Motif. La tarea tomó muchos años. Solo
+en 1997 LessTif, desarrollado por los <cite>Hungry Programmers</cite>,
+adquirió la potencia necesaria como para admitir la mayoría de las
+aplicaciones Motif.</p>
+<p>
+Entre 1996 y 1998, otra biblioteca del kit de herramientas <abbr
+title="Graphical User Interface">GUI</abbr> que no era libre, denominada Qt,
+se usó en una amplia colección de software libre: el escritorio <abbr
+title="K Desktop Environment">KDE</abbr>.</p>
+<p>
+Los sistemas libres GNU/Linux no podían usar KDE porque no podíamos
+incorporar la biblioteca. No obstante, algunos distribuidores comerciales de
+sistemas GNU/Linux que no eran tan estrictos con respecto a la inclusión de
+software libre, añadieron KDE a sus sistemas, obteniendo así un sistema con
+más funcionalidades pero con menos libertad. El grupo de KDE instaba
+activamente a los programadores a usar Qt, mientras millones de nuevos
+«usuarios de Linux» ni siquiera habían oído hablar del problema. La
+situación era desalentadora.</p>
+<p>
+La comunidad del software libre abordó este problema de dos maneras: GNOME y
+Harmony.</p>
+<p>
+GNOME, el <cite>GNU Network Object Model Environment</cite>, es el proyecto
+de escritorio de GNU. El proyecto fue inciado en 1997 por Miguel de Icaza y
+se desarrolló con el apoyo de <cite>Red Hat Software</cite> con el objetivo
+de proporcionar prestaciones similares, pero usando software libre
+exclusivamente. Tiene también ventajas técnicas, tales como admitir una
+variedad de lenguajes, no solo C++. Pero su propósito principal era la
+libertad: evitar el uso de cualquier software que no fuese libre.</p>
+<p>
+Harmony es una biblioteca sustitutiva compatible, diseñada para poder
+ejecutar el software KDE sin usar Qt.</p>
+<p>
+En noviembre de 1998, los desarrolladores de Qt anunciaron un cambio de
+licencia que, cuando se llevase a cabo, convertiría Qt en software libre. No
+puedo afirmarlo con certeza, pero pienso que en parte esto de se debió a la
+firme respuesta de la comunidad frente al problema que presentaba Qt cuando
+no era libre (la nueva licencia es inadecuada e injusta, por lo que sigue
+siendo preferible evitar el uso de Qt).</p>
+<p>
+(Nota posterior: en Septiembre de 2000 Qt se publicó bajo la licencia GPL
+de GNU, lo que esencialmente solucionó este problema).</p>
+<p>
+¿Cómo responderemos a la próxima tentación que nos presente una biblioteca
+que no sea libre? ¿Comprenderá la comunidad entera la necesidad de
+mantenerse alejados de la trampa? ¿O alguno de nosotros entregará su
+libertad a cambio de la conveniencia, generando así un problema fundamental?
+Nuestro futuro depende de nuestra filosofía.</p>
+
+<h3>Patentes de software</h3>
+<p>
+La peor amenaza a la que nos enfrentamos proviene de las patentes de
+software, que pueden impedir el uso de algoritmos y funcionalidades en el
+desarrollo de software libre hasta por veinte años. Las patentes del
+algoritmo de compresión LZW se introdujeron en 1983, y todavía no podemos
+publicar software libre que produzca archivos en formato <abbr
+title="Graphics Interchange Format">GIF</abbr> adecuadamente comprimidos.
+[Esas patentes expiraron en 2009.] En 1998 hubo que suspender la
+distribución de un programa libre para producir archivos de audio
+comprimidos en el formato <abbr title="MPEG-1 Audio Layer 3">MP3</abbr> a
+causa de una amenaza de demanda judicial por patentes. [Esas patentes
+expiraron en 2017. Vea cuánto ha habido que esperar.]
+</p>
+<p>
+Existen algunos métodos para afrontar el problema de las patentes: podemos
+buscar pruebas para demostrar la invalidez de la patente, y podemos buscar
+maneras alternativas de realizar una tarea. Pero cada uno de estos métodos
+funciona solo en algunos casos; cuando ambos fallan, una patente puede
+impedir la implementación en todo el software libre de alguna funcionalidad
+que los usuarios desean. Tras una larga espera, las patentes expiran, pero
+¿qué haremos mientras tanto?</p>
+<p>
+Quienes valoramos el software libre por la libertad que nos otorga,
+seguiremos usándolo de todos modos. Buscaremos el modo de realizar nuestro
+trabajo sin las funcionalidades patentadas. Pero quienes valoran el software
+libre porque esperan que sea técnicamente superior, tenderán a calificar de
+«fracaso» el software que no se puede desarrollar a causa de las
+patentes. Por ende, si bien es útil hablar acerca de la efectividad práctica
+del modelo de desarrollo llamado «bazar», y de la confiabilidad y la
+potencia de cierto software libre, no debemos quedarnos solo con
+eso. Debemos hablar de libertad y de principios.</p>
+
+<h3>Documentación libre</h3>
+<p>
+La mayor carencia de nuestros sistemas operativos libres no está en el
+software sino en la falta de buenos manuales libres que podamos incluir en
+nuestros sistemas. La documentación es una parte esencial de cualquier
+paquete de software; cuando un paquete importante de software libre no
+cuenta con un buen manual libre, nos encontramos con una laguna
+fundamental. En la actualidad existen muchas de estas lagunas.</p>
+<p>
+La documentación libre, al igual que el software libre, es una cuestión de
+libertad, no de precio. El criterio que se aplica a los manuales libres es
+muy similar al del software libre: otorgar a los usuarios ciertas
+libertades. La redistribución &mdash;incluso la venta comercial&mdash; debe
+estar permitida, tanto en forma digital como en papel, de modo que se pueda
+incluir el manual con cada copia del programa.</p>
+<p>
+La autorización para modificarlo también es crucial. Como regla general, no
+creo que sea esencial que las personas tengan permiso para modificar todo
+tipo de artículos y libros. Por ejemplo, no creo que usted ni yo estemos
+obligados a autorizar la modificación de artículos como este, en el que se
+describen nuestros actos y nuestros puntos de vista.</p>
+<p>
+Pero existe una razón específica debido a la cual la libertad para modificar
+la documentación es crucial para el software libre. Cuando las personas
+ejercen su derecho a modificar el software y añaden o cambian sus
+funcionalidades, si son concienzudas modificarán también el manual para que
+la documentación sea precisa y se pueda utilizar con el programa
+modificado. Un manual que no es libre, que no permite a los programadores
+ejercer su sentido de la responsabilidad y terminar el trabajo, no satisface
+las necesidades de nuestra comunidad.</p>
+<p>
+No hay inconveniente alguno en establecer ciertos tipos de límites a las
+modificaciones que se pueden realizar, como por ejemplo el requisito de
+preservar el aviso de copyright del autor original, los términos de
+distribución o la lista de autores. Tampoco ocasiona ningún problema el
+requisito que exige incluir una nota advirtiendo que se trata de una versión
+modificada, ni prohibir la alteración o la cancelación de enteras secciones,
+siempre y cuando dichas secciones traten temas que no sean de índole
+técnica. Restricciones de este tipo no ocasionan ningún problema porque no
+impiden al programador concienzudo cambiar el manual para adaptarlo al
+programa modificado. En otras palabras, son restricciones que no le impiden
+a la comunidad del software libre la plena utilización del manual.</p>
+<p>
+Sin embargo, se debe autorizar la modificación de todo el contenido
+<em>técnico</em> del manual, como así también la distribución del resultado
+a través de todos los medios y canales habituales; de no ser así, las
+restricciones estarían obstruyendo la comunidad. En ese caso el manual no
+será libre, y será necesario escribir otro.</p>
+<p>
+¿Tendrán los desarrolladores de software libre la conciencia y la
+determinación para producir una amplia gama de manuales libres? Una vez más,
+nuestro futuro depende de nuestra filosofía.</p>
+
+<h3>Es necesario hablar de libertad</h3>
+<p>
+En la actualidad se estima que hay unos diez millones de usuarios de
+sistemas GNU/Linux tales como Debian GNU/Linux y Red Hat «Linux». El
+software libre ha desarrollado tales ventajas prácticas que un gran número
+de usuarios lo eligen por razones puramente prácticas.</p>
+<p>
+Los resultados positivos de esto son evidentes: mayor interés en el
+desarrollo de software libre, más clientes para las empresas de software
+libre, y mayor capacidad para animar a las compañías a desarrollar software
+libre comercial en lugar de productos de software privativo.</p>
+<p>
+Pero el interés por el software crece más rápidamente que la conciencia de
+la filosofía sobre la cual se funda, y esto crea problemas. Nuestra
+capacidad de enfrentar los desafíos y amenazas que se describieron
+anteriormente depende de la voluntad de mantenernos firmes a favor de la
+libertad. Para asegurarnos de que nuestra comunidad tenga esta voluntad, es
+necesario difundir la idea entre los nuevos usuarios a medida que llegan a
+nuestra comunidad.</p>
+<p>
+Pero estamos fracasando en eso: los esfuerzos para atraer nuevos usuarios a
+nuestra comunidad superan con creces los esfuerzos dedicados a enseñarles
+nuestros principios. Tenemos que hacer ambas cosas, y es necesario mantener
+un equilibrio entre ambos esfuerzos.</p>
+
+<h3>«Open Source» («código abierto»)</h3>
+<p>
+Enseñar a los nuevos usuarios el valor de la libertad comenzó a resultar más
+difícil a partir de 1998, cuando parte de la comunidad decidió abandonar la
+expresión «software libre» reemplazándola por «software de código abierto»
+(«open source software» en inglés).</p>
+<p>
+La intención de algunos de los que adoptaron la nueva expresión era evitar
+la confusión entre «free» y «gratis», un objetivo razonable. Otros, sin
+embargo, apuntaban a dejar de lado los principios que habían dado vida al
+movimiento del software libre y al Proyecto GNU, con el propósito de atraer
+a los ejecutivos y usuarios empresariales, quienes en su gran mayoría
+sostienen una ideología que antepone los beneficios económicos a la
+libertad, a la comunidad, a los principios. Por lo tanto, la retórica del
+«código abierto» se centra en la posibilidad de desarrollar software potente
+y de alta calidad, pero elude las ideas de libertad, comunidad y principios.</p>
+<p>
+Las revistas sobre «Linux» son un claro ejemplo de esto. Están inundadas de
+publicidad sobre software privativo que funciona en GNU/Linux. La próxima
+vez que nos encontremos con productos como Motif o Qt, ¿advertirán estas
+revistas a los programadores aconsejándoles que los eviten, o publicarán
+anuncios para promoverlos?</p>
+<p>
+Dejando aparte todos los demás factores, el apoyo empresarial es útil y
+puede contribuir a la comunidad de varias maneras. Pero si para obtenerlo
+optamos por mencionar aún menos el tema de la libertad y los principios, el
+resultado puede ser desastroso; se agudizaría el desequilibrio entre la
+difusión del software libre y la enseñanza de sus principios.</p>
+<p>
+Las expresiones «software libre» y «código abierto» se refieren
+aproximadamente a la misma categoría de software, pero describen conceptos
+muy diferentes acerca del software y de los valores. El proyecto GNU
+continúa utilizando el término «software libre» para expresar la idea de que
+la libertad, y no solamente la tecnología, es importante.</p>
+
+<h3>¡Inténtalo!</h3>
+<p>
+El aforismo de Yoda («Intentos no hay») suena bien, pero conmigo no
+funciona. He realizado la mayor parte de mi trabajo con la ansiedad de no
+saber si podría llevarlo a cabo, y sin saber si sería suficiente para
+alcanzar la meta aún si lo lograba. Pero lo intenté de todos modos, porque
+entre el enemigo y mi ciudad estaba solo yo. Para mi sorpresa, a veces he
+tenido éxito.</p>
+<p>
+Otras veces fracasé. Algunas de mis ciudades han caído. Más tarde descubrí
+otra ciudad amenazada y me preparé para otra batalla. Con el tiempo, he
+aprendido a detectar las amenazas y a interponerme entre ellas y mi ciudad,
+haciendo un llamamiento a otros hackers para que se unan a mí.</p>
+<p>
+En la actualidad, a menudo no soy el único. Es para mí un alivio y una
+alegría ver a un regimiento de hackers excavando para mantener la trinchera,
+y me doy cuenta de que esta ciudad puede sobrevivir, por ahora. Pero los
+peligros aumentan cada año, y ahora Microsoft tiene a nuestra comunidad en
+su punto de mira. No podemos dar por sentado que el futuro de la libertad
+está asegurado. ¡No piense que es así! Si desea conservar su libertad, debe
+estar preparado para defenderla.</p>
+
+<div class="translators-notes">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
+<strong>Notas de Traducción</strong> <br /> <br /> <a href="#TransNote1-rev"
+id="TransNote1">[1]</a>. En inglés, «libre» se dice «free», término que
+también significa «gratuito». A causa de esta ambigüedad, la frase «free
+software» a veces es mal interpretada, lo cual no sucede con su equivalente
+«software libre» en español. <br /> <a href="#TransNote2-rev"
+id="TransNote2">[2]</a>. En inglés, la posición del calificativo
+<cite>free</cite> en <cite>Free University Compiler Kit</cite> no permite
+determinar si se refiere a la universidad o al compilador. <br /> <a
+href="#TransNote3-rev" id="TransNote3">[3]</a>. «Reversados», por similitud
+etimológica, semántica y fonética con «<cite>reversed</cite>».</div>
+</div>
+
+<!-- for id="content", starts in the include above -->
+<!--#include virtual="/server/footer.es.html" -->
+<div id="footer">
+<div class="unprintable">
+
+<p>Envíe sus consultas acerca de la FSF y GNU a <a
+href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Existen también <a
+href="/contact/">otros medios para contactar</a> con la FSF. <br /> Para
+avisar de enlaces rotos y proponer otras correcciones o sugerencias,
+diríjase a <a
+href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>
+
+<p>
+<!-- TRANSLATORS: Ignore the original text in this paragraph,
+ replace it with the translation of these two:
+
+ We work hard and do our best to provide accurate, good quality
+ translations. However, we are not exempt from imperfection.
+ Please send your comments and general suggestions in this regard
+ to <a href="mailto:web-translators@gnu.org">
+
+ &lt;web-translators@gnu.org&gt;</a>.</p>
+
+ <p>For information on coordinating and submitting translations of
+ our web pages, see <a
+ href="/server/standards/README.translations.html">Translations
+ README</a>. -->
+El equipo de traductores al español se esfuerza por ofrecer traducciones
+fieles al original y de buena calidad, pero no estamos libres de cometer
+errores.<br /> Envíe sus comentarios y sugerencias sobre las traducciones a
+<a
+href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.
+</p><p>Consulte la <a href="/server/standards/README.translations.html">Guía
+para las traducciones</a> para obtener información sobre la coordinación y
+el envío de traducciones de las páginas de este sitio web.</p>
+</div>
+
+<!-- Regarding copyright, in general, standalone pages (as opposed to
+ files generated as part of manuals) on the GNU web server should
+ be under CC BY-ND 4.0. Please do NOT change or remove this
+ without talking with the webmasters or licensing team first.
+ Please make sure the copyright date is consistent with the
+ document. For web pages, it is ok to list just the latest year the
+ document was modified, or published.
+
+ If you wish to list earlier years, that is ok too.
+ Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
+ years, as long as each year in the range is in fact a copyrightable
+ year, i.e., a year in which the document was published (including
+ being publicly visible on the web or in a revision control system).
+
+ There is more detail about copyright years in the GNU Maintainers
+ Information document, www.gnu.org/prep/maintain. -->
+<p>Copyright &copy; 1998, 2001, 2002, 2005, 2006, 2007, 2008, 2010, 2014, 2015,
+2017, 2018, 2020 Richard Stallman</p>
+
+<p>Esta página está bajo licencia <a rel="license"
+href="http://creativecommons.org/licenses/by-nd/4.0/deed.es_ES">Creative
+Commons Reconocimiento-SinObraDerivada 4.0 Internacional</a>.</p>
+
+<!--#include virtual="/server/bottom-notes.es.html" -->
+<div class="translators-credits">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
+<strong>Traducción y revisiones: colaborativas, 1998-2013.</strong></div>
+
+<p class="unprintable"><!-- timestamp start -->
+Última actualización:
+
+$Date: 2020/07/12 08:31:25 $
+
+<!-- timestamp end -->
+</p>
+</div>
+</div>
+<!-- for class="inner", starts in the banner include -->
+</body>
+</html>