taler-merchant-demos

shouldbefree.html (54024B)

---

 <!--#set var="ENGLISH_PAGE" value="/philosophy/shouldbefree.en.html" -->
 
 <!--#include virtual="/server/header.es.html" -->
 <!-- Parent-Version: 1.96 -->
 <!-- This page is derived from /server/standards/boilerplate.html -->
 <!--#set var="TAGS" value="essays aboutfs principles" -->
 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
 
 <!-- This file is automatically generated by GNUnited Nations! -->
 <title>Por qué el software debe ser libre - Proyecto GNU - Free Software Foundation </title>
 <style type="text/css" media="print,screen"><!--
 #content h3 { margin-top: 1.6em; }
 -->
 
 </style>
 
 <!--#include virtual="/philosophy/po/shouldbefree.translist" -->
 <!--#include virtual="/server/banner.es.html" -->
 <!--#include virtual="/philosophy/ph-breadcrumb.es.html" -->
 <!--GNUN: OUT-OF-DATE NOTICE-->
 <!--#include virtual="/server/top-addendum.es.html" -->
 <div class="article reduced-width">
 <h2>Por qué el software debe ser libre</h2>
 
 <address class="byline">por <a href="https://www.stallman.org/">Richard Stallman</a></address>
 
 <p  id="introduction">
 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
 <code>+</code> para la suma y <code>-</code> 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>
 <div class="column-limit"></div>
 
 <h3 id="footnotes" class="footnote">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 class="no-display" />
 <div class="edu-note c"><p id="fsfs">Este ensayo está publicado en el libro <a
 href="https://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></div>
 </div>
 
 <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" role="contentinfo">
 <div class="unprintable">
 
 <p>Envíe sus consultas acerca de la FSF y GNU a <a
 href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Existen también <a
 href="/contact/">otros medios para contactar</a> con la FSF. <br /> Para
 avisar de enlaces rotos y proponer otras correcciones o sugerencias,
 diríjase a <a
 href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>
 
 <p>
 <!-- TRANSLATORS: Ignore the original text in this paragraph,
         replace it with the translation of these two:
 
         We work hard and do our best to provide accurate, good quality
         translations.  However, we are not exempt from imperfection.
         Please send your comments and general suggestions in this regard
         to <a href="mailto:web-translators@gnu.org">
 
         &lt;web-translators@gnu.org&gt;</a>.</p>
 
         <p>For information on coordinating and contributing translations of
         our web pages, see <a
         href="/server/standards/README.translations.html">Translations
         README</a>. -->
 El equipo de traductores al español se esfuerza por ofrecer traducciones
 fieles al original y de buena calidad, pero no estamos libres de cometer
 errores.<br /> Envíe sus comentarios y sugerencias sobre las traducciones a
 <a
 href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.
 </p><p>Consulte la <a href="/server/standards/README.translations.html">Guía
 para las traducciones</a> para obtener información sobre la coordinación y
 el envío de traducciones de las páginas de este sitio web.</p>
 </div>
 
 <!-- Regarding copyright, in general, standalone pages (as opposed to
      files generated as part of manuals) on the GNU web server should
      be under CC BY-ND 4.0.  Please do NOT change or remove this
      without talking with the webmasters or licensing team first.
      Please make sure the copyright date is consistent with the
      document.  For web pages, it is ok to list just the latest year the
      document was modified, or published.
      
      If you wish to list earlier years, that is ok too.
      Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
      years, as long as each year in the range is in fact a copyrightable
      year, i.e., a year in which the document was published (including
      being publicly visible on the web or in a revision control system).
      
      There is more detail about copyright years in the GNU Maintainers
      Information document, www.gnu.org/prep/maintain. -->
 <p>Copyright &copy; 1991, 1992, 1998, 2006, 2010, 2021 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: 2021/09/21 11:32:55 $
 
 <!-- timestamp end -->
 </p>
 </div>
 </div>
 <!-- for class="inner", starts in the banner include -->
 </body>
 </html>