Cuando entré a trabajar en el Laboratorio de Inteligencia Artificial (AI Lab)
del MIT en 1971, pasé a formar parte de una comunidad que compartía software y
llevaba haciéndolo durante años. El acto de compartir software no se
circunscribe a nuestra comunidad en particular: es tan antiguo como los
propios ordenadores, lo mismo que compartir recetas es tan viejo como la
cocina. Simplemente, nosotros lo hacíamos en mayor medida.
En el AI Lab se utilizaba un sistema operativo de tiempo compartido llamado
ITS (Incompatible Timesharing System), diseñado y escrito por los
hackers de la plantilla del lab en lenguaje ensamblador para el Digital
PDP-10, uno de los ordenadores más grandes de la época. Como miembro de esta
comunidad y hacker de sistemas para el AI Lab, mi labor consistía en mejorar
dicho sistema.
No llamábamos «software libre» a nuestro software porque el término no existía
todavía; pero era exactamente eso. Cuando alguien de otra universidad o de
otra empresa quería instalar y utilizar un programa, se lo prestábamos de buen
grado. Si descubrías a alguien utilizando un programa poco habitual e
interesante, siempre podías preguntarle por el código fuente, leerlo,
modificarlo o canibalizar partes de él para montar un programa nuevo.
El uso de la palabra «hacker» para definir al «que rompe sistemas de
seguridad» es una confusión promovida por los medios de masas. Nosotros, los
hackers, nos negamos a reconocer esta acepción y seguimos utilizando este
término para describir a «alguien que ama la programación y disfruta
explorando nuevas posibilidades».2
La situación cambió drásticamente a principios de los años ochenta, con la
desaparición de la comunidad hacker del AI Lab, seguida de la desaparición del
ordenador PDP-10.
En 1981, la empresa pionera Symbolics contrató a casi todos los hackers del AI
Lab, y nuestra diezmada comunidad fue incapaz de sobrevivir. (En el libro
Hackers, Stephen Levy describe estos acontecimientos, a la vez que
nos proporciona un panorama bastante preciso de lo que fue la época dorada de
esta comunidad). Cuando el AI Lab compró un nuevo PDP 10 en 1982, sus
administradores decidieron usar un sistema de Digital de tiempo compartido no
libre en lugar del ITS en la nueva máquina.
Poco después, Digital dejó de fabricar la serie PDP-10. Su arquitectura
elegante y poderosa de los años sesenta no podía adaptarse de forma natural a
los grandes espacios de direccionamiento característicos de los años ochenta.
Lo cual explica que casi todos los programas que integraban el sistema ITS
resultaran obsoletos. De esa manera se enterraba definitivamente al ITS:
quince años de trabajo tirados por la borda.
Los modernos ordenadores de la época, como el VAX o el 68020, contaban con su
propio sistema operativo, pero ninguno utilizaba software libre. Había que
firmar un acuerdo de confidencialidad incluso para obtener una copia
ejecutable.
Todo ello significaba que antes de poder utilizar un ordenador tenías que
prometer no ayudar a tu vecino. Quedaban así prohibidas las comunidades
cooperativas. Los titulares de software propietario establecieron la siguiente
norma: «Si compartes con tu vecino, te conviertes en un pirata. Si quieres
hacer algún cambio, tendrás que rogárnoslo».
La idea de que el sistema social en torno al software propietario —un
sistema que te impide compartir o modificar el software— es antisocial, poco
ético, sencillamente equivocado, puede sorprender a algunos lectores. Pero
¿qué podemos decir acerca de un sistema que siembra la división entre el
público y abandona a los usuarios a la indefensión más absoluta? Estos
lectores probablemente hayan asumido el sistema social asociado con el
software propietario como algo inevitable o habrán considerado la cuestión de
la misma forma que se plantea por parte de las empresas de software
propietario. Los editores de software se han esforzado mucho en convencernos
de que sólo hay una forma de abordar esta cuestión.
Cuando los editores de software hablan de «ejercer» sus «derechos» o de
«acabar con la piratería», lo que dicen es, de hecho, secundario. El verdadero
mensaje de estas declaraciones se esconde en ciertas presunciones implícitas
que dan por supuestas; creen que el público debe aceptarlas sin cuestionarlas.
De modo que analicémoslas.
Una suposición es que las empresas de software tienen el derecho natural e
incuestionable a poseer software, y por ende a detentar todo el poder sobre
sus usuarios. (Si de verdad se tratara de un derecho natural, nosotros no
objetaríamos nada, independientemente del perjuicio que esto ocasionara al
público.) Pero lo interesante es que la Constitución de los EE.UU. y el
derecho tradicional rechazan este punto de vista. El copyright no es
una ley natural, sino un monopolio artificial impuesto por el Estado que
limita el derecho natural de los usuarios a copiar.
Otra presunción implícita es que lo único importante en el software es la
función que te permite desempeñar —que, como usuarios de ordenadores, no
deberíamos preocuparnos de que tipo de sociedad se nos permite tener.
Una tercera presunción es que no dispondríamos de software de utilidad —o de
un programa para realizar esta u otra tarea— si no cedemos el derecho de los
usuarios sobre un programa a la empresa responsable del mismo. Esto resultaba
convincente antes de que el movimiento del software libre demostrara que
podíamos crear muchísimos programas, y muy útiles, sin necesidad de cadenas.
Si preferimos rechazar estas presunciones y analizamos estas cuestiones de
acuerdo con los criterios morales y el sentido común del ciudadano de a pie,
anteponiendo a los usuarios a cualquier otra consideración, llegaremos a
conclusiones muy diferentes. Los usuarios de ordenadores deberían ser libres
para modificar los programas y ajustarlos a sus necesidades, libres para
compartirlos, porque la cooperación con los demás constituye la base de la
sociedad.
Una vez desapareció mi comunidad, era imposible seguir como hasta entonces. De
modo que me enfrenté a un dilema moral radical.
Lo más fácil hubiera sido subirme al tren del software propietario, firmar
acuerdos de confidencialidad y prometer no ayudar a mis compañeros hackers. Es
muy probable que ahora me dedicara a desarrollar software publicado con
cláusulas de confidencialidad, presionando así a otros para traicionar también
a sus compañeros.
Podría haber ganado mucho dinero de esta forma, y quizás me hubiera divertido
escribiendo código. Pero sabía que, al final de mi carrera, echaría la vista
atrás y sólo habría contribuido a levantar muros para dividir a la gente,
habría pasado toda mi vida convirtiendo este mundo en un lugar mucho peor.
Ya había experimentado lo que se siente al firmar un acuerdo de
confidencialidad cuando una persona se negó a entregarnos, a mí y al AI Lab,
el código fuente del programa de control de nuestra impresora. (La ausencia de
ciertas funciones en este programa convertía el uso de la impresora en una
experiencia muy frustrante.) De modo que no podía engañarme sobre la inocencia
de estos acuerdos. Monté en cólera cuando aquel individuo se negó a
compartirlo con nosotros. No podía hacerle lo mismo al resto del mundo.
Otra opción, más directa aunque desagradable, hubiera sido abandonar el mundo
de los ordenadores. De esa manera no malgastaría mis aptitudes, aunque con
todo seguirían sin servir de nada. No sería culpable de dividir y restringir
libertad a los usuarios de ordenadores, pero eso llegaría tarde o temprano.
Decidí estudiar la manera en que un programador podría hacer algo por el bien
común. Me pregunté si podía escribir uno o varios programas que permitiesen
resucitar nuevamente a nuestra extinta comunidad.
La respuesta era obvia: la primera cosa necesaria era crear un sistema
operativo, el software crucial para empezar a utilizar un ordenador. Con un
sistema operativo puedes hacer muchas cosas; sin él, ni siquiera puedes hacer
funcionar un ordenador. Mediante un sistema operativo libre podríamos armar
una nueva comunidad cooperativa de hackers —e invitar a todos a que se
uniesen a ella. Y cualquiera podría utilizar un ordenador sin verse obligado
previamente a conspirar para privar de esto a sus amigos.
Como desarrollador de un sistema operativo, tenía las aptitudes necesarias
para desempeñar esta labor. De manera que, aun cuando el éxito no estuviera
asegurado, comprendí que había sido elegido para llevar a cabo esta misión.
Opté por crear un sistema compatible con Unix para dotarle así de portabilidad
y facilitar el cambio a los usuarios de Unix. El nombre de GNU fue elegido
según una tradición de los hackers, como un acrónimo recursivo de «GNU's Not
Unix».3
Un sistema operativo no significa sólo un kernel, que apenas permite ejecutar
otros programas. En los años setenta, cualquier sistema operativo decente
incluía sus propios procesadores de comandos, ensambladores, compiladores,
interpretes, depuradores, editores de textos, gestores de correo y mucho más.
ITS, Multics, VMS y Unix, todos incluían estos componentes.
Más adelante, escuché estas palabras, atribuidas a Hillel: «Si no actúo en mi
nombre, ¿quién lo hará por mí? Y entonces, ¿en qué me convertiré? Y si ahora
no, entonces ¿cuándo?».
La decisión de emprender el proyecto GNU se basaba en un espíritu similar.
Como ateo, no sigo el ejemplo de ningún líder religioso, pero a veces admiro
las cosas que han llegado a decir.
A veces se malinterpreta el término de «software libre» —para empezar, no
tiene ninguna relación con el precio. Lo que nos interesa es la libertad. He
aquí la definición de software libre. Un programa es software libre para el
usuario siempre que, como usuario particular, tengas:
La libertad de ejecutar el programa sea cual sea el propósito.
La libertad para modificar el programa para ajustarlo a tus necesidades.
(Para que se trate de una libertad efectiva en la práctica, deberás tener
acceso al código fuente, dado que sin él la tarea de incorporar cambios en un
programa es extremadamente difícil.)
La libertad de redistribuir copias, ya sea de forma gratuita, ya sea a
cambio del pago de un precio.
La libertad de distribuir versiones modificadas del programa, de tal forma
que la comunidad pueda aprovechar las mejora introducidas.
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 a la venta en
formato de CD-ROM son muy importantes para la comunidad y venderlas es una
forma de recaudar fondos para el desarrollo de software libre. Por lo tanto,
cualquier programa que no podamos incluir en estas colecciones no podrá
calificarse de software libre.
Dada la ambigüedad del calificativo «libre», llevamos mucho tiempo buscando
alternativas, pero nadie ha encontrado ninguna satisfactoria. La lengua
inglesa es de las más rica en lo que a palabras y matices se refiere, pero
carece de un término simple e inequívoco para «libre» en el sentido de
libertad —«unfettered» [sin cadenas] sería el calificativo que más se ajusta
al significado. Alternativas como «liberado», «libertad» o «abierto» no
significan lo mismo o presentan otros inconvenientes.
El desarrollo de un sistema operativo de principio a fin es un proyecto
colosal. Como primera medida, decidí adaptar y utilizar algunas piezas
existentes de software libre siempre que me fuera posible. Desde el inicio,
decidí usar TeXcomo principal procesador de texto, y unos años más tarde me
pasé al X Window System en vez de escribir otro sistema de ventanas para GNU.
Debido a esta decisión, el sistema GNU no consiste en una colección completa
de software GNU. El sistema incluye programas desarrollados por otros
individuos y para proyectos con sus propios propósitos que empleamos por su
condición de software libre.
En enero de 1984 abandoné mi empleo en el MIT y comencé a escribir
software GNU. Abandonar el MIT era imprescindible si quería que nadie
interfiriera en la distribución de GNU como software libre. De haberme
quedado, el MIT podría haberse apropiado de mi trabajo e impuesto sus propios
términos de distribución, o incluso convertir el trabajo en un paquete de
software propietario. No tenía ninguna intención de hacer una gran cantidad de
trabajo para ver como se convertía en algo inútil en relación a su propósito
inicial: crear una nueva comunidad dedicada a compartir software.
No obstante, el profesor Winston, el entonces director del Lab AI en el MIT,
me invitó a utilizar las instalaciones del laboratorio.
Poco después de comenzar el proyecto GNU, me hablaron del Free University
Compiler Kit, también conocido como VUCK. [La palabra danesa para libre (free)
estaba escrita con una «V»] Se trataba de un compilador diseñado para trabajar
con múltiples lenguajes, incluido C y Pascal, y compatible con ordenadores de
objetivos múltiples. Me puse en contacto con el autor para pedirle permiso y
utilizarlo en GNU.
Me contestó burlonamente, diciendo que la universidad era gratuita, pero no el
compilador. Así que decidí que el primer programa para el proyecto GNU sería
un compilador capaz de trabajar en múltiples lenguajes y plataformas.
Para evitar tener que reescribir todo el compilador, obtuve el código fuente
para el compilador Pastel, un compilador de plataformas múltiples desarrollado
en Lawrence Livermore Lab. Soportaba, y estaba escrito, en una versión
ampliada de Pascal, diseñada como lenguaje de programación de sistemas. Le
añadí un front end C y comencé a pasarlo a un ordenador Motorola
68000, pero tuve que abandonar el intento al descubrir que el compilador
requería muchos megabytes de espacio, y el sistema Unix 68000 de entonces sólo
tenía capacidad para 64K.
Me di cuenta de que el compilador Pastel analizaba el archivo de entrada en
forma de árbol sintáctico, convirtiéndolo en una cadena de «instrucciones» y
luego generando todo el archivo de salida sin liberar espacio de
almacenamiento. Así que concluí que tendría que escribir un nuevo compilador
partiendo de cero. El resultado es el compilador conocido como GCC; aunque no
contiene ningún elemento del compilador Pastel, conseguí adaptar y utilizar el
front end C que había escrito. Pero eso fue años más tarde. Antes
trabajé en el GNU Emacs.
Comencé a trabajar en el GNU Emacs en septiembre de 1984, y a principios de
1985 ya podía ser utilizado. Esto me permitió
comenzar a usar el sistema Unix para labores de edición. Dado que nunca me
interesó aprender a usar vi o ed, hasta entonces había realizado mis ediciones
en otro tipo de máquinas.
En aquel momento había gente interesada en utilizar GNU Emacs, lo que planteó
el problema de la distribución. Por supuesto, lo coloqué en el servidor
anónimo ftp del ordenador del MIT [Este ordenador, prep.ai.mit.edu, se
convirtió así en el principal sitio ftp de distribución de GNU; al
desmantelarlo años más tarde, transferimos el nombre a nuestro nuevo servidor
ftp]. Pero en aquel entonces, muchos no tenían acceso a Internet y no podían
descargar una copia vía FTP. ¿Qué podía decirles?
Podría haberles dicho: «Busca un amigo en la red y que te haga una copia». O
podría haber hecho lo mismo que hiciera con el PDP-10 Emacs original, a saber,
decirles: «Envíame una cinta y un SASE, y te lo devolveré por correo con una
copia de Emacs». Pero como no tenía trabajo y andaba buscando la manera de
ganar dinero con el software libre, anuncié que enviaría copias a cualquiera
interesado a cambio de ciento cincuenta dólares. Así comenzó mi empresa de
distribución de software libre, precursora de las empresas que hoy distribuyen
sistemas Linux basados en GNU.
Cuando un programa de software libre deja de estar en manos de su autor, esto
no significa necesariamente que siga siendo software libre para cualquiera que
se haga con una copia de él. Por ejemplo, el software de dominio público
—software sin copyright— es software libre, pero cualquiera puede
modificarlo y hacer una versión propietaria a partir de él. Lo mismo ocurre
con muchos programas libres con copyright que se distribuyen con licencias
simples muy permisivas que autorizan el desarrollo de versiones propietarias
modificadas.
El ejemplo paradigmático de este problema es el X Window System. Desarrollado
en el MIT y publicado como software libre con una licencia permisiva, pronto
fue adoptado por diversas empresas informáticas. Añadieron X, sólo en forma
binaria, a sus sistemas propietarios Unix, siempre acompañados del clásico
acuerdo de confidencialidad. Estas copias de X dejaron de ser software libre,
igual que Unix.
Los desarrolladores del X Window System no lo consideraron un problema—lo
esperaban y pretendían que eso ocurriera. Su objetivo no era la libertad sino
el «éxito», definido en función del número de usuarios. No les importaba si
éstos eran libres o no, bastaba con que fueran muchos.
Esto condujo a una situación paradójica, en la que dos maneras de medir el
grado de libertad dieron respuestas distintas a la pregunta «¿Es libre este
programa?» Si atendemos a la libertad que proporcionaban los términos de
distribución del MIT, entonces la conclusión es que el X era software libre.
Pero si tenemos en cuenta la libertad del usuario medio de X, la respuesta es
que se trataba de software propietario. La mayoría de los usuarios de X
utilizaban las versiones propietarias que venían con el sistema Unix, no la
versión libre.
El objetivo de GNU era proporcionar libertad a los usuarios, no simplemente
ser popular. De modo que necesitábamos idear unos términos de distribución que
impidieran que el software de GNU se convirtiera en software propietario. El
método que empleamos se denominó copyleft.
Copyleft utiliza la ley de copyright, pero dándole la vuelta para
servir a un propósito opuesto al habitual: en lugar de privatizar el software,
ayuda a preservarlo como software libre.
La idea fundamental del copyleft es que se autoriza la ejecución del programa,
su copia, modificación y distribución de versiones modificadas, siempre que no
se añada ninguna clase de restricción a posteriori. De este modo, las
libertades cruciales que definen el «software libre» quedan garantizadas para
cualquiera que posea una copia; estas libertades se convierten en derechos
inalienables.
Para que el copyleft sea efectivo las versiones modificadas deberán ser libres
también. Esto garantiza que cualquier tarea basada en nuestro trabajo se
pondrá a disposición de la comunidad si llegara a publicarse. Cuando los
programadores que tienen empleo se ofrecen voluntariamente a mejorar el
software GNU, sólo el copyleft impide que sus jefes les digan: «No podéis
compartir esos cambios, porque vamos a utilizarlos para crear nuestra versión
propietaria del programa».
El requisito de que los cambios sean libres es esencial para garantizar la
libertad de los usuarios del programa. Las empresas que privatizaron el X
Window System incorporaron ciertos cambios para instalarlo en sus sistemas y
en su hardware. Estos cambios eran pequeños comparados con la envergadura del
sistema, pero no eran en absoluto triviales. Si estos cambios se esgrimían
como excusa para denegar la libertad a los usuarios, cualquiera podría
aprovecharse de ello.
Al combinar un programa libre con un código no libre se plantea un problema
similar. Esta combinación acabaría siendo inevitablemente no libre; las
libertades suprimidas en la parte no libre del programa afectarán a éste en su
totalidad. Autorizar este tipo de combinaciones abriría un boquete lo bastante
grande para hundir el barco entero. Por lo tanto, un objetivo crucial del
copyleft es tapar este boquete: cualquier cosa añadida o combinada con un
programa copyleft, para formar una versión modificada deberá preservar su
condición de software libre y su copyleft.
Nosotros aplicamos una forma específica de copyleft para la mayor parte del
software de GNU, conocida como la GNU General Public License o para abreviar
GNU GPL. Recurrimos a otros tipos de copyleft según las circunstancias
específicas. También se aplica el copyleft a los manuales de GNU, pero
utilizamos una forma más sencilla, porque la complejidad de la GNU GPL resulta
innecesaria en estos casos.
En 1984 o 1985, Don Hopkins —un compañero con mucha imaginación— me envió
una carta. En el sobre había escrito una serie de proverbios, incluido el que
sigue: «Copyleft—quedan revocados todos los derechos». Empleé la palabra
«copyleft» para bautizar el concepto de distribución que andaba desarrollando
en aquel momento.
A medida que aumentaba el interés por Emacs, otros vinieron a sumarse al
proyecto GNU, y decidimos que era el momento de volver a buscar
fuentes de financiación. De este modo, en 1985 creamos la Free Software
Foundation, una organización sin ánimo de lucro dedicada al desarrollo de
software libre. La FSF también se hizo con la empresa de distribución de
copias de Emacs, a lo que más tarde añadiría otros programas
libres—no sólo de GNU— así como la venta de manuales libres.
La FSF acepta donaciones, pero la mayor parte de sus ingresos siempre procedió
de las ventas —de copias de software libre y de otros servicios relacionados
con éste. En la actualidad, vende CD-Rom de códigos fuente, CD-Rom con los
binarios, manuales cuidadosamente impresos —con total libertad para
redistribuirlos y modificarlos— y Deluxe Distributions —colecciones
enteras de software adaptadas a la plataforma de elección del cliente.
Los empleados de la Free Software Foundation han escrito y se han encargado
del mantenimiento de una serie de paquetes de software de GNU. Dos ejemplos
notables son la librería C y la shell. Todos los programas ejecutados en un
sistema GNU/Linux utilizan la librería C de GNU para comunicarse con Linux.
Fue desarrollada por un miembro de la plantilla de la Free Software
Foundation, Roland McGrath. La shell utilizada en la mayoría de los sistemas
GNU/Linux se llama BASH —acrónimo de Bourne Again Shell—, desarrollada por
otro empleado de la FSF, Brian Fox.
Financiamos el desarrollo de estos programas porque el proyecto GNU no se
reducía exclusivamente a las herramientas o al entorno de desarrollo. Nuestra
meta era un sistema operativo completo, y estos programas eran necesarios para
alcanzar nuestro objetivo.
Con el nombre de «Bourne again Shell» pretendíamos mofarnos de la «Bourne
Shell», la shell más común en Unix.
La filosofía del software libre rechaza una práctica empresarial concreta y
muy generalizada, pero no rechaza el negocio en general. Cuando una
empresa respeta la libertad de los usuarios, le deseamos mucho éxito.
La venta de copias de Emacs ilustra una clase de empresa relacionada con el
software libre. Cuando la FSF se hizo con el negocio, me vi obligado a
buscarme nuevamente la vida. Así fue como empecé a vender servicios
relacionados con el software libre que acababa de desarrollar. Esto incluía la
enseñanza de cuestiones como la programación de GNU Emacs, la modificación del
GCC a la medida del usuario o el desarrollo de software, normalmente para
instalar el GCC en nuevas plataformas.
Hoy por hoy, una serie de corporaciones se dedican a este tipo de servicios
relacionados con el software libre. Algunas distribuyen colecciones de
software libre en CD-Rom; otras proporcionan servicio técnico a distintos
niveles, contestando a las preguntas de los usuarios, subsanando bugs
o añadiendo nuevas funciones. Incluso, estamos empezando a ver empresas
dedicadas al lanzamiento de nuevos productos de software libre.
Pero debemos andarnos con cuidado —una serie de empresas asociadas con el
término «código abierto» basan su mercado en el software no libre que funciona
con software libre. No son empresas de software libre, su software es
propietario, y con sus productos pretenden tentar a los usuarios y despojarles
de su libertad. Se las conoce como empresas de «valor añadido», lo que refleja
los valores que querrían que adoptásemos: la comodidad antes que la libertad.
Si valoramos la libertad, deberíamos hablar de productos de «libertad
sustraída».
El principal objetivo de GNU era ser software libre. Aun cuando GNU no
entrañara ninguna ventaja técnica frente a Unix, sí tendría una ventaja
social, al permitir que los usuarios cooperaran, y otra ética, al respetar su
libertad.
Pero es natural aplicar al trabajo los criterios ya conocidos de buena
práctica —por ejemplo, la asignación dinámica de estructuras de datos para
evitar las limitaciones de tamaño fijadas arbitrariamente y el empleo de
códigos de ocho bits, siempre que esto resultara apropiado.
Por otro lado, rechazábamos ese empeño de Unix en conservar una memoria
reducida, y así decidimos no dar soporte a las máquinas de 16 bits —estaba
claro que las de 32 bits serían la norma, para cuando hubiéramos terminado
el sistema GNU — y no reducir la memoria a menos que superásemos un
megabyte. En los programas en que no fuera crucial administrar archivos de
gran tamaño, animábamos a los programadores a insertar un archivo de entrada
entero en el core, luego a escanear su contenido sin preocuparse del I/O.
Estas decisiones permitieron que muchos programas GNU superasen a sus
homólogos de Unix en fiabilidad y velocidad.
A medida que iba aumentaba la popularidad del proyecto GNU, la gente empezó a
donar ordenadores que operaban con Unix. Y fueron de gran utilidad, porque la
forma más fácil de desarrollar componentes de GNU era partiendo de un sistema
Unix y reemplazar sus componentes uno a uno. Pero esto nos planteó un dilema
ético: ¿era correcto poseer, aunque fuera tan solo una copia, de
Unix?
Unix era —y es— software propietario, y según la filosofía del proyecto
GNU no debíamos recurrir a él. Pero, al aplicar la misma lógica que nos lleva
a justificar el uso de la violencia en legítima defensa, concluí que era
igualmente legítimo utilizar un paquete propietario cuando éste resultara
crucial para desarrollar un sustituto libre que ayudaría a otros a dejar de
utilizar el paquete propietario.
Pero, aun cuando los medios justificaran el fin, no dejaban de ser medios poco
éticos. Hoy en día ya no tenemos ninguna copia de Unix, porque lo
reemplazamos por sistemas operativos libres. Cuando no podíamos sustituir el
sistema operativo de un ordenador por otro libre, entonces reemplazábamos el
ordenador entero.
A medida que avanzaba el proyecto GNU y se desarrollaron o descubrieron un
creciente número de componentes de sistema, nos pareció muy útil elaborar una
lista de asignaturas pendientes. La utilizamos para reclutar desarrolladores
que escribieran las piezas que faltaban. Esta lista se conoció como la lista
de tareas de GNU. Además de los componentes de Unix, incluimos en la lista
otros proyectos útiles de software y la documentación que, en nuestra opinión,
precisaba cualquier sistema completo.
En la actualidad, apenas figuran algunos componentes de Unix en la lista de
tareas de GNU —hemos llevado a cabo la mayor parte, a excepción de algunas
menos trascendentales. Pero la lista está repleta de proyectos que podrían
calificarse de «aplicaciones». Cualquier programa que despierte el interés de
algo más que un reducido grupo de usuarios se añadirá al sistema operativo.
Incluso llegamos a incluir juegos en esta lista —lo hicimos desde
el principio. Unix contenía juegos, así que lógicamente GNU tenía que hacer lo
propio. Pero la compatibilidad nunca fue un problema para los juegos, de modo
que no replicamos los de Unix. Optamos en cambio por una gama de distintas
clases de juegos que pensamos podrán gustar a los usuarios.
La librería C GNU utiliza un copyleft especial llamado GNU Library General
Public License, que autoriza el enlace de software propietario con la
librería. ¿Por qué permitir esta excepción?
No es una cuestión de principios. Ningún principio establece el derecho de los
productos de software propietario a incluir nuestro código —¿por qué
contribuir a un proyecto que niega el derecho a compartir? El uso de la LGPL
para la librería C, o para cualquier otra librería, responde más bien a una
estrategia.
La librería C desempeña tareas genéricas; todo sistema o compilador
propietario viene acompañado de una librería C. Por lo tanto, limitar nuestra
librería C al software libre no reportaría ninguna ventaja para éste
—hubiera desalentado el uso de nuestra librería.
Nuestro sistema es una excepción a este respecto: en el sistema GNU
—incluido GNU/Linux—, la librería C GNU es la única en C. Por lo que los
términos de distribución de la librería C GNU determinan si es posible o no
compilar un programa propietario para el sistema GNU. No existen razones
éticas para autorizar la incorporación de aplicaciones propietarias en el
sistema GNU, pero estratégicamente parece que prohibir esto desincentivaría el
uso del sistema GNU en lugar de alentar el desarrollo de aplicaciones libres.
Esta es la razón de que utilizar la Library GPL sea una buena estrategia para
la librería C. Para otras librerías, la estrategia a adoptar debe estudiarse
caso por caso. Si una librería desempeña una tarea especial que puede ayudar a
escribir ciertos tipo de programas, publicarla con GPL, limitándola
exclusivamente a los programas libres, será una manera de ayudar a otros
desarrolladores de software libre, proporcionándoles una ventaja frente al
software propietario.
Tomemos por ejemplo la GNU Readline,4 una librería desarrollada para la
edición de comandos para BASH. Readline se publica con una GNU GPL ordinaria,
no con la Library GPL. Es indudable que esto reduce el volumen de uso de
Readline, pero no supone una pérdida para nosotros. Por otro lado, se ha
desarrollado al menos una aplicación útil en software libre que puede utilizar
la Readline, y esto sí constituye un auténtico logro para la comunidad.
Los desarrolladores de software propietario cuentan con la ventaja que
proporciona el dinero; los de software libre deben idear ventajas
entre ellos. Espero que un día contemos con una amplia colección de
librerías con GPL sin paralelo en el mundo del software propietario, una
colección que proporcione módulos útiles que sirvan de base para el futuro
software libre y entrañen una ventaja decisiva para fomentar su desarrollo.
Eric Raymond dice que «todo buen trabajo de software empieza
cuando un desarrollador se plantea un reto personal». Es posible
que esté en lo cierto, pero muchos componentes esenciales del software GNU se
desarrollaron con el fin de crear un sistema operativo libre y completo. Su
origen está en una visión y un plan, no en un impulso individual.
Por ejemplo, desarrollamos la librería C GNU, la Bourne Again Shell (BASH) y
el GNU tar porque cualquier sistema similar a Unix precisaba de estos
componentes. Lo mismo puede decirse de mis propios programas —el compilador
C GNU, GNU Emacs, GDB y GNU Make.
Algunos programas GNU se desarrollaron para enfrentarse a amenazas específicas
sobre nuestra libertad. Por eso desarrollamos el gzip, para sustituir al
programa Compress cuando éste dejó de estar a disposición de la comunidad
gracias a las patentes LZW.5 Buscamos a gente que pudiera desarrollar el
LessTif, y más recientemente GNOME y Harmony, y así abordar los problemas
planteados por ciertas librerías propietarias —véase a continuación
«Librerías no libres». Estamos desarrollando el GNU Privacy Guard para
reemplazar el popular software de encriptación no libre, porque los usuarios
no deberían verse obligados a elegir entre su privacidad y su libertad.
Claro que la gente encargada de escribir estos programas empezó a interesarse
en el trabajo, y algunos añadieron muchas funciones para satisfacer sus
propias necesidades e intereses. Pero esa no es la razón de la existencia de
los programas.
Al iniciarse el proyecto GNU pensé que desarrollaríamos el sistema en su
totalidad y luego lo publicaríamos entero. Pero no fue así.
Dado que cada uno de los componentes del sistema GNU se implantó en un sistema
Unix, todos ellos podían ejecutarse en sistemas Unix mucho antes de que
existiera el sistema GNU. Algunos de estos programas se hicieron muy populares
y los usuarios empezaron a ampliarlos y a transportarlos —a las diversas
versiones incompatibles de Unix, y también a otros sistemas.
El proceso dotó de mayor potencia a estos programas, y atrajo tanto fondos
como colaboradores al proyecto GNU. Pero es probable que también retrasara la
concepción de un sistema mínimamente funcional durante varios años, dado que
los desarrolladores de GNU dedicaban la mayor parte de su tiempo al
mantenimiento de estos puertos y a la incorporación de funciones a los
componentes existentes, en vez de escribir los que faltaban.
En 1990, el sistema GNU estaba casi terminado. Faltaba crear un solo
componente central, el kernel. Decidimos crearlo como una colección de
procesos de servidor que se ejecutaría sobre Mach. Mach es un microkernel
desarrollado en la Carnegie Mellon University y, más tarde, en la Universidad
de Utah. El GNU Hurd es una colección de servidores —o «manada de
gnus»—implantados en Mach que desempeñan las diversas tareas propias del
kernel de Unix. Su desarrollo se retrasó mientras esperábamos la publicación
de Mach como software libre, tal y como nos habían prometido.
Una de las razones que nos impulsó a elegir este diseño era evitar lo que
parecía la parte más dura del trabajo: depurar un programa de kernel sin un
depurador de fuentes. Esto ya se había resuelto en Mach, y esperábamos depurar
los servidores Hurd como programas de usuarios, con el GDB. Pero pasó mucho
tiempo hasta que lo logramos, y los servidores multiproceso que se envían
mensajes entre sí resultan extremadamente difíciles de depurar. La
consolidación del Hurd ha llevado muchísimos años.
En principio, el kernel GNU no iba a llamarse Hurd. Su nombre
original era Alix —por mi novia de aquel momento. Ella era administradora de
sistemas Unix, y advirtió que su nombre casaba perfectamente con los nombres
escogidos para las distintas versiones de Unix. Bromeando, le dijo a sus
amigos: «Deberían bautizar un kernel con mi nombre». No dije nada, pero decidí
sorprenderla con un kernel llamado Alix.
Sin embargo, el nombre no se mantuvo. Michael Bushnell —ahora Thomas—, el
principal desarrollador del kernel, prefería el nombre de Hurd, y llamó Alix a
una parte del kernel —la encargada de capturar las llamadas del sistema y
administrarlas enviando mensajes a los servidores Hurd.
Por fin, Alix y yo nos separamos y ella se cambió de nombre. En cualquier
caso, el diseño de Hurd se modificó para que la librería C enviase mensajes
directamente a los servidores, lo que supuso la desaparición del componente
Alix.
Pero antes de todo esto, una amiga de Alix se encontró con el nombre en el
código fuente de Hurd y se lo contó. Así que el nombre cumplió su cometido.
El GNU Hurd no está listo para producción. Afortunadamente, otro kernel estaba
a nuestra disposición. En 1991, Linus Torvalds desarrolló un kernel compatible
con Unix y lo llamó Linux. En el año 1992, la combinación de Linux con el
incompleto sistema GNU resultó en un sistema operativo libre. [Esta
combinación fue, por supuesto, una labor extraordinaria]. Gracias a Linux
podemos ejecutar hoy una versión del sistema GNU.
Denominamos esta versión GNU/Linux para explicar su composición, una
combinación del sistema GNU con Linux como kernel.
Hemos demostrado ser capaces de desarrollar una amplia gama de software libre.
Esto no significa que seamos invencibles e imparables. Existen diversos retos
que plantean un futuro incierto para el software libre. Enfrentarnos a ellos
nos exigirá un esfuerzo constante y mucha resistencia, a veces por muchos
años. Necesitaremos la clase de determinación que exhibe la gente cuando
valora su libertad y la protege a toda costa.
En los cuatro apartados que siguen discutiremos estos retos.
Los fabricantes de hardware tienden cada vez más a mantener en secreto las
especificaciones del hardware. Esto dificulta enormemente la tarea de escribir
drivers libres para que Linux y Xfree866 sean compatibles con el
hardware nuevo. Hoy contamos con sistemas libres y completos, pero no
durarán mucho si no son compatibles con los ordenadores del mañana.
Hay dos formas de enfrentarse a este problema. Los programadores pueden hacer
ingeniería inversa para descubrir cómo crear programas compatibles con el
hardware. El resto podemos elegir qué hardware será compatible con el software
libre. A medida que aumente el número de usuarios de software libre, el
secretismo de estas especificaciones se convertirá en una política
contraproducente.
Hacer ingeniería inversa es una labor colosal. ¿Contaremos con programadores
lo bastante decididos para llevarla a cabo? Sí, siempre que les hayamos
convencido de que el software libre es una cuestión de principios y de que los
drivers no libres son intolerables. ¿Invertiremos dinero extra, e incluso
tiempo extra, para poder utilizar drivers libres? Sí, siempre y cuando se
generalice esta voluntad de recuperar nuestra libertad.
La librería no libre que opera en un sistema operativo libre constituye una
trampa para los desarrolladores de software libre. Las atractivas funciones de
la librería son el cebo perfecto; al utilizar la librería, caes en la trampa,
porque tu programa no puede integrarse de forma útil en un sistema operativo
libre. [Estrictamente hablando, podríamos incluir tu programa, pero éste no
podría ejecutarse sin la librería]. Y, lo que es peor, en caso de
popularizarse un programa que utilice una librería propietaria, podría
arrastrar a otros programadores desprevenidos hacia la misma trampa.
El primer ejemplo de este problema se presentó en los años ochenta, con el
Motif toolkit.7 Aunque entonces no había sistemas operativos
libres, estaba claro qué problema iba a plantearles el Motif más tarde. El
Proyecto GNU respondió de dos formas: planteando la necesidad de que los
proyectos individuales de software libre fueran compatibles tanto con los
toolkit widgets X libres como con Motif, y encargando la creación de un
sustituto libre para Motif. La tarea tardó muchos años en concluirse. Sólo en
1997 el LessTif, desarrollado por los Hungry Programmers, fue lo
suficientemente potente para la mayoría de las aplicaciones Motif.
Entre 1996 y 1998, otro toolkit no libre de Graphical User Interface (GUI)
llamado Qt se incorporó a una notable colección de software libre, el
escritorio KDE.
Los sistemas libres GNU/Linux no podían aprovechar el KDE porque no podíamos
emplear la librería. A pesar de ello, algunos distribuidores comerciales de
sistemas GNU/Linux, bastante flexibles a la hora de mezclar software
libre, añadieron el KDE a sus sistemas —lo cual daría lugar a un sistema con
más posibilidades y menos libertad. El grupo KDE animó activamente a otros
programadores a que utilizasen Qt, mientras que millones de nuevos «usuarios
de Linux» ni siquiera sospechaban que pudiera existir un problema al respecto.
La situación era desoladora.
La comunidad del software libre reaccionó de dos maneras: GNOME y Harmony.
GNOME, el GNU Network Object Model Environment, es el proyecto de escritorio
de GNU. Miguel de Icaza tomó la iniciativa en 1997, y se desarrolló con el
apoyo de Red Hat Software. GNOME pretendía proveer prestaciones similares,
pero usando exclusivamente software libre. Entraña algunas ventajas técnicas,
como la de ser compatible con varios lenguajes, y no sólo el C++. Pero su
principal propósito era la libertad, funcionar sin software no libre.
Harmony es una librería sustitutiva compatible, diseñada con el fin de
ejecutar software KDE sin recurrir a Qt.
En noviembre de 1998, los desarrolladores de Qt anunciaron un cambio de
licencia que, en caso de aplicarse, lo convertiría en software libre. Aunque
no podemos estar seguros de esto, creo que el cambio se debió en parte a la
firme respuesta de la comunidad ante el problema que planteaba la condición no
libre de Qt. [Esta nueva licencia es incómoda y no equitativa, por lo que
sigue siendo aconsejable evitar el uso de Qt8]
¿Cómo responderemos a la tentación que plantee la próxima librería no libre?
¿Comprenderá la comunidad la necesidad de mantenernos alejados de cualquier
trampa que se nos presente en el camino? ¿O renunciaremos a la libertad a
cambio de la comodidad, y dar lugar así a un problema mucho mayor? Nuestro
futuro depende de nuestra filosofía.
La amenaza más seria a la que nos enfrentamos procede de las patentes de
software, que pueden introducir algoritmos y funciones fuera del alcance del
software libre al menos durante veinte años. Las patentes del
algoritmo de compresión LZW se aplicaron en 1983, y todavía no podemos
publicar software libre que produzca GIFs adecuadamente comprimidos. En 1998,
se suspendió la distribución de un programa libre para producir archivos de
audio MP3 comprimidos bajo amenaza de una demanda judicial por
patente.
Existen formas de abordar la cuestión de las patentes: buscar pruebas que
demuestren la invalidez de una patente o buscar modos alternativos
para realizar una tarea. Pero estos métodos funcionan sólo de vez en cuando;
cuando fallan ambos, la patente puede resultar en un software libre
desprovisto de alguna función necesaria para los usuarios. ¿Qué haremos
entonces?
Quienes valoramos el software libre por la libertad que éste entraña
seguiremos en la misma línea. Lograremos sacar adelante el trabajo sin
funciones patentadas. Pero quienes valoran el software libre porque esperan
que sea técnicamente superior se inclinarán por calificarlo de fracaso cuando
este software se vea restringido por una patente. De modo que, a pesar de que
resulta muy útil discutir la efectividad práctica del modelo de desarrollo de
tipo «catedral» y la fiabilidad y potencia de ciertos programas de software
libre, debemos ir más allá. Debemos hablar de libertad y de principios.
La mayor deficiencia de nuestros sistemas operativos no reside en el software,
sino en la ausencia de buenos manuales libres para nuestros sistemas. La
documentación es una parte esencial de cualquier paquete de software; un
paquete importante de software libre sin un buen manual libre que lo acompañe
constituye un lastre considerable. Tenemos muchos ejemplos de ello en la
actualidad.
La documentación libre, al igual que el software, es una cuestión de libertad,
no de precio. Los criterios para el manual libre son bastante parecidos a los
del software libre: hay que darles a los usuarios ciertas libertades. Debe
autorizarse la redistribución —incluida la venta comercial— en papel y
on line, de modo que el manual pueda acompañar a todas las copias del
programa.
Autorizar su modificación resulta igualmente crucial. Por regla general, no
creo que la gente deba tener el derecho de modificar toda clase de artículos y
libros. Por ejemplo, no creo que ni tú ni yo estemos obligados a autorizar la
modificación de artículos como este, que describe nuestros actos y opiniones.
Pero existe una razón específica de que la libertad para modificar sea un
elemento crucial para la documentación relativa al software libre. Cuando los
individuos ejercen su derecho a modificar el software, y añadir o cambiar sus
funciones, si son lo bastante concienzudos cambiarán asimismo el manual —y
así proporcionarán una documentación concisa y útil junto con el programa
modificado. Un manual que no permita a los programadores trabajar
concienzudamente y terminar su labor no satisfará las necesidades de la
comunidad.
Algunos límites a la incorporación de estas modificaciones no plantean
problema alguno, como es el caso de los requisitos establecidos para preservar
la advertencia sobre copyright del autor original, los términos de
distribución o la lista de autores. O aquellos que exigen que las versiones
modificadas incluyan la fecha de la modificación, o que incluso prohíben la
supresión o alteración de secciones enteras, siempre que éstas no traten sobre
temas técnicos. Este tipo de restricciones no plantean un problema porque no
impiden al programador concienzudo adaptar el manual para que se ajuste al
programa modificado. Dicho de otro modo, no impiden que la comunidad de
software libre disfrute plenamente del uso del manual.
Sin embargo, debemos ser capaces de modificar el contenido «técnico» del
manual y luego distribuir el resultado en los medios y canales habituales; de
lo contrario, las restricciones obstruirán a la comunidad, el manual dejará de
ser libre y necesitaremos elaborar uno nuevo.
¿Contarán los desarrolladores de software libre con 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.
Actualmente, se calcula que existen diez millones de usuarios de sistemas
GNU/Linux como Debian GNU/Linux y Red Hat Linux. El software libre ha
desarrollado tales ventajas prácticas que está ganando adeptos por razones
puramente prácticas.
Las consecuencias positivas de esto son evidentes: un mayor interés por
desarrollar software libre, más clientes para las empresas de software libre y
una mayor capacidad para alentar a las empresas a desarrollar software libre
comercial en lugar de productos de software propietario.
Pero el interés en el software crece a un ritmo superior que la conciencia de
la filosofía en que se fundamenta, y esto plantea ciertas dificultades.
Nuestra capacidad para hacer frente a los desafíos y las amenazas
anteriormente descritos dependerá de nuestra voluntad de mantenernos firmes en
nombre de la libertad. Para convencer de ello a nuestra comunidad, habremos de
difundir la idea entre los nuevos usuarios que pasen a formar parte de ella.
Pero estamos fracasando: nuestros esfuerzos por atraer a nuevos usuarios a
nuestra comunidad superan con creces a nuestras iniciativas a la hora de
enseñarles los principios de nuestra comunidad. Debemos dedicarnos a ambos
objetivos y compensar nuestros esfuerzos en ambas direcciones.
La tarea de enseñar a los nuevos usuarios el valor de la libertad se complicó
especialmente en 1998, cuando parte de la comunidad decidió abandonar el
término «software libre» y empezó a hablar de «software de código abierto».
Los partidarios de este término trataban de evitar la confusión entre «libre»
y «gratuito»—un objetivo muy legítimo. Pero otros intentaban dejar a un lado
los principios que habían impulsado la creación del software libre y el
proyecto GNU, procurando así atraer a los ejecutivos y a los usuarios de
empresas, quienes comparten mayoritariamente una ideología que antepone las
ganancias económicas a la libertad, a la comunidad, a los principios. De modo
que la retórica del «código abierto» se concentra en la posibilidad de crear
un software de alta calidad y capacidad, pero rehuye las nociones de libertad,
comunidad y principios.
Un claro ejemplo de ello son las revistas «Linux» —están repletas de
anuncios de software propietario que funciona con GNU/Linux. Cuando aparezca
el próximo Motif, o Qt, ¿advertirán estas revistas a los programadores de
que se alejen de ellos, o los anunciarán sin más?
El apoyo de la comunidad empresarial puede contribuir al bien de la comunidad
de distintas maneras, siempre que partamos de unas condiciones de igualdad.
Pero si nos ganamos su apoyo callándonos lo que pensamos sobre la libertad y
los principios, el resultado puede ser desastroso, y sólo se agudizaría el
desequilibrio ya existente entre la difusión y la educación cívica.
Los términos «software libre» y «código abierto» describen más o menos la
misma categoría de software, pero implican cosas muy distintas acerca del
software y sus valores. El Proyecto GNU sigue empleando el término «software
libre» para expresar la idea de que la libertad, y no sólo la tecnología, es
importante.
La filosofía de Yoda —«No podemos sólo intentarlo»— suena bien, pero no
me sirve. He realizado mi trabajo siempre ansioso ante la perspectiva de que
no tuviera suficiente capacidad para ello, sin saber si mi labor bastaría para
alcanzar el objetivo deseado. Pero lo intenté de todas formas, porque entre el
enemigo y mi ciudad sólo estaba yo. Para mi sorpresa, a veces del éxito
obtenido.
En otras ocasiones 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 unirse a mí.
Hoy en día, a menudo me encuentro que no estoy solo. La visión de un
regimiento de hackers manos a la obra constituye una fuente de alivio y de
alegría, y pienso que la ciudad sobrevivirá por el momento. Pero con el
transcurso de los años los peligros son cada vez mayores, y ahora Microsoft
nos tiene en su punto de mira. No podemos pensar que el futuro de la libertad
está asegurado. ¡No os engañéis! Si quieres conservar tu libertad, tienes que
estar preparado para defenderla.
Resulta difícil dar con una definición sencilla de algo tan variado como es
el hacking, pero creo que lo que la mayor parte de los hackers
tienen en común es la pasión lúdica, la inteligencia y la voluntad de
exploración. Podemos decir que el hacking significa explorar los
límites de lo posible con un espíritu de sagacidad imaginativa. Cualquier
actividad en la que se despliegue esta sagacidad tiene «valor» para el
hacker. Puedes ayudar a subsanar este malentendido haciendo una simple
distinción entre la intromisión en la seguridad de un sistema y las
actividades de hacking, empleando el término cracking para
la primera. Quienes se dedican a esto se denominan crackers. Es
posible que un cracker sea también hacker, o ajedrecista, o golfista; pero la
mayoría no lo son («On Hacking», RMS; 2002).
El Xfree86 es un programa que
proporciona un entorno de escritorio que interactúa con tu hardware —ratón,
teclado, etc. Funciona en plataformas muy diversas.
Motif es una interfaz gráfica y administrador
de ventanas que opera en X Window, un potente sistema gráfico basado en una
arquitectura cliente/servidor.
