Traducciones de esta página

Libre pero encadenado - La trampa de Java

12 de abril de 2004

por Richard Stallman

Si su programa es software libre, básicamente es ético--pero hay una trampa de la que debe estar alerta. Su programa, aunque en sí mismo libre, puede estar limitado por software no libre del que dependa. A día de hoy este problema es notable, sobre todo, en los programas en Java, por lo que lo llamamos «la trampa de Java».

Un programa es software libre si sus usuarios tienen ciertas libertades esenciales. Sin entrar en detalles, éstas son: la libertad de usar el programa, la libertad de estudiar y modificar el código fuente, la libertad de distribuir el código y los binarios, y la libertad de publicar versiones mejoradas (vea http://www.gnu.org/philosophy/free-sw.es.html). Que un programa dado sea software libre, depende únicamente de los términos de su licencia.

Si el programa se puede usar en el Mundo Libre, por la gente que quiere vivir en libertad, es una pregunta más compleja. Esto no lo determina la propia licencia del programa, porque ningún programa funciona aislado. Todos los programas dependen de otros programas. Por ejemplo, un programa necesita ser compilado o interpretado, así que depende de un compilador o un intérprete. Si es compilado a byte code, depende de un intérprete de byte code. Además, necesita bibliotecas para ejecutarse, y también puede invocar a otros programas aparte que se ejecutan en otros procesos. Todos estos programas son dependencias. Las dependencias pueden ser necesarias para que el programa pueda ejecutarse, o pueden ser necesarias solamente para ciertas funcionalidades. En cualquier caso, todo o parte del programa no puede funcionar sin las dependencias.

Si algunas de las dependencias de un programa no son libres, entonces todo o parte del programa no se puede ejecutar en un sistema completamente libre--es inusable en el Mundo Libre. Ciertamente podemos distribuir el programa y tener copias en nuestras máquinas, pero eso no sirve de mucho si no podemos ejecutarlo. El programa es software libre, pero en la práctica está encadenado por sus dependencias no libres.

Este problema puede suceder en cualquier tipo de software, en cualquier lenguaje. Por ejemplo, un programa libre que solamente funcione sobre Microsoft Windows es claramente inusable en el Mundo Libre. Pero el software que funciona sobre GNU/Linux también puede ser inútil si depende de otro software no libre. En el pasado, Motif (antes de que tuviéramos LessTif) y Qt (antes de que sus desarrolladores lo hicieran software libre) fueron importantes causas de este problema. La mayoría de las tarjetas gráficas 3D solamente funcionan a pleno rendimiento con controladores no libres, que también originan este problema. Pero hoy, la mayor fuente de este problema es Java, porque la gente que escribe software libre a menudo sienten que Java es sexy. Cegados por su atracción hacia el lenguaje, descuidan el asunto de las dependencias, y caen en la trampa de Java.

La implementación de Sun de Java no es libre. Blackdown tampoco es libre; es una adaptación del código privativo de Sun. Las bibliotecas estándar de Java tampoco son libres. Tenemos implementaciones libres de Java, como el Compilador de Java de GNU y GNU Classpath, pero todavía no soportan todas las funcionalidades. Todavía vamos por detrás.

Si usted desarrolla un programa en Java sobre la plataforma Java de Sun, está expuesto a usar funcionalidades exclusivas de Sun sin ni siquiera darse cuenta. Para cuando se dé cuenta, quizás las haya estado usando durante meses, y rehacer el trabajo le tomaría más meses. Podría decir «volver a empezar es demasiado trabajo». Entonces su programa habrá caído en la trampa de Java; será inusable en el Mundo Libre.

La manera fiable de evitar la trampa de Java es tener en su sistema solamente una implementación libre de Java. Así, si usted usa una funcionalidad o biblioteca de Java que el software libre todavía no soporta, se dará cuenta en seguida, y podrá reescribir ese código de inmediato.

Sun continúa desarrollando bibliotecas «estándar» de Java adicionales, y casi todas ellas son no libres; en muchos casos, incluso la especificación de la biblioteca es un secreto comercial, y la última licencia de Sun para estas especificaciones prohíbe publicar nada que sea menos que una implementación completa de la especificación (vea http://jcp.org/aboutJava/communityprocess/JSPA2.pdf y http://jcp.org/aboutJava/communityprocess/final/jsr129/j2me_pb-1_0-fr-spec-license.html, para encontrar ejemplos).

Afortunadamente, la licencia de esa especificación permite publicar una implementación como software libre; a otros que reciban la biblioteca se les permite modificarla y no se les exige adherirse a la especificación. Pero el requisito tiene el efecto de prohibir el uso de un modelo cooperativo de desarrollo para producir la implementación libre. El uso de ese modelo implicaría la publicación de versiones incompletas, que aquellos que han leído la especificación no están autorizados a hacer.

En los primeros días del Movimiento del Software Libre, era imposible evitar depender de programas no libres. Antes de que tuviéramos el compilador de C de GNU, todos los programas en C (libres o no) dependían de un compilador de C no libre. Antes de que tuviéramos la biblioteca de C de GNU, todos los programas dependían de un biblioteca de C no libre. Antes de que tuviéramos Linux, el primer núcleo libre, todos los programas dependían de un núcleo no libre. Antes de que tuviéramos Bash, todos los scripts de shell tenían que ser interpretados por un intérprete de órdenes no libres. Era inevitable que nuestros primeros programas estuvieran afectados al principio por estas dependencias, pero lo aceptamos porque nuestro plan incluía su posterior rescate. Nuestra meta final, un sistema operativo GNU autosuficiente, incluía sustitutos libres para todas estas dependencias; si alcanzábamos la meta, todos nuestros programas serían rescatados. Y así sucedió: con el sistema GNU/Linux, ahora podemos ejecutar estos programas en plataformas libres.

La situación es diferente hoy. Tenemos potentes sistemas operativos libres y muchas herramientas libres de programación. Cualquier trabajo que usted quiera hacer, lo puede hacer es una plataforma libre; no hay necesidad de aceptar una dependencia no libre ni siquiera temporalmente. La principal razón por la que la gente cae hoy en la trampa es porque no piensan en ello. La solución más fácil al problema de la trampa de Java es enseñar a la gente a no caer en ella.

Para mantener su código Java a salvo de la trampa de Java, instale un entorno de desarrollo de Java libre y úselo. De forma más general, cualquiera que sea el lenguaje que use, mantenga sus ojos abiertos, y compruebe el estado de libertad de los programas de los que dependa su código. La manera más fácil de verificar que un programa es libre es buscarlo en el Directorio de Software Libre. Si un programa no está en el directorio, puede comprobar si su licencia está en la lista de licencias de software libre.

Estamos intentando rescatar a los programas en Java atrapados, así que si a usted le gusta el lenguaje Java, le invitamos a ayudar en el desarrollo de GNU Classpath. También es útil probar sus programas con el compilador GJC y GNU Classpath, e informar de cualquier problema que encuentre en clases ya implementadas. Sin embargo, finalizar GNU Classpath tomará tiempo; si se siguen añadiendo más bibliotecas no libres, nunca podremos tener todas las últimas. Así que, por favor, no encadene su software libre. Cuando escriba una aplicación, escríbala para que funcione desde el principio sobre componentes libres.

Otros textos para leer