Previous Up Next
Capítulo 18 Por qué el software debe ser libre1

18.1 Introducción

La existencia del software plantea inevitablemente la pregunta de 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 que desearía tener otra copia del mismo. Es posible copiar el programa; ¿quién debería decidir si esto se lleva a cabo o no? ¿Las personas involucradas? ¿O un tercero, llamado «propietario»?

Por lo general, los desarrolladores de software consideran estos problemas basándose en que el criterio para responder a esta pregunta es el de maximizar los beneficios del desarrollador. El poder político del sector empresarial ha llevado al gobierno a adoptar igualmente este criterio y esta respuesta que proponen los desarrolladores: que el programa tiene un dueño, generalmente una compañía asociada a su desarrollo.

Me gustaría considerar el mismo problema usando un criterio diferente: la prosperidad y la libertad del público en general.

La respuesta no puede provenir de la ley vigente —la ley debería ajustarse a la ética y no al revés. Tampoco el día a día resuelve el problema, a pesar de que puede sugerir algunas soluciones posibles. La única forma de juzgar es observar quién se ve beneficiado y quién se ve perjudicado mediante el reconocimiento de los propietarios de software, por qué y en qué medida. En otras palabras, deberíamos realizar un análisis del tipo coste-beneficio en nombre de la sociedad como un todo, teniendo en cuenta la libertad individual así como la producción de bienes materiales.

En este ensayo, describiré los efectos provocados por el reconocimiento de los propietarios y mostrará que los resultados son perjudiciales. Mi conclusión es que los programadores debemos dedicarnos a animar a otros a compartir, redistribuir, estudiar y mejorar el software que escribimos, en otras palabras, animar a escribir software libre.2

18.2 Cómo los propietarios justifican su poder

Aquellos que se benefician del sistema actual, en el que los programas son concebidos como propiedad privada, esgrimen dos argumentos en favor de su derecho de ser propietarios de programas: el argumento emocional y el argumento económico.

El argumento emocional es del tipo: «Pongo mi sudor, mi corazón, mi alma en este programa. ¡Proviene de mí, es mío!»

Este argumento no requiere una refutación seria. 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 ha prevalecido durante cientos de años.

El argumento económico es del tipo: «Quiero ser rico —normalmente expresado de manera poco precisa como «tengo que vivir de algo»— y si no me dejas enriquecerme 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.

Explicaré más tarde por qué esta amenaza es algo completamente absurdo. Antes me gustaría presentar un presupuesto implícito que está mucho más presente en otra formulación del mismo argumento.

Esta formulación empieza comparando la utilidad social del software propietario con la utilidad que se derivaría de no tener software y entonces llega a la conclusión de que el software propietario es, en general, beneficioso y que debería ser promovido. La falacia reside aquí en comparar solamente dos posibilidades —software propietario versus ausencia de software— y suponer que no existen otras posibilidades.

En un sistema en el que impera la propiedad intelectual, el desarrollo del software se encuentra generalmente vinculado a la existencia de un dueño que controla el uso de ese software. Mientras exista este vínculo, nos enfrentamos continuamente a la elección entre software propietario o nada. Sin embargo, esta vínculo no es inherente ni tampoco inevitable; es más bien consecuencia de una decisión política sociolegal específica que aquí estamos cuestionando: la decisión de que el software tenga propietarios. Formular la elección entre software propietario y ausencia de software implica empobrecer la cuestión.

18.3 El argumento en contra de la propiedad del software

La pregunta que se nos plantea es: «¿debería el desarrollo del software estar vinculado a la existencia de propietarios que restrinjan su uso?»

Para resolver este problema, tenemos que evaluar el efecto en la sociedad de cada una las dos opciones independientemente: el efecto de desarrollar software —sin tener en cuenta la manera en que se redistribuye— y el efecto de restringir su uso —suponiendo que el software ha sido desarrollado. Si una de estas actividades es beneficiosa y la otra es perjudicial, deberíamos deshacernos de esta doble actividad y utilizar sólo la beneficiosa.

En otras palabras, si restringir la distribución de un programa ya desarrollado es perjudicial para la sociedad en su conjunto, entonces un desarrollador de software con una orientación ética debería rechazar esta opción.

Para determinar el efecto de restringir el derecho a compartir, necesitamos comparar los beneficios para la sociedad de un programa restringido —propietario— con los que ofrece ese mismo programa accesible a todo el mundo. Esto significa comparar dos mundos posibles.

Este análisis también tiene en cuenta el contra-argumento, a veces defendido, de que «los beneficios que se proporcionan al vecino al darle una copia de un programa se cancelan por el perjuicio provocado al propietario». Este contra-argumento presupone que el perjuicio y el beneficio son iguales en magnitud. El análisis implica la comparación de ambas magnitudes y muestra que el beneficio es mucho mayor que el perjuicio.

Para clarificar todo esto, vamos a aplicarlo a otro ámbito: la construcción de carreteras.

Pudiera ser que la financiación para construir todas las carreteras proviniese de los peajes. En 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 que pagasen por ella. Sin embargo, un punto de peaje es un obstáculo artificial para una circulación fluida —artificial, porque no es una consecuencia derivada del funcionamiento de los coches o de las carreteras.

Si comparamos la utilidad de las carreteras libres y de la carreteras con peaje, encontramos que —siendo iguales en todo—, las carreteras sin puntos de peaje son más baratas de construir, más baratas de administrar y más eficientes.3 En un país pobre, el peaje podría provocar que algunas carreteras fuesen inaccesibles a muchos ciudadanos. De manera que las carreteras sin peajes ofrecen mayores beneficios a la sociedad y un coste menor; por lo tanto son preferibles para la sociedad. De este modo, la sociedad debería elegir financiar las carreteras de otra forma, y no mediante peajes. El uso de las carreteras, una vez construidas, debería ser gratuito.

Cuando los defensores de los peajes, los presentan como meros recaudadores de fondos, distorsionan la elección que existe de verdad. Los peajes incrementan los fondos públicos, pero hacen algo más: degradan, de hecho, la carretera. La carretera de 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 carreteras libres por carreteras de peaje.

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 compramos una carretera gratuita.

No quiero decir que una carretera de peaje sea peor que la ausencia de carreteras. Eso sería verdad si el peaje fuese tan alto que casi nadie pudiese usarla —pero esta es una política improbable para un recaudador de impuestos. Sin embargo, en tanto que los peajes suponen pérdidas de tiempo y molestias considerables, es mejor conseguir el dinero de una manera menos obstructora.

Para aplicar este mismo argumento al desarrollo del software, mostrará ahora que introducir «peajes» en el software le cuesta caro a la sociedad: hace que se encarezca la construcción de los programas, encarece la distribución y los hace menos satisfactorios y eficientes con relación a su uso. De lo que se deduce que la construcción de programas debería promoverse de alguna otra forma. Más tarde, continuará explicando otros métodos de promoción y —hasta donde sea de verdad necesario— financiación del desarrollo de software.

18.4 El perjuicio ocasionado por obstaculizar el software

Consideremos por un momento que un programa ha sido desarrollado y que cualesquiera pagos necesarios para su desarrollo han sido realizados; ahora la sociedad debe decidir entre convertirlo en propietario o permitir que se use y comparta libremente. Supóngase que la existencia del programa y su disponibilidad es algo deseable.4

Las restricciones sobre la distribución y modificación del programa no pueden facilitar su uso. Sólo pueden interferir en él. Así que el efecto solamente puede ser negativo. ¿Pero cuánto? ¿Y de qué tipo?

Existen tres niveles diferentes de daño material que provienen de esta interferencia: Cada nivel de perjuicio material lleva asociado un perjuicio psico-social. Me refiero al efecto que tiene las decisiones de la gente sobre sus sentimientos, actitudes y predisposiciones posteriores. Estos cambios en la manera de pensar de la gente tendrán un efecto posterior en sus relaciones con sus conciudadanos y pueden acarrear consecuencias efectivas.

Los tres niveles de perjuicio material desaprovechan parte del valor que el programa podría proporcionar, pero no lo pueden reducir a nada. Si desaprovechan 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.

Sin embargo, teniendo en cuenta el perjuicio psico-social asociado, no existe límite al perjuicio que puede llegar a ocasionar el desarrollo de software propietario.

18.5 Obstaculizar el uso de programas

El primer nivel de perjuicio impide el simple uso del programa. Una copia del programa tiene un coste marginal nulo —y se puede pagar este coste realizando esta copia personalmente—, de manera que en un mercado libre tendría un precio casi nulo. El pago por una licencia es un desincentivo significativo a la hora de usar el programa. Si un programa de gran utilidad es propietario, mayor será la cantidad de gente que no lo use.

Es fácil mostrar que la contribución total que un programa proporciona a la sociedad se reduce al asignársele un propietario. Cada 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, esto es en realidad una transferencia nula de riqueza entre las dos partes. Pero cada vez que alguien elige no usar el programa, se provoca un perjuicio a esa persona sin que nadie salga beneficiada. La suma entre números negativos y ceros es siempre negativa.

Pero esto no reduce la cantidad de trabajo que lleva desarrollar el programa. Como resultado, la eficiencia del proceso entero, medida en satisfacción del usuario final por hora de trabajo, se reduce.

Esto muestra la diferencia crucial entre las copias de programas y los coches, 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; cualquiera puede producir tantas copias como desee, con muy poco esfuerzo. Esto no es cierto para 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.

Con objetos materiales, un desincentivo a la hora de usarlos tiene cierto sentido, porque un menor número de objetos comprados implica menos materia prima y menos trabajo para producirlos. Es cierto que generalmente existe un coste inicial, un coste de desarrollo, que se extiende sobre el proceso de producción. Pero mientras el coste marginal de producción puede ser significativo, añadir una participación en el coste de desarrollo no produce una diferencia cualitativa. Y no requiere restricciones sobre la libertad de los usuarios normales.

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 del software provoca un gran desincentivo.

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 las copias de software. Este sistema incluye enviar discos o cintas magnéticas en embalajes superfluos, mandar grandes cantidades de ellos a lo largo y ancho del mundo y almacenarlos para venderlos. Este costo se presenta como derivado de hacer negocios; en realidad, es una parte del gasto inútil causado por el hecho de tener dueños.

18.6 La cohesión social dañada

Suponga que tanto usted como su vecino consideraran útil la ejecución de un cierto programa. En un pacto ético con su vecino, seguramente entenderíais que una solución apropiada de la situación posibilitaría que los dos usasen el programa. Una propuesta que permitiese usar el programa solo a uno, restringiendo al otro, es discriminatoria; a ninguno de los dos, usted o su vecino, les debería de parecer aceptable.

Firmar una licencia típica de software implica traicionar a tu vecino: «Prometo privar a mi vecino de este programa para que yo pueda tener una sola copia para mí.» 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 sale perjudicado. Se trata de un daño psico-social asociado con el daño material provocado por la desincentivación de usar el programa.

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. Pero a menudo se sienten culpables haciéndolo. 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 —dado que lo son— es algo malo o de lo que sentirse avergonzados. Se trata, también, de un tipo de daño psico-social, pero se puede escapar de ello decidiendo que las licencias y las leyes no tienen fuerza moral alguna.

Los programadores también sufren ese daño psico-social al saber que a muchos usuarios se les impedirá aprovechar su trabajo. Esto conduce a una actitud de cinismo o de autoengaño. Un programador puede describir de manera entusiasta un trabajo que considera técnicamente interesante, y cuando se le pregunta: «¿Se me dejará usar el programa?», se vuelve cabizbajo y admite que la respuesta es no. Para evitar desalentarse, o bien la mayor parte del tiempo ignora este hecho, o adopta una cínica postura diseñada para menoscabar su importancia.

Desde la era Reagan,5 la principal fuente escasez de los Estados Unidos no es la de las innovaciones técnicas sino más bien la del deseo de trabajar juntos por el bien público. No tiene sentido alentar lo primero a expensas de esto último.

18.7 Obstruir la adaptación personalizada de programas

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 frente a formas mas antiguas de tecnología. Sin embargo, la mayoría del software comercial disponible no lo es en términos de «modificabilidad», ni siquiera después de comprarlo. Puedes decidir tomarlo o dejarlo, como una caja negra —tan solo eso.

El programa que ejecutas 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 hacer que el programa haga algo diferente.

Los programadores trabajan normalmente con el «código fuente» del programa, que se encuentra escrito en un lenguaje de programación como Fortran o C. Recurren a nombres que designan los datos usados y las partes del programa y representan operaciones con símbolos tales como «+» para la suma y «-» para la resta. 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:6 

  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);
  }
Aquí está ese mismo programa en formato ejecutable7 en el ordenador que suelo utilizar: 

  1314258944      -232267772      -231844864      1634862
  1411907592      -231844736      2159150         1420296208
  -234880989      -234879837      -234879966      -232295424
  1644167167      -3214848        1090581031      1962942495
  572518958       -803143692      1314803317
El código fuente es útil —potencialmente al menos— 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 propietario es guardado en secreto por el propietario, por miedo a que cualquier otro pueda aprender algo de él. Los usuarios reciben solamente ficheros de números incomprensibles, que el ordenador se encargará de ejecutar. Esto quiere decir que solo el propietario del programa puede modificar el programa.

Una amiga me habló 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 —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 Interior Bruto pero que realmente fue un desperdicio.

El laboratorio de Inteligencia Artificial del MIT (AI lab) recibió de regalo una impresora gráfica de Xerox hacía 1977. Corría con software libre al que añadimos bastantes mejoras útiles. Por ejemplo, el software notificaba inmediatamente al usuario cuando el trabajo de impresión se había realizado. Cuando la impresora tenía un problema, como una obstrucción de papel o falta de papel, el software lo notificaba inmediatamente a todos los usuarios que tuviesen trabajos pendientes. Estas mejoras facilitaban el trabajo.

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 propietario que corría en un ordenador independiente dedicado en 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 impreso —y generalmente el retraso era considerable. No había forma de saber cuando el trabajo se había impreso; lo único que podías 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.

Los programadores de sistema del laboratorio del IA Lab estaban capacitados para arreglar aquellos problemas, probablemente tan capacitados como los autores originales del programa. Xerox no mostró interés en arreglar aquellos fallos y prefirió advertirnos de los problemas, de manera que nos vimos forzados a aceptarlos. Nunca se arreglaron.

La mayoría de los programadores buenos 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é, sólo puede arrojar la toalla.

Arrojar la toalla 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 tu vida. La gente que padece de esta manera no se encuentran a gusto y no realiza un buen trabajo.

Imagínese cómo sería si las recetas de cocina se guardasen de la misma manera que el software. Uno se podría preguntar: «¿Cómo cambio esta receta de manera que no tenga sal?». De tal forma 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!»

«¡Pero mi doctor me ha prohibido tomar sal! ¿Qué puedo hacer? ¿Va a quitar usted la sal por mí?»

«Me encantaría hacer eso; mis honorarios son de sólo 50.000 dólares». (Las tasas suelen ser grandes debido a la posición de monopolio sobre los modificaciones.) «De todas formas, ahora mismo no tengo tiempo. Estoy ocupado con una comisión para diseñar una nueva receta de galleta marítima para el departamento de Marina. Estaré contigo más o menos en dos años».

18.8 Obstaculizar el desarrollo del software

El tercer nivel de daño material afecta al desarrollo del software. El desarrollo del software normalmente era el resultado de un proceso evolutivo, en el que una persona cogía un programa existente y reescribía algunas partes añadir una función nueva, y entonces otra persona reescribía algunas partes más para añadir otra más; en algunos casos, este proceso transcurría durante un periodo de veinte años. Mientras tanto, algunas partes de ese programa eran «canibalizadas» para constituir el comienzo de otros programas.

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.

Los propietarios también dificultan el aprendizaje. He conocido estudiantes brillantes en ciencia informática que nunca han visto el código fuente de un programa extenso. Puede que fueran buenos escribiendo pequeños programas, pero no pueden empezar a aprender las diferentes habilidades necesarias para escribir programas extensos si no pueden ver cómo lo han hecho otros.

En cualquier campo intelectual, uno puede conseguir metas más elevadas apoyándose en otros. Pero esto ya no se permite por lo general en el campo del software —sólo puedes apoyarte en otros en tu propia empresa.

El daño psicosocial asociado afecta al espíritu de cooperación científica, que normalmente era tan intensa que los científicos seguían cooperando incluso cuando sus países entraban en guerra. En este sentido, 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 EE.UU. y dejaron una nota pidiendo que lo guardaran bien.

El conflicto por la obtención de beneficio 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 para permitir a otros repetir el experimento. Publican solamente aquello que permita a los lectores maravillarse por lo mucho que saben hacer. Esto es así, desde luego, en la ciencia informática, en donde el código fuente de los programas es generalmente secreto.

18.9 No importa cómo se restringe el acto de compartir

He discutido sobre los efectos de impedir a la gente que copie, modifique o desarrolle un 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, o copyright, o licencias, o encriptación, o tarjetas ROM, o números de serie en el hardware, si tiene éxito impidiendo el uso, el perjuicio está hecho.

Los usuarios consideran algunos de estos métodos más repugnantes que otros. Creo que los métodos más odiados son aquellos que cumplen su objetivo.

18.10 El software debería ser libre

He argumentado cómo la propiedad de un programa —el poder de restringir las modificaciones o las copias— es obstructiva. Sus efectos negativos son extensos e importantes. Se sigue pues que en la sociedad no deberían existir propietarios de programas.

Otra manera de comprender esto es reconocer que lo que la sociedad necesita es software libre y el software propietario es un pobre sustituto. Promover el sustituto no es una manera lógica de conseguir lo que necesitamos.

Vaclav Havel nos aconsejó: «Trabajad por algo porque es bueno, no simplemente porque tiene probabilidades de éxito». Un negocio que produce software propietario tiene probabilidades de éxito en sus propios y estrechos términos, pero no es lo que beneficia a la sociedad.

18.11 Por qué la gente desarrollará software

Si eliminamos el copyright 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 esto es así, o si queremos aumentarla de todas formas, existen otras maneras de promover el desarrollo, exactamente igual que hay formas alternativas a los peajes para conseguir obtener dinero para las carreteras. Antes de que empiece a hablar sobre cómo hacer esto, primero quiero preguntar que grado de promoción artificial es verdaderamente necesario.

18.12 Programar es divertido

Existen algunos tipos de trabajo en los que pocos entrarán si no es por dinero; la construcción de carreteras, por ejemplo. Hay otros campos del estudio y del arte en los que existe escasa probabilidad de enriquecerse, en los que la gente entra por fascinación o por que perciben que son valiosos socialmente. Algunos ejemplos son la lógica matemática, la música clásica y la arqueología; y la organización política entre los trabajadores. La gente compite, de forma triste más que incisiva, por las pocas posiciones remuneradas existentes, ninguna de las cuales financiada de forma generosa. Quizás tengan que pagar por la posibilidad de trabajar en ese campo, si pueden permitírselo.

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 grandes sumas de dinero a cambio. 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 para lograrlo.

Esta transformación acaeció en el campo de la programación informática durante la década pasada. Hace quince años8 uno podía encontrarse con artículos sobre la «adicción a los ordenadores»: los usuarios estaban «conectados» y tenían adicciones que les costaban cien dólares por semana. Parecía aceptable que la gente amase tanto la programación como para acabar con sus matrimonios. Hoy en día, se entiende que nadie programe sin recibir una excelente remuneración a cambio. La gente ha olvidado lo que sabía hace quince años.

Llegado el momento en que quienes trabajan en un campo determinado exigen a cambio altas sumas de dinero, el campo en cuestión ya no necesita regirse por esa pasión voluntariosa. La dinámica del cambio puede efectuarse al revés 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, volverán una vez más a trabajar en ese campo por el placer de hacerlo.

La respuesta a «¿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. Es más fácil conseguir los fondos necesarios para ganarse la vida simplemente.

18.13 Financiar el software libre

Las instituciones que pagan a los programadores no tienen que ser necesariamente empresas de software. Otras muchas instituciones ya existentes se pueden encargar de ello.

Los fabricantes de hardware saben que es esencial colaborar en el desarrollo de software incluso aun cuando no puedan controlar el uso de ese software. En 1970, la mayoría del software era libre porque no se había considerado la posibilidad de restringirlo. Hoy en día, su creciente voluntad de unirse en consorcios refleja la consideración de que la propiedad del software no es lo que realmente les importa.

Las universidades dirigen bastantes proyectos de programación. Hoy en día, a menudo venden los resultados, cuando en la década de 1970 no lo hacían. ¿Hay alguna duda de que la universidades desarrollarían software libre si estuviese prohibida la venta de software? Estos proyectos podrían estar respaldados por los mismos contratos y subvenciones gubernamentales que ahora respaldan al desarrollo de software propietario.

Lo normal ahora es que los investigadores universitarios obtengan subvenciones para desarrollar un sistema, desarrollarlo casi hasta el punto de completarlo, denominando a eso un producto «acabado» y luego que las empresas realmente lo terminen y lo conviertan en algo útil. A veces declaran «libre» la versión sin acabar; si son profundamente corruptos entonces consiguen una licencia de exclusividad para la universidad. Esto no es un secreto; se admite abiertamente por todos los involucrados. Sin embargo, si los investigadores no se vieran tentados a hacer estas cosas, seguirían investigando de todas formas.

Los programadores que escriban software libre pueden vivir a base de vender servicios relacionados con el software. He sido contratado para trasladar el Compilador GNU de C a un hardware nuevo y para construir interfaces de usuario para GNU Emacs. (Ofrezco estas mejoras al público una vez acabadas.) También doy clases por las que me pagan.

No soy el único que trabaja de esta manera. Existe una corporación que está creciendo de forma exitosa y se dedica 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 inaccesible a través del software propietario, excepto a los más ricos.

Nuevas instituciones9 como la Free Software Foundation pueden también subvencionar a los programadores. La mayoría de los fondos de la Fundación provienen de los usuarios que compran disquetes o cintas por correo. El software en disquetes es libre, lo que quiere decir que cualquier usuario tiene la libertad de copiarlo y cambiarlo, pero muchos a pesar de ello pagan por conseguir copias. (Recuérdese que «software libre» se refiere a la libertad, no al precio.) Algunos usuarios encargan cintas magnéticas de las que ya tienen una copia como una forma de contribución que piensan que merecemos. La Fundación también recibe importantes donaciones de fabricantes de ordenadores.

La Free Software Foundation es una sociedad sin ánimo de lucro y sus ingresos se invierten en contratar a tantos programadores como se pueda. Si se hubiese planteado como una empresa, distribuir software libre al público por el mismo precio, proporcionaría ahora una buen estándar de vida a su fundador.

Precisamente porque la Fundación es una sociedad sin ánimo de lucro, los programadores trabajan por la mitad de lo que cobrarían en cualquier otro sitio. Hacen esto porque estamos libres de burocracia y porque encuentran satisfacción sabiendo que su trabajo no encontrará obstáculos a su uso. Y lo que es más importante, lo hacen porque sienten que programar es divertido. Además, los voluntarios han escrito muchos programas útiles para nosotros. (Incluso, han empezado a colaborar escritores técnicos.)

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 nadie quiera programar.

18.14 ¿Qué deben los usuarios a los desarrolladores?

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.

Sin embargo, esto no debería de aplicarse a los desarrolladores de software propietario, ya que el obstruccionismo se merece un castigo más que una recompensa.

De manera que tenemos una paradoja: el desarrollador de software útil tiene el derecho a recibir el apoyo de los usuarios, pero cualquier intento que convierta esta obligación moral en una petición destruye la base de la obligación. Un desarrollador puede o bien merecer una recompensa o pedirla, pero no las dos cosas a la vez.

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. Puede que los usuarios aprendan así 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.

18.15 ¿Qué es la productividad del software?

Si el software fuese libre seguiría habiendo programadores, pero quizá menos. ¿Sería esto perjudicial para la sociedad?

No necesariamente. Hoy en día las naciones desarrolladas tienen menos granjeros que en 1900, pero no creemos que esto sea malo para la sociedad porque esos agricultores distribuyen más comida a los consumidores que antes. Llamamos a esto mejora de la productividad. El software libre requeriría bastantes menos programadores para satisfacer la demanda, debido al aumento en la productividad del software en todos los niveles: 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 productividad. Y además estas personas aceptan generalmente la creencia universal de que la industria del software necesita un incremento de su productividad. ¿Cómo es esto posible?10

«La productividad del software» puede significar dos cosas diferentes: la productividad general de todo el desarrollo del 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 a la cooperación, que la reducen. Pero los investigadores que estudian el campo de la «productividad del software» se centran sólo en el segundo y más limitado sentido del término, en donde la mejora precisa de complejos avances tecnológicos.

18.16 ¿Es inevitable la competencia?

¿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 el combate.

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 gurús de la programación —competencia que consistía en quién era capaz de producir el ordenador que realizase las cosas más fascinantes 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 beneficiar a todos, mientras el espíritu de deportividad se mantenga.

Una competencia constructiva es suficiente para motivar a la gente a realizar grandes esfuerzos. Hay 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.

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, sea el mejor o no». El software propietario es perjudicial, no porque sea una forma de competición, sino porque es una forma de combate entre los ciudadanos de nuestra sociedad.

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; por el contrario, existe un pequeño margen de libertad en esta rama de los negocios carente de violencia física. No todas las áreas de negocio comparten esta misma característica. Preservar información que podría ayudar al avance de todos es una forma de combate.

La ideología empresarial no prepara a la gente para resistir la tentación de combatir a la competencia. Algunas formas de combate han sido prohibidas con leyes antimonopolio, leyes sobre honestidad en publicidad y otras más, pero lejos de generalizarse mediante una repulsa, por principio, hacia el combate en general, 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.

18.17 «¿Por qué no nos vamos a Rusia?»

En los Estados Unidos, 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 con el bien común se identifica en Estados Unidos con el comunismo. ¿Pero son semejantes estas ideas?

El comunismo, tal y como se practicó en la Unión Soviética, era un sistema de control central en donde toda la actividad era dirigida supuestamente por el bien común, pero en realidad en beneficio de los miembros del partido comunista. Y donde los equipos de copia estaban estrechamente vigilados para prevenir posibles copias ilegales.

El sistema de copyright sobre el software de Estados Unidos ejerce un control central sobre la distribución de un programa y protege los equipos de copia con sistemas automatizados de protección anticopia, de forma que pueda evitarse la copia ilegal.

Por el contrario, yo trabajo para construir un sistema donde la gente sea libre para decidir sus propias acciones; en particular, libre para ayudar a sus vecinos y libre para alterar y mejorar las herramientas con las que trabajan en su vida cotidiana. Un sistema basado en la cooperación voluntaria y en la descentralización.

Así, si fuésemos a juzgar posturas por su parecido al comunismo ruso, son los propietarios del software quienes son comunistas.

18.18 La cuestión de las premisas

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 dilucidar qué decisión es mejor.

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 dar al que contrata al autor la ventaja que se merece —independientemente de como puede afectar esto al público.

No tiene sentido tratar de demostrar o invalidar estas premisas. La prueba necesita premisas compartidas. Así que la mayoría de lo que digo está destinado sólo 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.

Pero, ¿por qué aceptaría un gran número de estadounidenses una premisa que eleva en importancia a algunas personas sobre el resto del mundo? 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.

Es importante ser consciente de que esta premisa no forma parte de nuestra tradición legal. Nunca lo fue.

Así, la Constitución dice que el propósito del copyright es «promover el progreso de la ciencia y de las artes útiles». El Tribunal Supremo ha discutido sobre esto, dictando en el caso «Fox Film contra Doyal» 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».

No estamos obligados a estar de acuerdo con la Constitución o con el Tribunal Supremo. (En un momento dado, los dos perdonaron el esclavismo.) De este modo, sus posiciones no rechazan la premisa de la supremacía del propietario. Pero espero que, la conciencia de que esta suposición es radicalmente conservadora, más que tradicional, debilite su poder.

18.19 Conclusión

Nos gusta pensar que nuestra sociedad promueve la buena vecindad, pero cada vez que recompensamos a alguien por su obstruccionismo o admiramos a otro por haberse enriquecido por esta vía, enviamos la señal opuesta.

La acumulación de software es una expresión de nuestra predisposición general a la indiferencia con respecto al bienestar de la sociedad y a favor del bien personal. Podemos observar esta indiferencia, desde Ronald Reagan a Jim Bakker,11 desde Ivan Boesky12 a Exxon,13 desde la falta de bancos a la de colegios. Podemos medirla por el número de personas sin hogar y la gente encarcelada. El espíritu antisocial se nutre de sí mismo, porque cada vez que comprobamos que la gente no nos ayudará, más fútil nos parece ayudarlos a ellos. Y así la sociedad degenera en una jungla.

Si no queremos vivir en una jungla, debemos cambiar nuestras formas de comportarnos. Debemos empezar enviando el mensaje de que un buen ciudadano es aquel que colabora cuando es apropiado, no aquel que logra éxito cuando roba 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.
1
Escrito originalmente en 1992
2
El adjetivo libre en «software libre» hace referencia a la libertad, no al precio; el precio pagado por una copia de un programa libre puede ser cero, bajo o —en muy pocas ocasiones— bastante alto.
3
Los problemas asociados a la contaminación y a la congestión del tráfico no modifican esta conclusión. Si queremos encarecer la conducción, para desanimar la conducción en general, no deberíamos recurrir a las peajes que contribuyen a aumentar la contaminación y la congestión. Un impuesto sobre la gasolina es mucho mejor. Del mismo modo, no es relevante el deseo de aumentar la seguridad en una carretera limitando el máximo de velocidad. Una carretera de libre acceso aumenta la media de velocidad evitando las paradas y los atascos, sea cual sea el límite de velocidad.
4
Podríamos considerar perjudicial un programa determinado y por lo tanto desear que no es disponible en absoluto, como ocurre con la base de datos personales de Lotus Marketplace, que se retiró del mercado gracias a las protestas del público. Buena parte de lo que vengo diciendo no es aplicable a este caso, pero no tiene sentido abogar por la existencia de propietarios por el simple hecho de que el propietario limite la disponibilidad del programa. El propietario no limitará completamente la disponibilidad de un programa, tal y como nos gustaría, en el caso de un programa cuyo uso se considere destructivo.
5
Ronald Reagan, presidente número 40 de los Estados Unidos, es famoso por haber realizado recortes en numerosos programas sociales. También creó un política económica, llamada a menudo trickle down economics, considerada por muchos un fracaso.
6
Comprender cómo funciona este código fuente no es lo importante; lo que es realmente importante es observar que el código fuente esté escrito a un nivel de abstracción que sea claramente comprensible.
7
Obsérvese la no comprensibilidad del formato ejecutable; dar sentido al formato ejecutable es claramente mucho más complejo que el código fuente de más arriba.
8
Quince años antes de escribir este artículo transcurría el año 1977.
9
Recordemos que este artículo fue originalmente escrito en 1992
10
De acuerdo con Eric Raymond el 95 por ciento de los empleos en la industria del software implica la producción de software de aplicaciones personalizadas, en absoluto destinado a la publicación. Se sigue que incluso si asumimos el peor presupuesto teórico, que no habrá empleo en el desarrollo del software libre —y ahora sabemos ya que algo hay—, el cambio al software libre sólo puede tener un pequeño efecto en el número total de empleos. Existe un gran nicho para la gente que tenga empleo escribiendo software de aplicaciones personalizadas y desarrolle software libre en su tiempo libre. No existe manera de saber si la plena conversión al software libre incrementaría o haría decrecer el número de empleos en el campo del software.
11
Jim Bakker recaudó millones de dólares de la televisión para sus grupos religiosos Heritige USA, PTL y The Inspirational Network en la década de 1980. Fue encarcelado por fraude en la financiación de PTL y sentenciado a 45 años de cárcel.
12
Ivan Boesky fue enviado a prisión por tráfico en la década de 1980 y multado con 100 millones de dólares. Es famoso por haber dicho en una ocasión: «La avaricia es buena. Quiero que sepáis que pienso que la avaricia es saludable. Puedes ser avaro y todavía sentirte bien contigo mismo».
13
En 1980 el Exxon Valdez causó el mayor derrame de petróleo en el mundo sobre la costa de Alaska, provocando un daño inconmensurable. La limpieza y las indemnizaciones les han costado más de 100.000 millones de dólares hasta la fecha.
Previous Up Next