lesman, el jdk 7 es PLVv2 ya no hay trampa java -- Miguel Angel Iglesias o--)---|--(o)--|---(--o http://dimeder.com/blog
> -----Original Message----- > From: [email protected] > Sent: Thu, 12 Mar 2009 01:33:22 -0500 > To: [email protected] > Subject: Re: [linux-l] Duda con java > > >>> -----Original Message----- >>> From: [email protected] >>> Sent: Thu, 12 Mar 2009 00:02:13 +0100 >>> To: [email protected] >>> Subject: Re: [linux-l] Duda con java >>> >>> Amigos: >>> >>> esto es una duda: el lenguaje de programación java es libre? >>> >>> yaroldi manzano >>> > > La especificación es libre, creo > El nombre no, creo > El jdk 7 si, creo > > -- > Miguel Angel Iglesias > o--)---|--(o)--|---(--o > http://dimeder.com/blog > > Entre noviembre de 2006 y mayo de 2007, Sun Microsystems liberó la mayor > parte de sus tecnologías Java bajo la Licencia pública general de GNU, > de acuerdo con las especificaciones del Java Community Process, de tal > forma que prácticamente todo el Java de Sun es ahora software libre > (aunque la biblioteca de clases de Sun que se requiere para ejecutar los > programas Java todavía no es software libre). > > de wikipedia. > > --------------------------------- > > La trampa de Java > > por Richard Stallman > Nota > > En diciembre de 2006 Sun está en pleno relanzamiento de su plataforma > Java bajo la GPL de GNU. Cuando este cambio de licencia haya terminado, > esperamos que Java ya no sea una trampa. A pesar de eso, el problema > general descrito aquí seguirá siendo importante, porque cualquier > biblioteca no libre o plataforma de programación puede causar un > problema similar. Debemos aprender una lección de la historia del Java, > para poder evitar otras trampas en el futuro. > > 12 de abril de 2004 > > Si su programa es software libre, básicamente es ético — pero hay una > trampa de la que debe estar atento —. 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 del 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 (véase > 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. > > Que el programa se pueda usar en el mundo libre, por la gente que quiere > vivir en libertad, es una pregunta más compleja. Esto no lo determina la > licencia del propio 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 funciones. 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 causantes 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 cree que el Java es sexy. > Cegados por su atracción por el lenguaje, descuidan el problema de las > dependencias y caen en la trampa del Java. > > La implementación del Java de Sun no es libre. Las bibliotecas estándar > del Java tampoco son libres. Sí que tenemos implementaciones libres del > Java, como el compilador de Java de GNU (GCJ) y Classpath de GNU, pero > todavía no tienen todas las funcionalidades. Estamos intentando > alcanzarlas. > > Si usted escribe 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 del Java; será inusable en el mundo Libre. > > La manera fiable de evitar la trampa del Java es tener en su sistema > solamente una implementación libre del Java. Así, si usted usa una > funcionalidad o biblioteca del 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» del Java adicionales, > y casi todas son no libres; en muchos casos, incluso la especificación > de la biblioteca es un secreto comercial, y la última licencia de Sun > para esta especificación prohíbe publicar nada que sea menos que una > implementación completa de la especificación (véase > 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 una 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 hoy es diferente. Tenemos potentes sistemas operativos > libres y muchas herramientas libres de programación. Cualquier trabajo > que usted quiera hacer, lo puede hacer en 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 del Java > es enseñar a la gente a no caer en ella. > > Para mantener su código Java a salvo de la trampa del Java, instale un > entorno de desarrollo del 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 atrapados en el Java, así > que si a usted le gusta el lenguaje Java, le invitamos a ayudar en > eldesarrollo 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. > > > saludos > Lesman > > > _______________________________________________ > Cancelar suscripción > https://listas.softwarelibre.cu/mailman/listinfo/linux-l > Buscar en el archivo > http://listas.softwarelibre.cu/buscar/linux-l ____________________________________________________________ GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at http://www.inbox.com/smileys Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and most webmails _______________________________________________ Cancelar suscripción https://listas.softwarelibre.cu/mailman/listinfo/linux-l Buscar en el archivo http://listas.softwarelibre.cu/buscar/linux-l
