¿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.