Software Libre: la revolución constructiva

Do livro: Argentina Copyleft. La crisis del modelo de derecho de autor y las prácticas para democratizar la cultura”.

Software Libre: la revolución constructiva

Federico Heinz*

Corre el año 2010, y el movimiento de software libre es mundialmente considerado un éxito. Si bien es cierto que aún hoy la inmensa mayoría de las personas usa software privativo, el software libre ha pasado de ser una ignota curiosidad confinada a ambientes técnicos y universitarios, a estar presente en la conciencia de prácticamente todos los usuarios de computadoras.

No hay ya empresas en el mercado de informática, ni siquiera entre sus más acérrimos enemigos, que no basen al menos parte de sus productos y servicios en software libre. Y aunque

hay muchos usuarios de software privativo, los disconformes con esa situación son cada vez más, llevando a las empresas a someter a sus usuarios a mecanismos de lock-in[1] cada vez más restrictivos e incómodos. Cuando Microsoft, detentora de la posición dominante de mercado más importante del mundo, debe presentar su informe anual al ente de regulación de la Bolsa de Estados

Unidos, menciona al software libre como la única amenaza seria a su predominancia en el mercado.

Mirando hacia atrás, este desarrollo parece inevitable: independientemente de sus características técnicas, las ventajas sociales, políticas y económicas del software libre son tan poderosas que es difícil imaginar hoy algo capaz de oponérsele. Pero eso es hoy. Hace veinticinco años, el movimiento de software libre no parecía tan prometedor.

Para empezar, contaba prácticamente con un único miembro: Richard Stallman, el primero en reconocer al software privativo como una amenaza social. Por otra parte, las condiciones del

contexto eran muy desfavorables: las computadoras estaban aún muy lejos de ser los dispositivos cotidianos que son hoy, de modo que era muy difícil lograr que el público comprendiera la dimen-

sión política y social del problema, y sus contrincantes eran grandes empresas de alta tecnología, admiradas por el público y, no pocas veces, vistas como benefactoras de la sociedad. Son tantas

las maneras en las que todo podría haber salido mal que, a la vista de los resultados, vale la pena estudiar las características salientes de un éxito tan improbable.

Por lo pronto, creo que hay poco riesgo en afirmar que un curso de oposición directa hubiera tenido pocas chances: aún hoy, cuando la idea de que usar software libre es bueno está avanzando, el concepto de que hay que evitar el software privativo sigue despertando escepticismo.

Aún con una población mucho más acostumbrada a las computadoras como elementos cotidianos, sigue siendo muy difícil convencer al público de que se prive de usar algunas herramientas “de moda” aún cuando éstas claramente atentan contra su intimidad, independencia personal o incluso a su propia capacidad de acceso a sus datos. Un movimiento de software libre que se limitara a señalar los daños del software privativo, o a exigir que se los prohibiera, seguramente no hubiera encontrado eco.

Quizás el aspecto más interesante de la estrategia adoptada por el software libre sea su carácter de oposición constructiva. Donde muchos movimientos encuentran que no pueden construir un mundo mejor sin antes tirar abajo las estructuras del actual, el software libre vio que, en su campo, la construcción podía preceder a la demolición.

El puntapié inicial del movimiento de software libre fue el lanzamiento del proyecto GNU en 1984, cuyo objetivo es la producción de un entorno de software completamente libre, con la idea de mostrar que el software se puede producir y compartir de otra manera. Por cierto que la dimensión de la tarea parecía, en el momento, un obstáculo insuperable. La única manera en que se puede describir el inicio de ese recorrido es recurriendo a aquella imagen de que “el viaje más largo comienza con un único paso”.

Un riesgo de la estrategia constructiva, por cierto, que puede ser aprovechada por los contrincantes. En el caso del software, esto se presentó muy tempranamente: si el software era libre, los vendedores de software privativo podían “empaquetarlo” y entregárselo a sus clientes en condiciones no libres. El resultado era que el proveedor se beneficiaba, mientras que el usuario se encontraba en posesión de una copia de un programa libre que no era libre para él.

La forma que Stallman encontró para enfrentar el problema es notable: descubrió que el mismo régimen de copyright que se usa para restringir la copia podía aplicarse, usando una técnica creativa, para restringir la capacidad de restringir a otros.

Esta idea, que hoy conocemos como copyleft, resultó tener varias ventajas importantes. La primera fue que sirvió para darle “peso legal” a la intención de los desarrolladores. A través de una herramienta habitual y conocida del copyright, la licencia, podían expresar su deseo de que el software fuera libre de una manera tal que pudiera (y, muchos años después, pudo) ser presentada ante la Justicia. Otra ventaja fue que, al fundar el copyleft firmemente en el copyright, sus contrincantes no se atrevían a desafiarlo ante la ley: corrían el riesgo de dañar al copyright al mismo tiempo. De hecho, si bien los proveedores de software privativo solían difundir dudas acerca de si la GPL era “válida”, pasaron más de veinte años antes de que alguno de ellos se atreviera a desafiarla

ante una corte, y no le fue bien.

Tanto el copyleft como la estrategia de oposición por construcción paralela fueron aciertos enormes, que permitieron al proyecto GNU construir una importante base de software libre, incluyendo las herramientas necesarias para desarrollar programas en forma distribuida, es decir, a través de la colaboración de varias personas sin más vínculo que su participación en el desarrollo, independientemente de su ubicación geográfica, afiliación a empresas u organizaciones. Cuando Internet comenzó a popularizarse a principios de los ’90, tanto la cantidad de personas participando en el desarrollo como la de proyectos de software libre comenzó a crecer a un ritmo comparable al de la red misma.

El software libre pudo capitalizar el crecimiento de la red con enorme eficacia gracias a que compartía con ella un tercer elemento de su estrategia: la descentralización radical. No hay estructuras centralizadas de coordinación ni control. Todo lo que una persona necesita hacer

para sumarse a la comunidad de software libre es instalar software libre en su computadora. Todo lo que hace falta para iniciar un proyecto de software libre es publicarlo. Todo lo que hace falta para convertirse en un promotor de software libre es promoverlo. No es necesario pedir permiso a nadie, ni adherir a nada en particular, al punto que muchas contribuciones al software libre (entre ellas el célebre núcleo Linux) son lideradas por personas con documentadas reservas respecto de la filosofía subyacente al movimiento.

Esta descentralización radical es eficaz, no necesariamente eficiente: la comunidad de software libre es conocida por su heterogeneidad, y por interminables peleas internas que cubren desde aspectos técnicos de los programas hasta discrepancias filosóficas, políticas, e incluso personales. No creo que sea razonable argumentar que es eficiente, por ejemplo, que el sistema GNU, que hasta hace poco tiempo carecía de una interfaz gráfica apta para usuarios finales, hoy tenga al menos cinco que compiten entre sí, y esta duplicación de esfuerzo es la regla, no la excepción: sean núcleos, navegadores de web, servidores de web, lectores de correo electrónico, bases de datos, o cualquier otra área de aplicación, es muy raro que haya un único proyecto de software libre cubriendo esa necesidad.

Tampoco son eficientes los enfrentamientos internos o de ego. Sin embargo, son el precio inevitable de la descentralización extrema, que aporta muchas ventajas. El bajo umbral de entrada para participar en la comunidad significa, en un mundo en red, que muchas personas lo cruzarán, y aportarán al menos algo al movimiento, y ese aporte es automáticamente sometido a un proceso casi darwiniano: si es bueno, probablemente mucha otra gente lo adoptará, si no lo es, se estancará y se perderá en el olvido. La gran cantidad de gente que aporta, aunque sea poco, junto con el concepto de copyleft resuelven a su vez el problema de la eficiencia: no necesitamos ser eficientes si tenemos gran capacidad de trabajo y en realidad todos nos beneficiamos con el trabajo de todos.

Incluso los disensos internos y la constante disputa por la preponderancia en el ámbito del software libre juega a favor del software libre en al menos un sentido: al no haber un liderazgo claro e indiscutido, al no existir una línea rígida de coordinación o siquiera de representación, el software libre se vuelve muy difícil de atacar institucionalmente. No existe ninguna persona, ninguna organización, ningún proyecto particular que sea esencial al software libre. No hay nada que una corporación pueda comprar, demandar o arruinar para ganar control del software libre, a menos que pueda hacer algo por el estilo con todos los usuarios de software libre al mismo tiempo.

La fórmula del éxito del software libre no es necesariamente fácil de traducir a otros movimientos. El software en sí tiene características particulares que hicieron que esta estrategia fuera efectiva: a diferencia del agua y la tierra, el software es intangible y fácilmente reproducible;

a diferencia de la ingeniería genética, el conocimiento necesario para programar es relativamente fácil de adquirir y un error de programación es fácil de “deshacer”; la naturaleza no rival del software hizo posible la estrategia de construcción alternativa que en otros campos no es posible.

Aún así, es posible que en esta estrategia haya elementos que puedan ser apropiados por otros movimientos, adaptándolos a su propio terreno. Es lo que está intentando hacer el movimiento de cultura libre, o el de redes libres, o el fenómeno relativamente reciente de re-enmarcar conflictos en el concepto de bienes comunes, como lo vienen haciendo algunas personas desde el movimiento ecologista, de agricultores campesinos, de acceso a la medicina y al conocimiento.

Referencias

* Fundación Vía Libre

1. Se conoce como “lock-in” a los mecanismos empleados por los productores de software para impedir que sus clientes dejen de usar sus programas. Una estrategia de “lock-in” muy común es guardar los datos del usuario en archivos cuya codificación es un secreto del proveedor. Así, si el usuario deja de usar el programa, corre riesgo de perder acceso a sus propios datos.

(veja a licença para modificação e distribuição do artigo no livro mencionado – é uma licença Creative Commons  🙂 )

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s


%d blogueiros gostam disto: