Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Java libre

Noticias
Por man ls
departamento como el chorizo al pan , Sección Software Libre
Puesto a las Thu Nov 16th, 2006 at 11:42:11 PM CET
Por fin, tras años de peticiones, el notición (ya reseñado en el diario de atopos): Java será libre. ¿Qué quiere decir todo esto? Traduciré y ampliaré mi comentario en LWN.

 


¿Dónde están ahora los agoreros que predecían la muerte, disgregación, bifurcación hasta la muerte de Java cuando se "hiciera libre"? Espero que estudiando la diferencia entre "especificación" e "implementación". Creo que en otros comentarios no ha quedado bastante claro así que por si acaso quedan despistados, vamos a explicarlo de nuevo.

Stallman siempre ha sido muy explícito sobre el término propiedad intelectual: es un término confuso y hecho para confundir, ya que mezclar copyrights, patentes, marcas comerciales, secretos industriales y demás no lleva a ningún sitio. Cada elemento de los mencionados debe considerarse por separado si se quieren tomar decisiones coherentes. Pero es más, el amigo Stallman nunca se preocupa sobre marcas, o sobre detalles como el copyright sobre los logotipos que tanto preocupan a las empresas. Sus escritos casi siempre tratan sobre el código en sí -- y sobre las patentes que pueden limitar la distribución y el uso del software. El motivo es que el código es funcional: hace cosas. Pero cambiarle el nombre o el logotipo a un programa no hace que se modifique su comportamiento. Las marcas son vistas, incluso dentro del software libre, como una forma legítima de proteger un producto. Y si no, que se lo pregunten a Qt, MySQL, o la todopoderosa Red Hat.

Pues bien, me da la impresión de que las especificaciones caen en el mismo lado de la cuchilla que los logotipos. El mensaje viene a ser: "Puedes crear las especificaciones que te dé la gana, que nosotros implementaremos lo que nos interese." Cuando pedíamos "Java libre", y saben los dioses que lo hemos pedido hasta desgañitarnos, mucha gente lo confundía "liberar la especificación del lenguaje" con "liberar la implementación de la máquina virtual y las librerías". La claque de Sun nos alertaba con gritos destemplados sobre los peligros de la fragmentación del lenguaje, como estuvo a punto de pasar con Microsoft. El club de fans del software libre respondíamos que sólo queríamos una implementación libre.

De hecho esta jugada pilla a nuestros aguerridos guerreros bastante ocupados; en este momento se están creando dos implementaciones libres del JDK, Harmony del grupo Apache y GCJ del proyecto GNU. Ya he escrito sobre este último, en mi opinión el más útil; la posibilidad de compilar código Java a código nativo (código máquina de toda la vida) es otra flecha en la aljaba, que nunca se puede saber cuándo nos puede venir bien. Sin embargo, mientras Sun siga añadiendo cosas a la especificación (en esencia huyendo hacia delante), las implementaciones libres siempre irán por detrás.

Así pues, dejemos que Sun decida qué es "Java"; si es necesario, llamaremos a nuestra versión "Gnava" o algún nombre peor aún. Al igual que Ghostscript es la versión libre de Postscript y nadie se lleva a confusión por ello. Pero ahora la implementación libre no tiene por qué estar jugando todo el tiempo a Aquiles y la tortuga, reimplementando todas las especificaciones que Sun añade constantemente. Aún más importante: no es necesario acarrear todo el peso muerto, como AWT, Swing, Java logging o los resultados de la peregrina idea de añadir las librerías completas Xerces y Xalan al sistema. Ahora podemos crear una versión de servidor de Java, bajar los componentes necesarios o añadir nuestras librerías favoritas.

Por fin, cada uno tiene lo que quiere. Esta jugada le va a salir más barato a Sun que montar el tinglado del JCP, los JSR's y todas las historias para dar impresión de "comunidad" al definir el lenguage; y al mismo tiempo va a ser más efectivo, por lo que podemos lamentarnos de que no haya ocurrido antes. Por otro lado, podemos regocijarnos de que el momento haya llegado por fin. Java y el software libre hacen muy buena pareja, aunque hasta ahora su amor fuera imposible. Justamente lo mismo ocurría con Unix y GNU hasta que llegó el kernel Linux. Éste es otro gran día.

< Proyecto de futuro para la tira ecol (8 comments) | ¡Ya está aquí! (22 comments) >
Enlaces Relacionados
· escomposlinux.org
· el diario de atopos
· Java será libre
· mi comentario en LWN
· propiedad intelectual
· Microsoft
· Harmony
· GCJ
· este último
· JCP
· More on Noticias
· Also by man ls

Encuesta
Tu interés por Java
· se desvaneció ya 16%
· está latente 27%
· empieza a despertar 11%
· se aviva 33%
· ¡viva el coletas de Schwartz! 0%
· para coletas la rubia 11%

Votos: 18
Resultados | Otras Encuestas

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
Java libre | 11 comentarios (11 temáticos, editoriales, 0 ocultos)
Sobre los cambios de especificaciones (none / 0) (#1)
por svampa a las Fri Nov 17th, 2006 at 12:03:00 AM CET
(Información Usuario)

Reimplementando todas las especificaciones que Sun añade constantemente    (...)    Aún más importante: no es necesario acarrear todo el peso muerto, como AWT, Swing, Java logging o los resultados de la peregrina idea de añadir las librerías completas Xerces y Xalan al sistema.

Hoy en día un lenguaje es: el lenguaje, un montón de librerías y a veces incluso entotno de desarrollo.

No me parece mal que las especificaciones de un lenguaje abarque un montón de liberías y componentes; especialmente hoy en día donde no trabajas aislado, sino que compartes e utilizas código de todas partes. Si te descargas unas fuentes de internet ¿no es ideal que gracias a un estándar amplio apenas haya dependencias?

Pongamos por ejemplo Perl. Tiene un montón de todo, y cada vez se añaden más liberías. Gracias a eso prácticamente cualquier script de perl puede hace de todo con un mínimo de dependencias. ¿Sería lógico que si alguien intentará implementar otro interprete del Perl se quejara del peso muerto que ha de acarrear?.

Otra cuestión es, al ampliar las especifaciones, cuanto había en Sun de mejorar el producto, y cuanto había de "versionitis" para mantenerse en las noticias y para poner la zancadilla a otra implementaciones.



Librerías en Java (none / 0) (#2)
por man ls a las Fri Nov 17th, 2006 at 12:56:43 AM CET
(Información Usuario)

Pongamos por ejemplo Perl. Tiene un montón de todo, y cada vez se añaden más liberías.
Sí, pero son opcionales; no te lo bajas todo con el entorno principal. (Supongo que hablas de CPAN, ¿no?)
Otra cuestión es, al ampliar las especifaciones, cuanto había en Sun de mejorar el producto, y cuanto había de "versionitis" para mantenerse en las noticias y para poner la zancadilla a otra implementaciones.
Exactamente. Fíjate si no lo que pasó con Log4j: Sun sacó su Java Logging y arrolló a esta librería, pese al apoyo de la comunidad. En su lugar podrían haber hecho como con J2EE: sacar un conjunto de interfaces, seguramente con una implementación de referencia, y dejar que cada cual la reemplace con lo que quiera.

Algo parecido con los parsers de XML: ¿cómo actualizo yo ahora el Xerces que viene con la JVM? ¿Y si quiero una versión anterior? Complicado.

[ Padre ]


Ya conoces una de las leyes de Murphy... (none / 0) (#3)
por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Sun Nov 19th, 2006 at 12:07:17 PM CET
(Información Usuario) http://www.escomposlinux.org/jcantero/

"Una vez abres una lata de gusanos, el único modo de volverlos a meter es usar una lata mayor (los viejos nunca mueren, sólo se desarrollan en latas mayores)"

Habría que cargarse un montón de las grades pifias de Java 1, como el AWT, los Vectors o las HashTables (no lo digo yo, lo dice Bruce Eckel). Pero el problema es el de siempre: los legacy systems: a nadie le gusta que le digan que tiene que reprogramar su codigo.

Lo peor de todo es que se sigue enseñando a programar en Java con Vector & cía...

--
"Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson
[ Padre ]


Totalmente (none / 0) (#4)
por man ls a las Sun Nov 19th, 2006 at 04:17:26 PM CET
(Información Usuario)

Por eso, precisamente porque el software libre tiene más libertad de acción (y porque estamos más acostumbrados a que las cosas se rompan a cada versión nueva :P ), se pueden crear proyectos que eliminen esas pifias y sean específicas para código moderno. Seguramente la JVM resultante sea más ligera y apta para entornos donde esto importe: servidores multiusuario, sistemas integrados. O simplemente para que los programas normales arranquen más rápido y ocupen menos.

[ Padre ]


 
Incorrecto. (none / 0) (#7)
por trukulo (mzv-at-menta-dot-net) a las Wed Nov 29th, 2006 at 09:31:12 AM CET
(Información Usuario) http://mercurio.homeip.net

La respuesta correcta es: Con una batidora.


Miguel Angel Zarza.
Aka trukulo.
email: trukulo(at)menta(dot)net
jabber ID: trukulo(at)bulmalug(dot)net
web: http://mercurio.homeip.net
[ Padre ]


 
Punto de vista de un usuario (none / 0) (#5)
por trinux a las Sun Nov 19th, 2006 at 04:24:32 PM CET
(Información Usuario) http://solognu.wordpress.com/

Se habla mucho, y la mayoría no me interesa. Al grano: ¿significa la noticia que el paquete que tengo instalado en mi Ubuntu Edgy "sun-java5-jre" pasara del repositorio "multiverse" a "main"? Nada más.



Pasará, pasará (none / 0) (#6)
por man ls a las Sun Nov 19th, 2006 at 07:25:12 PM CET
(Información Usuario)

Eventualmente pasará. Sun ha prometido liberar el JDK para la primera mitad de 2007 -- es la manera yanqui de decir "para mediados del año que viene". Ahora mismo está disponible la JVM, HotSpot incluído -- en el plazo fijado se espera que Sun publique también bajo GPL el código de las librerías de Java. Juntos forman el JRE, y sumando el compilador y utilidades similares (que también están ya bajo GPL, por cierto) tenemos el JDK.

También se liberará J2EE, según parece: el código de los servidores empresariales incluyendo Servlets, EJBs y demás también estará bajo GPL. Aunque aquí lo importante es básicamente la especificación, ya que el kit de Sun contiene poco más que un conjunto de interfaces públicos.

Hay un aspecto que sí te interesará, aunque sólo sea como usuario: en el momento en que Ubuntu quiera aplicar un parche de seguridad de una línea a su paquete, éste tendrá necesariamente que dejar de llamarse "java". Así, puede que el paquete que tengas que instalar ya no se llame "sun-java5-jre", sino "ubuntu-gnava5-gre": Sun es dueña de la marca registrada "Java" (y "JRE", por cierto), así que puede que no certifique implementaciones que se desvíen aunque sea mínimamente de la suya.

[ Padre ]


marcas registradas (none / 0) (#8)
por festuc (mi nick en el correo gratuito de google) a las Thu Nov 30th, 2006 at 12:47:44 PM CET
(Información Usuario) http://festuc.info

gnome, kde, linux ... son marcas registradas son usadas por ubuntu y otras en los paquetes.
o sea que quando java pase al main segira llamandose java pero quiza no sera sun-java por que quiza no sera ahora sun quien compile

M'ho van explicar i no m'ho vaig creure
Ho vaig Beure i ho vaig vomitar,
ho vaig fer i no pararia mai.
me lo explicaron y no me lo creii
me
[ Padre ]


Firefox (none / 0) (#10)
por algarcia a las Sat Dec 9th, 2006 at 02:56:15 AM CET
(Información Usuario)

Lo que dice man ls ya pasó con Firefox. Debian lo quitó por problemas con las directrices del software libre de Debian. Ahora está IceWeasel, que de momento es básicamente una compilación de los debianitas del código fuente de mozilla.org, creo, pero tengo entendido que en un futuro van a meter el fork que se llama igual y que depende del proyecto GNU, Gnuzilla e IceWeasel.

--
No me pregunto lo que yo puedo hacer por el S.L., si no lo que todos vosotros podéis hacer por mí. :-P
[ Padre ]


 
Diferencias en Software (none / 0) (#9)
por p3rti a las Fri Dec 8th, 2006 at 06:26:42 PM CET
(Información Usuario)

En el país donde vivo (Colombia), y yo creo que en muchos mas, todo software entra por la normatividad regida bajo las leyes del DERECHO DE AUTOR, y según tengo entendido esta se divide en DERECHOS DE AUTOR MORAL y DERECHOS DE AUTOR PATRIMONIAL, la GPL habla y actua explicitamente sobre la parte patrimonial la cual le da el derecho que la GPL concede a quien tenga el software, pero el derecho de autor moral es siempre y siempre sera de las personas ó la persona que creo dicho proyecto y no tiene vencimiento alguno. Por lo tanto el cambiar el nombre de un software que esta licenciado bajo la GPL no estaria violando la GPL, estaria violando el DERECHO DE AUTOR MORAL, sobre dicha obra. como si yo quisiera cambiar el nombre de quien hizo "La metamorfosis" si esta estaria con algún tipo de licencia de documentos libres.



No sé yo (none / 0) (#11)
por man ls a las Sun Dec 10th, 2006 at 07:34:12 PM CET
(Información Usuario)

Creo que entiendo lo que dices, y de hecho "La metamorfosis" está en el dominio público según las leyes de Copyright internacionales. Es decir: puedes tomar el texto y hacer lo que quieras con él.

Decir que lo has escrito tú no es violar ninguna "ley moral"; es mentir como un bellaco. Cambiarle el nombre a un programa de software, por otro lado, es algo de lo más común y que no tiene por qué ser inmoral. Quien lo escribió le puso la licencia GPL, que permite explícitamente su redistribución, en todo o en parte, y bajo cualquier nombre; por tanto, tenemos que entender que al autor le parecía bien esa práctica.

Ahora bien, si el autor original viene y nos dice que le parece mal que se haga eso, entonces habría que reevaluar la cuestión. Lo que se suele hacer en el mundo del software libre es que los líderes del nuevo proyecto van reescribiéndolo parte a parte, para al final no tener nada que ver con el indeseable que primero nos dice que sí, que bien; y luego cuando se da cuenta de lo que ha hecho se arrepiente.

En el caso de la fundación Mozilla, ellos han aceptado código de muchas partes distintas, bajo la condición explícita de que el software estaba licenciado bajo la GPL; y los cambios de nombre, etc. son admisibles. Así que no veo nada inmoral en trincar el código y buscar nuevos aires, visto el panorama. Con Java, ya se vería.

[ Padre ]


 
Java libre | 11 comentarios (11 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda