Si su programa es Software Libre, éste es ético en principio --pero aún así, puede haber una trampa de la que debe cuidarse.
Por Richard Stallman.
Su programa, aunque en sí mismo sea libre, puede estar restringido por software no libre del que depende. Dado que hoy se destacan por estar en esta situación los programas escritos en Java, llamaremos a esto la Trampa del Java.
Un programa es Software Libre si sus usuarios disponen de ciertas libertades cruciales. Groseramente, estas son: La libertad de ejecutar el programa, la libertad de estudiar y modificar los fuentes, la libertad de distribuir copias de los fuentes y binarios, y la libertad de publicar versiones mejoradas. Ver (
http://www.gnu.org/philosophy/free-sw.html).
Que un programa sea libre depende solamente de la forma en que se licencia su uso. Que el programa pueda ser usado en el Mundo Libre, usado por personas que desean vivir en libertad, es una cuestión más compleja. Esto no es determinado por la licencia del programa, porque ningún programa funciona aislado. Cada programa depende de otros programas.
Por ejemplo, un programa necesita ser compilado o interpretado, de manera que este depende de un compilador o un intérprete. Si se compila a 'byte code', este depende de un intérprete de 'byte code'. Más aún, necesita librerías para poder correr, e incluso podría también invocar otros ejecutables separados que corran en otros procesos. Todos esos programas generan dependencias. Las dependencias pueden ser necesarias solo para ciertas operaciones, o pueden impedir que el programa incluso logre ejecutarse.
Si alguna de las dependencias del programa es no libre, esto implica que parte o incluso todo el programa no podrá correr en un sistema totalmente libre --significa que no funcionará en el Mundo Libre.
Seguramente podríamos redistribuir el programa, y tener copias en nuestras máquinas, pero eso no serviría de mucho si el programa no se puede ejecutar. El programa es Software Libre, pero este está limitado en su libertad por sus dependencias no libres.
Este problema puede ocurrir con cualquier tipo de software, en cualquier lenguaje. Por ejemplo, un programa libre que solo corre en Microsoft Windows, es claramente inútil en el Mundo Libre. No obstante, software que ejecuta en GNU/Linux puede también 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 liberaran) fueron las mayores causas de este problema. La mayoría de las tarjetas de video 3D operan totalmente con drivers no libres, lo que también causa este problema.
Con mucho, la mayor fuente de este tipo de problemas los sufre Java en la actualidad, porque la gente que escribe Software Libre a menudo siente que Java es sexy. Ciegos por su atracción al lenguaje, minimizan el tema de las dependencias y caen en la Trampa de Java.
La implementación Java de Sun no es Software Libre. Blackdown tampoco es Software Libre, sino que se trata de una adaptación del código de Sun. Las librerías estándar de Java tampoco son libres. Tenemos implementaciones libre de Java, como el compilador Java de GNU y el de GNU, pero estos aún no poseen la totalidad de las funcionalidades.
Aún estamos tratando de implementarlas.
Si Ud desarrolla un programa Java sobre la plataforma Java de Sun, Ud es incluso litigable por usar las funcionalidades propias de Sun, aunque no se haya dado cuenta. Para el momento en que Ud pueda darse cuenta, puede haber estado usándolas por meses, y rehacer el trabajo puede tomar mas meses aún. Ud podría decir 'Es demasiado trabajo para recomenzar de vuelta'. Es entonces cuando su programa habrá caído dentro de la Trampa de Java, ya que no podrá ser usado en el Mundo Libre.
La manera segura de evitar la Trampa de Java es tener solo una implementación libre de Java en su sistema. Entonces, si Ud usa una característica o librería de Java que el Software Libre todavía no soporta, se dará cuenta de inmediato, y podrá reescribir ese código inmediatamente.
Sun continúa desarrollando librerías adicionales "standard" para Java, y la mayoría de ellas son No Libres, y en muchos casos, incluso las especificaciones de las librerías son secretos comerciales, y la última licencia de Sun para esas especificaciones prohiben el release de una implementación completa de la especificación. Vea (
JSPA2.pdf y
2METM Personal Basis Profile Specification)
Afortunadamente, la licencia de la especificación permite liberar una implementación como Software Libre; a los que reciben la librería les está permitido cambiarla sin que les sea requerido adherir a la especificación.
Pero el requerimiento tiene el efecto de prohibir el uso de un modelo de desarrollo colaborativo para producir la implementación libre. El uso de ese modelo podría imponer publicar versiones incompletas, que aquellos que han leído la especificación no tienen permitido.
En los primeros días del Movimiento del Software Libre, era imposible evitar depender de programas No Libres. Antes de tener el compilador de C GNU, cada programa C (libre o no) dependía de un compilador C No Libre. Antes de tener la librería de C GNU, cada programa dependía de una librería C No Libre. Antes de tener a Linux, el primer kernel Libre, cada programa dependía de un kernel No Libre.
Antes de tener Bash, cada script de shell tenía que ser interpretado por un shell No Libre. Era inevitable que nuestros primeros programas fueran inicialmente limitados por esas dependencias, pero lo aceptamos porque nuestro plan incluía rescatarlos a posteriori. Nuestra meta final, un sistema operativo GNU autosuficiente, incluía reemplazos Libres para todas esas dependencias, si alcanzábamos la meta, todos nuestros programas serían rescatados. Así sucedió, con el sistema GNU/Linux, ahora podemos ejecutar esos programas en plataformas Libres.
La situación es diferente en la actualidad. Ahora tenemos potentes sistemas operativos libres, y muchas herramientas libres de programación. Cualquiera sea el trabajo que desee hacer, puede hacerlo en una plataforma Libre, no hay necesidad de aceptar una dependencia no libre, ni siquiera en forma temporaria. La razón principal por la que la gente cae en la trampa hoy es porque no están pensando 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 fuera de la Trampa de Java, instale un entorno Libre de desarrollo Java, y úselo. Mas generalmente, sea el que fuere el lenguaje que use, mantenga sus ojos abiertos, y chequee el estatus de Libre de los programas de los que dependa su código. La manera más fácil de verificar qué programa es libre, es buscándolo en el Free Software Directory: (
http://www.fsf.org/directory). Si el programa no está en el directorio, entonces debe verificar su(s) licencia(s) comparándolas con la lista de licencias de Software Libre: (
http://www.gnu.org/licenses/license-list.html).
Estamos intentando rescatar los programas Java atrapados, de manera que si le gusta el lenguaje Java, le invitamos a ayudar en el desarrollo de una Classpath GNU, y reportar cualquier problema que encuentre en clases ya implementadas, esto también es útil. Finalizar la Classpath GNU tomará tiempo, y si más librerías No Libres continúan siendo agregadas, nunca tendremos las últimas. Entonces, por favor no ponga a su software libre en apuros. Cuando escriba un programa de aplicación hoy, escríbalo para que corra sobre facilidades libres desde el principio.
Copyright 2004 Richard Stallman Verbatim copying and distribution of this entire article are permitted worldwide without royalty in any medium provided this notice is preserved.
Traducción: 11 Abril 2004 Gerardo Díaz <
gerardodiaz@hotmail.com>
Por favor, envíe sus comentarios y preguntas sobre este documento a SOLAR <
info@solar.org.ar>
También puede contactarse con SOLAR por otros medios, ver en
http://www.solar.org.ar
Envié enlaces rotos y otras correcciones (o sugerencias) a <
inet@solar.org.ar>
Copyright 2004 SOLAR Software Libre Argentina. Se permite la distribución y la copia literal de este artículo en su totalidad y por cualquier medio siempre y cuando se conserve esta nota.
Atículos relacionados
FSF India - Entrevista con Richard Stallman
La comunidad de Software Libre después de 20 años: Con un gran éxito incompleto
Guarda y comparte este artículo en 
Más artículos en el tema Opinión
