Java, historia y presente. Sus actores. La ida de Apache de JCP

Image via Wikipedia

Son muchas las noticias que leemos sobre Java y en especial desde la venta de Sun Microsystems a Oracle. Por todos es sabido que a Oracle lo único que le importó -o al menos en mayor medida- para adquirir Sun era Java, a tal punto de restarle importancia a otros productos de Sun, pero sin dejar de demostrar, medida tras medida, su falta de interes en el Open Source, siquiera como modelo de negocios.

Hace poco un lector, utilizó una palabra poco afortunada en una entrada de este blog para describir a la mismoa. En efecto, se la tildó como «paranoica», pero a las pruebas me remito, y antes de charlar sobre la retirada de Apache a Java Community Process y sus motivos, me gustaría hacer un reconto de la historia de Java.

Java. Sus orígenes.

Se creó como una herramienta de programación para ser usada en un proyecto de set-top-box en una pequeña operación denominada the Green Project en Sun Microsystems en el año 1991. El equipo (Green Team), compuesto por trece personas y dirigido por James Gosling [1], trabajó durante 18 meses en Sand Hill Road en Menlo Park en su desarrollo.

El lenguaje se denominó inicialmente Oak (por un roble que había fuera de la oficina de Gosling), luego pasó a denominarse Green tras descubrir que Oak era ya una marca comercial registrada para adaptadores de tarjetas gráficas y finalmente se renombró a Java.

El término Java fue acuñado en una cafetería frecuentada por algunos de los miembros del equipo. Pero no está claro si es un acrónimo o no, aunque algunas fuentes señalan que podría tratarse de las iniciales de sus creadores: James Gosling, Arthur Van Hoff, y Andy Bechtolsheim. Otros abogan por el siguiente acrónimo, Just Another Vague Acronym. La hipótesis que más fuerza tiene es la que Java debe su nombre a un tipo de café disponible en la cafetería cercana, de ahí que el icono de java sea una taza de cafe caliente. Un pequeño signo que da fuerza a esta teoría es que los 4 primeros bytes (el número mágico) de los archivos .class que genera el compilador, son en hexadecimal, 0xCAFEBABE. A pesar de todas estas teorías, el nombre fue sacado al parecer de una lista aleatoria de palabras.

Objetivos y evolución.

Image via Wikipedia

Los objetivos de Gosling eran implementar una máquina virtual y un lenguaje con una estructura y sintaxis similar a C++. Entre junio y julio de 1994, tras una sesión maratoniana de tres días entre John Gaga, James Gosling, Joy Naughton, Wayne Rosing y Eric Schmidt (este muchacho está en todos lados, de Apple a Google pasando por Java!), el equipo reorientó la plataforma hacia la Web. Sintieron que la llegada del navegador web Mosaic, propiciaría que Internet se convirtiese en un medio interactivo, como el que pensaban era la televisión por cable. Naughton creó entonces un prototipo de navegador, WebRunner, que más tarde sería conocido como HotJava.

Java ha experimentado numerosos cambios desde la versión primigenia, JDK 1.0, así como un enorme incremento en el número de clases y paquetes que componen la biblioteca estándar.

Desde J2SE 1.4, la evolución del lenguaje ha sido regulada por el JCP (Java Community Process), que usa Java Specification Requests (JSRs) para proponer y especificar cambios en la plataforma Java. El lenguaje en sí mismo está especificado en la Java Language Specification (JLS), o Especificación del Lenguaje Java.

Image via Wikipedia

Java y el código abierto. OpenJDK

Java se ha convertido en un lenguaje con una implantación masiva en todos los entornos (personales y empresariales). El control que mantuvo Sun sobre éste había generado reticencias en la comunidad de empresas con fuertes intereses en Java (IBM, Oracle) y obviamente en la comunidad de desarrolladores de software libre.

La evolución basada en un comité en el que participen todos los implicados no er suficiente y la comunidad demandaba la liberación de las APIs y bibliotecas básicas de la JDK. En diciembre de 2006 Sun comenzó relanzamiento de su plataforma Java bajo la licencia GPL de GNU.

En 1995, Sun Microsystems lanza la versión 1.0 del JDK, iniciando un capítulo importante en la industria de desarrollo de software.

Aunque ya era posible crear software libre con Java, ya que es un lenguaje de programación con una especificación abierta, para su ejecución depende de la máquina virtual Java, que era software no libre. Richard Stallman llamó a esta situación como «la trampa de Java», pues aunque el programa desarrollado sea software libre, este puede encontrar dificultades para distribuirse en entornos de software libre. Esto provocó que en todas las distribuciones GNU/Linux la máquina virtual java no esté incluida, pues el único mecanismo legal era descargarla de la propia web de Sun.

Se crearon diversos proyectos para implementar una máquina virtual Java con licencia libre, entre los que destacan Kaffe y Harmony así como GCJ que permiten compilar el código fuente Java en bytecodes y en código nativo. Para el desarrollo de las librerías base se creó el proyecto GNU Classpath.

Desde 1998 Sun crea un proceso de desarrollo abierto para la tecnología Java, a través del programa Java Community Process. El programa ha evolucionado desde entonces, permitiendo un desarrollo cada vez más abierto de la plataforma Java bajo la licencia JRL. En 2006 la versión Java SE 6 se realizó con una gran participación de la comunidad. Sin embargo, Sun se mostraba indeciso en la licencia con la que sería liberada, aunque se consideraba utilizar la licencia Common Development and Distribution License (CDDL) utilizada por OpenSolaris.

Finalmente en Agosto de 2006 Sun modificó su licencia de forma que pudiera incluirse el binario de la máquina virtual Java en distribuciones GNU/Linux.

El 13 de noviembre del 2006, después de 10 años de desarrollo, Sun anuncia el lanzamiento de las versiones Java SE 6 y SE 7 bajo licencia GPL versión 2. Al proyecto se le nombró OpenJDK e incluyó inicialmente la máquina virtual Java HotSpot, el compilador de Java javac y el sistema de ayuda JavaHelp 2.0. Anuncia también la liberación del resto de la plataforma a lo largo del primer semestre del 2007, con excepción de unos pocos componentes con problemas de licenciamiento ajenos a Sun.

Apache. Apache-Harmony. Java Community Process. Oracle.

Oracle, La compañía intentó comprar Red Hat hace unos años y acaba de presentar una distribución basada en el código fuente de RHEL: Oracle Unbreakable Linux. Es decir, no pudo comprar la compañía pero se aprovecha del trabajo y experiencia de Red Hat. Pero no todo acaba ahí ya que encima ofrece este software a un precio más económico que Red Hat. Eso es competencia… uso tu producto le cambio cuatro cosas y lo ofrezco más barato que tú…

Cuando Oracle [Demanda a Oracle por fraude] adquiere Sun Microsystems la historia y relación con la comunidad open source comienza a enturbiarse más aún. En efecto, tras la adquisición, Oracle ha demostrado su completo desinterés con el OpenSource y su falta de interés para con los productos de Sun. Le tocó a OpenSolaris, le tocó a OpenOffice, le está tocando a VirtualBox y obviamente a Java. Esto obviamente generó ciertas incompatibilidades en el ceno de JCP (principalmente con ASF, Google como miembro de EC Tim Peieris) y con la necesidad de aprobar Java 7 SE la cosa no podía tardar mucho en complicarse, más aún cuando Oracle no daba paso sin otro sentido que hacerse del control de Java.

Esto decía James Goseling al respecto:

Fue bastante claro durante el tiempo que conocí a Oracle que Java, en sus manos, está condenado.

Es una verdadera pena lo que está sucediendo y Java en manos de Oracle se encuentra en peligro…

Image by jaaron via Flickr

Es así que la Apache Software Foundation (ASF), convocó a los demás miembros de Java Community Process, para impedir que el lanzamiento de Java 7 si Oracle se negaba a publicar éste bajo los términos de una licencia de código fuente abierto que sea compatible con la implementación Java de Apache.

No hace mucho Oracle e IBM hicieron un pacto bajo el cual IBM se comprometía a apoyar la versión de Java de Oracle. Ésto significó un duro golpe para Apache, ya que hasta entonces habían trabajado junto con IBM sobre la implementación libre de Java de Apache conocida como Apache Harmony. IBM se vio obligado a pactar con Oracle debido al temor de que éste último dificultase el camino para utilizar Java SE Compatibility Kit que Apache requería para mantener el estándar en su implementación y la interoperabilidad.

Apache ha manifestado que abandonarán Java Community Process si fallaba en convencer al resto de los miembros de votar en contra si Oracle continúa imponiendo restricciones sobre el uso de las porciones de código fuente abierto de Java.

IBM solía ser uno de los principales aliados de Apache en lo referente a la posición respecto de las crecientes restricciones sobre los campos de uso de (FOU, Fields-of-use) de Java, y su cambio de bando para apoyar solamente a OpenJDK, sugirió que votarían en apoyo a Oracle. De esta manera IBM estaría siguiendo los pasos de otras organizaciones, como Red Hat y la Fundación Eclipse, que desean dejar que Oracle haga su voluntad por el bien de sus cada vez más gordos bolsillos el lenguaje de programación Java.

Si a esto le sumamos la absurda demanda de Oracle a Google [1] [2]  (Sin defender a Google, sus politicas apestan cada vez más. Obviamente la demanda es por violación de patentes; recordar y no confundir que Java tiene licencia GPL. El principal «problema» deviene de la máquina virtual que se utilice, en el caso de Google – Android Dalvik Virtual Machine) por la implementación de Java en Android, caemos muy fácil en la cuenta del verdadero motivo detrás de la adquisición: CONTROLAR A PLACER JAVA.

Todo el dilema entre Oracle y Apache consiste en sí se deben aplicar restricciones sobre como se utilizan las versiones de código fuente abierto de Java. Pero la cosa no dió para más y La Apache anunció que ha renunciado a su asiento en el Comité Ejecutivo de Java SE/EE,el cual ocupó por 10 años, ganado el premio de Miembro del Año en 4 ocasiones.

La gota que rebalsó el vaso.

La reciente votación sobre Java SE 7 fue la última oportunidad para que el Comité Ejecutivo de Java Community Process (JCP) demostrara sus intenciones de defenderse como una especificación abierta. Oracle proveyó al Comité Ejecutivo con una solicitud de especificación de Java SE 7 y una licencia que son auto-contradictorias y que restringen severamente la distribución de implementaciones independientes de la especificación, prohibiendo la distribución de implementaciones independientes de la especificación si éstas son de código fuente abierto.

Esto también originó la renuncia de dos importantes miembros del comité, Doug Lea y Tim Peierls.

Específicamente, Oracle se ha rehusado a proveer una licencia TCK para Java al proyecto Harmony de Apache (así certificar que su Java OpenSource -harmony- sea compatible con Java y, eventualmente, obtener ciertas patentes), lo cual rompe la promesa pública hecha por los ejecutivos de Sun Micosystems a la comunidad Java.

«Oracle está violando sus obligaciones contractuales según lo dispuesto en las normas de la JCP sólo por ofrecer una licencia TCK que impone los términos y condiciones adicionales que no son compatibles con las licencias de código abierto o software libre», declaró el FSA.

Al aprobar Java SE 7, el comité fracasó cuando algunos miembros de éste se rehusaron a defender los derechos de las implementaciones independientes y al aceptar los términos de la licencia TCK de Oracle (que según ellos es justa y no discriminatoria) para Java SE 7, permitiendo se rompiese la integridad de la estructura de licencia de JCP.

Fue por tal motivo que la Fundación Apache concluyó que JCP dejó de ser un proceso de especificación abierta y que las especificaciones de Java son tecnología privativa que debe ser distribuida bajo términos de licenciamiento que Oracle elija.

De esta manera, Oracle -al igual que Sun en su momento- no certificará Harmony; anunciando que, junto a IBM, apoyarán a OpenJDK, implementación Open Source para la plataforma Java.

“Los intereses comerciales de una única entidad, Oracle, continuarán interfiriendo en la gestión transparente del ecosistemas”, puede leerse en un post publicado en el blog de la fundación.

Esto significa que o bien la comunidad debe comenzar a ejercer presión política sobre Oracle para que cambie sus posturas, o bien se tratará de hacer una bifurcación de Java. Recordemos las palabras de Gosling y su esperanza en la comunidad.

Image by plαdys via Flickr

Pero no toda la culpa es de Oracle, Sun tiene su cuota de responsabilidad en todo esto. Sun ha sido vendida al peor postor, y don Larry Ellison (que aparece en Iron Man 2) da sobradas muestras que quiere eliminar todo el Open Source de su empresa. No está mal, negocios son negocios, y Red Hat ha demostrado que el Open Source puede ser un buen modelo de negocios. Pero el que no te interese el Open Source, ¿justifica lo que Oracle está haciendo?

La respuesta de Oracle.

Obviamente la respuesta de Oracle no se hizo esperar, invitando a ASF a reonsiderar su posición:

…We encourage Apache to reconsider its position and remain a part of the process to move Java forward. ASF and many open source projects within it are an important part of the overall Java ecosystem.

¿Volverá ASF a su puesto? ¿Qué pasará con Harmony que al no ser certificada por Oracle no obtiene la protección legal suficiente y Apache podría ser demandada por violación de patentes siguiendo los fundamentos de la demanda contra Google? ¿Qué pasará con OpenJDK luego de recibir «el apoyo» de Oracle e IBM?

Fuentes. Principalmente Alcance libre y Wikipedia; otras fuentes linkeadas en el artículo.

Related Articles

• Apache Declares War on Oracle Over Java (pcworld.com)
• Apache threatens Oracle with Java exit (go.theregister.com)
• Oracle: no license for Android’s Harmony friend (go.theregister.com)
• James Gosling: Why I Quit Oracle (eweek.com)
• Apache is being forced into a Java Fork (zdnet.com)
• Apache Leaves Java Community Process (informationweek.com)
• Java SE 7 and SE 8 specs move forward amid protest (infoworld.com)