taler-merchant-demos

thegnuproject.html (64961B)

---

 <!--#set var="ENGLISH_PAGE" value="/gnu/thegnuproject.en.html" -->
 
 <!--#include virtual="/server/header.es.html" -->
 <!-- Parent-Version: 1.96 -->
 <!-- This page is derived from /server/standards/boilerplate.html -->
 <!--#set var="TAGS" value="gnu-history" -->
 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
 
 <!-- This file is automatically generated by GNUnited Nations! -->
 <title>Acerca del proyecto GNU - Proyecto GNU - Free Software Foundation</title>
 <style type="text/css" media="print,screen"><!--
 a[href*='#ft'] { font-size: .94em; }
 -->
 </style>
 <meta http-equiv="Keywords" content="GNU, Proyecto GNU, FSF, software libre, Fundación por el Software Libre,
 Free Software Foundation, Historia" />
 
 <!--#include virtual="/gnu/po/thegnuproject.translist" -->
 <!--#include virtual="/server/banner.es.html" -->
 <!--#include virtual="/gnu/gnu-breadcrumb.es.html" -->
 <!--GNUN: OUT-OF-DATE NOTICE-->
 <!--#include virtual="/server/top-addendum.es.html" -->
 <div class="article reduced-width">
 <h2>El Proyecto GNU</h2>
 
 <address class="byline">por <a href="https://www.stallman.org/">Richard Stallman</a></address>
 
 <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, al igual que compartir recetas de cocina
 es tan antiguo como cocinar. Pero nosotros lo hacíamos más que la mayoría.</p>
 <p>
 En el laboratorio de inteligencia artificial se utilizaba 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&#8239;<a
 href="#ft1">[1]</a> del laboratorio para el <abbr title="Programmed Data
 Processor">PDP</abbr>-10, uno de los ordenadores más grandes de la época, de
 la empresa <cite>Digital</cite>. Como miembro de esa comunidad, y hacker del
 laboratorio, mi trabajo consistía en mejorar dicho sistema.</p>
 <p>
 No llamábamos a nuestro software «software libre» 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 y utilizar un programa, se lo permitíamos de
 buen grado. Si veíamos a alguien utilizar un programa poco corriente e
 interesante, siempre le podíamos pedir que nos mostrara el código fuente
 para leerlo, modificarlo o tomar partes de él para hacer otro programa.</p>
 
 <div class="announcement comment" role="complementary">
 <hr class="no-display" />
 <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>
 <hr class="no-display" />
 </div>
 
 <h3>La desintegración 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 potente 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
 disuelto no mucho antes. En 1981, la compañía derivada
 <cite>Symbolics</cite> contrató a casi todos los hackers del laboratorio, y
 la diezmada comunidad no pudo sobrevivir. (En el libro <cite>Hackers</cite>,
 Steve Levy narra estos hechos, a la vez que ofrece una clara imagen de esta
 comunidad en sus comienzos). Cuando el laboratorio compró un nuevo PDP-10 en
 1982, los administradores decidieron utilizar el sistema de
 <cite>Digital</cite>, que no era libre, en lugar del sistema de uso
 compartido de ITS.</p>
 <p>
 Los modernos ordenadores de aquella época, como el VAX o el 68020, tenían
 sus propios sistemas operativos, pero 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
 comprometerse a no ayudar al prójimo. Se prohibía la existencia de una
 comunidad cooperativa, y los dueños del software privativo establecieron el
 siguiente principio: «Si lo compartes con el prójimo, eres un pirata. Si
 quieres algún cambio, ruéganos que lo hagamos».</p>
 <p>
 La idea de que el sistema social del software privativo (el sistema que
 impide compartir y modificar el software) es antisocial, que es contrario a
 la ética, que es sencillamente incorrecto, puede sorprender a algunos
 lectores. Pero ¿qué otra cosa se puede decir de un sistema que se basa en
 dividir a la gente y en mantener al usuario indefenso? Es probable que los
 lectores a quienes esto les sorprende den por sentado el sistema social del
 software privativo, o que lo juzguen en los términos planteados por las
 empresas que desarrollan ese tipo de software. 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 <a
 href="/philosophy/words-to-avoid.html#Piracy">piratería</a>», lo que de
 hecho <em>dicen</em> es secundario. El verdadero mensaje se esconde en
 suposiciones tácitas que ellos dan por sentadas y que pretenden que el
 público acepte sin discusión. Examinémoslas.</p>
 <p>
 Una suposición es que las empresas de software tienen un derecho natural e
 incuestionable a la propiedad del 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). Es interesante el hecho de que la Constitución de los Estados
 Unidos de América y la tradición jurídica rechazan este punto de vista. El
 copyright 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 tácita es que lo único relevante con respecto al software es
 qué tareas nos permite realizar, y que a las personas que utilizamos
 ordenadores no nos tendría que importar el tipo de sociedad que se nos
 permite tener.</p>
 <p>
 Una tercera suposición es que no dispondríamos de software útil (o nunca
 tendríamos un programa para realizar tal o cual tarea en particular) si no
 le otorgáramos a una empresa el poder sobre los usuarios del programa. Esto
 podía parecer 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
 basándonos en criterios morales corrientes y de 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 disponemos aquí de espacio para extendernos en las razones que llevan a
 esta conclusión, por lo que remito al lector a las páginas <a
 href="/philosophy/why-free.html">Por qué el software no debe tener
 propietarios</a> y <a
 href="/philosophy/free-software-even-more-important.html">El software libre
 es ahora aún más importante</a>.
 </p>
 
 <h3>Una difícil elección moral</h3>
 <p>
 Al desaparecer mi comunidad, me resultó imposible continuar como antes. Tuve
 que afrontar una difícil 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 a mis compañeros
 <cite>hackers</cite>. Es muy probable que también hubiera tenido que
 programar software que se publicaría bajo acuerdos de no divulgación,
 aumentando así la presión sobre otras personas para que también traicionaran
 a sus compañeros.</p>
 <p>
 Podría haber ganado dinero de esa manera, y tal vez me hubiese divertido
 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 empleado mi vida en hacer del mundo un lugar peor.</p>
 <p>
 Ya había tenido la experiencia de toparme con un acuerdo de no
 divulgación. Sucedió cuando alguien se negó a entregarnos, a mí y al
 laboratorio de inteligencia artificial del MIT, el código fuente del
 programa que controlaba 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 compartirlo con nosotros; no podía
 virar y hacerles lo mismo a los demás.</p>
 <p>
 Otra posibilidad, sencilla pero indeseable, era abandonar el campo de la
 informática. De esa manera no se haría un uso indebido de mis habilidades,
 pero quedarían desaprovechadas. Yo no sería culpable de dividir y restringir
 a los usuarios de ordenadores, pero eso sucedería de todos modos.</p>
 <p>
 Así que busqué la manera de hacer algo positivo como programador. Me
 pregunté si yo podría escribir uno o más programas que sirvieran para hacer
 resurgir la comunidad.</p>
 <p>
 La respuesta era clara: lo primero que se necesitaba era un sistema
 operativo. Ese es el software fundamental para comenzar a utilizar 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
 tener de nuevo una comunidad de <cite>hackers</cite> cooperando entre sí 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 y amigas.</p>
 <p>
 Como programador de sistemas operativos, tenía las aptitudes necesarias para
 esa labor, y aunque no podía estar seguro de que lo lograría, me di cuenta
 de que era la persona elegida para realizarla. Opté por hacer el sistema
 compatible con Unix para que fuera portable, y facilitar así 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>), que se pronuncia <a
 href="/gnu/pronunciation.html">como una sola sílaba: <cite>ñu</cite></a>.</p>
 <p>
 Un sistema operativo no implica solo un núcleo, que apenas es suficiente
 para ejecutar otros programas. En los años setenta, todo sistema operativo
 digno de tal nombre incluía procesadores de comandos, ensambladores,
 compiladores, intérpretes, depuradores, editores de texto, gestores de
 correo y mucho más. 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, atribuidas a Hillel&#8239;<a
 href="#ft2">[2]</a>:</p>
 
 <blockquote><p>
      Si yo no me ocupo de mí, ¿quién lo hará?<br />
      Si solo me ocupo de mí, ¿qué soy?<br />
      Si no es ahora, ¿cuándo?
 </p></blockquote>
 <p>
 La decisión de comenzar el Proyecto GNU se basó en un espíritu similar.</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 libertad. He aquí pues
 la definición de software libre.</p>
 
 <p>Un programa es software libre, para usted como usuario concreto, si le
 ofrece las siguientes libertades:</p>
 
 <ul>
   <li>La libertad de ejecutar el programa como desee y para cualquier propósito.</li>
 
   <li>La libertad de modificar el programa con el fin de adaptarlo a sus propias
 necesidades (para poder ejercer esta libertad en la práctica, 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 de redistribuir copias, ya sea gratuitamente, ya sea por un
 precio.</li>
 
   <li>La libertad de 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
 de 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 adjetivo «<cite>free</cite>», la gente ha
 estado buscando alternativas durante mucho tiempo, pero nadie ha encontrado
 un término mejor. 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
 «<cite>free</cite>» 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 viable, decidí adaptar y utilizar piezas de
 software libre ya existentes siempre que fuera posible. Por ejemplo, desde
 el principio decidí usar TeX como principal formateador 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
 dificultara la distribución de GNU como software libre. De haber continuado
 como parte del personal, el MIT habría podido reclamar la titularidad de la
 obra e imponer sus propios términos de distribución, o incluso convertirla
 en un paquete de software privativo. No tenía ninguna intención de hacer un
 trabajo enorme para después comprobar que resultaba inútil para lograr su
 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 neerlandesa correspondiente 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 muchos
 tipos de ordenadores destino. Le escribí al autor pidiéndole permiso para
 utilizarlo en GNU.</p>
 <p>
 Me respondió en tono burlón, diciendo que la universidad era libre pero el
 compilador no<a href="#TransNote2"
 id="TransNote2-rev"><sup>[2]</sup></a>. En consecuencia, 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 Pascal y estaba escrito en una versión ampliada del mismo diseñada
 para utilizarse 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 que el sistema Unix 68000 admitía solo 64k.</p>
 <p>
 Advertí entonces que el compilador Pastel analizaba el fichero de entrada al
 completo para transformarlo en un árbol sintáctico, después convertía todo
 el árbol en una cadena de «instrucciones» y luego generaba todo el fichero
 de salida, sin liberar en ningún momento el espacio ocupado. En ese momento
 concluí que tendría que escribir un nuevo compilador desde cero. Ese nuevo
 compilador 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 GNU Emacs.</p>
 
 <h3>GNU Emacs</h3>
 <p>
 Comencé a trabajar en GNU Emacs 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 había interesado
 aprender a utilizar 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 mostrar interés por
 utilizar GNU Emacs, lo que suscitó la cuestión de cómo distribuirlo. Lo puse
 en el servidor anónimo ftp del ordenador del MIT que yo ya utilizaba (a raíz
 de ello, ese ordenador, <em>prep.ai.mit.edu</em>, 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é podía decirles?</p>
 <p>
 Podría haberles dicho: «Buscad un amigo que esté en la red y que os haga una
 copia». O podría haber hecho lo mismo que hice con el Emacs original para
 PDP-10, decirles: «Enviadme una cinta y un sobre prefranqueado con vuestra
 dirección, y os 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 una 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
 sistemas GNU/Linux completos.</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 tienen copyright
 pero se distribuyen bajo simples licencias permisivas que permiten 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, únicamente en formato binario, y
 lo pusieron bajo el mismo acuerdo de no divulgación. Así, estas copias de X
 pasaron a ser software privativo, tal como era Unix.</p>
 <p>
 Los desarrolladores del sistema de ventanas X no consideraban que esto fuese
 un problema, esperaban y pretendían que sucediera. 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 tendrían libertad o no, solo que fueran
 numerosos.</p>
 <p>
 Esto condujo a la paradójica situación de que dos maneras distintas de medir
 el grado de libertad daban por resultado diferentes respuestas a la
 pregunta: «¿Es libre este programa?». Si se juzgaba en función de la
 libertad que otorgaban las cláusulas de distribución de la versión publicada
 por el MIT, se diría 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 necesitábamos unos términos de
 distribución que impidieran que el software de GNU pudiera convertirse en
 software privativo. El método que empleamos se denomina «copyleft»&#8239;<a
 href="#ft3">[3]</a>.</p>
 <p>
 El copyleft hace uso de la ley de copyright, pero le da la vuelta de modo
 que sirva para la finalidad contraria 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 fundamentales 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, si se
 publica, quedará a disposición de la comunidad. 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 utilizar 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. Esos cambios fueron
 pequeños comparados con la envergadura de X, pero no triviales. Si hacer
 cambios fuera una excusa para negar la 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: las
 libertades de las que carezca la parte que no es libre, le faltarán también
 al conjunto. Permitir tales combinaciones abriría un boquete lo bastante
 grande como para hundir el barco. En consecuencia, 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 permitir que la versión
 combinada total también sea libre y esté igualmente bajo copyleft.</p>
 <p>
 La implementación concreta de copyleft que utilizamos 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&#8239;<a
 href="#ft4">[4]</a>.</p>
 
 <h3>La Free Software Foundation</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 recaudar fondos. Con ese objetivo, en 1985 creamos la <a
 href="https://www.fsf.org/">Free Software Foundation</a> (FSF), una
 organización sin ánimo de lucro exenta de impuestos que promueve el
 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 procedía de la venta de copias de
 software libre y otros servicios relacionados: CD-ROM con código fuente,
 CD-ROM con los binarios, manuales elegantemente impresos (todos con la
 libertad de redistribuirlos y de modificarlos) y distribuciones de lujo con
 toda la colección de software apta para la plataforma elegida por el
 cliente. Hoy en día la FSF continúa con la <a
 href="https://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="https://my.fsf.org/join">>fsf.org</a>.</p>
 
 <p>Empleados de la Free Software Foundation han escrito y se han encargado del
 mantenimiento de una serie de paquetes de GNU. Dos ejemplos destacables son
 la biblioteca C y el intérprete de comandos. La biblioteca C de GNU es
 utilizada por todo programa que se ejecuta en un sistema GNU/Linux para
 comunicarse con Linux, el núcleo; fue programada por Roland McGrath, un
 miembro del personal de la Free Software Foundation. El intérprete de
 comandos que se utiliza en la mayoría de los sistemas GNU/Linux es «BASH»,
 acrónimo de <cite>Bourne Again Shell</cite>&#8239;<a href="#ft5">[5]</a>, y
 fue desarrollado 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 proporcionar herramientas o un entorno de
 desarrollo. Nuestra meta era construir un sistema operativo completo, y
 necesitábamos esos programas para lograrlo.</p>
 
 <h3>Servicios relacionados con el software libre</h3>
 
 <p>La filosofía del software libre rechaza una práctica empresarial
 generalizada específica, 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 se hizo cargo de esa actividad, tuve que
 buscarme otra forma de ganarme la vida. La 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 existe buen número de corporaciones que realizan esos tipos de
 actividades comerciales 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 renunciar a su libertad. Denominan esos programas «paquetes
 con valor añadido», lo que demuestra cuáles son los valores que desearían
 que adoptáramos: comodidad 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 una ventaja ética, respetar
 la libertad de los usuarios.</p>
 
 <p>Pero era natural que aplicáramos a nuestro trabajo los conocidos estándares
 de buenas prácticas; por ejemplo, la asignación dinámica de estructuras de
 datos, para evitar así límites de tamaño fijados arbitrariamente, y el
 empleo de todos los códigos de ocho bits posibles, siempre que fuera
 razonable.</p>
 
 <p>Además, rechazamos la opción de Unix por un tamaño de memoria reducido, por
 lo que 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 de un megabyte. En los programas en los que no fuera
 fundamental manejar archivos 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 permitieron que muchos programas de GNU superaran a sus
 homólogos de Unix en fiabilidad 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 donar
 al proyecto máquinas con Unix. 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 suscitó el
 problema ético de si era correcto que tuviéramos siquiera una copia de Unix.</p>
 
 <p>Unix era (y es) software privativo, y según la filosofía del Proyecto GNU no
 debemos utilizar software privativo. Pero aplicando el mismo razonamiento
 que lleva a la conclusión de que la violencia en defensa propia está
 justificada, concluí que era igualmente legítimo utilizar un paquete
 privativo cuando eso fuera fundamental para 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 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.</p>
 
 <h3>La lista de tareas de GNU</h3>
 
 <p>A medida que el Proyecto GNU avanzaba, se encontró o desarrolló un número
 cada vez mayor de componentes para el sistema, por lo que finalmente nos
 pareció útil elaborar una lista de las piezas que faltaban. Luego la
 utilizamos para reclutar programadores que las desarrollaran. Se trata de la
 lista posteriormente conocida como «Lista de tareas de GNU». Además de los
 componentes Unix que faltaban, 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&#8239;<a href="#ft6">[6]</a> ya no queda casi ningún
 componente Unix en la Lista de tareas de GNU; se concluyeron todas, excepto
 unas pocas que no son esenciales. Pero la lista contiene muchos proyectos
 que podrían considerarse «aplicaciones». Es útil añadir al sistema operativo
 todo programa que despierte el interés de un conjunto de usuarios no muy
 reducido.</p>
 
 <p>Incluso los juegos están incluidos en la lista de tareas y lo han estado
 desde el principio. Unix incluía juegos, así que era natural que también GNU
 los incluyera. Los juegos no presentaban ningún problema de compatibilidad,
 así que no seguimos la lista de juegos que tenía Unix. En vez de eso
 incluimos en la lista una gama de diferentes tipos de juegos que podrían
 gustar a los usuarios.</p>
 
 <h3>La GPL Reducida de GNU</h3>
 
 <p>La biblioteca C de GNU utiliza un tipo especial de copyleft denominado
 <cite>GNU Lesser General Public License</cite>&#8239;<a href="#ft7">[7]</a>
 (Licencia Pública General Reducida de GNU) 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 diga que
 los productos de software privativo están autorizados a incluir nuestro
 código (¿por qué contribuir a un proyecto que se niega a compartir su código
 con nosotros?). La utilización de la LGPL para la biblioteca C, o para
 cualquier otra biblioteca, es una decisión estratégica.</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 del software libre no habría significado ninguna
 ventaja para este; solo habría desalentado la utilización de nuestra
 biblioteca.</p>
 
 <p>Existe una excepción a lo anterior: en el sistema GNU (y esto incluye a
 GNU/Linux), la biblioteca C de GNU es la única biblioteca C. De modo 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 desde un punto de vista estratégico parece que no
 autorizarlo contribuiría más a desalentar la utilización del sistema GNU que
 a incentivar el desarrollo de aplicaciones libres. Esta es la razón por la
 que utilizar la GPL Reducida (<cite>Lesser GPL</cite>) es una buena
 estrategia para la biblioteca C.</p>
 
 <p>Para otras bibliotecas es necesario considerar la estrategia a adoptar caso
 por caso. Cuando una biblioteca desempeña una función especial que puede
 facilitar el desarrollo de cierto tipo de programas, publicarla bajo la GPL,
 limitándola únicamente a programas libres, es una manera de ayudar a otros
 programadores de software libre, ya que eso les otorga una ventaja frente al
 software privativo.</p>
 
 <p>Consideremos por ejemplo la biblioteca Readline de GNU, desarrollada para
 editar los comandos de BASH. Readline se publica bajo la GPL de GNU
 ordinaria, no bajo la GPL Reducida. Es probable que de esta manera se
 reduzca el uso de Readline, pero eso no supone una pérdida para nosotros. En
 cambio, al menos una aplicación útil ha sido transformada en software libre
 específicamente para poder utilizar Readline, y eso es un auténtico logro
 para la comunidad.</p>
 
 <p>Los desarrolladores de software privativo tienen las ventajas que
 proporciona el dinero; quienes desarrollan software libre necesitan del
 apoyo mutuo para aventajarlos. Confío en que algún día contaremos con una
 amplia colección de bibliotecas cubiertas por la GPL sin equivalentes en el
 software privativo, bibliotecas que constituyan módulos útiles para
 construir nuevos programas libres y supongan así una ventaja para el
 posterior desarrollo de software libre.</p>
 
 <h3>¿Rascando donde pica?</h3>
 <p>
 Eric Raymond dice que «Toda buena obra de software comienza por que un
 programador se pone a rascar donde le pica». Puede que a veces sea así, 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 por 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 un intérprete de comandos, y el tar de GNU porque un sistema
 similar a Unix necesita un programa tar. Lo mismo ocurre con 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 hacer frente a
 amenazas específicas a nuestra libertad. Por esta razón desarrollamos gzip
 para reemplazar Compress, programa que la 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 de cifrado muy utilizado que no es libre, ya que los usuarios no
 deben verse obligados a elegir entre privacidad y libertad.</p>
 <p>
 Por supuesto, la gente que escribía estos programas se interesaba por el
 trabajo, y varias personas añadieron muchas funcionalidades para satisfacer
 sus propias necesidades e intereses. Pero ese no es el motivo por el que
 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 en su totalidad. Pero no fue así.</p>
 <p>
 Debido a que cada componente del sistema GNU se implementó en un sistema
 Unix, todos podían ejecutarse en sistemas Unix mucho antes de que el sistema
 GNU se hubiera completado. Algunos de esos programas se hicieron populares,
 y los usuarios comenzaron a ampliarlos y portarlos a las distintas versiones
 incompatibles de Unix, y en ocasiones 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 los desarrolladores de GNU dedicaban más tiempo al mantenimiento de
 esas migraciones y a añadir funcionalidades a los componentes ya existentes
 que a continuar con el desarrollo de los componentes que faltaban uno tras
 otro.</p>
 
 <h3>El Hurd de GNU</h3>
 <p>
 En 1990 el sistema GNU estaba casi completo, el único componente importante
 que faltaba era el núcleo. Habíamos decidido implementar nuestro núcleo como
 un conjunto 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 consiste en una serie de
 servidores (esto es, una «manada de <cite>gnus</cite> [ñus]) que se ejecutan
 sobre Mach y realizan las diversas tareas del 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 para
 ello con un depurador de código fuente. 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 llevaba mucho tiempo lograrlo, y los
 servidores multihilo que se intercambian mensajes resultaron ser muy
 difíciles de depurar. Hacer que Hurd funcione sólidamente es un trabajo que
 lleva extendiéndose muchos años.</p>
 
 <h3>Alix</h3>
 <p>
 Al principio el núcleo de GNU 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 comentado que su nombre seguía el esquema de
 nomenclatura habitual en las versiones de los sistemas Unix. En broma, les
 dijo a sus amigos: «Alguien debería ponerle 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 mantuvo. Michael Bushnell (ahora 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 rompimos y ella se cambió el
 nombre. Independientemente de eso, el diseño de Hurd se modificó para que la
 biblioteca C enviara los mensajes a los servidores, 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 final Alix tuvo
 la oportunidad de 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 capacidades
 (<cite>capability-based design</cite>) presenta dificultades 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, que aún no estaba completamente terminado, dio
 como resultado un sistema operativo libre completo (claro que combinarlos
 supuso una considerable cantidad de trabajo). Se debe a Linux que en la
 actualidad podamos 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 reflejar el hecho de que
 el sistema es 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 para el futuro</h3>
 <p>
 Hemos demostrado nuestra capacidad para desarrollar un amplio espectro de
 software libre. Pero esto no significa que seamos invencibles e
 imparables. Diversos desafíos hacen que el futuro del software libre sea
 incierto. Afrontarlos requerirá constante esfuerzo y empeño, a veces durante
 años. Se necesita mucha determinación, como la que demuestran quienes
 valoran su libertad y no permiten que nadie se la arrebate.</p>
 <p>
 En las cuatro secciones siguientes nos ocupamos de esos desafíos.</p>
 
 <h4>Hardware secreto</h4>
 <p>
 Los fabricantes de hardware tienden cada vez más a mantener en secreto las
 especificaciones de sus productos. Esto dificulta el desarrollo de
 controladores libres que permitan que Linux y XFree86 puedan reconocer el
 nuevo hardware. 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 formas de abordar este problema. Los programadores pueden
 recurrir a la ingeniería inversa para buscar la manera de soportar el
 hardware. Los demás 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 volverá contraproducente.</p>
 <p>
 La ingeniería inversa implica un trabajo enorme, ¿tendremos programadores
 con la suficiente determinación para realizarla? Sí, siempre que logremos
 crear 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 muchos los que estaremos dispuestos a invertir algún
 dinero extra, o algo de tiempo extra, para que podamos usar controladores
 libres? Sí, si la determinación de gozar de libertad se convierte en algo
 generalizado&#8239;<a href="#ft8">[8]</a>.</p>
 
 <h4>Bibliotecas que no son libres</h4>
 <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 se utiliza la
 biblioteca, se cae en la trampa, porque el programa que hace uso de ella no
 podrá formar parte de un sistema operativo libre de manera útil
 (estrictamente hablando, podríamos incluir el programa, pero no
 <em>funcionará</em> sin esa biblioteca). Peor aún, si un programa que
 utiliza una biblioteca privativa se populariza, 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á por los años ochenta. Aunque por aquel entonces no había todavía
 sistemas operativos libres, estaba claro el problema que Motif les
 ocasionaría más adelante. El Proyecto GNU respondió de dos maneras: pidiendo
 a los proyectos de software libre individuales 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 llevó muchos
 años. LessTif, desarrollado por los <cite>Hungry Programmers</cite>, no
 alcanzó la potencia necesaria para admitir la mayoría de las aplicaciones
 Motif hasta 1997.</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 utilizó 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 utilizar 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 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 iniciado 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 utilizando exclusivamente
 software libre. 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 la utilización de cualquier software que no fuese libre.</p>
 <p>
 Harmony es una biblioteca sustitutiva compatible, diseñada para poder
 ejecutar el software KDE sin utilizar 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 esto se debió en parte a la
 firme respuesta de la comunidad frente al problema que presentaba Qt cuando
 no era libre. (La nueva licencia no es práctica ni justa, por lo que sigue
 siendo preferible evitar el uso de Qt)&#8239;<a href="#ft9">[9]</a>).</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
 mantenernos alejados de la trampa? ¿O alguno de nosotros cederá su libertad
 a cambio de la comodidad, generando así un problema fundamental? Nuestro
 futuro depende de nuestros valores.</p>
 
 <h4>Patentes de software</h4>
 <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&#8239;<a href="#ft10">[10]</a>. 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>
 debido a una amenaza de demanda por infracción de patente&#8239;<a
 href="#ft11">[11]</a>.
 </p>
 <p>
 Hay maneras de 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 estos métodos funcionan 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 utilizá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, es probable que
 vean en él un fallo cuando una patente los detenga. Por tanto, si bien es
 útil mencionar la eficacia práctica del modelo de «bazar», y hablar de la
 fiabilidad y la potencia de cierto software libre, no debemos quedarnos solo
 con eso. Debemos hablar de libertad y de principios.</p>
 
 <h4>Documentación libre</h4>
 <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, tenemos una importante laguna. En la
 actualidad adolecemos de 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 (la venta comercial incluida) debe estar
 permitida, tanto en línea 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
 exponen nuestras iniciativas y puntos de vista.</p>
 <p>
 Pero existe una razón concreta que hace que la libertad de modificar la
 documentación sea crucial para el software libre. Cuando una persona ejerce
 su derecho a modificar el software y añade o cambia sus funcionalidades, si
 es meticulosa modificará también el manual, de manera que al programa
 modificado le acompañe documentación precisa y útil. Un manual que no es
 libre, que no permite a los programadores ser concienzudos 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 supresión de secciones enteras,
 siempre que 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 diligente 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>
 No obstante, 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 supondrían un obstáculo para la comunidad. En ese caso el
 manual no será libre, y será necesario escribir otro.</p>
 <p>
 ¿Serán los desarrolladores conscientes de la necesidad de disponer de un
 abanico completo de manuales libres y tendrán la determinación necesaria
 para elaborarlos? Una vez más, nuestro futuro depende de nuestros valores.</p>
 
 <h3>Es necesario hablar de libertad</h3>
 <p>
 Se estima que en la actualidad 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>
 Las consecuencias positivas 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 el conocimiento de
 la filosofía en la que se basa, y esto crea problemas. Nuestra capacidad de
 afrontar los desafíos y amenazas antes descritos depende de nuestro
 compromiso en la defensa de la libertad. Para asegurar el compromiso de
 nuestra comunidad es necesario difundir esa idea entre los nuevos usuarios a
 medida que se incorporan a la comunidad.</p>
 <p>
 Pero no lo estamos consiguiendo: los esfuerzos para atraer nuevos usuarios a
 nuestra comunidad superan con creces los esfuerzos dedicados a transmitirles
 nuestros principios. Tenemos que hacer ambas cosas, y es necesario mantener
 un equilibrio entre esos dos empeños.</p>
 
 <h3>«Open Source» («código abierto»)</h3>
 <p>
 Transmitir 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 «<cite>free</cite>» y «gratis», un objetivo razonable. La
 intención de otros, sin embargo, era dejar de lado los principios que
 motivaron el movimiento del software libre y el Proyecto GNU, con el
 propósito de atraer a los ejecutivos y usuarios empresariales, muchos de los
 cuales tienen una ideología que antepone los beneficios económicos a la
 libertad, a la comunidad y a los principios. De modo que la retórica del
 «código abierto» se centra en la capacidad de desarrollar software potente y
 de alta calidad, evitando las ideas de libertad, comunidad y principios.</p>
 <p>
 Las revistas sobre «Linux» son un claro ejemplo de ello. Están inundadas de
 publicidad sobre software privativo que funciona en GNU/Linux. Cuando se
 publique un nuevo Motif o Qt, ¿aconsejarán estas revistas a los
 programadores que los eviten, o publicarán anuncios para promoverlos?</p>
 <p>
 Dejando a un lado otras consideraciones, el apoyo empresarial es útil y
 puede contribuir a la comunidad de muchas 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 agravaría el mencionado desequilibrio
 entre el crecimiento del número de usuarios y su educación cívica.</p>
 <p>
 Las expresiones «software libre» y «código abierto» se refieren
 aproximadamente a la misma categoría de software, pero dicen cosas
 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 es importante, no solo la tecnología.</p>
 
 <h3>¡Inténtelo!</h3>
 <p>
 El aforismo de Yoda, «"Intentar" no existe» <a href="#TransNote4"
 id="TransNote4-rev"><sup>[4]</sup></a>, suena bien, pero conmigo no
 funciona. He realizado la mayor parte de mi trabajo con la inquietud de no
 saber si podría llevarlo a cabo, y sin saber si una vez terminado sería
 suficiente para alcanzar el objetivo. Pero lo intenté de todos modos, porque
 no había nadie más entre el enemigo y mi ciudad. 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 una legión de hackers movilizados para mantener la línea de
 frente, 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 asegurado el futuro de la
 libertad. ¡No crea que es así! Si desea conservar su libertad, debe estar
 preparado para defenderla.</p>
 <div class="column-limit"></div>
 
 <h3 class="footnote">Notas</h3>
 <ol>
 <li id="ft1">El uso del término «hacker» para referirse a alguien que burla la seguridad
 de un sistema es un error provocado por los medios de comunicación. Nosotros
 los hackers rechazamos ese significado y continuamos empleando esa palabra
 para designar a alguien a quien le gusta programar, o que disfruta
 utilizando su ingenio de una manera lúdica, o una suma de las dos
 cosas. Véase mi artículo <a
 href="https://stallman.org/articles/on-hacking.html"><cite>On
 Hacking</cite></a> (en inglés).</li>
 
 <li id="ft2">Como ateo, no sigo a ningún líder religioso, pero a veces admiro algo que ha
 dicho uno de ellos.</li>
 
 <li id="ft3">En 1984 o 1985, Don Hopkins (un compañero muy ocurrente) me envío una
 carta. <a href="/graphics/copyleft-sticker.html">En el sobre</a> había
 escrito varias frases divertidas, entre ellas: «Copyleft, 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 definiendo por entonces.</li>
 
 <li id="ft4">Para la documentación ahora utilizamos la <a
 href="/licenses/fdl.html">Licencia de documentación libre de GNU</a> (<abbr
 title="Free Documentation License">FDL</abbr> de GNU).</li>
 
 <li id="ft5">«<cite>Bourne Again Shell</cite>» es un juego de palabras con el nombre
 «<cite>Bourne Shell</cite>», que era el intérprete de comandos comúnmente
 utilizado en Unix.</li>
 
 <li id="ft6">Ese texto se escribió en 1998. En 2009 ya no tenemos una larga lista de
 tareas. La comunidad programa software libre con tanta rapidez que ni
 siquiera podemos seguirle la pista a todos. Tenemos en cambio una lista de
 Proyectos de Alta Prioridad, una lista mucho más corta de proyectos en los
 que de verdad queremos animar a la gente a trabajar.</li>
 
 <li id="ft7">Esta licencia se llamaba inicialmente <cite>GNU Library General Public
 License</cite> (Licencia Pública General de GNU para Bibliotecas). Le
 cambiamos el nombre 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>.</li>
 
 <li id="ft8">Aclaración de 2008: esto se aplica también al BIOS. Existe un BIOS libre
 llamado <a href="https://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 sean libres.</li>
 
 <li id="ft9">En Septiembre de 2000 Qt se publicó bajo la licencia GPL de GNU, lo que
 solucionó completamente el problema.</li>
 
 <li id="ft10">Las patentes sobre GIF expiraron en 2009.</li>
 
 <li id="ft11">Las patentes sobre MP3 expiraron en 2017. Vea cuánto tiempo tuvimos que
 esperar.</li>
 </ol>
 
 <div class="infobox extra" role="complementary">
 <hr />
 <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
 sido un defensor del «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>
 </div>
 </div>
 
 <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, «free» significa «libre», pero también
 «gratuito». A causa de esta ambigüedad, la expresión «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>». <br /> <a href="#TransNote4-rev"
 id="TransNote4">[4]</a> El aforismo entero dice: «No lo intentes. Hazlo o no
 lo hagas. "Intentar" no existe».</div>
 </div>
 
 <!-- for id="content", starts in the include above -->
 <!--#include virtual="/server/footer.es.html" -->
 <div id="footer" role="contentinfo">
 <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 contributing 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, 2005, 2008, 2010, 2012, 2015, 2017, 2018, 2021
 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-2021.</strong></div>
 
 <p class="unprintable"><!-- timestamp start -->
 Última actualización:
 
 $Date: 2021/12/25 21:34:15 $
 
 <!-- timestamp end -->
 </p>
 </div>
 </div>
 <!-- for class="inner", starts in the banner include -->
 </body>
 </html>