¿El principio del fin de Java?

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.

34 thoughts on “¿El principio del fin de Java?

  1. Adrián Santalla

    Hola Micael,

    gracias por toda la información que nos has dejado escrita en este post. Es increíble el poder que tiene el dinero y cómo las empresas juegan con las licencias y las leyes.

    Espero que Java siga su curso como hasta ahora. Es importante, porque Java está en todos los lados y, como tú has comentado, puede ejectuarse en casi cualquier hardware sin tener que generar binarios específicos, y esto es una de las características (para mi) más relevantes de este lenguaje.

    Un saludo.

  2. Leo

    Andale!!! Pero que pasaria si Oracle gana la batalla?
    Lo peor que nos puede pasar es abandonar java aunque nos duela y buscar otras alternativas. Pero cuales ?
    Como dicen cuando un vaso de cristal se raja ya no es el mismo vaso, y usar las alternativas GNU Compiler for Java, ClassPath, etc creo que ya no sera lo mismo, precisamente por la amenaza de demanda de Oracle.
    Que alternativa tomar ?

    • micaelgallego

      El problema no es la implementación concreta de Java que se use, el problema es que todo tiene pinta de que no podremos usar el lenguaje Java como querámos, sólo lo podremos usar como Oracle nos permita. Y es precisamente ese control el que muchos programadores no quieren. Así que si Oracle gana la batalla, tendremos que empezar a usar otro lenguaje y otra librería de programación y otra máquina virtual.

      Pero la alternativa concreta a usar no se sabe todavía. Cada programador no puede elegir una tecnología concreta en la que apoyarse… así que serán los grandes de la industria como Google, IBM, RedHat, etc… los que nos tienen que marcar el camino.

  3. josempelaez

    Micael, quiero agradecerte la información que compartes y plantearte una duda que me ha quedado.

    No he sido capaz de ver el fundamento legal del riesgo que apuntas para los desarrolladores partidarios del software libre que trabajan con el OpenJDK. ¿No les protege la licencia GPL otorgada por los anteriores propietarios de las patentes que Oracle esgrime ahora contra Google?

    • micaelgallego

      Gracias a ti por haberte leído este “ladrillo” 🙂

      En el tema de las patentes software, las cosas no parecen estar tan claras como apuntas. En principio se podría pensar lo que tu dices, que Sun, cuando liberó el OpenJDK como GPLv2 ya estaba “licenciando las patentes” para aquellos que usen ese software. Pero algunos desarrolladores y juristas no lo tienen tan claro. Precisamente ese fue uno de los motivos por los que se creó la GPLv3. En ésta página de Richard Stallmand, en la que indica por qué hay que pasarse a la GPLv3, dice lo siguiente:

      GPLv3 also provides users with explicit patent protection from the program’s contributors and redistributors. With GPLv2, users rely on an implicit patent license to make sure that the company which provided them a copy won’t sue them, or the people they redistribute copies to, for patent infringement.

      The explicit patent license in GPLv3 does not go as far as we might have liked. Ideally, we would make everyone who redistributes GPL-covered code give up all software patents, along with everyone who does not redistribute GPL-covered code, because there should be no software patents. Software patents are a vicious and absurd system that puts all software developers in danger of being sued by companies they have never heard of, as well as by all the megacorporations in the field. Large programs typically combine thousands of ideas, so it is no surprise if they implement ideas covered by hundreds of patents. Megacorporations collect thousands of patents, and use those patents to bully smaller developers. Patents already obstruct free software development.

      The only way to make software development safe is to abolish software patents, and we aim to achieve this some day. But we cannot do this through a software license. Any program, free or not, can be killed by a software patent in the hands of an unrelated party, and the program’s license cannot prevent that. Only court decisions or changes in patent law can make software development safe from patents. If we tried to do this with GPLv3, it would fail.

      Una de las claves está en la primera frase, que traduzco aquí: “GPLv3 también proporciona protección explícita frente a las patentes a los usuarios desde los que contribuyen al programa o a los que le redistribuyen. Con la GPLv2, los usuarios se basan en una licencia de patentes implícita para asegurarse de que la compañía que les proporciona una copia no les demandará […] por infracción de patentes.

      Quizás tengas razón en que si Google hubiese usado OpenJDK para hacer Android Oracle no le podría haber demandado. Pero no creo que hubiese sido así de sencillo. Por que si lo hubiese sido, lo habrían hecho. Google habría usado OpenJDK para hacer una versión de la JVM adaptada a Android. No hubiese tenido que liberar el resto del código de Android, solamente esa JVM adaptada. Hay que recordar que Google no tiene ningún problema en liberar partes de su código (de hecho Android es completamente software libre). El kernel de linux incluido en Android es GPL, así que nada habría impedido a Google hacer la máquina virtual de Java también GPL. Quizás no la usó en su día porque no aún no estaba liberado el OpenJDK, o quizás no lo hizo porque pensó que basándose en Apache Harmony iba a tener menos problemas legales.

      Pero como dice Richard Stallman, parece que todos los problemas vienen de las patentes de software, y sólo si las invalidan, el mundo del software libre estará libre de una demanda por violación de patentes. Por ponerte algunos ejemplos, Google ha liberado WebM, un codec de vídeo. Apple ya ha dicho que es bastante probable que viole patentes del MPEG (pero todavía no lo han demandado). Microsoft ha dicho en muchas ocasiones que Linux viola patentes suyas (pero no ha demandado a nadie).

      Espero haberte aclarado (o no) por qué creo que la liberación con GPLv2 no te protege completamente frente a una demanda por violación de patentes.

      • josempelaez

        Gracias, Micael. Tu cita de Stallman me aclara el riesgo que señalabas para los desarrolladores de OSS. No obstante, opino que Richard se excede en su apreciación sobre la imperativa necesidad de explicitar la protección frente a las patentes de software.

        Mi cuestión no iba por el lado de la demanda a Google, donde creo la situación es distinta por la viralidad de la licencia GPLv2 de Java ME, que no gusta a las operadoras/OEM en que Google iba a apoyarse.

  4. Luis

    Creo que omites algo, supongo que no intencionadamente. Dices “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.”, pero no mencionas que la implementación libre de Java (OpenJDK) es GPL, mientras que Android esta licenciado con Apache, si Android fuese GPL, no habría ningún problema. Es como decir que Stallman es muy malo porque no me permite coger el GCC, modificarlo, y distribuirlo con una licencia privativa.

    • micaelgallego

      Creo que la respuesta a josempelaez también sirve para responder tu comentario. Si Android fuese GPL habría pasado exactamente lo mismo que teniendo una licencia Apache. Quizás algo habrían cambiado las cosas si Dalvik (la máquina virtual de Android) hubiese sido un derivado del OpenJDK y se hubiese licenciado con GPL. Pero si eso hubiese protegido completamente a Google frente a esta demanda, lo habrían hecho. De hecho, en Android hay partes GPL (el kernel de linux) y supongo que no les habría importado nada haber incluido un OpenJDK modificado con licencia GPL.

      • Luis

        Google tiene otros motivos bien claros para no utilizar OpenJDK, y es precisamente el caracter viral de la licencia GPL, que obligaría a que todas las aplicaciones que corriesen sobre Android fuesen también GPL, cosa que no pasa con la licencia Apache, con la que se puede desarrollar software propietario a partir de sofware libre. El kernel de Linux es GPL, pero no es viral en el sentido de que las posibles aplicaciones que corran sobre Android, no enlazan código librerias del kernel, lo que hacen son llamadas al sistema.

      • micaelgallego

        Luis, creo que te equivocas. OpenJDK se ha liberado con GPLv2 con la excepción de classpath. Eso permite que cualquier programa se pueda ejecutar en el OpenJDK independientemente de la licencia que tenga (privativa, Apache, BSD, GPLv3, etc). De hecho, actualmente esto ocurre en muchos escenarios. Por ejemplo, cuando Tomcat (con licencia Apache) se ejecuta sobre OpenJDK (con licencia GPLv2 con la excepción de classpath).

        En el caso de Java ME, la cosa fue diferente, Sun liberó Java ME con la licencia GPLv2 sin la excepción de classpath. Este “pequeño” detalle ha impedido que los fabricantes de móviles puedan usar esta versión liberada y tengan que pagar a Sun/Oracle por usar Java ME en sus teléfonos.

        No obstante, las cuestiones que estamos debatiendo, no afectan a lo que supone para el mundo Java la demanda de Oracle a Google. Si todos consideráramos que una demanda como esa es lícita, entonces no habríamos visto con buenos ojos que Apache comenzara el proyecto Apache Harmony. Tampoco habríamos visto con buenos ojos que GNU desarrollara GCJ y GNU Classpath. Pero en aquellos momentos a todos nos pareció bueno que se implementaran versiones open-source de Java (aunque no fueran 100% compatibles).

        Espero haber aclarado un poco las cosas… aunque obviamente, puedo seguir estándo equivocado 🙂

  5. Juanjo

    Yo creo que no tiene nada que ver con el lenguaje, y no afectará a Java en absoluto.

    La demanda de Oracle viene por patentes y, según tengo entendido, apuntan a ciertos aspectos de la implementación de la MV de Java en su edición mobile.

    Google ha intentado saltarse algunas de las patentes, y no sé si la demanda prosperará, pero como dicen tanto por ahí con este tema: no soy abogado.

    Se bromeaba también que el mayor beneficio que ha conseguido Sun nunca con Java vino de la demanda a Microsoft, y que Oracle solo intenta repetir el caso de éxito 😉

    ¿Java en peligo? No creo (aunque no programo “voluntariamente” en Java, y como sysadm mira que me gusta poco).

    • micaelgallego

      Cuando hablo de Java no me refiero al lenguaje de programación, me refiero a la tecnología Java y al ecosistema que se ha creado alrededor de esa tecnología. Java seguirá siendo un lenguaje de programación y una tecnología para el desarrollo de aplicaciones. Como he indicado en el post, Java no morirá porque a Oracle (su dueño) no le interesa que eso suceda. Simplemente digo que si Oracle gana esta demanda a Google y finalmente Google tiene que pagar, habrá mucha gente que dejará de usar Java y buscará otras alternativas. Por qué? Porque Oracle habrá demandado a una empresa que distribuye una versión libre de (algo parecido a) Java. Y bueno, hay personas a las que no les gusta utilizar una tecnología que esté controlada sólo por una empresa. Pero obviamente hay otra mucha gente (muchas otras empresas) a las que esto les parece de los más normal, y por eso sus servidores son Windows, y programan en .NET Framework.

      Es decir, no estamos hablando de una cuestión técnica. Java no morirá nunca. Estamos hablando de tendencias, de tecnologías populares, de comunidades de desarrolladores y de ecosistemas. Quizás después de 15 años ya sea el momento de empezar la nueva gran tecnología del futuro.

  6. isacc

    hola Micael¡¡¡

    Te felicito primeramente por dar a conocer este interesante tema a quienes de una u otra manera estamos involuctados en este facinante tema de la programacion y en las TI(tecnología Informática) en general.

    No se nada del tema pero por cultura general siempre me interezado por conocer, en vista de mi ignorancia, de lo que logro entender. Si Oracle es ahora dueño de Java y como explicas claramente por la demanda hacia Google, esto afectará todo su entorno (ecosistema). Entonces mi pregunta es: ¿Esto a la larga afectaría tambien a la tecnología AJAX?. Digo, por lo de JavaScript, porque al parecer tambien estaria dentro del ecosistema de Java. ¿o me equivoco?

    • micaelgallego

      Hola Isacc, la tecnología JavaScript no tiene nada que ver con la tecnología Java. Netscape (creador de JavaScript) decidió llamar de esta forma al lenguaje basado en ECMAScript por una cuestión de marketing, aprovechando la popularidad de Java. Es decir, la cuestión planteada en el post no afectará de ninguna forma a la tecnología AJAX o JavaScript.

  7. isacc

    Gracias Micael, nuevamente por tu oportuna y bien fundada respuesta, esto me saca mas de mi ignorancia. Seguire urgando en el internet aprendiendo de los embrollos de los gigantes tecnologicos y de la incipiente manera de convivencia para quienes la “paz” y el equilibrio del ecosistema informático son los billones de dolares. Eso me recuerda que aun estoy vivo. Por asi decirlo.

  8. Landerox

    Felicicades por este post tan completo, entradas como estas se echan de menos en la blogosfera, además se no ta que sabes bien de lo que hablas, es genial, aunque una lástima que sea un post un poco dramático.

    Personalmente me encantaba la actitud de Sun en general, y la cantidad de productos inovadores a los que contribuyó, siempre al lado de la comunidad open-source, proyectos como JAVA, VirtualBox, OpenOffice, OpenSolaris, MySQL, Postgre, JINI, OSGi, etc.

    Esperemos que Oracle pierda todos los juicios que tenga, y que Google no le dé tregua.

    Saludos!

  9. Jorge Alberto Huape Alcaraz

    Hola Micael,

    Muchas gracias por toda la información que nos has expuesto. Soy estudiante del último semestre de la carrera de Lic. en Sistemas Computacionales. En mi universidad (UABC) y en concreto, en mi carrera, nos hemos apoyado de la tecnología Java para la mayoría de las asignaturas que tienen que ver con la programación. Es interesante y muy apreciable el esfuerzo que has hecho por compilar toda la información y tu conocimiento sobre este tema. Veo que ya hace un año de este post. Si fuera posible, o ya lo has hecho, el actualizar o escribir un post con información actualizada respecto a este tema, te estaría muy agradecido. Actualmente me he visto muy interesado en este caso de Oracle y tomando notas de como una empresa con tintes anti-open-source refuerza a la comunidad.

    De nuevo muchas gracias.
    Saludos.

    • micaelgallego

      De nada Jorge.

      No he actualizado el post porque la verdad es que no hay mucho que actualizar. El juicio sigue su curso y todavía no se sabe el desenlace. Ha habido algunos movimientos. Por ejemplo Oracle ya ha dicho que le gustaría ganar para retirar la demanda: unos suculentos beneficios por la publicidad. También ha habido algún movimiento respecto a Java y Oracle y es que IBM se ha unido a Oracle para potenciar el desarrollo del OpenJDK en detrimento de Harmony, la implementación de Java libre de la comunidad Apache.

      En resumidas cuentas, los lios siguen pero todavía no se sabe si Oracle ganará, si ganará Google o si llegarán a un acuerdo económico antes de que la sangre llegue al rio.

  10. Roberto

    Sin duda el titulo debió ser “El fin de Java bueno” o “El fin de Java libre”………muy interesante e informativo.
    Sin duda apoyo a Google, esperemos que Oracle no gane la demanda, por que los perjudicados al final son los usuarios que tendrían que pagar mas por una alternativa libre de calidad.

  11. Erwin

    Apache Software Foundation publicó la retirada del proyecto Apache Harmony el 16 de noviembre del 2011. Es decir “adiós open java”.

  12. Anonimo

    Hola, ya estamos en el 2012 y por ahi en un post lei que google le habria ofrecido a oracle 3 millones de dolares por daños y perjuicios, sera que oracle esta ganando la demanda y google trata de perder lo minimo?

    Podrias actualizarnos como es que va o a que tiende el futuro de los desarrolladores de Java con respecto a la demanda de oracle a google.

    Gracias

  13. David Vargas

    Junio del 2012, seguimos teniendo Android y va en aumento su popularidad, yo me estoy iniciando en el desarrollo de aplicaciones para Android y en verdad se me hace una tecnología que promete mucho, el post muy bueno en verdad, ahora comprendo por que en los manuales de Android poco se hace referencia al término Java gracias micaelgallego.

  14. Fernando

    Estimado micaelgallego estamos Mayo del 2013, podrías por favor indicarnos como va el juicio y si ya finalizó cuales son los escenarios futuros posibles.
    Agradezco por anticipado tu tiempo.

  15. Adan

    Amigo creo conveniente, (en la medida de tus posibilidades) nos actualizes el post sobre el futuro de JAVA. Como sabras GOOGLE ha ganado la batalla legal, como lo comentas en tu post el uso basico de las librerias de JAVA (Para la maquina virtual DALVIK) ha generado un parteaguas para el futuro uso de los lenguajes, compiladores, maquinas virtuales y entornos de programacion basados en “JAVA” (por asi decirlo), estamos ante un mundo completamente OPEN SOURCE. Sera..?

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s