Etiqueta: oracle

Como supongo que todos sabréis, Oracle ha demandado a Google por usar Java en Android. En este post me gustaría exponer las implicaciones que esto tiene para los millones de desarrolladores Java que hay en el mundo.

No sabía muy bien como titular la entrada… en mi GTalk he puesto «Java D.E.P» y en Facebook he sido un poco más explícito «Españoles, Java ha muerto (Oracle lo ha matado)». Realmente nadie sabe si Java morirá con esta demanda… pero todo el mundo está de acuerdo en que Java nunca volverá a ser lo que era cuando Sun Microsystems era su dueño. Mucha gente tenía miedo de lo que Oracle pudiera hacer con Java, incluso el propio James Gosling (el padre y creador de Java) ha dicho en varias ocasiones en su blog que no le gustaba un pelo lo que Oracle estaba haciendo con la adquisición de Sun (hay que recordar que el creador de Java ya está fuera de Oracle, fue «despedido» al completarse la adquisición). Cuando se ha sabido la noticia, James Gosling ha puesto un post con un título muy descriptivo: «The shit finally hits the fan….» algo así como que «la mierda ha llegado finalmente al ventilador…».

Antes de nada, me gustaría decir que es bastante probable que Google y su Android no tengan ningún problema con esta demanda. De hecho, Apple demandó el otro día a HTC también por Android. Son grandes empresas y estas demandas sirven para repartirse dinero entre ellas. También tengo que decir que para los programadores que consideran que Microsoft es una empresa ejemplar y que programan con VisualStudio en Visual C++ o en .NET Framework, esta demanda es lo más razonable del mundo. Es decir, esta demanda no quiere decir que los programadores dejen de usar y programar en Java. Java se seguirá usando y por mucho mucho tiempo, al igual que la gente usa Windows (a pesar de las reiteradas acusaciones por monopolio) y tiene iPhone (a pesar de las restricciones que Apple impone a los usuarios de sus productos). Entonces… ¿Por qué digo que este puede ser el principio del fin de Java? Precisamente en este post intentaré explicar lo que supone esta demanda. Pero antes de nada, un poco de historia para saber dónde estamos y a dónde vamos.

Los comienzos de Java

Java apareció en un momento en el que MS Windows dominaba el mundo de los PCs en la era pre-Internet. Esta tecnología supuso un soplo de aire fresco en el mundo del desarrollo por varias razones:

• Permitía desarrollar programas que funcionaran en Windows, Linux, Apple, Solaris, etc. Es decir, un desarrollador podría hacer un programa que se ejecutase en cualquier plataforma sin realizar ninguna modificación. Esto sobre todo era bueno para Linux y para Solaris, porque la gente podría seguir programando para Windows (la plataforma dominante) y los usuarios de Linux y Solaris podrían usar los programas sin modificación.
• Creaba un nuevo lenguaje de programación mucho más sencillo y potente que los anteriores. La recolección de basura, la sencilla orientación a objetos y el chequeo de arrays en tiempo de ejecución han sido de lejos sus puntos más fuertes. Al ser el lenguaje más sencillo, se podían desarrollar programas más complejos de forma más rápida (reduciendo costes).
• Ofrecía una librería estándar bastante completa y bien documentada. Lo que permitía hacer programas muy completos y funcionales desde el primer momento. Además, el código fuente de esa librería se podía leer, aunque no se podía copiar ni modificar. Pero al poder leerse, se podía aprender de él y además se podían notificar errores al equipo de desarrollo de Java.

Al principio se utilizó sobre todo para hacer mini-programas en las páginas web. Lo que ahora se hace con Adobe Flash en los albores de Internet se hacía con Java y sus «applets». Posteriormente debido a los problemas legales entre Sun y Microsoft se dejó de usar en el desarrollo de páginas en Internet y se popularizó el uso de Macromedia Flash como sustituto. Pero debido a la popularidad de la tecnología Java, poco a poco empezó a usarse para el desarrollo de aplicaciones Web (en la parte del servidor) y para el desarrollo de las títpicas aplicaciones de gestión (yo he llegado a ver una aplicación implementada en Java en un banco). El índice TIOBE (un índice que mide la «popularidad» de los lenguajes de programación), considera que Java ha sido (y es) el lenguaje más popular desde 2002, momento en que empieza a realizarse este índice. Es un hecho que Java ha sido una tecnología muy utilizada por los desarrolladores. Ha sido tan usada que Microsoft sacó una copia de esta tecnología y la llamó .NET Framework y su lenguaje C#. Otra de las características de Java es que se podía utilizar para el desarrollo de aplicaciones móviles, principalmente juegos, en la era pre-iPhone. Hasta aquí todo bien… Java es una tecnología popular que utilizan muchos desarrolladores y lo seguirá siendo mucho tiempo.

¿Qué hizo popular a Java?

Pese a los grandes méritos técnicos de la plataforma Java, hay otras cuestiones que han hecho popular a Java frente a otras alternativas. Java fue desarrollado por la empresa Sun Microsystems. Es considerado por todos que los creadores de aquella tecnología llamada Oak eran ingenieros realmente buenos e hicieron un buen trabajo innovando en aspectos en los que hacía muchos años que no se veían avances. Java marcó un antes y un despúes en el desarrollo de aplicaciones al llevar a la práctica el desarrollo con máquinas virtuales y al popularizar la orientación a objetos. Además, la empresa creadora de Java era «buena» (a diferencia de otras empresas con Microsoft que tenían políticas bastante cerradas y que cobraban por los compiladores, los entornos de desarrollo, etc). Sun era «buena» porque todo era gratuito, el compilador de Java (para hacer programas) y la máquina virtual de Java para ejecutarlos. Además, había hecho una implementación de Java de primer nivel para Linux, lo que hizo que muchos linuxeros usaran esta tecnología. Y toda la documentación estaba accesible por Internet y era gratuita. Resumiendo, una tecnología puntera, con muchas posibilidades, portable y además gratuita (y en la época del Microsoft más poderoso…) pronto granjeó la simpatía de muchos desarrolladores.

Java y el software libre

Java no era software libre, eso hizo que muchos comprometidos con el software libre pusieran problemas a aquella tecnología. Incluso Richard Stallmand (fundador de la Free Software Fundation) habló en 2004 de la «Trampa de Java«, en la que indicaba que un programa libre implementado en Java no sería realmente libre porque necesitaba la máquina virtual de Java para poder ejecutárse y esta máquina virtual no era libre (aunque estuviese disponible gratuitamente para Linux). Java no era libre… pero Sun Microsystems, su dueña, habían sido bastante «buenos» siempre con la comunidad del software libre. Por ejemplo, la fundación Apache (creadora del popular servidor web Apache) era la encargada de implementar con licencia libre el servidor Tomcat, un servidor web para aplicaciones Java.

Y entonces en 2006 llegó el día en que Sun Microsystems liberó Java como software libre con licencia GPLv2. En ese momento, los amantes del software libre más reacios dejaron de ver con malos ojos a la tecnología Java. Ese era el paso que todos habían estado esperando, si era gratuito y abierto… ¿por qué no hacerlo software libre? Sun Microsystem argumentó durante mucho tiempo que no lo quería hacer software libre porque no quería que Java se fragmentara. Es decir, que cada uno cogiese y se hiciese su propio Java y lo empezara a cambiar y a modificar de forma que una aplicación Java ya no se podría ejecutar en cualquier plataforma. Precisamente eso es lo que llevó a Sun a demandar a Microsoft muchos años antes (juicio que ganó llegando a un acuerdo de 1.500 millones de dóalres). Parecía entonces que todo era como un anuncio de compresas… todos felices, Java dominaría el mundo, etc, etc ¿o no?

Pero todo tiene su lado oscuro… Sun no era tan «buena»

Hasta aquí he contado la parte buena de Sun Microsystems como creador y dueño de Java. Ahora empezaré a contar las partes más oscuras de Sun como padre de Java. Aunque Sun haya sido un dueño «bueno» de Java, esto quiere decir que Java siempre ha tenido dueño. La tecnología Java no es un estándar que cualquiera pueda implementar (pagando o sin pagar licencia), Java es una tecnología propietaria de una empresa. Por ejemplo, los lenguajes C y C++ son estándares (para los que cualquiera puede hacer un compilador). Incluso el lenguaje C# es un estándar. No obstante, como Sun ha sido un dueño bueno, creó el Java Community Process (JCP), una especie de organización que coordina el avance de Java. En realidad es como si fuera una especie de organización de estándares para Java. En esta organización están todos los grandes de la industria (y los pequeños) menos Microsoft, es decir, Apache, Google, IBM, Intel, Red Hat, Oracle, Eclipse y muchos más. Sun ha sido una empresa «buena» porque ha creado este mecanismo para la evolución de Java como un cuasi-estándar, y podría no haberlo hecho. Pero no ha sido tan buena porque Sun tenía más privilegios que cualquier otra empresa en las votaciones.

En el JCP empezaron todos los problemas con Sun y el software libre

En el JCP comenzaron todos los problemas y Sun Microsystem empezó a mostrar su lado más oscuro como dueño de Java. Hay que hablar un poco de tecnicismos para entender exactamente qué hizo Sun Microsystems. Desde un punto de vista técnico, la tecnología Java es un conjunto de cuasi-estándares (desde el punto de vista de la organización JCP). Cada estándar se denomina Java Specification Request (JSR) y habitualmente define como se comporta una librería de Java (o varias). Por ejemplo, el JSR 316 es el estándar de la especificación Java EE 6, esta especificación dice qué funcionalidades deben ofrecer los servidores web que indiquen que tienen ese estándar. En este caso se comporta como cualquier otro estándar, sólo si cumples el estándar podrás decir que lo cumples. Gracias a este mecanismo, cualquier programa desarrollado usando esos estándares podrá cambiar de servidor web y seguirá funcionando igual. De hecho este aspecto ha sido uno de los que más ha caracterizado a Java. Hasta aquí, todo bien, el padre de Java no sólo era bueno y lo dejaba gratis, si no que además, había montado una organización para decidir «entre todos» cómo debía evolucionar la tecnología. Además, en vez de que cada uno pudiera hacer lo que quisiera, se definían unos estándares que todo el mundo que estuviese interesado, debía cumplir «completamente».

Sun abrió todavía más el JCP permitiendo implementaciones libres de los estándares

Pero como siempre, las cosas no se hacen de un día para otro y el organismo JCP también fue evolucianando poco a poco. Al principio, si alguien quería implementar un estándar y tener el sello oficial de que realmente lo implementaba (lo que posiblemente le haría ganar dinero) entonces tenía que pagar (a Sun Microsystem o a otros creadores del estándar). Hasta aquí suena todo era razonable, pero Apache, la fundación de software libre, presionó a Sun Microsystem para que los proyectos con licencias libres pudieran implementar los estándares sin tener que pagar. Después de mucho tira y afloja, Sun Microsystems cedió y gracias a eso, hay muchos proyectos con licencias libres que implementan estándares del JCP. Por ejemplo, Tomcat implementa el JSR 315 que define la especificación Servlets 3.0. De nuevo el mundo era bonito y Sun Microsystem era un padre bueno. Las empresas y sus productos privativos convivían en harmonía con las implementaciones libres de las fundaciones o las empresas. Precisamente todos ingredientes (que no están en la tecnología .NET Framework de MS) han hecho que Java sea muy popular. Una buena tecnología, una organización formada por los grandes de la industria y las fundaciones de software libre que deciden cómo la tecnología evoluciona y la libertad de implementar los estándares con licencia de código abierto.

Sun volvió a mostrar su lado oscuro

Pero las cosas se volvieron a oscurecer en Sun. El problema es que en aquella época el estándar Java SE 5 sólo estaba implementado por software privativo, gratuito y muy abierto (con licencias que permitían la innovación e investigación de forma explícita pero aun así, al fin y al cabo, software privativo). Es decir, el núcleo de Java, la máquina virtual de Java con las librerías y el compilador (técnicamente el Java Runtime Environment, JRE y el Java Development Kit, JDK) eran software privativo. Había una implementación libre llamada GCJ (GNU Compiler for Java), pero nunca llegó a ser razonablemente compatible con el estándar y por tanto nunca llegaría a llamarse Java ni ser una alternativa «razonable». Hasta que un día, en 2005, la fundación Apache decide ponerse manos a la obra e implementar una versión libre del estándar Java SE 5 conocida como Apache Harmony. Como es obvio, la licencia sería Apache (una licencia software libre muy permisiva), lo que implica que cualquiera podría usar y modificar el código a su antojo. Detrás de esta iniciativa estaban IBM, Intel y como en cualquier otro proyecto de software libre, cualquiera que quisiera ayudar. Pero empezaron los problemas cuando Sun Microsystem dijo que nunca certificaría a Apache Harmony como una versión compatible de Java SE 5. Es decir, se saltaría las normas del organismo de estandarización (JCP) que debería permitir las implementaciones libres de los estándares de forma gratuita. De hecho, Java SE 5 es un estándar como otro cualquiera, en concreto el JSR 176. Ante este problema, Apache escribió una carta abierta a Sun para que le permitiese implementar una versión libre de Java.

El problema, como siempre, era el dinero

El «dueño» de Java ya no era tan bueno como lo había sido hasta entonces. Pero, ¿por qué Sun Microsystems se negó a permitir una implementación libre de Java? Para comprender el motivo, hay que saber cómo ganaba dinero Sun con la tecnología Java. Sun licenciaba la tecnología Java (cobrando por ello) a grandes empresas como IBM, Oracle, HP, Apple para que ellos pudieran crear sus modificaciones/variaciones particulares de la máquina virtual de Java adaptándola a sus sistemas o incluyendo algún tipo de mejora particular. La versión de Java de IBM para Windows no era muy popular para el gran público aunque fuera gratuita, pero si se usaba en clientes empresariales. En el caso de Apple, hasta hace muy poco tiempo la única máquina virtual de Java que funcionaba en su sistema operativo Leopard, era su versión adaptada de Java licenciada a Sun Microsystems. Eso en los PCs de escritorio, pero en los teléfonos móviles la situación era mucho más ventajosa para Sun Microsystems, ya que los fabricantes de teléfonos móviles tenían que pagar por incluir la versión de Java para móviles en cada uno de los teléfonos. Es decir, Sun no quería aceptar una implementación libre de Java porque si lo hiciera, se le acabaría el negocio de la venta de licencias por su implementación de Java (ya que cualquiera podría utilizar la versión libre).

¿Por qué Sun liberó su implementación de Java?

No obstante, la implementación de Apache Harmony seguía su curso, Sun Microsystem se encontró en la tesitura de que una implementación de Java que pretendía ser una versión oficial de Java SE 5 se estaba desarrollando y estaba cerca de ser una alternativa real. Y ellos «sólo» ofrecían una versión gratuita (pero no libre) de su JRE. Y bueno, como se suele decir, les vieron las orejas al lobo y temían que la versión libre, aunque no tuviera la certificación oficial de ser compatible con Java, podría suponer un peligro para ellos porque la podrían empezar a utilizar los desarrolladores de software libre u otras empresas. Algunos consideran que por este motivo Sun se vio «presionada» a liberar su implementación de Java como software libre para «luchar» en cierta manera con la implementación alternativa.

Y ahora volvemos de nuevo a las cuestiones técnicas sobre cómo Sun liberó exactamente Java. Sun liberó con licencia GPL su implementación de Java para los PCs y servidores, liberó Java SE 6 como OpenJDK 6. Utilizó una licencia de tipo GPL con la excepción de classpath. Por resumir, esta licencia permite que un programa privativo escrito en Java pueda ejecutarse en OpenJDK 6. Además, esta licencia «obliga» a cualquiera que modifique y adapte el OpenJDK a hacer públicas tales modificaciones (o que pague dinero a Sun Microsystem por obtener otro tipo de licencia que no le obligue a hacerlo). Por tanto, con esta licencia, Apple seguiría pagando a Sun para adaptar Java a su sistema operativo sin tener que hacer públicas tales adaptaciones. Esto para los PCs y servidores, pero para el caso de los teléfonos móviles, la versión Java ME, la liberó con licencia GPL (sin la excepción). Esta liberación era bastante inservible para cualquier fabricante de teléfonos, porque si la usaban, tendrían que hacer software libre todo el software del teléfono (y por aquella época, ninguna empresa de teléfonos móviles estaría dispuesta a liberar el código de sus sistemas). Además, parece ser que ni se podrían ejecutar programas escritos en Java para móviles si estos eran privativos. Es decir… para los amantes del software libre la liberación de Java ME tenía sentido para el estudio del software en sí, pero desde un punto de vista práctico y empresarial, no supuso ningún cambio en el dinero que las empresas fabricantes de móviles pagaban a Sun Microsystems.

¿El equilibrio perfecto?

Llegados a este punto, parece que Sun Microsystems había llegado a un equilibrio con Java. Era un padre lo suficientemente «bueno» como para liberar su implementación de Java, pero se las había arreglado para que su negocio siguiese funcionando. Todos contentos, ¿no? Pues no todo el mundo estaba contento porque Sun se negaba a considerar como Java a Apache Harmony, una implementación que tuviera una licencia Apache. La licencia Apache pondría en peligro todo el sistema de ingresos de Sun con Java porque cualquier empresa podría adaptar Java a sus necesidades sin tener que hacer el resto del código público. Es decir, nadie querría pagar a Sun Microsystems si lo podían evitar.

Llegaron los problemas económicos a Sun

El gran problema de Sun Microsystems es que la empresa llevaba varios años con pérdidas. IBM, Oracle y otras muchas empresas han hecho mucho más dinero con Java que la propia Sun Microsystems. Además, a Sun no le iban bien las otras líneas de negocio. Así que Sun salió a la venta y en Abril de 2009 fue absorbida/comprada por Oracle. Esta empresa de bases de datos no se ha caracterizado nunca por ser precisamente defensora del software libre, así que los desarrolladores estaban bastante espectantes/preocupados sobre el nuevo futuro que le esperaba a Java en las manos de Oracle. Algunos desarrolladores anunciaron que esto sería el fin de Java, aunque nadie sabía lo que sucedería. Toda la comunidad estaba de acuerdo en que pasara lo que pasara con Oracle, ya había una implementación libre de Java y por tanto, siempre se podría continuar el desarrollo de la tecnología Java con una comunidad de software libre independiente de Oracle (técnicamente, hacer un fork). Pero no se sabía nada, todo el mundo estaba expectante. Además, como hubo tantos problemas legales con la compra, todo se retrasó mucho.

Las tecnologías de «alternativas» de Java

De forma paralela a la historia del Java «oficial», han existido proyectos «alternativos» y con licencias libres que giraban en torno a la tecnología Java:

• GNU Compiler for Java: El ya mencionado GCJ, una versión libre (aunque bastante incompleta) de la máquina virtual de Java con licencia GPL. Sun nunca puso ningún problema con esta implementación porque no la consideró nunca como una alternativa real. Aún sigue en desarrollo pero de forma poco activa.
• GNU Classpath: Una implementación con licencia GPL de la librería estándar de Java (se utiliza en conjunto con GCJ y otras máquinas virtuales). Sun tampoco puso nunca ningún problema con esta implementación. Se distribuye con licencia GPL con la excepción que permite usar la librería en programas privativos.
• JNode: Un sistema operativo completo implementado en Java y un micro kernel escrito en ensamblador. Más que nada un juguete para aprender, nada serio. Se distribuye con licencia LGPL.
• GWT: Una tecnología de desarrollo de aplicaciones web en Java que se basa en la transformación de código Java a JavaScript de forma que pueda ejecutarse en los navegadores web. Esta tecnología está desarrollada y respaldada por Google. Actualmente esta tecnología tiene bastante aceptación para el desarrollo aplicaciones web altamente interactivas. Su licencia es Apache.
• GAE para Java: Una tecnología de computación en la nube que permite el desarrollo de aplicaciones con Java que se pueden ejecutar en la infraestructura de Google. Esta tecnología también está desarrollada por Google. Las herramientas para el desarrollo de las aplicaciones se distribuyen con licencia Apache, aunque la infraestructura donde se ejecutan las aplicaciones no es pública.
• Apache Harmony: La única que ha pretendido ser una implementación del estándar Java SE 5. Es decir, la únique que pretendía ser una alternativa real a la implementación de escritorio de Java de Sun Microsystems.
• Android: Un sistema operativo para móviles basado en un kernel de Linux y una máquina virtual de Java adaptada. En esta plataforma las aplicaciones se desarrollan principalmente en Java. Esta licenciado preferiblemente con licencia Apache aunque hay algunas partes licenciadas con GPL. La implementación de Java está basada en Apache Harmony y una máquina virtual completamente reimplementada desde cero llamada Dalvik.

Una de las implementaciones «alternativas» amenaza con hacer sombra a la versión oficial

Como puede verse, ha habido muchas versiones «alternativas» de Java al margen de la versión oficial de Java. La mayoría de ellas han tenido poco impacto en el desarrollo de aplicaciones (GCJ, JNode..). En cambio, las «alternativas» promovidas por Google si son tecnologías relevantes para el desarrollo de aplicaciones. Y sobre todo, la tecnología más relevante de todas por su impacto en la industria es la plataforma Android (parece que acaba de superar a iPhone en número total de terminales vendidos). Además, se da la circunstancia de que la versión de Java para móviles (Java ME) está en un imparable declive. Es bastante probable que dentro de un par de años Java ME sea una tecnología irrelevante en los teléfonos móviles con la llegada de Android, iPhone y Windows Phone.

Empieza la guerra, Oracle quiera sacar dinero con Android

Así que con todos estos ingredientes, Oracle ha decidido sacar dinero a Google por Android. Si Oracle está viendo que cada vez va a ganar menos dinero con Java ME, y ya que es el «dueño» de Java, quiere sacar dinero de Android. Como he dicho al comienzo de este (interminable) post, a mucha gente este movimiento de Oracle le parecerá de lo más lógico. De hecho, hay gente que hace programas con las tecnologías de Microsoft y le gustan los Mac e iPhones de Apple. Pero hay otra mucha gente que considera que si Oracle ha ido a por Google por utilizar Java en Android, podría ir a por cualquiera que utilice Java un poco «fuera de lo normal». Y ahí es donde está realmente el problema. A partir de ahora, Oracle va a hacer lo que consiere oportuno con Java y por tanto Oracle va a decidir lo que considera «lo normal» en Java. Los que considerábamos que tener una implementación libre de Java (el OpenJDK) nos libraría del control de Oracle, nos habíamos equivocado porque Oracle ha demandado a Google, que ha desarrollado Android como software libre partiendo completamente de cero. Precisamente por eso esta demanda se considera como el posible principio del fin de Java, porque aunque se use una implementación de Java completamente libre (e incluso desarrollada de forma indepediente), Oracle siempre podrá demandarte igual que como lo acaba de hacer con Google.

Muchos consideran que si Java es de Oracle, puede hacer lo que quiera con esa tecnología. Sun se había labrado una razonablemente buena reputación entre los desarrolladores porque siempre ha sido un dueño bastante «bueno» de la tecnología. Siempre ha sido bastante abierto y muy razonable con la comunidad del software libre. Son simplemente formas de hacer y entender los negocios. Canonical hace dinero con Ubuntu, Microsoft también hace dinero con Windows, Appe hace dinero con iPhone y Google hace dinero con Android. Todas son empresas, todas sirven para ganar dinero, pero algunas hacen dinero de una forma y otras hacen dinero de otra. No hablamos de tecnología, hablamos de principios, de formas de entender cómo las empresas se relacionan con sus clientes.

Si Oracle ha hecho esto, con Google, ¿Qué otras cosas podría hacer con Java?

¿Y qué cosas podría hacer Oracle con Java? Pues realmente lo que quisiera. Podría empezar a cobrar dinero por usar la máquina virtual de Java. O quizás por utilizar una versión «avanzada» de la máquina virtual (dejando como gratuita una versión simplificada con menos prestaciones). Podría imponer algún tipo de restricción a las aplicaciones que se ejecutan sobre la máquina virtual (al estilo de la App Store del iPhone). Podría cerrar completamente el comité de estandarización (JCP) y hacer literalmente lo que le diera la gana con Java, haciendo evolucionar la tecnología según sus propios intereses en el mundo de las bases de datos. Incluso podría dejar morir la tecnología y no dedicar más recursos al desarrollo de Java. Todos pensábamos que daría igual que lo hiciera, porque siempre se podría continuar el desarrollo de Java por parte de la comunidad y las empresas interesadas partiendo de una implementación libre de Java. Pero eso es justamente lo que ha hecho Google con Android y le han demandado por hacerlo. Aquí está la clave… el «dueño» de Java ya no es «bueno»… cada vez es más malo.

¿Pero no es cierto que las licencias de software libre te dan protección ante estas cuestiones?

Quizás haya algunos lectores a los que no les cuadre mucho cómo es posible que una empresa te demande si tu haces una implementación desde cero y completamente libre de una tecnología. Para responder a esta cuestión necesitamos hablar de tecnicísmos y aclarar algunos conceptos. Google ha implementado un máquina virtual completamente nueva desde cero llamada Dalvik. Esta máquina virtual no ejecuta código Java compilado (bytecode), si no que ejecuta otro tipo de bytecode diseñado de forma independiente. Es decir, desde un punto de vista formal y legal, Android no es Java, es «parecido», pero realmente no es Java. De hecho, si nos fijamos en la documentación de Android, las apariciones de la palabra Java están cuidadosamente seleccionadas y nunca se dice que Android sea «Java». Entonces ¿cómo es posible que Oracle haya demandado a Google por Android? En realidad, Google utiliza Java como el lenguaje de programación, y luego transforma el código compilado de Java a código compilado de la máquina virtual de Android. Es decir, en Android no hay ni rastro de Java, los programas se programan en Java y luego se transforman para ser ejecutados en Android. Es una cosa parecida a GWT, que permite programar aplicaciones en Java y luego el código se transforma a JavaScript para poder ejecutarse en los navegadores web.

Entonces vuelve la pregunta de nuevo ¿Cómo es posible que Oracle haya demandado a Google por Android si no se usa Java? La demanda está divida en dos partes, la primera de ellas acusa a Google de infringir el copyright de Oracle simplemente por utilizar Java.Y bueno, ese es uno de los problemas, según Oracle, cualquiera que utilice su lenguaje de programación debería pagarles o atenerse a sus reglas. De nuevo repito que algunos desarrolladores lo considerarán lo más lógico, pero a otros que no les gustan ese tipo de imposiciones y controles de un único fabricante. Algunos desarrolladores considerarán que Oracle se comportará como Microsoft y precisamente huían de eso cuando empezaron a usar Java. Este problema de propiedad intelectual en Android ya se veía venir en cuanto Google anunció la plataforma. Este post de Noviembre del 2007 ya habla de ello. Pero como el propio CEO de Sun Microsystems, Jonathan Schwartz, felicitó a Google por Android, el miedo a cualquier problema legal se esfumó rápido. De hecho Google quiso llegar a acuerdos con Sun para utilizar Java ME en Android, pero no llegaron a un acuerdo. No era cuestión de dinero, era una cuestión de la forma en la que se licenciaría la plataforma, Google quería liberar Android de forma que cualquier fabricante la pudiera usar sin pagar un duro (lo que aumentaría sus posibilidades de éxito), pero Sun quería recibir dinero por licenciar esa tecnología.

Y por otro lado, y este es el más importante, Oracle ha puesto en la demanda que Google ha violado siete patentes software al construir la máquina virtual de Dalvik. Las patentes son:

Sin entrar mucho en detalle en las patentes concretas, basta con decir que cualquier máquina virtual de cualquier lenguaje que se implemente/desarolle ahora o en el futuro, virtualmente violaría alguna de estas patentes porque son cuestiones básicas de construcción de máquinas virtuales. Dicho de otra forma, Oracle posiblemente podría demandar a la fundación Mozilla por la máquina virtual TraceMonkey de JavaScript que implementa en Firefox o a cualquier otra empresa o fundación que hibiese implementado una máquina virtual.

¿Será Google el salvador de Java que todos habíamos estado esperando?

Google ya ha respondido a la demanda y como era de esperar echa más leña al fuego. En concreto Google ha dicho:

“Estamos decepcionados de que Oracle haya escogido atacar a Google y a la comunidad open-source de Java con esta demanda carente de base. La comunidad open-source de Java está por encima de cualquier compañía y trabaja cada día para hacer que Internet sea un lugar mejor. Defenderemos con todas nuestras armas los estándares open-source y seguiremos trabajando para desarrollar la plataforma Android.”

Parece que habrá guerra en torno a Java. Quizás este sea el final de Java si Oracle gana la demanda. O quizás sea el comienzo de un Java renovado si Google gana la demanda y demuestra judicialmente que puede hacer lo que ha hecho. Pero para eso todavía falta mucho mucho tiempo. Si se llega a acuerdos extra-judiciales, eso querrá decir que Google pagará dinero por Android y se habrán cumplido los peores augurios. El padre de Java ya no será tan bueno como lo había sido siempre y esta tecnología iría perdiendo el interés de forma paulatina. Pero si Google gana el juicio y demuestra que puede hacer lo que ha hecho, entonces todos los miedos se habrán disipado y posiblemente Google sea la empresa (junto con IBM, Intel y otras muchas) que comenzarán a tirar del carro de Java. Sólo el tiempo nos dirá a lo que conduce todo esto.

Espermos que Java salga reforzado con todo esto… o tendremos que decir adiós a nuestro viejo amigo.

Actualización: Si realmente te interesa el tema (si has llegado hasta aquí es porque te interesa) y quieres más detalles sobre quién podría ganar la demanda, he encontrado un post muy bueno (en perfecto inglés) de un empleado de Sun/Oracle. El creador de JRuby habla del tema de forma mucho más detallada que yo.

Por cierto, soy Micael Gallego, el co-director de Sidelab junto a Patxi. Es el primer post que escribo… y me ha salido bastante largo :). Espero que el próximo sea un poco más ligerito.