summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/es/shouldbefree.html
diff options
context:
space:
mode:
Diffstat (limited to 'talermerchantdemos/blog/articles/es/shouldbefree.html')
-rw-r--r--talermerchantdemos/blog/articles/es/shouldbefree.html947
1 files changed, 947 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/es/shouldbefree.html b/talermerchantdemos/blog/articles/es/shouldbefree.html
new file mode 100644
index 0000000..cc4fe5b
--- /dev/null
+++ b/talermerchantdemos/blog/articles/es/shouldbefree.html
@@ -0,0 +1,947 @@
+<!--#set var="ENGLISH_PAGE" value="/philosophy/shouldbefree.en.html" -->
+
+<!--#include virtual="/server/header.es.html" -->
+<!-- Parent-Version: 1.86 -->
+
+<!-- This file is automatically generated by GNUnited Nations! -->
+<title>Por qué el software debe ser libre - Proyecto GNU - Free Software Foundation </title>
+
+<!--#include virtual="/philosophy/po/shouldbefree.translist" -->
+<!--#include virtual="/server/banner.es.html" -->
+<h2>Por qué el software debe ser libre</h2>
+
+<p>
+por <a href="http://www.stallman.org/"><strong>Richard Stallman</strong></a></p>
+<h3 id="introduction">Introducción</h3>
+<p>
+La existencia de software plantea inevitablemente la cuestión sobre qué
+decisiones deberían tomarse respecto a su uso. Por ejemplo, supongamos que
+una persona que tiene una copia de un programa se encuentra con otra a quien
+le gustaría tener otra copia. Sabemos que es posible copiar el programa
+pero, ¿quién debe decidir si esto se lleva a cabo?: ¿las personas
+involucradas?, ¿o un tercero, llamado «propietario»?</p>
+<p>
+ Por lo general, los desarrolladores de software responden a estas preguntas
+basándose en el criterio de maximizar los beneficios del programador. El
+poder político del sector empresarial ha llevado al gobierno a adoptar el
+mismo criterio y la respuesta que proponen los desarrolladores: que el
+programa tiene un dueño, generalmente una empresa asociada a su desarrollo.</p>
+<p>
+ Me gustaría considerar esta cuestión adoptando un criterio diferente: la
+prosperidad y la libertad del público en general.</p>
+<p>
+ La respuesta no puede provenir de la ley vigente, la ley debería ajustarse a
+la ética, y no al revés. Tampoco la práctica actual resuelve esta cuestión,
+aunque puede sugerir algunas respuestas posibles. La única manera de juzgar
+es observar quién se beneficia y quién se perjudica si se reconoce que el
+software tiene propietarios, por qué y en qué medida. En otras palabras,
+deberíamos realizar un análisis del tipo costo-beneficio en nombre de la
+sociedad como un todo, teniendo en cuenta tanto la libertad individual como
+la producción de bienes materiales.</p>
+<p>
+ En este ensayo describiré los efectos provocados por el reconocimiento de
+propietarios y mostraré que los resultados son perjudiciales. Mi conclusión
+es que los programadores tenemos que animar a otros a compartir,
+redistribuir, estudiar y mejorar el software que escribimos; en otras
+palabras, escribir <a href="/philosophy/free-sw.html">software
+«libre»</a>.<a href="#f1">(1)</a></p>
+
+<h3 id="owner-justification">Cómo justifican su poder los propietarios</h3>
+<p>
+ Aquellos que se benefician del sistema actual, en el que los programas son
+concebidos como objetos de propiedad, esgrimen dos argumentos en favor de su
+derecho de ser propietarios de los programas: el argumento emocional y el
+económico.</p>
+<p>
+ El argumento emocional es del tipo: «Pongo mi sudor, mi corazón, mi alma en
+este programa. <em>Yo</em> lo hice, ¡es <em>mío</em>!»</p>
+<p>
+ Este argumento no resiste un análisis serio. El sentimiento de apego puede
+ser cultivado por los programadores cuando les convenga, pero no es
+inevitable. Considérese, por ejemplo, cuán deseosos firman y ceden sus
+derechos sobre el programa a una gran empresa a cambio de un salario;
+misteriosamente el apego emocional se desvanece. Por el contrario,
+considérense a los grandes artistas y artesanos de la época medieval, que ni
+siquiera firmaban sus trabajos. Para ellos, el nombre del artista no era
+importante. Lo que importaba era que el trabajo se había hecho, y el
+propósito al que servía. Esta visión prevaleció durante cientos de años.</p>
+<p>
+ El argumento económico es del tipo: «Quiero ser rico (normalmente expresado
+de manera poco precisa como &ldquo;de algo tengo que vivir&rdquo;), y si no
+dejas que me enriquezca programando, entonces no programaré. Todo el mundo
+es como yo, de manera que nadie programará jamás. ¡Y te encontrarás con que
+no tienes programas!&rdquo;. Esta amenaza suele venir disfrazada como un
+amigable y sabio consejo.</p>
+<p>
+ Explicaré más tarde por qué esta amenaza es completamente absurda. En primer
+lugar, me gustaría presentar una hipótesis implícita que está mucho más
+presente en otra formulación del mismo argumento.</p>
+<p>
+ Esta formulación comienza comparando la utilidad social de un programa
+privativo con la utilidad que se derivaría de no tenerlo, y entonces
+concluye que el software privativo es en general beneficioso, y que debería
+ser promovido. La falacia reside aquí en comparar solamente dos
+posibilidades: software privativo versus ausencia de software, y suponer que
+no existen otras posibilidades.</p>
+<p>
+ En un sistema en el que imperan los derechos de autor, el desarrollo de
+software se encuentra generalmente vinculado a la existencia de un dueño que
+controla su uso. Mientras exista este vínculo, nos enfrentamos continuamente
+a la elección entre software privativo o nada. Sin embargo, este vínculo no
+es inherente ni tampoco inevitable; es más bien consecuencia de una decisión
+política social y legal específica que aquí estamos cuestionando: la
+decisión de que el software tenga propietarios. Formular la elección entre
+software privativo y ausencia de software es una petición de principio.</p>
+
+<h3 id="against-having-owners">El argumento en contra de la propiedad del software</h3>
+<p>
+ La pregunta que se nos plantea es, «¿debería el software estar vinculado a
+la existencia de dueños para, de esa manera, restringir su uso?»</p>
+<p>
+ Para resolver este problema, tenemos que evaluar el efecto en la sociedad de
+cada una las dos opciones <em>independientemente</em> una de otra: el efecto
+de desarrollar software (sin considerar los términos de distribución) y el
+efecto de restringir su uso (suponiendo que el software ya haya sido
+desarrollado). Si una de estas opciones es beneficiosa y la otra es
+perjudicial, deberíamos deshacer el vínculo y utilizar solo aquella que
+resulta beneficiosa.</p>
+<p>
+ En otras palabras, si restringir la distribución de un programa ya
+desarrollado es perjudicial para la sociedad en su conjunto, un programador
+con conciencia ética rechazará esta opción.</p>
+<p>
+ Para determinar el efecto de restringir el derecho de compartir, tenemos que
+comparar los beneficios para la sociedad de un programa restringido (por
+ejemplo, un programa privativo) con los que ofrece ese mismo programa pero
+libre. Esto significa comparar dos mundos posibles.</p>
+<p>
+ Este análisis también tiene en cuenta un contraargumento usado en ciertas
+ocasiones, el cual dice que «los beneficios que se proporcionan al prójimo
+al darle una copia de un programa se cancelan por el perjuicio provocado al
+propietario». Este contraargumento presupone que el perjuicio y el beneficio
+son de igual magnitud. El análisis implica la comparación de ambas
+magnitudes y demuestra que el beneficio es mucho mayor que el perjuicio.</p>
+<p>
+ Para clarificar este argumento, vamos a aplicarlo a otro ámbito: la
+construcción de carreteras.</p>
+<p>
+ La financiación para construir todas las carreteras podría provenir de
+peajes. Como consecuencia nos encontraríamos puntos de peaje en cada
+esquina. Un sistema de este tipo generaría incentivos a la hora de mejorar
+las carreteras. También tendría la virtud de obligar a los usuarios de una
+determinada carretera a pagar por ella. Sin embargo, un punto de peaje es un
+obstáculo artificial que dificulta la circulación fluida del tráfico;
+artificial, porque no es una consecuencia derivada del modo en que funcionan
+los automóviles o las carreteras.</p>
+<p>
+ Si comparamos la utilidad de las carreteras libres y de aquellas con peaje,
+vemos que, siendo iguales en todo, la contrucción y la administración de
+carreteras sin puntos de peaje resultan más económicas, además de ser más
+seguras y más eficientes <a href="#f2">(2)</a>. En un país pobre, el peaje
+podría impedir a muchos ciudadanos el acceso a las carreteras. De manera que
+las carreteras sin peajes ofrecen mayores beneficios a la sociedad a un
+costo menor; por lo tanto son mejores para la sociedad. Así, la sociedad
+debería escoger otros medios para financiar las carreteras, no mediante
+peajes. Una vez construidas, el uso de las carreteras debería ser gratuito.</p>
+<p>
+ Cuando los defensores de los peajes los presentan como una<em>simple</em>
+forma de recaudación de fondos, distorsionan la opción que existe. Los
+peajes incrementan los fondos públicos, pero hacen algo más: degradan, de
+hecho, la carretera. La carretera con peaje no es tan buena como la
+carretera libre; que se nos proporcionen más carreteras o carreteras
+técnicamente superiores puede muy bien no ser una mejora si implica
+sustituir las carreteras gratuitas por carreteras con peaje.</p>
+<p>
+ Por supuesto, la construcción de una carretera gratuita cuesta dinero, que
+de alguna manera la gente debe pagar. Sin embargo, esto no implica la
+inevitabilidad de los peajes. Nosotros, que en ambos casos pagamos,
+obtendremos mayores beneficios de nuestro dinero si lo invertimos en una
+carretera gratuita.</p>
+<p>
+ No quiero decir con esto que una carretera con peaje sea peor que la
+ausencia de carreteras. Eso sería verdad si el peaje fuese tan alto que casi
+nadie pudiera usarla, pero es improbale que un recaudador de impuestos
+adopte una política de ese tipo. Sin embargo, en tanto que los peajes
+suponen pérdidas de tiempo y molestias considerables, es mejor conseguir el
+dinero de una manera menos obstruccionista.</p>
+<p>
+ Para aplicar este mismo argumento al desarrollo de software, mostraré ahora
+que introducir «peajes» en el software útil le cuesta caro a la sociedad:
+encarece la construcción de los programas, encarece su distribución, y su
+uso resulta menos satisfactorio y menos eficiente. De lo que se deduce que
+la construcción de programas debería promoverse de alguna otra manera. Más
+adelante continuaré explicando otros métodos posibles para la promoción y,
+en la medida en que sea realmente necesario, para la financiación del
+desarrollo de software.</p>
+
+<h4 id="harm-done">El perjuicio ocasionado por obstaculizar el software</h4>
+<p>
+ Consideremos por un momento que se ha desarrollado un programa y que se ha
+efectuado todo pago necesario para su desarrollo; ahora la sociedad debe
+decidir entre convertirlo en privativo o permitir que se use y se comparta
+libremente. Supongamos que la existencia del programa y su disponibilidad
+sean algo deseable.<a href="#f3">(3)</a></p>
+<p>
+ Las restricciones a la distribución y modificación del programa no pueden
+facilitar su uso. Sólo pueden interferir. Así que el efecto solamente puede
+ser negativo. ¿Pero en qué medida? ¿Y de qué tipo?</p>
+<p>
+ Existen tres niveles diferentes de daño material que provienen de estas
+restricciones:</p>
+
+<ul>
+<li>Un menor número de personas usa el programa.</li>
+
+<li>Ninguno de los usuarios puede adaptar o mejorar el programa.</li>
+
+<li>Otros desarrolladores no pueden aprender del programa, ni basar en el mismo
+un nuevo programa.</li>
+</ul>
+
+<p>
+ Cada nivel de perjuicio material lleva asociado un perjuicio
+psico-social. Me refiero al efecto que tienen las decisiones de las personas
+sobre sus sentimientos, actitudes y predisposiciones posteriores. Estos
+cambios en la manera de pensar de las personas afectarán la relación con sus
+conciudadanos y pueden acarrear consecuencias concretas.</p>
+<p>
+ Los tres niveles de perjuicio material desperdician parte del valor que el
+programa podría proporcionar, pero no lo anulan. Si desperdician casi todo
+el valor del programa, entonces el hecho de escribir el programa perjudica a
+la sociedad en la medida en que se dedicó un esfuerzo en escribir el
+programa. Se podría decir que aquel programa que produce beneficios al
+venderse debe proporcionar algún tipo de beneficio material directo.</p>
+<p>
+ Sin embargo, teniendo en cuenta el perjuicio psico-social asociado, no
+existe límite alguno al perjuicio que puede ocasionar el desarrollo de
+software privativo.</p>
+
+<h4 id="obstructing-use">Obstaculizar el uso de programas</h4>
+<p>
+ El primer nivel de perjuicio impide el simple uso del programa. Una copia
+del programa tiene un costo marginal casi nulo (y se puede pagar este costo
+realizando la copia personalmente) de manera que en un mercado libre tendría
+un precio casi nulo. El pago por una licencia es un factor de disuasión
+significativo a la hora de usar el programa. Si un programa ampliamente útil
+es privativo, menos personas lo usarán.</p>
+<p>
+ Es fácil mostrar que la contribución total que un programa proporciona a la
+sociedad se reduce al asignársele un propietario. Todo usuario potencial del
+programa, enfrentado al hecho de tener que pagar para usarlo, puede escoger
+entre pagar o renunciar a usar el programa. Cuando un usuario escoge pagar,
+la transferencia de riqueza entre las dos partes es igual a suma cero. Pero
+cada vez que alguien elije no usar el programa, se provoca un perjuicio a
+esa persona sin que nadie salga beneficiado. La suma entre números negativos
+y ceros es siempre negativa.</p>
+<p>
+ Pero esto no reduce la cantidad de trabajo necesario para
+<em>desarrollar</em> el programa. Como resultado, la eficiencia del entero
+proceso, medida en términos de satisfacción del usuario final por hora de
+trabajo, se reduce.</p>
+<p>
+ Esto refleja la diferencia crucial entre las copias de programas y los
+automóviles, las sillas o los bocadillos. No existe una copiadora de objetos
+materiales fuera de la ciencia ficción. Pero los programas son fáciles de
+copiar, con muy poco esfuerzo cualquiera puede producir tantas copias como
+desee. Esto no es así para los objetos materiales porque la materia se
+conserva: cada copia nueva tiene que generarse con materia prima, de la
+misma forma en que se construyó la primera copia.</p>
+<p>
+ Con objetos materiales, desalentar su uso tiene cierto sentido, porque un
+menor número de objetos comprados implica menos materia prima y menos
+trabajo para producirlos. Es cierto que generalmente existen costos
+iniciales y de desarrollo que se extienden al proceso de producción. Pero
+mientras el costo marginal de producción sea significativo, añadir una parte
+del costo de desarrollo no produce una diferencia cualitativa. Y no requiere
+la imposición de restricciones a la libertad de los usuarios normales.</p>
+<p>
+ Sin embargo, imponer un precio en algo que, de otra manera, podría ser
+gratuito, es un cambio cualitativo. Un pago impuesto unilateralmente sobre
+la distribución de software provoca una fuerte falta de incentivos.</p>
+<p>
+ Más aún, la producción centralizada tal y como se practica en nuestros días,
+es ineficiente incluso en términos de distribución de copias de
+software. Este sistema consiste en enviar discos o cintas magnéticas en
+embalajes superfluos, mandar grandes cantidades a lo largo y a lo ancho del
+mundo, y almacenarlos para la venta. Este coste se presenta como derivado de
+hacer negocios; en realidad, es una parte del gasto inútil causado por el
+hecho de tener dueños.</p>
+
+<h4 id="damaging-social-cohesion">En perjuicio de la cohesión social</h4>
+<p>
+ Supongamos que tanto usted como su vecino consideran útil la ejecución de un
+cierto programa. En un pacto ético con su vecino, seguramente se pondrían de
+acuerdo en que una solución apropiada de la situación es que ambos usen el
+programa. Una propuesta que permitiese usar el programa sólo a uno,
+restringiendo al otro, es discriminatoria; a ninguno de los dos, les
+parecerá aceptable.</p>
+<p>
+ Firmar una licencia típica de software implica traicionar a su vecino:
+«Prometo privar a mi vecino de este programa para que yo pueda tener una
+sola copia para mi». Las personas que toman estas decisiones sienten una
+presión psicológica interna que les empuja a justificarlas degradando la
+importancia de ayudar al prójimo de tal forma que el espíritu público
+resulta perjudicado. Se trata de un daño psicosocial asociado con el daño
+material provocado por la desincentivación del uso del programa.</p>
+<p>
+ Muchos usuarios admiten inconscientemente que resulta erróneo negarse a
+compartir, así que deciden ignorar las licencias y las leyes, y comparten el
+programa de todas formas. Sin embargo, a menudo se sienten culpables de
+hacerlo. Saben que deben infringir las leyes para poder ser buenos vecinos,
+pero siguen considerando que las leyes tienen autoridad y concluyen que ser
+un buen vecino (que lo son) es algo malo de lo que hay que avergonzarse. Se
+trata también de un tipo de daño psicosocial, pero se puede escapar de ello
+concluyendo que estas licencias y estas leyes no tienen fuerza moral alguna.</p>
+<p>
+ Los programadores también sufren ese daño psicosocial cuando llegan a saber
+que a muchos usuarios se les impedirá usar su obra. Esto conduce a una
+actitud de cinismo o de autoengaño. Un programador puede describir de manera
+entusiasta una obra que considera técnicamente interesante, y cuando se le
+pregunta: «¿Se me permitirá usar el programa?», se vuelve cabizbajo y admite
+que la respuesta es «no». Para evitar desalentarse, casi siempre ignora este
+hecho, o bien adopta una postura cínica pensada para minimizar su
+importancia.</p>
+<p>
+ Desde la era Reagan, la principal fuente de escasez de los Estados Unidos de
+Norteamérica no es la de las innovaciones técnicas sino más bien la falta de
+voluntad para trabajar juntos por el bien público. No tiene sentido alentar
+lo primero a expensas de esto último.</p>
+
+<h4 id="custom-adaptation">Obstaculizar la adaptación personalizada de programas</h4>
+<p>
+ El segundo nivel de perjuicio material es la imposibilidad de adaptar los
+programas. La posibilidad de modificar el software es una de las grandes
+ventajas en comparación con las antiguas tecnologías. Sin embargo, la mayor
+parte del software disponible comercialmente no está disponible para ser
+modificado, ni siquiera después de haberlo comprarlo. Se puede decidir
+tomarlo o dejarlo, como una caja negra, solo eso.</p>
+<p>
+ El programa que se ejecuta consiste en una serie de números cuyo significado
+permanece oscuro. Nadie, ni siquiera un buen programador, puede cambiar
+fácilmente esos números para lograr que el programa haga algo diferente.</p>
+<p>
+ Los programadores trabajan normalmente con el «código fuente» del programa,
+que está escrito en un lenguaje de programación como por ejemplo Fortran o
+C. Mediante nombres se designan los datos que se están usando y las partes
+del programa, y se representan las operaciones con símbolos tales como «+»
+para la suma y «-» para la resta. El lenguaje está diseñado para ayudar a
+los programadores a leer y modificar los programas. He aquí un ejemplo. un
+programa que calcula la distancia entre dos puntos en un plano:</p>
+
+<pre>
+ float
+ distance (p0, p1)
+ struct point p0, p1;
+ {
+ float xdist = p1.x - p0.x;
+ float ydist = p1.y - p0.y;
+ return sqrt (xdist * xdist + ydist * ydist);
+ }
+</pre>
+<p>
+ El punto no es qué significa precisamente el código fuente, el punto es que
+parece álgebra, y para una persona que conoce este lenguaje de programación
+será claro y significativo. Por el contrario, este es el mismo programa
+programa en formato ejecutable, en la computadora que usaba normalmente
+cuando escribí esto:
+</p>
+
+<pre>
+ 1314258944 -232267772 -231844864 1634862
+ 1411907592 -231844736 2159150 1420296208
+ -234880989 -234879837 -234879966 -232295424
+ 1644167167 -3214848 1090581031 1962942495
+ 572518958 -803143692 1314803317
+</pre>
+
+<p>
+ El código fuente es útil (al menos potencialmente) para cualquier usuario de
+un programa. Pero a la mayoría de los usuarios no se les permite tener
+copias del código fuente. Generalmente el código fuente de un programa
+privativo es guardado en secreto por el propietario, por miedo a que
+cualquier otro pueda aprender algo. Los usuarios reciben solamente ficheros
+de números incomprensibles que el ordenador se encargará de ejecutar. Esto
+quiere decir que únicamente el propietario del programa lo puede modificar.</p>
+<p>
+ Una amiga me contó una vez que trabajó como programadora en un banco durante
+seis meses, escribiendo un programa similar a otro que se podía obtener
+comercialmente. Pensaba que si hubiese tenido acceso al código fuente de ese
+programa comercial lo podría haber adaptado fácilmente a las necesidades del
+banco. El banco estaba dispuesto a pagar por ello, pero no le estaba
+permitido hacerlo pus el código fuente era secreto. De manera que tuvo que
+dedicar seis meses de trabajo de desarrollo, un trabajo que aparece
+contabilizado en el Producto Bruto Interno (PBI) pero que realmente fue un
+desperdicio.</p>
+<p>
+ Hacia 1977, el Laboratorio de Inteligencia Artificial (AI lab) del <abbr
+title="Instituto de Tecnología de Massachusetts ">MIT</abbr> recibió de
+regalo una impresora gráfica de Xerox. Corría con software libre al que
+añadimos bastantes mejoras útiles. Por ejemplo, el programa notificaba
+inmediatamente al usuario cuando el trabajo de impresión había
+terminado. Cuando la impresora tenía un problema, por ejemplo una
+obstrucción o falta de papel, el software lo notificaba inmediatamente a
+todos los usuarios que tuviesen trabajos pendientes. Estas mejoras
+facilitaban el trabajo.</p>
+<p>
+ Más tarde Xerox donó al laboratorio de IA una impresora nueva, más rápida,
+una de las primeras impresoras láser. Funcionaba con software privativo que
+corría en un ordenador independiente dedicado en forma exclusiva, de manera
+que no pudimos añadir ninguna de nuestras mejoras favoritas. Pudimos hacer
+que enviase una notificación cuando se mandaba un trabajo de impresión al
+ordenador dedicado a la impresora, pero no cuando el trabajo se había
+terminado, y generalmente el retraso era considerable. No había forma de
+saber cuándo la impresión había terminado, lo único que se podía hacer era
+adivinarlo. Y nadie sabía nunca cuando se atascaba el papel, así que a
+menudo la impresora se quedaba fuera de servicio por espacio de una hora.</p>
+<p>
+ Los programadores de sistemas del laboratorio de IA Lab estaban capacitados
+para solucionar aquellos problemas, probablemente tan capacitados como los
+autores originales del programa. Xerox no mostró interés en arreglar
+aquellas fallas y nos lo impidió, de manera que nos vimos forzados a
+aceptar. Nunca se arreglaron.</p>
+<p>
+ La mayoría de los buenos programadores han experimentado esta
+frustración. El banco podía permitirse resolver un problema escribiendo un
+programa nuevo partiendo de cero, pero un usuario corriente, no importa lo
+capacitado que esté, no tiene más opción que rendirse.</p>
+<p>
+ Rendirse provoca un daño psicosocial, al espíritu de independencia. Es
+desmoralizante vivir en una casa que no puedes arreglar para adecuarla a tus
+necesidades. Lleva a la resignación y al retraimiento, que pueden extenderse
+a otros ámbitos de la vida. La gente que padece de esta manera no se
+encuentra a gusto y no realiza un buen trabajo.</p>
+<p>
+ Imagínese cómo sería si las recetas de cocina se acaparasen de la misma
+manera que el software. Uno se podría preguntar: «¿Cómo cambio esta receta
+para que no tenga sal?» y que el gran chef respondiese: «¿Cómo se atreve a
+insultar mi receta, mi creación y mi paladar, manoseándola? ¡No tiene usted
+el juicio necesario para cambiar mi receta y hacer que salga bien!»</p>
+<p>
+ «¡Pero mi médico me ha prohibido tomar sal! ¿Qué puedo hacer? ¿Va a quitar
+usted la sal por mí?»</p>
+<p>
+ «Me encantaría hacerlo, mis honorarios son de sólo 50.000 dólares» (como el
+dueño posee el monopolio sobre los modificaciones, las tarifas suelen ser
+elevadas). «De todas formas, ahora mismo no tengo tiempo. Estoy ocupado en
+una comisión para diseñar una nueva receta de galleta marítima para la
+Armada. Estaré contigo en unos dos años.»</p>
+
+<h4 id="software-development">Obstaculizar el desarrollo de software</h4>
+<p>
+ El tercer nivel de daño material afecta al desarrollo de software. El
+desarrollo de software normalmente era el resultado de un proceso evolutivo
+en el que una persona tomaba un programa existente y modificaba algunas
+partes para añadir una función nueva, y luego otra persona volvía aescribir
+algunas partes para añadir otra función; en algunos casos, este proceso
+transcurría durante un periodo de veinte años. Mientras tanto, algunas
+partes de ese programa podían ser «canibalizadas» para comenzar el
+desarrollo de otros programas.</p>
+<p>
+ La existencia de propietarios impide este tipo de evolución, hace necesario
+empezar desde cero cuando se quiere desarrollar un programa. También impide
+a los nuevos programadores estudiar los programas disponibles para aprender
+técnicas útiles o incluso ver cómo están estructurados los programas de
+mayor envergadura.</p>
+<p>
+ Los propietarios también obstruyen el aprendizaje. He conocido estudiantes
+brillantes en informática que nunca han visto el código fuente de un
+programa extenso. Pueden ser buenos escribiendo pequeños programas, pero no
+pueden empezar a adquirir las diferentes habilidades necesarias para
+escribir programas extensos si no pueden ver cómo lo han hecho otros.</p>
+<p>
+ En cualquier campo intelectual, uno puede alcanzar metas más elevadas
+apoyándose en otros. Pero esto ya no se permite por lo general en el campo
+del software: uno puede apoyarse solamente en otras personas <em>de la
+propia empresa</em>.</p>
+<p>
+ El daño psicosocial asociado afecta el espíritu de cooperación científica,
+que normalmente era tan intenso que los científicos seguían cooperando
+incluso cuando sus países entraban en guerra. Con este espíritu, los
+oceanógrafos japoneses que abandonaron su laboratorio en una isla del
+Pacífico preservaron cuidadosamente su trabajo en el momento de la invasión
+de los marines de los EEUU y dejaron una nota pidiendo que lo conservaran
+bien.</p>
+<p>
+ El conflicto por la obtención de ganancias ha destruido lo que se salvó del
+conflicto internacional. Hoy en día, científicos de numerosas disciplinas no
+publican lo suficiente en sus trabajos como para permitir a otros repetir el
+experimento. Publican solamente lo necesario para que los lectores puedan
+maravillarse de lo mucho que los científicos saben hacer. Desde luego, esto
+también es así en el campo de la informática, donde el código fuente de los
+programas que se anuncian es generalmente secreto.</p>
+
+<h4 id="does-not-matter-how">No importa cómo se restrinja el acto de compartir</h4>
+<p>
+ He discutido sobre los efectos de impedir la copia o la modificación de un
+programa o de impedir que se utlice para usarlo como base para desarrolar
+otro programa. No he especificado cómo se lleva a cabo esta obstrucción,
+puesto que no afecta a la conclusión. Como quiera que se haga, mediante
+protección anticopia, derechos de autor, licencias, encriptación, tarjetas
+<abbr title="Read-only Memory">ROM</abbr>, o números de serie del hardware,
+si se <em>logra</em> impedir el uso, el daño está hecho.</p>
+<p>
+ Los usuarios consideran algunos de estos métodos más desagradables que
+otros. Creo que los métodos más odiosos son aquellos que cumplen su
+objetivo.</p>
+
+<h4 id="should-be-free">El software debe ser libre</h4>
+<p>
+ He argumentado que la propiedad de un programa, o sea el poder de restringir
+las modificaciones o las copias, es obstructiva. Sus efectos negativos son
+extensos e importantes. La conclusión es que en la sociedad no deberían
+existir propietarios de programas.</p>
+<p>
+ Otra manera de comprender esto es reconocer que la sociedad necesita que el
+software sea libre y que el software privativo es un mal sustituto. Promover
+el sustituto no es una manera lógica de conseguir lo que necesitamos.</p>
+<p>
+ Vaclav Havel nos aconsejó: «Trabaja por algo porque es bueno, no simplemente
+porque tiene probabilidades de éxito» Una empresa que produce software
+privativo tiene probabilidades de éxito en sus propios y estrechos términos,
+pero no es lo que beneficia a la sociedad.</p>
+
+<h3 id="why-develop">Por qué la gente desarrollará software</h3>
+<p>
+ Si eliminamos los derechos de autor como forma de animar a la gente a
+desarrollar software, al principio se desarrollará una menor cantidad de
+software, pero ese software será más útil. No está claro si la satisfacción
+total del usuario será inferior; pero si así fuera, o si quisiéramos
+aumentarla, existen otras maneras de promover el desarrollo, exactamente
+igual que hay formas alternativas a los peajes para conseguir dinero con el
+fin de pagar las carreteras. Antes de hablar acerca de cómo lograrlo,
+quisiera abordar la cuestión del grado de promoción artificial
+verdaderamente necesario.</p>
+
+<h4 id="fun">Programar es divertido</h4>
+<p>
+ Existen algunos tipos de trabajo que poca gente haría si no fuera por el
+dinero; la construcción de carreteras, por ejemplo. Hay otros campos de la
+ciencia y del arte en los que existe escasa probabilidad de enriquecerse, en
+los que las personas se involucran por fascinación o por que perciben que
+son socialmente valiosos. Algunos ejemplos son la lógica matemática, la
+música clásica y la arqueología, como así también la organización política
+entre los trabajadores. La gente compite, más triste que amargamente, por
+las pocas vacantes remuneradas disponibles, ninguna de las cuales está muy
+bien financiada. Incluso hasta pueden pagar por la oportunidad de trabajar
+en ese campo, si pueden permitírselo.</p>
+<p>
+ Un campo así puede transformarse de la noche a la mañana si empieza a
+ofrecer posibilidades de enriquecimiento. Cuando un trabajador prospera,
+otros demandan las mismas oportunidades. Pronto todos pedirán grandes sumas
+de dinero por aquello que antes hacían por placer. En un par de años, todo
+el mundo relacionado con ese campo se burlará de la idea de que ese trabajo
+se realice sin obtener a cambio grandes sumas de dinero. Aconsejarán a los
+planificadores sociales que se aseguren de que estos retornos de capital
+sean posibles, creando privilegios especiales, poderes y monopolios,
+alegando que son necesarios.</p>
+<p>
+ Esta transformación sucedió en el campo de la programación de ordenadores
+durante los años setenta. En la década del 70 uno podía encontrarse con
+artículos sobre la «adicción a las computadoras»: los usuarios estaban
+«conectados» y llevaban indumentos de cien dólares por semana. Se llegó a un
+punto en que la gente amaba tanto la programación como para acabar con sus
+matrimonios. Hoy en día, lo que se dice es que nadie programa sin recibir
+una excelente remuneración. La gente ha olvidado lo que se sabía en ese
+entonces.</p>
+<p>
+ Llegado el momento en el que quienes trabajan en un campo determinado lo
+hacen solamente por las altas sumas de dinero que se pagan, esto no debe
+llevar a la conclusión de que será siempre así. La dinámica del cambio puede
+invertir la dirección si la sociedad proporciona el empuje inicial. Si
+anulamos la posibilidad de enriquecerse enormemente, entonces, después de un
+tiempo, cuando la gente haya reajustado sus actitudes, se volverá una vez
+más a trabajar en ese campo por el placer de hacerlo.</p>
+<p>
+ La respuesta a la pregunta «¿cómo podemos pagar a los programadores?»
+resulta más fácil cuando nos damos cuenta de que no es una cuestión de
+pagarles una fortuna. Se trata de conseguir los fondos necesarios como para
+poder ganarse la vida.</p>
+
+<h4 id="funding">Financiación del software libre</h4>
+<p>
+ Las instituciones que pagan a los programadores no tienen que ser
+necesariamente empresas de software. Existen ya muchas otras instituciones
+que pueden hacerlo.</p>
+<p>
+ Los fabricantes de hardware saben que es esencial colaborar en el desarrollo
+de software, incluso cuando no puedan controlar su uso. En 1970 la mayoría
+del software era libre porque no se había considerado la posibilidad de
+restringirlo. Hoy en día, la creciente voluntad de los fabricantes de unirse
+en consorcios refleja su comprensión de que la propiedad del software no es
+lo que realmente les importa.</p>
+<p>
+ Las universidades dirigen muchos proyectos de programación. Hoy en día, a
+menudo venden los resultados, pero en los años setenta no lo hacían. ¿Cabe
+alguna duda de que las universidades desarrollarían software libre si no se
+les permitiera vender el software? Estos proyectos podrían estar respaldados
+por los mismos contratos y subvenciones gubernamentales que ahora respaldan
+el desarrollo de software privativo.</p>
+<p>
+ Hoy en día lo normal es que los investigadores universitarios obtengan
+subvenciones para desarrollar un sistema casi hasta el punto de completarlo,
+denominando a eso un producto «acabado», y luego son las empresas las que
+realmente lo terminen y lo conviertan en algo útil. A veces declaran «libre»
+esa versión sin acabar, pero si son profundamente corruptos, lo que hacen es
+conseguir que la universidad les otorgue una licencia de exclusividad. Esto
+no es un secreto, es abiertamente admitido por todos los involucrados. Sin
+embargo, si los investigadores no se vieran tentados a hacer estas cosas,
+seguirían investigando de todas formas.</p>
+<p>
+ Los programadores que escriben software libre pueden vivir de la venta de
+servicios relacionados con el software. Yo he sido contratado para adaptar
+el <a href="/software/gcc/">Compilador GNU de C</a> a un hardware nuevo y
+para construir extensiones de interfaces de usuario para <a
+href="/software/emacs/">GNU Emacs</a>. Ofrezco esas mejoras al público una
+vez acabadas. También doy clases por las que me pagan.</p>
+<p>
+ No soy el único que trabaja de esta manera. Existe una corporación que está
+creciendo de forma exitosa y se dedica exclusivamente a este tipo de
+trabajo. Otras empresas proporcionan soporte comercial para el software
+libre del sistema GNU. Este es el comienzo de una industria independiente de
+soporte de software, una industria que podría crecer bastante si el software
+libre se llega a imponer. Proporciona a los usuarios una opción generalmente
+no disponible para el software privativo, excepto para los ricos.</p>
+<p>
+ Nuevas instituciones como la <a href="/fsf/fsf.html">Free Software
+Foundation</a> pueden también subvencionar a los programadores. La mayoría
+de los fondos de la Fundación provienen de los usuarios que compran cintas
+magnéticas por correo. Las cintas contienen software que es libre, lo que
+quiere decir que cualquier usuario tiene la libertad de copiarlo y
+modificarlo, pero aún así muchos pagan por las copias. Recuérdese que
+«software libre» se refiere a la libertad, no al precio. Algunos usuarios
+encargan cintas magnéticas de programas que ya tienen como una forma de
+contribución que estiman que merecemos. La Fundación también recibe
+importantes donaciones de fabricantes de computadoras.</p>
+<p>
+ La Free Software Foundation es una asociación sin fines de lucro y sus
+ingresos se invierten en contratar a tantos programadores como se pueda. Si
+se hubiese planteado como una empresa para distribuir software libre al
+público por el mismo precio, proporcionaría ahora un elevado nivel de
+ingresos a su fundador.</p>
+<p>
+ Precisamente porque la Fundación no persigue fines de lucro, los
+programadores trabajan por la mitad de lo que cobrarían en cualquier otro
+lugar. Hacen esto porque estamos libres de burocracia y porque les agrada
+saber que su trabajo no encontrará obstáculos al uso de sus obras. Y lo que
+es más importante, lo hacen porque programar es divertido. Además, los
+voluntarios han escrito muchos programas útiles para nosotros. Incluso han
+empezado a colaborar escritores técnicos.</p>
+<p>
+ Esto confirma que la programación se encuentra entre los campos más
+fascinantes, junto con la música y el arte. No debemos temer que no haya
+nadie que quiera programar.</p>
+
+<h4 id="owe">¿Qué deben los usuarios a los desarrolladores?</h4>
+<p>
+ Los usuarios de software tienen una buena razón para sentirse moralmente
+obligados a contribuir a su soporte. Los desarrolladores de software libre
+contribuyen a las actividades de los usuarios, y a largo plazo es justo, a
+la vez que beneficioso para los usuarios, proporcionar fondos para que esto
+continúe.</p>
+<p>
+ Sin embargo, esto no se aplica a los desarrolladores de software privativo,
+ya que el obstruccionismo merece un castigo más que una recompensa.</p>
+<p>
+ De manera que tenemos una paradoja: el desarrollador de software útil tiene
+el derecho de recibir el apoyo de los usuarios, pero cualquier intento que
+convierta esta obligación moral en un requisito destruye la base de la
+obligación. Un desarrollador puede merecer una recompensa o pedirla, pero no
+las dos cosas a la vez.</p>
+<p>
+ Creo que un desarrollador con perspectiva ética, enfrentado con esta
+paradoja, debe actuar de modo que merezca la recompensa, pero debería
+asimismo animar a los usuarios a que realicen donaciones voluntarias. Con el
+tiempo los usuarios aprenderán a ayudar a los desarrolladores sin coacción,
+como han aprendido a ayudar a las emisoras de radio o a las cadenas de
+televisión públicas.</p>
+
+<h3 id="productivity">Qué es la productividad de software </h3>
+<p>
+ Si el software fuese libre seguiría habiendo programadores, pero quizá
+menos. ¿Sería esto perjudicial para la sociedad?</p>
+<p>
+ No necesariamente. Hoy en día las naciones desarrolladas tienen menos
+granjeros que en el 1900, pero no creemos que esto sea malo para la sociedad
+porque esos pocos agricultores distribuyen a los consumidores más alimentos
+que los que antes proporcionaban muchos agricultores. Llamamos a esto mejora
+de la productividad. El software libre requeriría bastantes menos
+programadores para satisfacer la demanda, debido al incremento en la
+productividad de software en todos los niveles:</p>
+
+<ul>
+<li> El uso más extendido de cada programa que se desarrolla.</li>
+<li> La posibilidad de adaptar programas existentes a configuraciones especiales
+en lugar de tener que desarrollar los programas desde cero.</li>
+<li> Mejor educación de los programadores.</li>
+<li> La eliminación de la duplicación de esfuerzos en el desarrollo.</li>
+</ul>
+
+<p>
+ Aquellos que se oponen a la cooperación, quejándose de que podría producir
+una reducción en el empleo de los programadores, están, en realidad,
+oponiéndose al aumento de la productividad. Pero estas personas generalmente
+aceptan la creencia universal de que la industria del software necesita un
+incremento de productividad. ¿Cómo se explica esto?</p>
+<p>
+ La «productividad de software» puede significar dos cosas diferentes: la
+productividad general de todo el desarrollo de software o la productividad
+de proyectos individuales. La productividad general es lo que a la sociedad
+le gustaría mejorar y la forma más directa de lograrlo es eliminar los
+obstáculos artificiales que reducen la cooperación. Pero los investigadores
+que estudian el campo de la «productividad de software» se enfocan solamente
+en el segundo y más limitado sentido del término, en donde la mejora precisa
+de complejos avances tecnológicos.</p>
+
+<h3 id="competition">¿Es inevitable la competencia?</h3>
+<p>
+ ¿Es inevitable que la gente trate de competir y superar a sus rivales en la
+sociedad? Puede que así sea. Pero la competencia en sí misma no es dañina;
+lo dañino es <em>combatir</em>.</p>
+<p>
+ Existen muchas formas de competir. La competencia puede consistir en tratar
+de conseguir siempre más, en mejorar lo que otros han hecho. Por ejemplo, en
+el pasado, existía competencia entre los magos de la programación, que
+consistía en saber quién era capaz de hacer las cosas más fascinantes en la
+computadoras o quién era capaz de escribir el programa más corto o más
+rápido para una determinada tarea. Este tipo de competencia puede ser
+beneficiosa para todos, <em>siempre y cuando</em> se mantenga el espíritu de
+deportividad.</p>
+<p>
+ Una competencia constructiva es suficiente para motivar a la gente a
+realizar grandes esfuerzos. Hay un gran numero de personas que compiten por
+ver quién es el primero en visitar todos los países de la Tierra; algunos
+llegan a gastar una fortuna intentándolo. Pero no sobornan a los capitanes
+de barcos para que dejen desamparados a sus rivales en islas desiertas. No
+tienen ningún problema en dejar que gane al mejor.</p>
+<p>
+ La competencia se convierte en combate cuando los competidores intentan
+obstaculizarse los unos a los otros en lugar de avanzar por sí mismos,
+cuando «que gane el mejor» se convierte en «déjame ganar, aunque no sea el
+mejor». El software privativo es perjudicial, no porque sea una forma de
+competición, sino porque es una forma de combate entre los ciudadanos de
+nuestra sociedad.</p>
+<p>
+ La competición en los negocios no es necesariamente un combate. Por ejemplo,
+cuando dos supermercados compiten, todo su esfuerzo se emplea en mejorar sus
+actividades, no en sabotear al rival. Pero esto no demuestra un especial
+compromiso con una ética empresarial; más bien, existe poco margen de en
+esta rama de los negocios para la violencia física. No todas las áreas de
+negocio comparten esta característica. No revelar información que podría
+ayudar el progreso de todos es una forma de combate.</p>
+<p>
+ La ideología empresarial no prepara a las personas para resistir a la
+tentación de combatir a la competencia. Algunas formas de combate han sido
+prohibidas con leyes antimonopolio, leyes sobre publicidad honesta y otras
+más. Sin embargo, lejos de generalizar estas medidas repudiando el combate
+en general por cuestión de principios, los ejecutivos inventan otras formas
+de combate que no están específicamente prohibidas. Los recursos de la
+sociedad se despilfarran en el equivalente económico de una guerra civil
+entre distintas facciones.</p>
+
+<h3 id="communism">«¿Por qué no nos vamos a Rusia?»</h3>
+<p>
+ En los Estados Unidos de Nortemérica, cualquier partidario de otra cosa que
+no sea la forma más extrema de laissez-faire ha oído a menudo esta
+acusación. Por ejemplo, es esgrimida contra los defensores de un sistema de
+sanidad pública, como los que existen en todas las demás naciones
+industrializadas del mundo libre. Es esgrimida contra los que desean
+subvenciones al mundo de las artes, también universal en las naciones
+avanzadas. La idea de que los ciudadanos tienen una obligación para con el
+bien común se identifica en ese país con el comunismo. Pero, ¿cuán
+semejantes son estas ideas?</p>
+<p>
+ El comunismo, tal y como se practicó en la ex Unión Soviética, era un
+sistema de control central donde toda la actividad era dirigida
+supuestamente por el bien común, pero en realidad era en beneficio de los
+miembros del partido comunista. Y donde los equipos de copiado estaban
+estrechamente vigilados para prevenir posibles copias ilegales.</p>
+<p>
+ En los Estados Unidos de Norteamérica, el sistema de derechos de autor sobre
+el software ejerce un control central sobre la distribución de un programa y
+custodia los equipos de copiado con sistemas automatizados de protección
+anticopia para prevenir el copiado ilegal.</p>
+<p>
+ Por el contrario, yo trabajo para construir un sistema donde las personas
+sean libres de decidir sus propias acciones; en particular, libres de ayudar
+a sus vecinos y libres de alterar y mejorar las herramientas con las que
+trabajan en su vida diaria. Un sistema basado en la cooperación voluntaria y
+en la descentralización.</p>
+<p>
+ Así, si fuésemos a juzgar posturas por su parecido al comunismo ruso, son
+los propietarios de software quienes son comunistas.</p>
+
+<h3 id="premises">La cuestión de las premisas</h3>
+<p>
+ En este texto, parto del supuesto de que un usuario de software no es menos
+importante que un autor, o incluso que el jefe del autor. En otras palabras,
+sus intereses y necesidades tienen igual peso cuando se trata de elegir la
+mejor opción.</p>
+<p>
+ Esta premisa no es aceptada universalmente. Muchos sostienen que la persona
+que contrata al autor es fundamentalmente más importante que ningún
+otro. Dicen, por ejemplo, que el propósito de que existan propietarios de
+software es ceder al que contrata la ventaja que se merece,
+independientemente de de cómo puede afectar esto al público.</p>
+<p>
+ No tiene sentido tratar de demostrar o refutar estas premisas. La prueba
+necesita premisas compartidas. Así que la mayor parte de lo que digo está
+destinado solo a aquellos que comparten mis premisas o que al menos están
+interesados en cuáles son sus consecuencias. Para aquellos que crean que los
+propietarios son más importantes que nadie, este documento es simplemente
+irrelevante.</p>
+<p>
+ Pero, ¿por qué un gran número de estadounidenses acepta una premisa que da
+más importancia a algunas personas sobre el resto de los demás? En parte
+debido a la creencia de que esta premisa forma parte de las tradiciones
+legales de la sociedad estadounidense. Algunas personas sienten que poner en
+duda esta premisa implica cuestionar los fundamentos de la sociedad.</p>
+<p>
+ Es importante que esas personas sean concientes de que esta premisa no es
+parte de nuestra tradición legal. Nunca lo fue.</p>
+<p>
+ Así, la Constitución dice que el propósito de los derechos de autor es
+«promover el progreso de la ciencia y de las artes útiles». La Corte Suprema
+ha discutido sobre esto, dictando en el caso <em>Fox Film contra Doyal</em>
+que «el único interés del los Estados Unidos y el objetivo principal por el
+que se otorga el monopolio [del copyright] descansa en los beneficios
+generales obtenidos por el público gracias al trabajo de los autores».</p>
+<p>
+ No estamos obligados a estar de acuerdo con la Constitución o con la Corte
+Suprema (en un momento dado, los dos perdonaron el esclavismo). De modo que
+sus posiciones no rechazan la premisa de la supremacía del propietario. Pero
+espero que esa premisa se desvanezca con una toma de conciencia sobre el
+hecho de que es una posición adoptada por la derecha radical, no
+tradicionalmente reconocida.</p>
+
+<h3 id="conclusion">Conclusión</h3>
+<p>
+ Nos gusta pensar que nuestra sociedad promueve la solidaridad con el
+prójimo, pero cada vez que recompensamos a alguien por su obstruccionismo o
+admiramos a otro por haberse enriquecido por esa vía, transmitimos el
+opuesto.</p>
+<p>
+ Especular con el software es una expresión de nuestra predisposición general
+a la indiferencia con respecto al bienestar de la sociedad y a favor del
+bienestar personal. Podemos observar esta indiferencia desde Ronald Reagan a
+Dick Cheney, desde Exxon a Enron, desde bancos inadecuados a escuelas
+inadecuadas. Podemos medirla por el número de personas sin hogar y aquellas
+encarceladas. El espíritu antisocial se retroalimenta, porque cuanto más
+comprobamos que la gente no nos ayudará, más inútil nos parece ayudarlos a
+ellos. Y así la sociedad degenera en una jungla.</p>
+<p>
+ Si no queremos vivir en una jungla, debemos cambiar nuestras formas de
+comportamiento. Debemos empezar transmitiendo el mensaje de que un buen
+ciudadano es aquel que colabora cuando es apropiado, no aquel que logra
+éxito expropiando a los demás. Espero que el movimiento por el software
+libre pueda contribuir a esto: al menos en un área, reemplazaremos la jungla
+por un sistema más eficiente que anime y se base en la cooperación
+voluntaria.</p>
+
+
+<h3 id="footnotes">Notas</h3>
+
+<ol>
+<li id="f1">La palabra «<em>free</em>» en «<em>free software</em>» se refiere a la
+libertad, no al precio; el precio pagado por una copia del programa puede
+ser cero, o muy bajo, o en muy raras ocasiones bastante
+elevado. [<strong>n. de t.</strong>: en inglés la palabra «<em>free</em>»
+significa tanto «libre» como «gratuito», per en español existen dos términos
+distintos para cada concepto; por lo tanto «software libre» es la forma
+correcta en español.]</li>
+
+<li id="f2">Los problemas de la contaminación y la congestión del tráfico no modifican
+esta conclusión. Si queremos desanimar el uso de automóviles en general,
+haciendo que resulte más costoso, las cabinas de peaje son una mala idea ya
+que contribuyen a la contaminación y la congestión. Un impuesto sobre el
+combustible es mucho mejor. Del mismo modo, el deseo de mejorar la seguridad
+mediante la limitación de la velocidad máxima no es relevante; una carretera
+de acceso libre mejora la velocidad media evitando las paradas y sus
+respectivos retrasos, para cualquier límite de velocidad dada.</li>
+
+<li id="f3">Se podría considerar algún un programa en particular como algo perjudicial
+que no debería estar siempre disponible, como sucedió con la base de datos
+de información personal Lotus Marketplace, que se retiró del mercado debido
+a la desaprobación pública. La mayor parte de lo que digo no es aplicable a
+este caso, pero no tiene mucho sentido estar a favor de que el programa
+tenga un propietario argumentando que el proprietario se encargará de que el
+programa sea más difícil de obtener. El propietario no lo hará
+<em>completamente</em> inaccesible, como sería de desear en el caso de un
+programa cuyo uso se considere destructivo.</li>
+</ol>
+
+<hr />
+<blockquote id="fsfs"><p class="big">Este ensayo está publicado en el libro <a
+href="http://shop.fsf.org/product/free-software-free-society/"><cite>Software
+libre para una sociedad libre: Selección de ensayos de Richard
+M. Stallman</cite></a>.</p></blockquote>
+
+<div class="translators-notes">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
+ </div>
+</div>
+
+<!-- for id="content", starts in the include above -->
+<!--#include virtual="/server/footer.es.html" -->
+<div id="footer">
+<div class="unprintable">
+
+<p>Envíe sus consultas acerca de la FSF y GNU a <a
+href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Existen también <a
+href="/contact/">otros medios para contactar</a> con la FSF. <br /> Para
+avisar de enlaces rotos y proponer otras correcciones o sugerencias,
+diríjase a <a
+href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>
+
+<p>
+<!-- TRANSLATORS: Ignore the original text in this paragraph,
+ replace it with the translation of these two:
+
+ We work hard and do our best to provide accurate, good quality
+ translations. However, we are not exempt from imperfection.
+ Please send your comments and general suggestions in this regard
+ to <a href="mailto:web-translators@gnu.org">
+
+ &lt;web-translators@gnu.org&gt;</a>.</p>
+
+ <p>For information on coordinating and submitting translations of
+ our web pages, see <a
+ href="/server/standards/README.translations.html">Translations
+ README</a>. -->
+El equipo de traductores al español se esfuerza por ofrecer traducciones
+fieles al original y de buena calidad, pero no estamos libres de cometer
+errores.<br /> Envíe sus comentarios y sugerencias sobre las traducciones a
+<a
+href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.
+</p><p>Consulte la <a href="/server/standards/README.translations.html">Guía
+para las traducciones</a> para obtener información sobre la coordinación y
+el envío de traducciones de las páginas de este sitio web.</p>
+</div>
+
+<p>Copyright &copy; 1991, 1992, 1998, 2000, 2001, 2006, 2007, 2010, 2017, 2018,
+2020 Free Software Foundation, Inc.</p>
+
+<p>Esta página está bajo licencia <a rel="license"
+href="http://creativecommons.org/licenses/by-nd/4.0/deed.es_ES">Creative
+Commons Reconocimiento-SinObraDerivada 4.0 Internacional</a>.</p>
+
+<!--#include virtual="/server/bottom-notes.es.html" -->
+<div class="translators-credits">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
+<strong>Traducción: Pablo Ruiz Múzquiz, 2000</strong>. Revisiones: Holman
+Romero, Iván Martinez Cortés, Hugo Gayosso, Alejandro Luis Bonavita, Kostas
+Kamaki.</div>
+
+<p class="unprintable"><!-- timestamp start -->
+Última actualización:
+
+$Date: 2020/07/07 09:59:54 $
+
+<!-- timestamp end -->
+</p>
+</div>
+</div>
+<!-- for class="inner", starts in the banner include -->
+</body>
+</html>