Mis experiencias con Lisp y el desarrollo de Emacs de GNU

---

Dado que ninguna de mis charlas habituales tiene nada que ver con Lisp, ninguna era apropiada para hoy. Así que voy a tener que improvisar. En cualquier caso, la cantidad de trabajo relacionado con Lisp que he hecho a lo largo de mi carrera es bastante amplia y debería ser capaz de decir algo interesante al respecto.

Mi primera experiencia con Lisp tuvo lugar en la escuela secundaria, cuando leí el manual de Lisp 1.5. Entonces quedé maravillado con la idea de que pudiera haber un lenguaje de programación así. La primera vez que tuve la oportunidad de hacer algo en Lisp fue siendo un novato en Harvard, cuando escribí un intérprete de Lisp para el PDP-11. Era una máquina muy pequeña, tenía algo así como 8k de memoria, y me las arreglé para escribir el intérprete en unas mil instrucciones. Eso me dejó sitio para unos pocos datos. Aquello fue antes de que llegara a conocer cómo era el software real, el que hacía el trabajo en los sistemas reales.

Fue tras comenzar mi trabajo en el MIT cuando empecé a trabajar en una implementación real de Lisp con JonL White. No fui contratado para el Laboratorio de Inteligencia Artificial gracias a JonL, sino por Russ Noftsker, lo cual es muy irónico teniendo en cuenta lo que vendría después. Debe de haber lamentado realmente lo ocurrido aquel día.

En la década de los 70, antes de que mi vida se politizara a causa de terribles sucesos, simplemente me dedicaba a hacer una extensión tras otra de varios programas, la mayoría de los cuales no tenía nada que ver con Lisp. Pero, al mismo tiempo, escribí un editor de textos: Emacs. Lo interesante de Emacs era que no solo incluía un lenguaje de programación, sino que además los comandos de edición de los que disponía el usuario estaban escritos en ese mismo lenguaje, de forma que permitía cargar nuevas instrucciones mientras se estaba editando. Podía modificar los programas que estaba utilizando e, inmediatamente, editar utilizando los programas recién modificados. Es decir, teníamos un sistema que resultaba útil para tratar con texto además de programar, y que, sin embargo, permitía al usuario programar el editor mientras lo estaba usando. No sé si era el primer sistema de estas características, pero, desde luego, sí el primer editor con tales prestaciones.

Esta construcción de programas complejos y gigantescos para usarlos en las ediciones de textos de uno, y después intercambiarlos con otros, alimentó el espíritu de cooperación espontánea que teníamos entonces en el Laboratorio de Inteligencia Artificial. La idea era que podía dar una copia de cualquier programa que tuviera a quien quisiera una. Compartíamos programas con todo el que deseara usarlos, eran conocimiento humano. Así que, a pesar de que no había un pensamiento político organizado que relacionara la forma en que compartíamos software con el diseño de Emacs, estoy convencido de que había una conexión entre ellos, quizá una conexión inconsciente. Creo que fue la naturaleza de la forma de vida que llevábamos en el Laboratorio de Inteligencia Artificial lo que condujo a Emacs e hizo de él lo que fue.

El Emacs original no incluía Lisp. Su lenguaje, de más bajo nivel y no interpretado, era Ensamblador del PDP-10. El intérprete que escribimos nosotros en realidad no fue escrito para Emacs, sino para TECO. TECO era nuestro editor de textos y era un lenguaje de programación extremadamente feo, no podía haber sido más feo. La razón era que no fue diseñado para ser un lenguaje de programación, sino como un lenguaje de órdenes y un editor de textos. Había órdenes como 5l, que significaba «mover cinco líneas», o i seguido de una cadena de caracteres y después ESC para insertar esa cadena de caracteres. Podría escribir una cadena de caracteres que fuera una secuencia de órdenes, lo que se llamaba una cadena de órdenes, terminada con ESC ESC, y sería ejecutada.

Bien. La gente quería extender este lenguaje con elementos útiles para la programación, así que añadió algunos. Por ejemplo, uno de los primeros fue una estructura iterativa: < >. Encerrar algo entre estos signos hacía que se ejecutara en un bucle. Había otras crípticas órdenes que podían usarse para salir del bucle condicionalmente. Para construir Emacs, nosotros [1] añadimos mecanismos para tener subrutinas con nombres. Antes de esto, de forma análoga a lo que ocurre con Basic, los nombres de las subrutinas sólo podían estar formados por una letra. Con esta limitación era difícil escribir programas grandes, así que añadimos código que permitió que pudieran tener nombres más largos. De hecho, había algunos mecanismos bastante sofisticados; creo que Lisp tomó su mecanismo unwind-protect, llamémosle, «de-aplicación-abierta», de TECO.

Empezamos a añadir otros mecanismos sofisticados, todos ellos con la sintaxis más horrible que puedan imaginar, y funcionó, por lo menos la gente fue capaz de escribir programas extensos con él. La lección obvia fue que utilizar un lenguaje como TECO, que no había sido diseñado como lenguaje de programación, fue una opción equivocada. El lenguaje sobre el que construye sus extensiones no debería ser considerado como un lenguaje de programación a posteriori, sino que debería ser diseñado como un lenguaje de programación desde un principio. De hecho, descubrimos que el mejor lenguaje de programación para ese propósito era Lisp.

Fue Bernie Greenberg quien descubrió que lo era  [2]. Escribió una versión de Emacs en Multics MacLisp, y programó sus órdenes en MacLisp de forma sencilla. El propio editor estaba escrito enteramente en Lisp. Multics Emacs fue un gran éxito: programar nuevas órdenes de edición era tan práctico que incluso los administrativos empezaron a aprender a hacerlo en sus oficinas. Utilizaban un manual que mostraba cómo extender Emacs, pero que no lo llamaba programación, de forma que los administrativos, que pensaban que no sabían programar, no se asustaran. Leyeron el manual, descubrieron que podían hacer cosas útiles y aprendieron a programar.

Así que Bernie vio que una aplicación, un programa creado para solucionar problemas prácticos, que llevara incorporado LISP, de forma que pudiera extender las funcionalidades que este trae por defecto, incluso reescribirlas enteramente, era en sí misma un muy buen medio de aprender a programar. Le da a uno la oportunidad de ajustar dichas utilidades a su medida, algo que en la mayoría de las situaciones simplemente no puede hacer. Lo cual es estimulante en sí mismo y le mueve a extender las aplicaciones, y transitar así desde el momento más duro, en el que asume que no es capaz de programar, hasta aquel en que está, de hecho, programando.

Llegado este punto, la gente se empezó a preguntar cómo podría conseguir algo así en una plataforma que no poseyera una implementación de Lisp completa. Multics MacLisp tenía tanto un compilador como un intérprete, era un sistema Lisp con todas las de la ley, pero la gente quería implementar algo similar en otros sistemas para los cuales todavía no había programado un compilador de Lisp. Bien, si no tenía el compilador de Lisp no podía escribir todo el editor en Lisp: resultaría demasiado lento, especialmente al refrescar la pantalla, si tenía que ejecutarse en Lisp interpretado. Así que desarrollamos una técnica híbrida. La idea era escribir conjuntamente un intérprete de Lisp y los fragmentos de nivel más bajo del editor, de forma que algunos fragmentos del editor fueran mecanismos incorporados en el intérprete de Lisp. Estos fragmentos serían todas aquellas partes que consideráramos que teníamos que optimizar. Ya habíamos utilizado esta técnica en el Emacs original, cuando reescribimos en lenguaje máquina algunas funciones de nivel relativamente alto, transformándolas en primitivas TECO. Por ejemplo, había una primitiva TECO para rellenar un párrafo (en realidad, para hacer casi todo el trabajo necesario para rellenar un párrafo, porque algunas de las tareas que menos tiempo consumían eran realizadas en un nivel superior por un programa TECO). Se podría haber hecho todo el trabajo con un programa TECO, pero habría resultado demasiado lento, por eso lo optimizamos escribiendo parte de él en lenguaje máquina. Esa misma idea es la que usamos aquí (en la técnica híbrida): escribimos la mayoría del editor en Lisp, pero escribimos en un nivel inferior algunas partes que tenían que ejecutarse particularmente rápido.

Por lo tanto, cuando escribí mi segunda implementación de Emacs seguí el mismo esquema. El lenguaje de bajo nivel ya no era lenguaje máquina, sino C. C era un lenguaje bueno y eficiente para programas portátiles que fueran a ejecutarse en un sistema operativo tipo Unix. Había un intérprete de Lisp, pero implementé directamente en C funciones para tareas de edición de propósito específico: manipular las zonas de memoria intermedia [buffers] del editor, insertar texto por delante, leer y escribir ficheros, refrescar la pantalla con el contenido de la memoria intermedia y gestionar la ventanas del editor.

Ahora bien, este no fue el primer Emacs escrito en C y que se ejecutaba en Unix. El primero lo escribió James Gosling, y era conocido como GosMacs. Con James ocurrió algo extraño. Al principio parecía estar influido por el mismo espíritu de participación y cooperación del Emacs original. En primer lugar liberé el Emacs original para personal del MIT. Alguien quería adaptarlo para su ejecución en Twenex, inicialmente sólo se podía ejecutar sobre el Incompatible Timesharing System [sistema de tiempo compartido incompatible] que usábamos en el MIT. Lo adaptaron a Twenex, lo cual significaba que había unos pocos cientos de instalaciones alrededor del mundo que podían, potencialmente, usarlo. Empezamos a distribuírselo junto con la norma de que «usted debía enviarnos todas sus mejoras» para que así todos nos pudiéramos beneficiar. Nadie intentó nunca hacer cumplir esta norma pero, hasta donde yo sé, la gente cooperaba.

Inicialmente Gosling parecía participar de este espíritu. Escribió en un manual que llamó Emacs al programa con la esperanza de que otros miembros de la comunidad lo mejoraran hasta que llegara a ser merecedor de ese nombre. Esa es la forma correcta de enfocar la relación con la comunidad, pedirle que se una al proyecto y mejore el programa. Pero más adelante pareció cambiar el espíritu, y lo vendió a una empresa.

Por aquel entonces yo estaba trabajando en el sistema GNU (un sistema operativo libre tipo Unix al que mucha gente llama erróneamente «Linux»). No había ningún editor Emacs que pudiera ejecutarse en Unix y que fuera software libre. No obstante, tenía un amigo que había participado en el desarrollo del Emacs de Gosling. Gosling le había dado permiso, por correo electrónico, para distribuir su propia versión. Me propuso que usara esa versión. Entonces me di cuenta de que el Emacs de Gosling no incluía un Lisp real. Tenía un lenguaje de programación conocido como «mocklisp», que sintácticamente parece Lisp pero que no tiene sus estructuras de datos. Así, los programas no eran datos, y carecía de elementos vitales de Lisp. Sus estructuras de datos eran cadenas de caracteres, números y unos pocos elementos especializados más.

Llegué a la conclusión de que no podía utilizarlo y tuve que reemplazarlo por completo, para lo cual el primer paso fue escribir un intérprete de Lisp real. Gradualmente adapté cada componente del editor basándolo en estructuras de datos de Lisp real, en lugar de estructuras de datos ad hoc, y haciendo las estructuras de datos internas del editor visibles y manipulables por los programas Lisp del usuario.

La excepción fue redisplay. Durante mucho tiempo, redisplay fue una especie de universo paralelo. El editor pasaba al universo de redisplay y todo funcionaba con estructuras de datos muy especiales que no eran seguras para la recolección de memoria [garbage collection], no eran seguras frente a interrupciones, y no podía ejecutar ningún programa Lisp mientras tanto. Posteriormente lo hemos modificado, ahora se puede ejecutar código Lisp concurrentemente con redisplay. Es algo muy práctico.

Este segundo Emacs era «software libre» en el sentido moderno del término: formaba parte de una campaña política explícita para la elaboración de software libre. La esencia de la campaña era que todo el mundo debería tener la libertad de hacer lo que nosotros hacíamos en el MIT en los viejos tiempos: trabajar conjuntamente en el software y colaborar con todo el que quisiera trabajar con nosotros. Esta es la base del movimiento por el software libre, la experiencia que tuve, la vida que viví en el Laboratorio de Inteligencia Artificial del MIT: trabajar para el conocimiento, y no obstaculizar su uso ni su expansión.

En esa época, podía construir un ordenador por un precio similar al de otros ordenadores que no estaban pensados para usar Lisp, en el cual Lisp se ejecutaría mucho más rápido y que incluiría validación de tipos en cada operación. Los ordenadores normales típicamente le forzaban a elegir entre velocidad de ejecución y buena validación de tipos. O sea que sí, podía tener un compilador de Lisp y ejecutar sus programas con velocidad, pero cuando sus programas intentaban tomar car de un número, obtenían resultados absurdos y terminaban por fallar o bloquearse.

La máquina Lisp podía ejecutar instrucciones aproximadamente a la misma velocidad que esas otras máquinas, pero para cada instrucción una instrucción car validaría los tipos de los datos, de modo que cuando se intentara obtener el car de un número en un programa compilado, devolvería un error inmediato. Construimos la máquina y un sistema operativo Lisp para ella. Estaba escrito en Lisp casi en su totalidad, con las únicas excepciones de algunos fragmentos escritos en microcódigo. Hubo quien se interesó en fabricarla, lo que significaba fundar una empresa.

Había dos visiones diferentes sobre cómo debería ser esa empresa. Greenblatt quería fundar lo que él llamaba una empresa «hacker». Esto quería decir que sería una empresa gestionada por hackers y que operaría de un modo propicio para hackers. Otro objetivo era mantener la cultura del Laboratorio de Inteligencia Artificial  [3]. Desafortunadamente, Greenblatt no tenía experiencia empresarial, por lo que otros miembros del grupo de la máquina Lisp expresaron sus dudas sobre el éxito de la empresa. Pensaban que su plan para evitar inversiones externas no funcionaría.

¿Por qué quería evitar la inversión externa? Porque cuando una empresa tiene inversores externos, éstos toman el control y no permiten que tenga ningún escrúpulo. Y, si usted tiene algún escrúpulo, finalmente le relevan de sus funciones directivas.

La idea de Greenblatt era encontrar un cliente que pagara sus máquinas por adelantado para poder comprar las piezas necesarias. Construirían las máquinas y las entregarían; con los beneficios obtenidos podrían comprar las piezas para unas pocas máquinas más, venderlas, comprar piezas para un número mayor de máquinas, y así sucesivamente. Los otros miembros del grupo pensaban que lo más probable era que el plan no saliera bien.

Entonces Greenblatt reclutó a Russell Noftsker, la persona que me había contratado, quien había dejado el Laboratorio de Inteligencia Artificial y creado una empresa exitosa. Russell era considerado una persona con aptitudes para los negocios. Demostró serlo al decir a los otros miembros del grupo: «deshagámonos de Greenblatt, olvidad sus ideas, y fundaremos otra empresa». Apuñalando por la espalda, sin duda un auténtico hombre de negocios. Decidieron crear una empresa llamada Symbolics. Obtendrían financiación externa, no tendrían escrúpulos y harían todo lo posible por ganar.

Pero Greenblatt no se dio por vencido. Fundó, junto con los pocos que permanecieron leales a él, Lisp Machines Inc. y siguió adelante con sus planes. ¡Y tuvieron éxito! Consiguieron el primer cliente y éste les pagó por adelantado. Construyeron las máquinas y las vendieron, y construyeron más y más máquinas. Tuvieron éxito a pesar de no contar con la ayuda de la mayor parte de los miembros del grupo. Symbolics también empezó con buen pie, así que había dos empresas de máquinas Lisp compitiendo. Cuando Symbolics vio que LMI no se iba a caer de bruces empezó a buscar maneras de destruirla.

Por lo tanto, al abandono de nuestro laboratorio le siguió la «guerra» en nuestro laboratorio. El abandono tuvo lugar cuando Symbolics se llevó a todos los hackers, excepto a los pocos que trabajaban a tiempo parcial en LMI y a mí mismo. Luego apelaron a una norma y eliminaron a la gente que trabajaba a tiempo parcial para el MIT, que tuvo que marcharse, lo cual me dejo sólo a mí. En ese momento el Laboratorio de Inteligencia Artificial estaba indefenso. Y, además, el MIT había llegado a un acuerdo muy poco sensato con esas dos empresas. Era un contrato a tres bandas por el que ambas empresas autorizaban el uso de las fuentes del sistema de la máquina Lisp. Estas empresas debían permitir al MIT usar sus modificaciones. Pero el contrato no decía que el MIT tuviera derecho a instalarlas en las máquinas Lisp para cuyo uso le habían otorgado licencia ambas empresas. Nadie había previsto que el grupo de hackers del Laboratorio de Inteligencia Artificial sería aniquilado, pero lo fue.

A Symbolics se le ocurrió un plan [4]. Dijeron al laboratorio: «seguiremos permitiéndoles que usen nuestras modificaciones al sistema, pero no podrán instalarlas en la máquina Lisp del MIT. En su lugar, les daremos acceso al sistema de la máquina Lisp de Symbolics, y podrán ejecutarlo, pero eso será todo lo que podrán hacer».

Esto, en la práctica, significaba que nos exigían posicionarnos en un bando y utilizar, o bien la versión del MIT del sistema, o bien la versión de Symbolics. Nuestra decisión determinaría a qué sistema irían nuestras mejoras. Si mejorábamos la versión de Symbolics, estaríamos apoyando a Symbolics exclusivamente. Si utilizábamos y mejorábamos la versión del sistema del MIT, ambas empresas tendrían acceso a nuestro trabajo. Pero Symbolics vio que estaríamos dando apoyo a LMI porque estaríamos ayudando a que siguiera existiendo. Así, no se nos permitió seguir siendo neutrales.

Hasta ese momento yo no había tomado partido por ninguna de las dos empresas, aunque me entristecía ver lo que le había ocurrido a nuestra comunidad y al software. Pero ahora, Symbolics había forzado la situación. Así que, en un intento por ayudar a mantener Lisp Machines Inc. a flote [5], empecé a duplicar todas las mejoras que había hecho Symbolics al sistema de la máquina Lisp. Escribí por mí mismo las mejoras equivalentes de nuevo (es decir, el código era mío).

Después de un tiempo [6], llegué a la conclusión de que sería mejor ni siquiera mirar su código. Cuando anunciaban la liberación de una actualización del código, podía ver en las notas correspondientes a la nueva liberación cuáles eran las modificaciones introducidas e implementarlas. Cuando ellos hacían finalmente la liberación de las modificaciones, yo también liberaba las mías.

De esta manera, durante dos años evité que acabaran con Lisp Machines Incorporated, y las dos empresas siguieron adelante. Pero no quería pasarme años y años castigando a alguien, evitando que se cometiera un acto malvado. Supuse que ya habían sido castigados bastante puesto que estaban inmersos en una competición que no tendría fin  [7]. Por otro lado, había llegado el momento de formar una nueva comunidad que reemplazara a la que las acciones suyas y de otros exterminaron.

La comunidad Lisp en los setenta no estaba limitada al Laboratorio de Inteligencia Artificial del MIT, y no todos los hackers estaban en el MIT. La guerra iniciada por Symbolics fue lo que aniquiló el MIT, pero había otras actividades en marcha. Había gente que abandonó la cooperación, y esto también contribuyó a extinguir la comunidad.

Una vez que dejé de castigar a Symbolics, tuve que pensar qué hacer a continuación. Tenía que hacer un sistema operativo libre, eso estaba claro. La única forma de que la gente pudiera trabajar conjuntamente y compartir era con un sistema operativo libre.

Al principio pensé en hacer un sistema basado en Lisp, pero me di cuenta de que no sería una buena idea desde el punto de vista técnico. Para tener algo como el sistema de la máquina Lisp, se necesita un tipo de microcódigo llamado «de propósito específico». Eso es lo que hizo posible ejecutar programas con la misma velocidad con la que se ejecutaban programas en otros ordenadores y con el beneficio adicional de la validación de tipos. Sin eso, se habría visto limitado a algo similar a los compiladores Lisp para otras máquinas. Los programas habrían sido más rápidos, pero inestables. Ahora bien, eso puede ser admisible si está ejecutando un programa en un sistema de tiempo compartido: que un programa falle no es un desastre, es algo que ocurre ocasionalmente. Pero no es admisible cuando lo que escribimos es el sistema operativo, así que rechacé la idea de hacer un sistema como la máquina Lisp.

En su lugar, decidí hacer un sistema operativo tipo Unix que tuviera implementaciones Lisp, las cuales serían ejecutadas como programas de usuario. El núcleo no estaría escrito en Lisp, pero tendríamos Lisp. Así que el desarrollo de ese sistema operativo, el sistema operativo GNU, fue lo que me llevó a escribir Emacs de GNU. Al hacerlo, me propuse como meta hacer la implementación de Lisp mínima posible. El tamaño de los programas era algo a tener muy en cuenta.

Había gente en aquellos días, en 1985, que tenía máquinas con un megabyte de memoria y sin memoria virtual. Querían poder usar Emacs de GNU. Esto significaba que tenía que hacer que el programa fuera lo más pequeño posible.

Por ejemplo, en aquel entonces la única estructura iterativa era while, implementada de forma extremadamente simple. No había ningún mecanismo para interrumpir la ejecución de la sentencia while y transferir el control a la instrucción siguiente a dicha sentencia, usted tenía que hacer un catch y un throw, o monitorizar una variable para salir del bucle. Esto muestra hasta dónde estaba llevando las cosas para mantener los programas pequeños. No teníamos caar, cadr, etc. Había que sacarle el mayor jugo posible, ese fue el espíritu de Emacs de GNU, el espíritu de Emacs Lisp desde el principio.

Evidentemente, las máquinas actuales tienen mayor capacidad, y ya no hacemos las cosas así. Ahora incluimos caar, cadr, etc. Y podríamos añadir otra estructura iterativa un día de estos. Queremos ampliarlo en cierta medida, pero no hasta el punto de Common Lisp. Una vez implementé Common Lisp en una máquina Lisp, y no estoy muy satisfecho con el resultado. Algo que no me gusta gran cosa son los parámetros de palabra clave [8]. No me parecen muy de Lisp; los utilizo a veces pero intento hacerlo lo menos posible.

Ese no fue el fin de los proyectos de GNU implicados con Lisp. Más tarde, alrededor de 1995, estábamos estudiando el inicio de un proyecto de escritorio gráfico. Teníamos claro que queríamos un lenguaje de programación que hiciera fácilmente extensibles, como el editor, los programas accesibles desde el escritorio. La cuestión era cuál.

En aquel momento, TCL estaba recibiendo un fuerte impulso como lenguaje a utilizar para este propósito. Yo tenía una opinión muy negativa de TCL, básicamente porque no era Lisp. Tiene un ligerísimo parecido con Lisp, pero no semánticamente, y no es tan limpio. Después, me mostraron un anuncio en el que Sun ofrecía un puesto de trabajo para trabajar con TCL y hacer de él el «lenguaje de extensión estándar, de facto» en el mundo. Y pensé: «Tenemos que evitar que eso llegue a ocurrir.». Así que empezamos a hacer de Scheme el lenguaje para extensiones estándar para GNU. No Common Lisp, porque era demasiado voluminoso. La idea era tener un intérprete Scheme diseñado para ser enlazado en las aplicaciones de la misma manera que se enlazaba TCL. Entonces lo recomendaríamos como el paquete para extensiones prefererido para todos los programas GNU.

Usted puede obtener un beneficio interesante del uso de un lenguaje tan potente como un dialecto de Lisp como su lenguaje primario de extensión: puede implementar otros lenguajes traduciéndolos a su lenguaje primario. Si su lenguaje primario es TCL, usted no podrá implementar Lisp fácilmente mediante su traducción a TCL. Pero si su lenguaje primario es Lisp, no es tan difícil implementar otros lenguajes traduciéndolos. Nuestra idea era que si cada aplicación extensible admitía Scheme, usted podría escribir una implementación de TCL o Python o Perl en Scheme que tradujera los programas en esos lenguajes a Scheme. Entonces, usted podría cargar su traductor en cualquier aplicación y extender dicha aplicación usando su lenguaje favorito.

Mientras los lenguajes de extensión sean débiles, los usuarios sólo pueden usar los lenguajes proporcionados por el programador. Lo que significa que a quien le guste utilizar un lenguaje de programación determinado tiene que competir por la elección de los diseñadores de aplicaciones diciendo «por favor, programador, ponga mi lenguaje en su aplicación, no el lenguaje de aquél.». Después los usuarios no tienen ninguna opción, la aplicación viene con un lenguaje y tienen que quedarse con él. Pero cuando dispone de un lenguaje potente que puede implementar otros mediante la traducción, da al usuario la posibilidad de elegir el lenguaje y ya no hay necesidad de una guerra de lenguajes. Esto es lo que esperamos que haga «Guile», nuestro intérprete Scheme. El verano pasado tuvimos a una persona trabajando en la finalización de un traductor de Python a Scheme. No sé si ya está completamente terminado, pero cualquiera que esté interesado en este proyecto, por favor póngase en contacto. Este es nuestro plan para el futuro.

Esta charla no es sobre software libre, pero déjenme comentarles brevemente lo que significa. Software libre no se refiere al precio¹, no significa que usted lo obtiene gratis (puede haber pagado por una copia, o haberla obtenido gratis.). Lo que significa es que usted tiene libertad como usuario. Lo fundamental es que es libre de ejecutar el programa, libre de estudiar qué hace, libre de modificarlo para adaptarlo a sus necesidades, libre de redistribuir las copias de otros y libre de publicar versiones mejoradas, ampliadas. Esto es lo que significa software libre. Si utiliza un programa que no es libre, pierde una libertad crucial, así que no lo haga nunca.

El propósito del proyecto GNU es hacer más fácil para la gente rechazar el software que no sea libre, pisotea libertades y domina usuarios, proporcionándole software libre para sustituirlo. Para aquellos que no tienen el valor moral de rechazar el software que no es libre cuando hacerlo representa un inconveniente práctico, lo que intentamos hacer es ofrecer una alternativa libre de forma que puedan mudarse a la libertad de forma más ordenada y con menos sacrificios en términos prácticos. Cuanto menor el sacrificio, mejor. Queremos hacer más fácil vivir en libertad, cooperar.

Es una cuestión de libertad para cooperar. Solemos pensar en la libertad y en la cooperación con la sociedad como si fueran opuestos. Pero aquí están del mismo lado. Con software libre es libre de cooperar con otros así como libre de ayudarse a usted mismo. Con software que no es libre, alguien le está dominando y está manteniendo dividida a la gente. No se le permite compartir con el resto, no es libre de cooperar ni de ayudar a la sociedad, como tampoco es libre de ayudarse a usted mismo. Divididos y desamparados es como se encuentran los usuarios de software que no es libre.

Hemos producido una enorme variedad de software libre. Hemos hecho lo que la gente decía que nunca lograríamos hacer; tenemos dos sistemas operativos de software libre. Tenemos muchas aplicaciones y, obviamente, todavía tenemos mucho camino por recorrer. Así que necesitamos su ayuda. Me gustaría pedirles que colaboraran como voluntarios para el proyecto GNU; ayúdennos a desarrollar software libre para más tareas. Echen un vistazo a gnu.org/help para encontrar sugerencias sobre cómo ayudar. Si quieren hacer algún pedido, hay un enlace disponible en la página principal. Si quieren leer sobre cuestiones filosóficas, miren en /philosophy. Si están buscando el software libre disponible, miren en /directory, donde se listan alrededor de 1900 paquetes en la actualidad (lo cual es una fracción de todo el software libre disponible ahí fuera). Por favor, escriban más software y contribuyan. Mi libro de ensayos, «Free Software and Free Society» se encuentra a la venta y puede adquirirse en www.gnu.org [9]². ¡Feliz hacking!

Notas

1. Guy Steele diseñó el conjunto de órdenes simétrico original de Emacs; luego, él y yo empezamos a implementar Emacs (sobre TECO), pero, tras una larga sesión conjunta de desarrollo, Steele empezó a distanciarse, así que yo finalicé Emacs. Otros, entre los que destacan Eugene C. Cicciarelli y Mike McMahon, contribuyeron más tarde de forma sustancial.
2. Bernie Greenberg dice que Dan Weinreb implementó Emacs para la Máquina Lisp antes de que Greenberg lo implementara para Multics. Pido disculpas por el error.
3. El plan de Greenblatt, según lo entendía yo, era contratar a la gente del laboratorio a tiempo parcial, de forma que pudieran seguir trabajando en el Laboratorio de Inteligencia Artificial. En cambio, Symbolics les contrató a jornada completa, así que dejaron de trabajar en el MIT.
4. Las circunstancias de este plan, que no expuse explícitamente en la charla, fueron las siguientes: durante un periodo inicial los hackers que habían dejado el Laboratorio de Inteligencia Artificial, tanto los que trabajaban para Symbolics como los que lo hacían para LMI, continuaron aportando al sistema de la máquina Lisp del MIT sus modificaciones, a pesar de que el contrato no lo exigía. El plan de Symbolics era provocar unilateralmente la ruptura de esta cooperación.
5. No era que me preocupara especialmente el destino de LMI, sino más bien que no quería que Symbolics saliera vencedora gracias a haber agredido como lo hizo al Laboratorio de Inteligencia Artificial.
6. Esta afirmación ha sido malinterpretada atribuyéndole el significado de que nunca miré el código de Symbolics. En realidad dice que sí lo hice, al principio. El código fuente de Symbolics estaba disponible en el MIT, por lo tanto yo podía leerlo, y al principio era así como me enteraba de sus modificaciones.

   Pero eso significaba que tenía que hacer un esfuerzo especial para resolver cada problema de forma diferente, para evitar que mi código fuera una copia del código de Symbolics. Pasado un tiempo, llegué a la conclusión de que era mejor no mirarlo. De esa forma podía escribir el código de la forma que considerara mejor sin preocuparme de lo que contenía el código de Symbolics.

7. En una ocasión Symbolics se quejó al MIT de que mi trabajo, al frustrar sus planes, le había costado un millón de dólares.
8. No me molesta si una función muy compleja y avanzada toma parámetros de palabras clave. Lo que me molesta es ponerlas en funciones simples y básicas como «member».
9. En 2021, este libro (en inglés) puede adquirirse en GNU Press.