path: root/talermerchantdemos/blog/articles/es/thegnuproject.html

<!--#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>