[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNU-traductores] old-gnudist:/home/www/html/gnu/thegnuproject.es.html -
|
From: |
old-gnudist's file diff daemon |
|
Subject: |
[GNU-traductores] old-gnudist:/home/www/html/gnu/thegnuproject.es.html -- New file |
|
Date: |
Tue, 15 Jan 2002 06:31:39 -0800 (PST) |
This is an automated report from old-gnudist.
This appears to be a new file or has only recently been added to
the list of monitored files:
61 -rw-rw-r-- 1 webcvs www 60897 Feb 12 2001
/home/www/html/gnu/thegnuproject.es.html
Contents:
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.5 [en] (X11; I; Linux 2.2.13 i586)
[Netscape]">
<title>El Proyecto GNU - Fundación para el Software Libre (Free
Software Foundation (FSF))</title>
<!-- -*- coding:iso-8859-1.unix; -*- -->
<!-- http://www.gnu.org/gnu/thegnuproject.html -->
<link REV="made" HREF="mailto:address@hidden";>
</head>
<body text="#000000" bgcolor="#FFFFFF" link="#1F00FF" vlink="#9900DD"
alink="#FF0000">
<h3>
El Proyecto GNU</h3>
por <b><a href="http://www.stallman.org/rms.es.html";>Richard Stallman</a></b>
<p> publicado originalmente en el libro «Open Sources»
<p><a href="/graphics/whats-gnu.es.html"><img SRC="/graphics/whats-gnu-sm.jpg"
ALT="[Imagen de Qué es un Ñu (GNU)]" height=120 width=125></A>
[ <a href="/gnu/thegnuproject.html">Inglés</a> | <a
href="/gnu/thegnuproject.ru.html">Ruso</a>
]
<h3>
La primera comunidad que comparte el software</h3>
Cuando comencé a trabajar en el Laboratorio de Inteligencia Artificial
del MIT en 1971, me incorporé a una comunidad que compartía
el software que ya tenía varios años de existencia. El acto
de compartir software no estaba limitado a nuestra comunidad en particular;
es tan antiguo como las computadoras, de la misma manera que compartir
recetas es tan antiguo como cocinar. Pero nosotros lo hacíamos en
mayor grado que la mayoría de los otros.
<p>El Laboratorio de IA usaba un sistema operativo denominado ITS
(<i>Incompatible
Timesharing System</i>) [Sistema incompatible de tiempo compartido] que
los hackers (1) del <i>staff</i> habían diseñado y escrito
en lenguaje ensamblador para la PDP-10 de Digital, una de las más
grandes computadoras de la época. Mi trabajo como miembro de esta
comunidad, como hacker de sistema en el <i>staff</i> del laboratorio de
IA, era mejorar este sistema.
<p>No denominábamos «software libre» a nuestro software
porque dicho término no existía; pero éso es lo que
era. Cuando alguien de otra universidad o compañía deseaba
portar y usar un programa, lo permitíamos con gusto. Si usted veía
a alguien usando un programa interesante y poco conocido, siempre se
podía
pedir el código fuente para verlo, de manera que uno podía
leerlo, cambiarlo, o canibalizar ciertas partes del mismo para hacer un
nuevo programa.
<p>(1) El uso de «hacker» para referirse al «quebrantador
de la seguridad» es una confusión proveniente de los medios
masivos. Nosotros los hackers nos negamos a reconocer dicho significado,
y continuamos utilizando la palabra para indicar a «alguien apasionado
por la programación y que disfruta al ser hábil e
ingenioso».
<h3>
El colapso de la comunidad</h3>
La situación cambió drásticamente durante la primera
parte de los 1980s cuando Digital discontinuó la serie PDP-10. Su
arquitectura, elegante y poderosa en los 60s, no se pudo extender naturalmente
a los espacios de direccionamiento más grandes que se hicieron factibles
en los 80s. Esto significó que prácticamente todos los programas
que componían a ITS se volvieron obsoletos.
<p>La comunidad de hackers del laboratorio de IA ya se había colapsado,
cierto tiempo antes. En 1981, la compañía derivada Symbolics
había contratado a casi todos los hackers del laboratorio de IA,
y la despoblada comunidad ya no era capaz de mantenerse a sí misma.
(El libro <i>Hackers</i>, de Steve Levy, describe estos eventos, y muestra
un claro panorama de esta comunidad en sus comienzos.) Cuando el laboratorio
de IA adquiere una nueva PDP-10 en 1982, sus administradores deciden utilizar
el sistema no libre de tiempo compartido de Digital en lugar de ITS.
<p>Las computadoras modernas de esa época, como la VAX o el 68020,
tienen sus propios sistemas operativos, pero ninguno de ellos es software
libre: usted debe firmar un «acuerdo de no revelar»
(<i>nondisclosure
agreement</i>) aún para obtener una copia ejecutable.
<p>Esto quiere decir que el primer paso para poder utilizar una computadora
era prometer que no ayudaría a su vecino. Se prohibía la
existencia de una comunidad cooperativa. La regla hecha por los dueños
de software propietario era: «si usted comparte con su vecino, usted
es un pirata. Si desea algún cambio, ruéguenos para que lo
hagamos nosotros».
<p>La idea de que el sistema social del software propietario--el sistema
que dice que usted no tiene permitido compartir o cambiar el software--
es antisocial, que no es ético, que está sencillamente equivocado,
puede ser una sorpresa para algunos lectores. ¿Pero qué otra
cosa podríamos decir sobre un sistema que se basa en dividir el
público e impide socorrer a los usuarios? Los lectores que se sorprendan
por esta idea es porque han tomado el sistema social del software propietario
tal como se lo han dado, o porque lo han juzgado en función de los
términos sugeridos por las empresas que hacen software propietario.
Los publicadores de software han trabajado duro y parejo para convencer
a las personas de que solamente hay una manera de ver este tema.
<p>Cuando los publicadores de software habla de «hacer valer»
sus «derechos» o de «detener la piratería»,
lo que *dice* es secundario. El mensaje real de estas declaraciones está
en las presunciones no declaradas que ellos dan por sentado; se supone
que el público debe aceptarlas de manera acrítica. Así
que examinémoslas.
<p>Una de las presunciones es que las compañías de software
tienen un derecho natural incuestionable que las habilita para ser dueñas
de un software, y por lo tanto a disponer de poder sobre todos los usuarios
del mismo. (Si éste fuera un derecho natural, entonces sin importar
cuánto daño le causare al público, no podríamos
objetarlo.) De manera muy interesante, la Constitución de los Estados
Unidos de América y la tradición legal rechazan esta
visión;
el copyright no es un derecho natural, sino un monopolio artificial impuesto
por el gobierno que limita el natural derecho a copia de los usuarios.
<p>Otra presunción no declarada es que la única cosa importante
sobre del software es qué trabajo le permite realizar a usted--que
a nosotros los usuarios de computadoras no nos debe importar qué
clase de sociedad nos permiten tener.
<p>Una tercera presunción es que no tendríamos software utilizable
(o, que nunca tendríamos un programa para hacer tal o cual trabajo
en particular) si no le ofrecemos a una compañía poder sobre
los usuarios de dicho programa. Esta presunción puede haber sonado
plausible, antes de que el movimiento por el software libre demostrara
que podemos hacer abundante software útil sin ponerle cadenas.
<p>Si nos resistimos a aceptar dichas presunciones, y juzgamos acerca de
estos temas sobre la base moral que nos da el sentido común ordinario
y ponemos al usuario en primer lugar, arribaremos a conclusiones muy distintas.
Los usuarios de computadoras deben tener libertad para modificar los programas
para ajustarlos a sus necesidades, y libertad para compartir el software,
porque la base de la sociedad está en ayudar a las otras personas.
<p>No se dispone aquí del espacio necesario para explayarnos en
el razonamiento que hay detrás de esta conclusión, y por
ese motivo pido al lector que vea la página web
<a
href="http://www.gnu.org/philosophy/why-free.es.html";>http://www.gnu.org/philosophy/why-free.es.html</a>.
<h3>
Una elección moral severa.</h3>
Al desaparecer mi comunidad, se hizo imposible continuar como antes. En
lugar de ello, me enfrenté a una elección moral severa.
<p>La elección fácil era unirme al mundo del software propietario,
firmar los acuerdos de no revelar, y prometer que no iría en ayuda
de mi amigo hacker. Es muy probable que desarrollara software que se
entregaría
bajo acuerdos de no revelar y de esa manera incrementara también
las presiones sobre otra gente para que traicionen a sus compañeros.
<p>Podría haber hecho dinero de esta manera, y tal vez me hubiese
divertido escribiendo código. Pero sabía que al final de
mi carrera, al mirar atrás a los años construyendo paredes
para dividir a la gente, sentiría que usé mi vida para empeorar
el mundo.
<p>Ya había estado del lado en que se reciben los acuerdos de no
revelar, por experiencia propia, cuando alguien se negó a entregarme,
a mí y al Laboratorio de IA del MIT, el código fuente del
programa de control de nuestra impresora. (La ausencia de ciertas
características
en este programa hacía que el uso de la impresora fuera frustrante
en extremo.) Así que no podía decirme a mí mismo que
los acuerdos de no revelar son inocentes. Me enojó mucho cuando
él se negó a compartir con nosotros; no podía ahora
cambiarme de lugar y hacerle lo mismo a todos los demás.
<p>Otra elección, fácil pero dolorosa, era abandonar el campo
de la computación. De esta manera no se usarían mis habilidades
para mal, pero aún así se desperdiciarían. Yo no
sería
culpable por dividir y restringir a los usuarios de computadoras, pero
ello sucedería igual.
<p>Así que busqué la manera en la cual un programador
podría
hacer algo para bien. Me pregunté: ¿habrá algún
programa o programas que yo pueda escribir, de tal manera de otra vez hacer
posible una comunidad?
<p>La respuesta era clara: lo primero que se necesitaba era un sistema
operativo. Este es el software crucial para empezar a usar una computadora.
Con un sistema operativo usted puede hacer muchas cosas; sin uno, ni siquiera
puede funcionar la computadora. Con un sistema operativo libre, podríamos
tener de nuevo una comunidad de hackers cooperando--e invitar a cualquiera
a unírsenos. Y cualquiera sería capaz de utilizar una computadora
sin que de movida conspire a favor de la privación de sus amigas
o amigos.
<p>Como desarrollador de sistema operativo, tengo las habilidades apropiadas
para esa tarea. Así que aún cuando no tenía
garantías
de éxito, me dí cuenta que había sido elegido para
hacer ese trabajo. Decidí hacer que el sistema fuese compatible
con Unix pues así sería portable, y los usuarios de Unix
podrían cambiarse a él con facilidad. El nombre GNU se
eligió
siguiendo una tradición hacker, como acrónimo recursivo para
«<i>GNU's Not Unix</i>».
<p>Un sistema operativo es más que un núcleo, apenas suficiente
para hacer funcionar otros programas. En los 1970s, todo sistema operativo
digno de llamarse así incluía procesadores de órdenes,
ensambladores, compiladores, intérpretes, depuradores, editores
de texto, programas de correo, y muchos otros. ITS los tenía, Multics
los tenía, VMS los tenía, Unix los tenía. El sistema
operativo GNU también los incluiría.
<p>Más adelante escuché estas palabras, atribuídas
a Hillel (1):
<p><QUOTE>Si yo no me preocupo por mí mismo, ¿quién
lo hará por mí?
<br>Si sólo me preocupo por mí mismo, ¿qué
es lo que soy?
<br>Si no lo hago ahora, ¿cuándo?</QUOTE>
<p>La decisión de iniciar el proyecto GNU se basó en un
espíritu
similar.
<p>(1) Como ateo que soy, no soy seguidor de ningún líder
religioso, pero algunas veces encuentro que admiro alguna cosa que dijo
uno de ellos.
<h3>
Libre como en libertad</h3>
El término «<i>free software</i>» [N. del T.: en
inglés
free = libre o gratis] se malinterpreta a veces--no tiene nada que ver
con el precio. El tema es la libertad. Aquí, por lo tanto, está
la definición de software libre: un programa es software libre,
para usted, un usuario en particular, si:
<ul>
<li>
Usted tiene libertad para ejecutar el programa, con cualquier
propósito.</li>
<li>
Usted tiene la libertad para modificar el programa para adaptarlo a sus
necesidades. (Para que esta libertad sea efectiva en la práctica,
usted debe tener acceso al código fuente, porque modificar un programa
sin disponer del código fuente es extraordinariamente dificultoso.)</li>
<li>
Usted tiene la libertad para redistribuir copias, tanto gratis como por
un cánon.</li>
<li>
Usted tiene la libertad para distribuir versiones modificadas del programa,
de tal manera que la comunidad pueda beneficiarse con sus mejoras.</li>
</ul>
Como «<i>free</i>» [libre] se refiere a libertad y no a precio,
no existe contradicción entre la venta de copias y el software libre.
De hecho, la libertad para vender copias es crucial: las colecciones de
software libre que se venden en CD-ROM son importantes para la comunidad,
y la venta de las mismas es una manera importante de obtener fondos para
el desarrollo de software libre. Por lo tanto, si la gente no puede incluir
un programa en dichas colecciones, dicho programa no es software libre.
<p>A causa de la ambigüedad de «<i>free</i>», la gente
ha estado buscando alternativas, pero nadie ha encontrado una alternativa
apropiada. El idioma inglés tiene más palabras y matices
que ningún otro, pero carece de una palabra simple, no ambigüa
que signifique «libre», como en
libertad--«<i>unfettered</i>»
[sin cadenas] es la palabra que más se acerca en significado. Otras
alternativas como
<i>liberated</i> [liberado], <i>freedom</i> [libertad]
y
<i>open</i> [abierto] tienen el significado equivocado o alguna otra
desventaja.
<h3>
Software GNU y el sistema GNU</h3>
El desarrollo de un sistema complejo es un proyecto de gran envergadura.
Para ponerlo dentro de mi alcance, decidí adaptar y usar las piezas
existentes de software libre siempre que fuera posible. Por ejemplo, en
los mismos comienzos decidí que TeX sería el principal
compaginador
de texto; unos pocos años más tarde, decidí que
usaría
el sistema X Window, en lugar de escribir otro sistema de ventanas para
GNU.
<p>A causa de esta decisión, el sistema GNU no coincide con la suma
de todo el software GNU. El sistema GNU incluye programas que no son software
GNU, programas que fueron desarrollados por otras personas y proyectos
para sus propios propósitos, pero que nosotros podemos utilizar
porque constituyen software libre.
<h3>
El inicio del proyecto</h3>
En enero de 1984 renuncié a mi trabajo en el MIT y comencé
a escribir software GNU. Era necesario abandonar el MIT, para que el MIT
no interfiriera con la distribución de GNU como software libre.
Si hubiese continuado como parte del <i>staff</i>, el MIT podría
haber reclamado propiedad sobre el trabajo, y podría haber impuesto
sus propios términos de distribución, o incluso podría
haberlo transformado en un paquete de software propietario. Yo no tenía
la intención de hacer un trabajo enorme sólo para ver que
perdía la utilidad para la cual se había realizado: crear
una nueva comunidad para compartir software.
<p>Sin embargo, el Profesor Winston, por entonces a cargo del Laboratorio
de IA del MIT, me invitó amablemente a que continúe utilizando
las instalaciones del Laboratorio.
<h3>
Los primeros pasos</h3>
Poco después de comenzar en el proyecto GNU, escuché acerca
del <i>Free University Compiler Kit</i> [Kit de Compilador de la Universidad
Libre], también conocido como VUCK. (La palabra alemana para
<i>free</i>
comienza con una V.) Se trataba de un compilador diseñado para manejar
múltiples lenguajes, C y Pascal entre ellos, y para admitir
múltiples
máquinas destino. Le escribí a su autor para consultarle
si GNU lo podría usar.
<p>Él me respondió burlonamente, dejando en claro que la
universidad era libre, pero el compilador no. Por lo tanto, decidí
que mi primer programa para el proyecto GNU sería un compilador
multilenguaje, multiplataforma.
<p>Con la esperanza de evitar tener que escribir todo el compilador por
mí mismo, obtuve el código fuente del compilador Pastel,
que era un compilador multiplataforma desarrollado en el «Lawrence
Livermore Lab». Admitía, y estaba escrito en una versión
extendida de Pascal, diseñada para usarse como lenguaje de
programación
a nivel de sistema. Le agregué un <i>front end</i> para C, y
comencé
a transportarlo a la computadora Motorola 68000. Pero tuve que abandonar
la idea al descubrir que el compilador necesitaba varios megabytes de espacio
en la pila, y los sistemas Unix basados en 68000 sólo permitían
64 kbytes.
<p>Fue entonces cuando me dí cuenta que el compilador Pastel funcionaba
analizando el fichero de entrada completo y transformándolo en un
árbol sintáctico, luego convertía todo el árbol
sintáctico en una cadena de «instrucciones» y luego
generaba el fichero entero de salida, y en ningún momento liberaba
el espacio ocupado. En ese momento llegué a la conclusión
de que debería escribir un nuevo compilador partiendo desde cero.
Ese nuevo compilador se conoce ahora como GCC; no hay nada del compilador
Pastel en él, pero me las arreglé para adaptar y usar el
<i>front
end</i> que había hecho para C. Pero eso pasó unos años
más tarde; primero, trabajé sobre GNU Emacs.
<h3>
GNU Emacs</h3>
Comencé a trabajar sobre GNU Emacs en setiembre de 1984, y al principio
de 1985 ya empezaba a ser usable. Esto me permitió usar sistemas
Unix para las tareas de edición; como no tenía ningún
interés en aprender a usar vi o ed, había realizado mis tareas
de edición en otras clases de máquinas hasta ese momento.
<p>A estas alturas, la gente comenzó a querer usar Emacs, con lo
que apareció el tema de cómo distribuirlo. Por supuesto,
lo puse en el servidor de FTP anónimo de la computadora del MIT
que usaba. (Esta computadora, prep.ai.mit.edu, se transformó a causa
de ello en la sede principal de distribución a través de
FTP de GNU; cuando fue decomisada unos años después, transferimos
el nombre a nuestro nuevo servidor FTP.) Pero en aquella época,
mucha gente interesada no estaba en Internet y no podía obtener
una copia por FTP. Así que la pregunta era: ¿qué
tendría
que decirles a ellos?
<p>Podría haber dicho, «Busque un amigo que esté en
la red y que haga una copia para usted». O podría haber hecho
lo que hice con el Emacs para PDP-10 original, decirles: «Envíeme
por correo una cinta y un sobre con su dirección y los sellos de
correo necesarios, y yo le devolveré la cinta con Emacs dentro».
Pero no tenía trabajo, y estaba buscando de qué manera
podía
hacer dinero con el software libre. Entonces anuncié que le
enviaría
la cinta a quien me la pidiera, mediante el pago de un cánon de
$150. De esta manera, inicié un negocio de distribución de
software libre, el precursor de las compañías que en la actualidad
distribuyen completos sistemas GNU basados en Linux.
<h3>
¿Es libre el programa para cualquier usuario?</h3>
Si un programa es software libre cuando abandona las manos de su autor,
esto no significa que será software libre para todos los que tienen
una copia de él. Por ejemplo, el software de dominio público
(software que no está sujeto al copyright de nadie) es software
libre; pero cualquiera puede hacer una versión modificada propietaria
a partir de él. En ese mismo sentido, muchos programas libres
están
sujetos a copyright pero se distribuyen mediante sencillas licencias permisivas
que admiten las versiones modificadas propietarias.
<p>El ejemplo paradigmático de este problema es el <i>X Window
System</i>.
Desarrollado en el MIT, y entregado como software libre con un licencia
permisiva, fue rápidamente adoptado por varias compañías
de computación. Éstas agregaron X a sus sistemas Unix
propietarios,
sólo en formato binario, y lo cubrieron con el mismo acuerdo de
no revelar. Estas copias de X eran tanto (software) libres en cuanto lo
era el Unix.
<p>Los desarrolladores del X Window System no consideraban que esto fuese
un problema--esperaban y buscaban que esto sucediese. Su meta no era la
libertad, sólo el «éxito», definido como «tener
muchos usuarios». No les preocupaba si esos usuarios tenían
libertad, sólo que sean numerosos.
<p>Esto nos lleva a una situación paradójica en la cual dos
maneras distintas de contabilizar la cantidad de libertad dan por resultado
dos respuestas distintas a la pregunta «¿Es libre este
programa?».
Si usted juzga en base a la libertad que se proporcionaba con los
términos
de distribución de la entrega del MIT, diría que X es software
libre. Pero si usted mide la libertad del usuario promedio de X, diría
que X es software propietario. La mayoría de los usuarios de X usan
las versiones propietarias que vienen con los sistemas Unix, no la
versión
libre.
<h3>
Copyleft y la GNU GPL</h3>
La meta de GNU era dar libertad a los usuarios, no sólo ser popular.
Por lo tanto, debíamos usar términos de distribución
que impidieran que el software GNU se transformara en software propietario.
El método que utilizamos se denomina «copyleft».(1)
<p>El copyleft usa la ley de copyright, pero la da vuelta para servir a
lo opuesto de su propósito usual: en lugar de ser un medio de privatizar
el software, se transforma en un medio de mantener libre al software.
<p>La idea central del copyleft es que le damos a cualquiera el permiso
para correr el programa, copiar el programa, modificar el programa y
redistribuir
versiones modificadas--pero no le damos permiso para agregar restricciones
propias. De esta manera, las libertades cruciales que definen al «software
libre» quedan garantizadas para cualquiera que tenga una copia; se
transforman en derechos inalienables.
<p>Para que el copyleft sea efectivo, las versiones modificadas deben ser
también libres. Esto asegura que todo trabajo basado en el nuestro
quedará disponible para nuestra comunidad si se publica. Cuando
los programadores que tienen trabajo como programadores se ofrecen como
voluntarios para mejorar un software GNU, es el copyleft lo que impide
que sus empleadores digan: «no puede compartir esos cambios, porque
los queremos usar para hacer nuestra versión propietaria del
programa».
<p>El requerimiento de que los cambios deben ser libres es esencial si
queremos asegurar la libertad para cada usuario del programa. Las
compañías
que privatizaron el X Window System en general realizaron algunos cambios
para transportarlo a sus sistemas y hardware. Estos cambios fueron
pequeños
comparados con el gran tamaño de X, pero no fueron triviales. Si
el hacer cambios fuera una excusa para negar libertad a los usuarios,
sería
fácil para cualquiera tomar ventaja de la excusa.
<p>Un tema relacionado trata la combinación de un programa libre
con código no libre. Tal combinación será inevitablemente
no-libre; cualesquiera libertades que falten a la parte no-libre, le
faltarán
también al todo. Si se permiten tales combinaciones se abriría
un agujero lo suficientemente grande como para hundir el barco. Por ello,
un requerimiento crucial para el copyleft es que se tape este hoyo: cualquier
cosa agregada a o combinada con un programa bajo copyleft debe ser tal
que la versión combinada total sea también libre y bajo copyleft.
<p>La implementación específica de copyleft que usamos para
la mayoría del software GNU es la Licencia Pública General
de GNU (<i>GNU General Public License</i>) o LPG GNU para abreviar. Tenemos
otras clases de copyleft que se usan en circunstancias específicas.
Los manuales GNU también están bajo copyleft, pero utilizamos
un copyleft mucho más simple, porque no es necesaria la complejidad
de la LPG GNU para los manuales.
<p>(1) En 1984 o 1985, Don Hopkins (un compañero muy imaginativo)
me envío una carta por correo. En el sobre, escribió varios
dichos divertidos, entre ellos éste: «<i>Copyleft--all rights
reversed</i>» [Copyleft--todos los derechos "reversados"]. Utilicé
la palabra «copyleft» para denominar al concepto de
distribución
que estaba desarrollando en esa época.
<h3>
La Fundación para el Software Libre</h3>
A medida que el interés en el uso de Emacs crecía, otras
personas se involucraron en el proyecto GNU, y decicimos que era el momento
de buscar fondos nuevamente. Por ello en 1985 creamos la «<i>Free
Software Foundation</i>» [Fundación para el Software Libre--FSL],
una organización de caridad libre de impuestos para el desarrollo
del software libre. La FSL también acaparó el negocio de
distribución en cinta de Emacs; más adelante lo extendió
al agregar otros productos de software libre (tanto GNU como no-GNU) a
la cinta, y con la venta de manuales libres.
<p>La FSL acepta donaciones, pero la mayoría de sus ingresos han
provenido siempre de las ventas--de copias de software libre, y otros servicios
relacionados. En la actualidad vende CD-ROMs de código fuente, CD-ROMs
con binarios, manuales agradablemente impresos (todos con libertad para
redistribuir y modificar), y las Distribuciones De Lujo (en las cuales
incorporamos toda la colección de software lista para usar en la
plataforma de su elección).
<p>Los empleados de la Fundación para el Software Libre han escrito
y mantenido una cantidad de paquetes de software GNU. Dos notables casos
son la biblioteca C y el shell. La biblioteca C de GNU es lo que usa todo
programa que corre en un sistema GNU/Linux para comunicarse con Linux.
Fue desarrollada por un miembro del <i>staff</i> de la Fundación
para el Software Libre, Roland McGrath. El shell que se usa en la mayoría
de los sistemas GNU/Linux es BASH, el <i>Bourne Again SHell</i>(1), que
fue desarrollado por Brian Fox, empleado de la FSL.
<p>Hemos provisto los fondos para el desarrollo de esos programas porque
el proyecto GNU no se queda solamente en herramientas o un entorno de
desarrollo.
Nuestra meta era tener un sistema operativo completo, y esos programas
eran necesarios para esa meta.
<p>(1) «<i>Bourne again shell</i>» es una broma sobre el nombre
«Bourne Shell», que era el shell usual en Unix.
<h3>
Asistencia para el Software Libre</h3>
La filosofía del software libre rechaza una práctica
específica
de negocio ampliamente difundida, pero no está contra el negocio.
Cuando los negocios respetan la libertad de los usuarios, les deseamos
éxito.
<p>La venta de copias de Emacs demostró una clase de negocio con
software libre. Cuando la FSL se apropió de ese negocio, necesité
de otro medio de vida. Lo encontré en la venta de servicios relacionados
con el software libre que había desarrollado. Esto incluía
la enseñanza, sobre temas tales como cómo programar GNU Emacs,
y cómo personalizar GCC, y desarrollo de software, en la mayor parte
transportar GCC a otras plataformas.
<p>En la actualidad cada una de esas clases de negocios con software libre
está puesta en práctica por una cantidad de corporaciones.
Algunas distribuyen colecciones de software libre en CD-ROM; otras venden
asistencia en niveles que van desde responder preguntas de usuarios,
reparación
de errores, hasta el agregado de nuevas características mayores.
Incluso estamos viendo compañías de software libre basadas
en el lanzamiento de nuevos productos de software libre.
<p>Aunque, tenga cuidado--una cantidad de compañías que se
asocian a sí mismas con el término «<i>open
source</i>»
en realidad basan su negocio en software no-libre que trabaja con software
libre. Ellas no son compañías de software libre, sino
compañías
de software propietario cuyos productos tientan a los usuarios a abandonar
su libertad. Ellas usan la denominación «valor agregado»
lo que refleja los valores que desearían que adoptemos: conveniencia
por encima de libertad. Si valoramos más la libertad, deberíamos
denominarlos productos con «libertades sustraídas».
<h3>
Metas técnicas</h3>
La meta principal de GNU era el software libre. Aún en el caso que
GNU no tuviese ventajas técnicas sobre Unix, tendría una
ventaja social, al permitir cooperar a los usuarios, y una ventaja ética,
al respetar la libertad de los usuarios.
<p>Pero era natural que se apliquen los estándares conocidos de
buenas prácticas al trabajo--por ejemplo, reservar dinámicamente
las estructuras de datos para evitar límites de tamaño fijo
arbitrarios, y manejar todos lo posibles códigos de 8 bits cuando
tuviese sentido.
<p>Además, rechazamos el enfoque de Unix para pequeños
tamaños
de memoria, al decidir que no trabajaríamos para máquinas
de 16 bits (era claro que las máquinas de 32 bits serían
la norma para cuando el sistema GNU estuviese terminado), y al no hacer
ningún esfuerzo para reducir el uso de memoria, a menos que excediera
el megabyte. En los programas para los cuales no era crucial el manejo
de ficheros muy grandes, incentivamos a los programadores a leer el fichero
completo en memoria, y luego explorar su contenido, sin tener que preocuparse
por la E/S.
<p>Estas decisiones permitieron que muchos programas GNU sobrepasaran a
sus contrapartidas UNIX en confiabilidad y velocidad.
<h3>
Computadoras donadas</h3>
A medida que la reputación del proyecto GNU crecía, la gente
comenzó a ofrecer al proyecto donaciones de máquinas con
UNIX corriendo. Fueron muy útiles porque la manera más
fácil
de desarrollar componentes de GNU era hacerlo en un sistema UNIX, y luego
ir reemplazando los componentes del sistema uno a uno. Pero ellas trajeron
una cuestión ética: si era correcto para nosotros siquiera
tener una copia de UNIX.
<p>UNIX era (y es) software propietario, y la filosofía del proyecto
GNU dice que no debemos usar software propietario. Pero, aplicando el mismo
razonamiento que lleva a la conclusión que la violencia en defensa
propia está justificada, concluí que era legítimo
usar un paquete propietario cuando ello era crucial para desarrollar un
reemplazo libre que ayudaría a otros a dejar de usar el paquete
propietario.
<p>Pero, aún cuando esto era un mal justificable, era todavía
un mal. En la actualidad ya no tenemos más copias de Unix, porque
las hemos reemplazado por sistemas operativos libres. En los casos en que
no pudimos reemplazar el sistema operativo de una máquina por uno
libre, se procedió al reemplazo de la máquina.
<h3>
La lista de tareas de GNU</h3>
A medida que proseguía el proyecto GNU, se desarrollaron o encontraron
una cantidad creciente de componentes, y eventualmente se vio la utilidad
de hacer una lista con los huecos faltantes. La usamos para reclutar
desarrolladores
para escribir las piezas faltantes. Esta lista comenzó a conocerse
como la lista de tareas de GNU. Además de los componentes Unix faltantes,
agregamos a la lista otros útiles proyectos de software y
documentación
que, de acuerdo a nuestra visión, debe tener un sistema verdaderamente
completo.
<p>En la actualidad, casi ningún componente Unix queda en la lista
de tareas GNU--esos trabajos ya han sido terminados, fuera de algunos no
esenciales. Pero la lista está llena de proyectos que algunos pueden
denominar «aplicaciones». Cualquier programa que sea atrayente
a más de una estrecha franja de usuarios sería una cosa
útil
para añadir a un sistema operativo.
<p>Aún los juegos están incluídos en la lista de tareas--y
han estado desde el principio. Unix incluía juegos, así que
GNU debía incluirlos también. Pero la compatibilidad no es
un problema para los juegos, así que no seguimos la lista de juegos
que Unix tenía. En lugar de ello, listamos un espectro de diferentes
clases de juegos que les podrían gustar a los usuarios.
<h3>
La LPG para Bibliotecas de GNU</h3>
La biblioteca C de GNU usa una clase especial de copyleft denominada
«<i>GNU
Library General Public License</i>» [Licencia Pública General
para Bibliotecas de GNU] que da permiso para enlazar software propietario
con la biblioteca. ¿Porqué hacer esta excepción?
<p>No es una cuestión de principios; no hay ningún principio
que diga que debemos incluir código de los productos de software
propietario. (¿Porqué contribuir con un proyecto que se rehusa
a compartir con nosotros?) El uso de la LPGB para la biblioteca C, o para
cualquier otra biblioteca, es un tema de estrategia.
<p>La biblioteca C hace un trabajo genérico; todo sistema propietario
o compilador viene con una biblioteca C. Por lo tanto, el hacer que nuestra
biblioteca esté sólo disponible para el software libre, no
le daría al software libre ninguna ventaja--sólo hubiera
desalentado el uso de nuestra biblioteca.
<p>HAy un sistema que es una excepción a esto: en un sistema GNU
(y esto incluye los sistemas GNU/Linux), la biblioteca C de GNU es la
única
biblioteca C. Así que los términos de distribución
de la biblioteca C de GNU determinan si es posible compilar un programa
propietario para un sistema GNU. No hay ninguna razón ética
para permitir aplicaciones propietarias en un sistema GNU, pero
estratégicamente
parece que si no se permite, ello hará más para desalentar
el uso del sistema GNU que para alentar el desarrollo de aplicaciones libres.
<p>Por estas razones es que el uso de la LPG para Bibliotecas es una buena
estrategia para la biblioteca C. Para otras bibliotecas, la decisión
estratégica necesita considerarse en cada caso particular. Cuando
una biblioteca hace un trabajo especial que puede ayudar a escribir cierta
clase de programas, y luego entregarla bajo la LPG, limitándola
sólo a programas libres, es una manera de ayudar a otros desarrolladores
de software libre, al proporcionarles una ventaja contra el software
propietario.
<p>Considere la GNU Readline, una biblioteca desarrollada para proporcionar
la edición en la línea de órdenes para BASH. Readline
se entrega bajo la LPG GNU ordinaria, no bajo la LPG para Bibliotecas.
De esta manera probablemente se reduce la cantidad de uso de Readline,
pero eso no significa pérdida para nosotros. Mientras tanto, al
menos una útil aplicación se ha transformado en software
libre específicamente para poder usar Readline, y ésa es
una ganancia real para nuestra comunidad.
<p>Los desarrolladores de software propietario tienen las ventajas que
el dinero proporciona; los desarrolladores de software libre necesitan
crear ventajas entre sí. Tengo la esperanza de que algún
día tendremos una gran colección de bibliotecas cubiertas
por LPG que no tengan parangón entre el software propietario, que
proporcionen útiles módulos que sirvan como bloques constructivos
en nuevo software libre, y que sumen una mayor ventaja para adelantar el
desarrollo de software libre.
<h3>
¿Rascarse una comezón?</h3>
Eric Raymond dice que «Todo buen trabajo de software comienza con
un desarrollador rascándose una comezón personal».
Puede que ocurra algunas veces, pero muchas de las piezas esenciales de
software GNU se desarrollaron a los fines de tener un sistema operativo
libre completo. Vinieron desde una visión y un plan, no desde el
impulso.
<p>Por ejemplo, desarrollamos la biblioteca C de GNU porque un sistema
del estilo Unix necesita una biblioteca C, el shell Bourne-Again (bash)
porque un sistema del estilo Unix necesita un shell, y el tar GNU porque
un sistema del estilo Unix necesita un programa tar. Lo mismo se aplica
a mis propios progamas--el compilador GNU C, GNU Emacs, GDB y GNU Make.
<p>Algunos de los programas GNU se desarrollaron para tratar amenazas
específicas
a nuestra libertad. Por ello, desarrollamos gzip para reemplazar al programa
Compress, perdido para nuestra comunidad a causa de las patentes LZW.
Proporcionamos
fondos para desarrollar LessTif, y más recientemente iniciamos GNOME
y Harmony, para lidiar con los problemas causados por cierta biblioteca
propietaria (vea más abajo). Estamos desarrollando el GNU Privacy
Guard para reemplazar un software popular de cifrado no-libre, porque los
usuarios no deben verse obligados a elegir entre privacidad y libertad.
<p>Por supuesto, la gente que escribe estos programas se interesa en el
trabajo, y varias personas han agregado muchas características para
satisfacer sus propias necesidades e intereses. Pero ése no es el
motivo por el cual existe el programa.
<h3>
Desarrollos inesperados</h3>
Al comienzo del proyecto GNU, imaginé que desarrollaríamos
el sistema GNU completo, y luego lo entregaríamos completo. No es
así como ha sucedido.
<p>Como cada componente de un sistema GNU se implementó en un sistema
Unix, cada componente podía correr en sistemas Unix, mucho antes
de que existiera un sistema GNU completo. Algunos de esos programas se
hicieron populares, y los usuarios comenzaron a extenderlos y transportarlos--a
las distintas versiones incompatibles de Unix, y algunas veces a otros
sistemas también.
<p>El proceso hizo que dichos programas sean más potentes, y atrayeran
tanto fondos como contribuyentes al proyecto GNU. Pero también
demoró
el completamiento de un sistema mínimo en funciones por varios
años,
a medida que el tiempo de los desarrolladores GNU se usaba para mantener
esos transportes y en agregar características a los componentes
existentes, en lugar de adelantar la escritura de los componentes faltantes.
<h3>
El GNU Hurd</h3>
En 1990, el sistema GNU estaba casi completo; el único componente
importante faltante era el núcleo. Decidimos implementar nuestro
núcleo como una colección de procesos servidores corriendo
sobre Mach. Mach es un micronúcleo desarrollado en Carnegie Mellon
University y luego en la University of Utah; el GNU HURD es una colección
de servidores (o «manada de ñus») que corren sobre Mach,
y se ocupan de las tareas del núcleo Unix. El inicio del desarrollo
se demoró mientras esperábamos que Mach se entregue como
software libre, tal como se había prometido.
<p>Una razón para elegir este diseño había sido evitar
lo parecía ser la parte más dura del trabajo: depurar el
núcleo sin un depurador a nivel de código fuente para utilizar.
Esta parte del trabajo ya había sido hecha en Mach, y esperábamos
depurar los servidores HURD como programas de usuario, con GDB. Pero
llevó
un largo tiempo hacer esto posible, y los servidores multihilo que se
envían
mensajes unos a otros han sido muy difíciles de depurar. Hacer que
HURD trabaje sólidamente se ha tardado varios años.
<h3>
Alix</h3>
El núcleo GNU no se iba a llamar originalmente el HURD. Su nombre
original era Alix--denominado así a partir de una mujer que era
mi amor de aquella época. Ella era administradora de sistema Unix
y había hecho notar que su nombre seguía el patrón
de nomenclatura común a las versiones de sistema Unix; a modo de
broma, le dijo a sus amigos, «Alguien debería darle mi nombre
a un núcleo». Yo no dije nada, pero decidí sorprenderla
con un núcleo llamado Alix.
<p>No se dió de esa manera. Michael Bushnell (ahora Thomas), el
principal desarrollador 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 gestiona por medio del
envío de mensajes a los servidores HURD.
<p>Más tarde, Alix y yo nos separamos, y ella cambió su nombre;
independientemente, el diseño de HURD se cambió para que
la biblioteca C envíe los mensajes directamente a los servidores,
y esto hizo que el componente Alix desapareciera del diseño.
<p>Pero antes que estas cosas sucedieran, un amigo de ella encontró
el nombre Alix en el código fuente de HURD, y se lo mencionó.
Así que el nombre cumplió su objetivo.
<h3>
Linux y GNU/Linux</h3>
El GNU HURD no está listo para el uso en producción.
Afortunadamente,
está disponible otro núcleo. En 1991, Linus Torvalds
desarrolló
un núcleo compatible con Unix y lo denominó Linux. Cerca
de 1992, al combinar Linux con el sistema no tan completo de GNU, resultó
en un sistema operativo libre completo. (La combinación en sí
misma dió un considerable trabajo.) Es gracias a Linux que podemos
ver funcionar un sistema GNU en la actualidad.
<p>Denominamos a esta versión GNU/Linux, para expresar su
composición
como combinación de un sistema GNU con Linux como núcleo.
<h3>
Desafíos en nuestro futuro</h3>
Hemos probado nuestra capacidad para desarrollar un amplio espectro de
software libre. Esto no significa que somos invencibles o que nada nos
puede detener. Muchos desafíos hacen que el futuro del software
libre sea incierto; estar a la altura de los mismos requerirá esfuerzos
firmes y resistencia, algunas veces durante años. Requerirá
la clase de determinación que la gente muestra cuando valora su
libertad y no deja que nadie se la quite.
<p>Las siguientes cuatro secciones discuten dichos desafíos.
<h3>
Hardware secreto</h3>
Los fabricantes de hardware tienden cada vez más a mantener las
especificaciones de hardware secretas. Esto hace difícil la escritura
de controladores libres, y de esa manera, que Linux y XFree86 puedan admitir
nuevo hardware. Tenemos sistemas libres completos por hoy, pero no los
tendremos mañana si no podemos usar las computadoras del mañana.
<p>Existen dos maneras de lidiar con este problema. Los programadores pueden
hacer ingeniería reversa para darse cuenta como usar el hardware.
El resto de nosotros puede elegir el hardware que admite software libre;
a medida que nuestro número crezca, el secreto de las especificaciones
se transformará en una política contraproducente.
<p>La ingeniería reversa es un trabajo enorme; ¿tendremos
los programadores con la suficiente determinación para realizarla?
Sí--si hemos construído un fuerte sentimiento de que el software
libre es un tema de principio, y de que los controladores no libres son
intolerables. ¿Y una gran cantidad de nosotros estará dispuesto
a gastar dinero extra, o incluso tiempo extra, para que podamos usar
controladores
libres? Sí, si se difunde la determinación para tener libertad.
<h3>
Bibliotecas no libres</h3>
Una biblioteca no libre que corre sobre un sistema operativo actúa
como una trampa para los desarrolladores de software libre. Las
características
atractivas de la biblioteca son el cebo; si usted usa la biblioteca, cae
en la trampa, porque su programa no puede ser parte útil de un sistema
operativo libre. (Estrictamente hablando, podemos incluir su programa,
pero no <b>funcionará</b> sin la biblioteca faltante.) Peor aún,
si el programa que usa la biblioteca se hace popular, puede hacer caer
a otros programadores incautos dentro de la trampa.
<p>La primer instancia de este problema fue el kit de herramientas Motif,
allá en los 80s. Aunque aún no había sistemas operativos
libres, era claro el problema que Motif iba a causarles más adelante.
El proyecto GNU respondió de dos maneras: solicitando a los proyectos
individuales de software libre que admitan tanto los widgets del kit libre
de herramientas de X como el de Motif, y solicitando a alguien que escriba
un reemplazo libre para Motif. El trabajo tomó varios años;
LessTif, desarrollado por <i>Hungry Programmers</i> [Programadores hambrientos]
tomó la potencia necesaria como para admitir la mayoría de
las aplicaciones Motif recién en 1997.
<p>Entre 1996 y 1998, otra biblioteca kit de herramientas GUI no libre,
denominada Qt, se usó en una sustancial colección de software
libre: el escritorio KDE.
<p>Los sistemas libres GNU/Linux no podían usar KDE, porque no
podíamos
usar la biblioteca. Sin embargo, algunos distribuidores comerciales de
sistemas GNU/Linux que no eran tan estrictos al adherirse al software libre,
agregaron KDE a sus sistemas--produciendo un sistema con más capacidades,
pero menos libertad. El grupo KDE instaba activamente a más programadores
a usar Qt, y millones de nuevos «usuarios de Linux» nunca escucharon
la idea de que había un problema con esto. La situación se
presentaba lúgubre.
<p>La comunidad del software libre respondió a este problema de
dos maneras: GNOME y Harmony.
<p>GNOME, el <i>GNU Network Object Model Environment</i> [Entorno Modelo
de Objetos en Red de GNU], es el proyecto de escritorio de GNU. En 1997
Miguel de Icaza lo inició, y se desarrolló con aporte de
Red Hat Software, para proporcionar capacidades de escritorio similares,
pero usando sólo software libre. Tiene también ventajas
técnicas,
tales como admitir una variedad de lenguajes, no sólo C++. Pero
su propósito principal fue la libertad: evitar el uso de cualquier
software no libre.
<p>Harmony es una biblioteca de reemplazo compatible, diseñada para
poder hacer funcionar el software KDE sin usar Qt.
<p>En noviembre de 1998, los desarrolladores de Qt anunciaron un cambio
de licencia, que cuando se lleve a cabo, hará que Qt sea software
libre. No hay manera de estar seguro, pero pienso que esto ocurrió
en parte debido a la firme respuesta de la comunidad frente al problema
que presentaba Qt cuando no era libre. (La nueva licencia es inconveniente
e injusta, así que aún es deseable evitar su uso.)
<p>¿Cómo responderemos a la siguiente biblioteca no libre
que nos tiente? ¿Comprenderá la totalidad de la comunidad
la necesidad de mantenerse fuera de la trampa? ¿Alguno de nosotros
entregará libertad por conveniencia, y generará un importante
problema? Nuestro futuro depende de nuestra filosofía.
<h3>
Patentes de software</h3>
La peor amenaza que enfrentamos proviene de las patentes de software, que
pueden colocar a algoritmos y características fuera de los límites
del software libre hasta por veinte años. Las patentes del algoritmo
de compresión LZW se solicitaron en 1983, y hasta ahora no podemos
entregar software libre que produzca GIFs adecuadamente comprimidos. En
1998, se tuvo que quitar de una distribución un programa libre para
producir audio comprimido MP3 a causa de la amenaza de un juicio por patente.
<p>Existen maneras de tratar con las patentes: podemos buscar evidencia
de que la patente no es válida, y podemos buscar maneras alternativas
de realizar el trabajo. Pero cada uno de estos métodos trabaja
sólo
ciertas veces; cuando ambos fallan, una patente puede forzar a que todo
software libre carezca de alguna característica que los usuarios
desean. ¿Qué haremos cuando esto suceda?
<p>Aquellos de nosotros que valoremos el software libre por la libertad
nos apegaremos al software libre de cualquier manera. Nos las arreglaremos
para tener nuestro trabajo realizado sin las características patentadas.
Pero aquellos que valoren el software libre porque esperan que sea
técnicamente
superior, cuando las patentes lo obliguen a mantenerse atrás, es
más probable que piensen que se trata de una falla. Por lo tanto,
si bien es útil hablar acerca de la efectividad práctica
del modelo «catedral» de desarrollo, y de la confiabilidad
y potencia de cierto software libre, no debemos detenernos allí.
Debemos hablar acerca de libertad y principio.
<h3>
Documentación libre</h3>
La mayor deficiencia en nuestro sistema operativo libre no está
en el software-- es 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 viene con un buen manual libre, ése es un hueco importante.
Tenemos muchos de esos huecos en la actualidad.
<p>La documentación libre, como el software, es un tema de libertad,
no de precio. El criterio para un manual libre es muy parecido al del software
libre: es una cuestión de otorgar a los usuarios ciertas libertades.
La redistribución (incluso la venta comercial) debe estar permitida,
en línea y en papel, de tal manera que el manual pueda acompañar
a cada copia del programa.
<p>El permiso para modificarlo es también crucial. Como regla general,
no creo que sea esencial que las personas tengan permiso para modificar
toda clase de artículos y libros. Por ejemplo, no creo que usted
o yo estemos obligado a dar permiso para modificar artículos como
este, que describe nuestras acciones y nuestra visión.
<p>Pero existe una razón particular debido a la cual la libertad
para modificar la documentación es crucial para el software libre.
Cuando la gente ejercita su derecho a modificar el software, y agrega o
cambia características, si son concientes también cambiarán
el manual--así proporcionarán documentación precisa
y útil con el programa modificado. Un manual que no permite a los
programadores ser concientes y terminar el trabajo, no satisface las necesidades
de nuestra comunidad.
<p>La existencia de algunas clases de límites acerca de cómo
se deben hacer las modificaciones no implica problemas. Por ejemplo, el
requerimiento de preservar el aviso de copyright del autor original, los
términos de distribución, o la lista de autores, están
bien. Tampoco trae problemas requerir que la versión modificada
incluya un aviso de que fue modificada, e incluso que haya secciones completas
que no puedan borrarse o cambiarse siempre y cuando dichas secciones traten
temas que no sean de índole técnica. Estas clases de restricciones
no son un problema porque no impiden al programador conciente que adapte
el manual para ajustarlo al programa modificado. En otras palabras, no
impiden a la comunidad del software libre la completa utilización
del manual.
<p>Sin embargo, debe ser posible modificar todo el contenido *técnico*
del manual, y luego distribuir el resultado en todos los medios usuales,
a través de todos los canales usuales; si esto no es así,
las restricciones obstruyen la comunidad, el manual no es libre, y necesitaremos
otro maual.
<p>¿Será que loa desarrolladores de software libre tendrán
la conciencia y determinación para producir un espectro completo
de manuales? Una vez más, nuestro futuro depende de nuestra
filosofía.
<h3>
Debemos hablar acerca de la libertad</h3>
En la actualidad se estima que hay unos diez millones de usuarios de sistemas
GNU/Linux, tales como el Debian GNU/Linux y Red Hat Linux. El software
libre ha desarrollado ciertas ventajas prácticas que hacen que los
usuarios estén congregándose hacia allí por razones
puramente prácticas.
<p>Las buenas consecuencias de esto son evidentes: mayor interés
en el desarrollo de software libre, más clientes para empresas de
software libre, y mayor capacidad para animar a las compañías
a que desarrollen productos de software libre, en lugar de productos de
software propietario.
<p>Pero el interés en el software crece más rápido
que la conciencia acerca de la filosofía sobre la cual está
basado, y esto crea problemas. Nuestra capacidad de enfrentar los
desafíos
y amenazas que se describieron más arriba depende de la voluntad
de mantenerse firmes del lado de la libertad. Para asegurarnos de que nuestra
comunidad tiene esta voluntad, necesitamos esparcir la idea entre los nuevos
usuarios a medida que ellos llegan a nuestra comunidad.
<p>Pero estamos fracasando en esto: los esfuerzos realizados para atraer
nuevos usuarios a nuestra comunidad sobrepasan por lejos a los esfuerzos
dedicados a la enseñanza cívica acerca de nuestra comunidad.
Necesitamos hacer ambas cosas, y es necesario que mantengamos ambos esfuerzos
balanceados.
<h3>
«Open Source»</h3>
La enseñanza acerca de la libertad a los nuevos usuarios se hizo
más difícil en 1998, cuando una parte de la comunidad
decidió
dejar de usar el término «software libre» y usar «open
source software» en su lugar.
<p>Algunos de los que favorecieron este término tenían como
objetivo evitar la confusión de «<i>free</i>» con
«gratis»--una
meta válida. Otros, sin embargo, apuntaban a apartar el espíritu
de principio que ha motivado el movimiento por el software libre y el proyecto
GNU, y resultar así atractivos a los ejecutivos y usuarios comerciales,
muchos de los cuales sostienen una ideología que pone las ganancias
por encima de la libertad, de la comunidad, y de los principios. Por lo
tanto, la retórica de «open source» se centra en el
potencial de realización de potente software de alta calidad, pero
esquiva las ideas de libertad, comunidad y principio.
<p>Las revistas sobre «Linux» son un claro ejemplo de
esto--están
llenas de propagandas acerca de software propietario que funciona sobre
GNU/Linux. Cuando aparezca la próxima Motif o Qt,
¿incentivarán
estas revistas a los programadores a apartarse de ellas, o pondrán
propagandas de las mismas?
<p>El apoyo de las empresas puede contribuir a la comunidad de varias maneras;
si todo lo demás se mantiene igual, esto es útil. Pero si
ganamos su apoyo mediante el recurso de hablar menos de libertad y principio
esto puede ser desastroso; hace que empeore el desbalance previo entre
el alcance y la educación cívica.
<p>«Software libre» y «open source» describen la
misma categoría de software, más o menos, pero dicen diferentes
cosas acerca del software, y acerca de los valores. El proyecto GNU
continúa
utilizando el término «<i>free software</i>» [software
libre] para expresar la idea de que la libertad, no solamente la
tecnología,
es lo importante.
<h3>
¡Pruébelo!</h3>
La filosofía de Yoda («No hay 'para probar'») suena
linda, pero no funciona conmigo. He realizado la mayor parte de mi trabajo
con ansiedad por saber si podría llevarlo a cabo, y con la inseguridad
de que no sería suficiente alcanzar la meta si lo lograba. Pero
lo intenté igual, porque no había otro entre el enemigo y
mi ciudad. Para mi propia sorpresa, algunas veces he tenido éxito.
<p>Algunas veces he fallado; algunas de mis ciudades han caído.
Luego he encontrado otra ciudad amenazada, y me preparé para otra
batalla. A lo largo del tiempo, aprendí a buscar las amenazas y
ponerme entre ellas y la ciudad, y llamar a otros hackers para que se unan
a mí.
<p>En la actualidad, con frecuencia no soy el único. Es un consuelo
y un placer cuando veo un regimiento de hackers excavando para mantener
la trinchera, y caigo en cuenta que esta ciudad sobrevivirá--por
ahora. Pero los peligros son mayores cada año que pasa, y ahora
Microsoft tiene a nuestra comunidad como un blanco explícito. No
podemos dar por garantizado el futuro en libertad. ¡No lo dé
por garantizado! Si usted desea mantener su libertad, debe estar preparado
para defenderla.
<p>
<hr>Regresar a la <a href="/home.es.html">página principal de GNU</a>.
<p>Por favor envíe sus preguntas (en inglés) sobre FSF &
GNU a <i><a href="mailto:address@hidden";>address@hidden</a></i>. También
hay <a href="/home.es.html#ContactInfo">otras maneras de contactar</a>
a la FSF.
<p>Por favor envíe comentarios (en inglés) sobre estas
páginas
a <i><a href="mailto:address@hidden";>address@hidden</a></i>,
envíe otras preguntas (en inglés) a
<i><a href="mailto:address@hidden";>address@hidden</a></i>.
<p>Copyright (C) 1998 Richard Stallman
<p>Está permitida la copia textual y distribución de este
artículo en su totalidad por cualquier medio, siempre y cuando esta
nota se preserve.
<p>Actualizado:<!-- hhmts start -->23 Mayo 1999 rms<!-- hhmts end -->
<hr>Traducción: <i>César Ballardini (Argentina)</i> <a
href="mailto:address@hidden";><address@hidden></a>
<br>$Date: 2001/02/13 01:22:39 $
<p>Revisión:
<ul>
<li>
<i>Ramsés Morales (Panamá)</i> <a
href="mailto:address@hidden";><address@hidden></a></li>
<li>
<i>César Villanueva (Venezuela)</i> <a
href="mailto:address@hidden";><address@hidden></a></li>
<li>
<i>Oscar Mendez Bonilla (México)</i> <a
href="mailto:address@hidden";><address@hidden></a></li>
</ul>
Coordinación:
<ul>
<li>
<i>Hugo Gayosso</i> <a href="mailto:address@hidden";><address@hidden></a></li>
</ul>
<p>Actualizada: 30 Nov 1999 <a href="mailto:address@hidden";>Cesar Javier
Bolaños Vizcarra (México)</a>
<hr>
</body>
</HTML>
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNU-traductores] old-gnudist:/home/www/html/gnu/thegnuproject.es.html -- New file,
old-gnudist's file diff daemon <=