diff options
Diffstat (limited to 'talermerchantdemos/blog/articles/es/shouldbefree.html')
-rw-r--r-- | talermerchantdemos/blog/articles/es/shouldbefree.html | 947 |
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 “de algo tengo que vivir”), 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!”. 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"><gnu@gnu.org></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"><webmasters@gnu.org></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"> + + <web-translators@gnu.org></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"><web-translators@gnu.org></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 © 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> |