Copyright (c) 2002, Abraham Otero Quintana y Alvaro Sanchez-Mariscal. Este documento puede ser distribuido solo bajo los términos y condiciones de la licencia de Documentación de javaHispano v1.0 o posterior (la última versión se encuentra en /licencias/).
Introducción
Este trabajo analiza si se puede o no considerar que la plataforma Java sea libre. Este análisis no requiere sólo estudiar la parte software de la plataforma, fuente tradicional de las críticas a Java por su condición de "no libre", sino también la libertad de las especificaciones que definen la plataforma, y por lo tanto al software.
Mostraremos de qué partes consta la plataforma Java, y explicaremos el proceso mediante el cual se definen y mantienen las especificaciones que la guían, resaltando las principales causas de la falta de libertad, y proponiendo soluciones a éstas. Esto no siempre es simple, ya que no es fácil compatibilizar algunas ideas en las que se basa Java con las ideas en las que se basa el software libre. En el trabajo se proponen posibles soluciones a este problema, y se analiza la posición de Sun respecto a liberar completamente la plataforma.(1)
Introducción
Determinar la libertad de la plataforma no es sólo cuestión de analizar las licencias bajo las que se distribuye el conjunto de herramientas de desarrollo (jdk), y las librerías básicas, de Sun Microsystems, principal fuente de críticas de la comunidad de Software Libre (SL) hacia Java. En la plataforma Java, además de software, hay algo más importante: las especificaciones que debe cumplir el software, recogidas en una serie documentos pdf que describen todas y cada una de las tecnologías que componen la plataforma. Un análisis acerca de la libertad de la plataforma no puede olvidar estas especificaciones. Sin embargo, organizaciones como Free Software Foundation (FSF) [1], y Open Source Iniciative (OSI) [2] no proporcionan criterios para determinar si una especificación es o no libre. En este documento hemos analizado, con la filosofía del SL, el proceso de creación y mantenimiento de las especificaciones, concluyendo que no se pueden considerar completamente libres, y proponiendo las modificaciones que consideramos necesarias para que se puedan considerar libres.
En cuanto a la parte software de la plataforma, las ideas del movimiento del SL, acceder y modificar el código fuente del software sin restricciones, pueden entrar en conflicto con el principio básico de la plataforma Java: "escríbelo una vez y ejecútalo en cualquier sitio" (adaptación de "Write Once Run Anywhere", WORA). En el trabajo se proponen posibles soluciones para compatibilizar, en la medida de lo posible, estos objetivos parcialmente enfrentados.
Este trabajo se organiza del siguiente modo: en el primer apartado se exponen las partes de las que consta la plataforma Java, a continuación se explica cómo se define ésta; es decir, cómo se crean y mantienen las especificaciones que la guían. En el cuarto apartado analizamos la libertad de la plataforma, analizando por un lado la libertad de las especificaciones y por otro la libertad de las implementaciones de estas especificaciones. En el quinto apartado se analiza la posición de Sun Microsystems acerca de liberar o no Java. Finalmente se exponen las conclusiones a las que hemos llegado en este trabajo.
¿Qué es la plataforma Java?
Hill Venners en su libro [3] afirma que Java está formado por cuatro piezas completamente distintas: una especificación de un lenguaje de programación, una especificación de un formato binario, los bytecodes, una especificación de una máquina virtual, encargada de interpretar los bytecodes, y un conjunto de librerías estándar. Estos cuatro elementos definen, sin duda, el lenguaje de programación Java.
Sin embargo si Java ha alcanzado tanto éxito y difusión no es sólo gracias al lenguaje, sino también al resto de la plataforma, que integra múltiples tecnologías en su seno, tecnologías para el desarrollo de aplicaciones Web (Servlets y JSP ), de aplicaciones empresariales (EJB), de aplicaciones para telefonía móvil (MIDlets), tarjetas inteligentes (JavaCard)... y un inmenso sinfín de tecnologías que hicieron a Java único hasta hace tan sólo un par de años, cuando apareció .NET. El fin de este trabajo no es sólo analizar la libertad del lenguaje de programación, y/o del jdk distribuido por Sun, sino de toda la plataforma en su conjunto.
Por ello, para nuestros objetivos, es más correcto considerar que la plataforma Java está compuesta por un conjunto de especificaciones, que definen todas y cada una de las partes de la plataforma, y una serie de implementaciones de estas especificaciones. Sin duda, por ser la base sobre la cual se edifica el resto de la plataforma, las especificaciones del lenguaje, bytecode, máquina virtual, y de las librerías estándar juegan un papel protagonista, pero no son las únicas. Por ello, un análisis que pretenda determinar si se puede o no considerar libre la plataforma Java, no sólo debe analizar su parte software, sino también las especificaciones.
La definición de las especificaciones: el Java Community Process
El JCP, "Java Community Process" [4] es el organismo que dirige, mediante la creación de nuevas especificaciones y el mantenimiento de las ya existentes, la evolución plataforma Java. El JCP define su propio funcionamiento y las normas por las que se rige, normas que han ido evolucionando desde su creación en Diciembre de 1998. La versión actual del JCP, y la que se describe en este documento, es la 2.6 [6].
El JCP es administrado por el Program Management Office (PMO), organismo formado por asalariados de Sun Microsystems. Dos Comités Ejecutivos (CE) se encargan de aprobar las modificaciones y extensiones de la plataforma; uno encargado de las especificaciones relacionadas con J2EE y J2SE (ediciones empresarial y estándar, respectivamente, de la plataforma), y el otro de las relacionadas con J2ME (edición para pequeños dispositivos: teléfonos móviles, tarjetas inteligentes...). Cada uno de estos comités está compuesto por 16 miembros con derecho a voto, 5 elegidos mediante votación entre los miembros del JCP, votación en la que participan todos los miembros del JCP. 10 son propuestos por el PMO, siguiendo los criterios de "comunidad balanceada" y "representación regional" [5]. Estos miembros han de ser ratificados mediante votación pública. El miembro restante es un representante de Sun. En cada comité hay un segundo representante de Sun, que ejerce la labor de presidente, pero que no posee derecho a voto.
Convertirse en miembro del JCP es gratis para empresas licenciatarias de Sun (empresas que implementan especificaciones de la plataforma con ánimo de lucro y pagan por ello a Sun), y para personas que a título individual deseen formar parte del JCP. Las empresas no licenciatarias han de pagar 5000 $ por año. En el caso de organizaciones sin ánimo de lucro, e instituciones académicas, es un comité formado por un miembro de Sun, un miembro del mundo del SL, o del mundo educacional, y un miembro elegido democráticamente, quien decide si pueden formar parte del JCP gratis, o han de pagar 2000 $.
Figura 1: Diversas etapas por las que pasa un Java Specification Request.
Las incorporaciones de nuevas tecnologías a la plataforma Java se realizan a través del JCP, mediante un "Java Specification Request" [6] (JSR). Para crear un JSR se ha de explicar en un documento la necesidad de esa nueva tecnología, o de modificación de una tecnología ya existente, y cómo afectará este cambio al resto de la plataforma. Aunque no es necesario, también es recomendable proponer un grupo de expertos que se encargará de desarrollar el JSR, en caso de ser aceptado. Cualquiera, sea o no miembro del JCP, puede proponer nuevos JSR. Uno de los dos CE del JCP, según el nuevo JSR afecte a J2ME, o a J2SE/J2EE, analiza la propuesta y decide si acepta o no la creación del JSR. Esta decisión se realiza mediante una votación pública, donde el nuevo JSR debe obtener mayoría simple.
A continuación el grupo de expertos, normalmente liderados por quien propuso el nuevo JSR, trabaja sobre la especificación. Deberán completar el documento que define la nueva tecnología o modificación de una ya existente, una implementación de esta tecnología, denominada Implementación de Referencia (IR), para probar que la tecnología es factible, y un Test de Compatibilidad (TC), una batería de pruebas que permitan comprobar si una implementación cumple o no la especificación. Tanto la IR como el TC son desarrollados bajo la licencia que el grupo de expertos decida, incluida cualquier licencia libre.
En una primera fase el grupo de expertos se centra en la definir la tecnología. Los documentos sobre los que trabajan son accesibles a todo el mundo a través de Internet, y cualquiera puede opinar y enviar realimentación sobre ellos al grupo de expertos. Una vez que los expertos han llegado a un acuerdo en la especificación ésta ha de ser aprobada por el CE correspondiente, mediante votación pública en la que necesita una mayoría simple de los votos emitidos para aprobarse. Si es aprobada pasa a una tercera fase, donde es toda la comunidad la que revisa y comenta la especificación, mientras el grupo de expertos se centra en el desarrollo de la IR y el TC. Una vez que el grupo de expertos ha terminado su trabajo éste, nuevamente, ha de ser aprobado por el CE correspondiente mediante una votación pública. Finalmente se entra en una fase cíclica de mantenimiento de la tecnología, fase también abierta al público (ver Fig. 1).
Hay una serie de JSR en los que Sun tiene privilegios especiales y que se rigen por unas normas ligeramente diferentes: los "Umbrella Java Specification Request" (UJSR) [6]. Estos son los JSR que definen las tres ediciones de la plataforma: J2SE, J2EE, J2ME y los diversos perfiles de J2ME. Estos JSR "paraguas" protegen, entre otros, la especificación de la máquina virtual, el lenguaje, y el bytecode. Los cambios en estas especificaciones pueden afectar a la compatibilidad hacia atrás, o a la portabilidad, de las aplicaciones, por ello Sun justifica este trato especial. Cualquier nueva funcionalidad o tecnología que quiera incorporarse a cualquiera de las tres ediciones de la plataforma ha de hacerlo a través de un UJSR.
Para que un UJSR sea aprobado debe obtener al menos 5 votos positivos del CE correspondiente, y de los votos emitidos al menos dos tercios han de ser de aprobación. Además el representante de Sun puede vetar la nueva especificación, lo que se traduce en que Sun tiene la última palabra en lo que se refiere a la aprobación de los UJSR, y por lo tanto a cambios sobre J2SE, J2EE y J2ME.
No todos los JSR existentes actualmente se rigen por estas normas; como ya hemos comentado, el propio JCP es un JSR que evoluciona y por lo tanto sus normas cambian. En un principio no era tan abierto, no permitiendo, por ejemplo, la implementación de los TC e IR bajo licencias libres. Sun también tenía derechos de veto sobre más JSR, y las implementaciones de las especificaciones estaban obligadas a respetar las posibles patentes que hubiese en las especificaciones, obligación que ya no hay en la actualidad.
Algunos JSR todavía se guían por versiones anteriores del JCP, siendo el líder del grupo de expertos el que puede decidir si actualizar o no la versión del JCP. Es de esperar que según estos JSR saquen nuevas versiones de mantenimiento se vayan pasando a la última versión del JCP, más abierta y más respetuosa con el mundo del SL.
Finalmente, cualquiera puede implementar las especificaciones, y distribuir su implementación bajo la licencia que considere oportuno. No está obligado a pasar el TC, pero si desea hacerlo, y ha realizado la implementación con ánimo de lucro, ha de pagar a Sun por pasar el TC. Si la implementación ha sido realizada por una organización sin ánimo lucro, como suele ser el caso de los desarrollos libres, el mismo comité de tres personas que decide si las organizaciones sin ánimo de lucro pagan por pertenecer al JCP, decide si ha de pagar o no por pasar el TC. No pasar el TC no implica que una determinada implementación no cumpla especificación, sin embargo es una garantía para sus usuarios de que efectivamente la cumple.
Análisis de la libertad de la plataforma Java
La plataforma java se construye sobre las especificaciones, recogidas en documentos públicos, y acompañados de una IR y un TC. Normalmente determinar si algo es o no "software libre" sólo requiere estudiar si se puede o no, y bajo qué condiciones, acceder, modificar y redistribuir su código fuente. En el caso de la plataforma Java hemos de analizar además las especificaciones. Éstas son una clave fundamental en el éxito de la plataforma, ya que permiten la existencia de múltiples implementaciones de cada tecnología, libres y no libres, todas cumpliendo una misma interfaz. Esto evita estar ligado a un determinado producto: si encontramos otro mejor, o que se adapte más a nuestras necesidades, podemos cambiar el actual por el nuevo sin modificar una sola línea de código en nuestro desarrollo, siempre que ambos implementen correctamente las especificaciones, y la garantía de esto es que ambos hayan superado el TC.
Las especificaciones también son la base sobre la que se sustenta toda la filosofía de la plataforma, WORA. Sin la seguridad de que las máquinas virtuales de todas las plataformas implementan correctamente la misma especificación, y sin la seguridad de que el formato binario, el bytecode, generado por cualquier compilador, sigue unas mismas especificaciones, no tendríamos garantizado que un binario se podrá ejecutar en cualquier plataforma.
Por ello estudiar la libertad de la plataforma no implica sólo estudiar la libertad del software, sino también la libertad de sus especificaciones. Ni FSF, ni OSI han definido criterios para analizar la libertad de una especificación. Si bien los criterios con los que se analiza si un código es SL no son directamente aplicables a las especificaciones, sí podemos analizar su proceso de creación y mantenimiento con la filosofía que hay detrás del SL.
En cuanto a la parte software de la plataforma, entendemos que el análisis no debe incluir las implementaciones de terceros, las ajenas al JCP. Hacerlo sería como requerir que, para que un lenguaje de programación sea libre, todos los desarrollos que empleen ese lenguaje sean libres. No obstante nos alegramos de poder afirmar que en la plataforma Java hay implementaciones libres de prácticamente todas las especificaciones, así como multitud de herramientas libres para el desarrollo de software que se han convertido en estándares de facto en la comunidad (Ant, Struts, Hibernate, JUnit, Eclipse, NetBeans...). En este sentido los trabajos [7,8] son un buen repertorio de estas soluciones libres de la plataforma Java.
Libertad de las especificaciones
Los documentos que recogen las especificaciones son públicos, estando disponible en Internet en formato PDF. Cualquiera puede descargárselas e implementarlas si así lo desea; esto incluye la especificación de la máquina virtual y bytecode [9], y del lenguaje [10]. Cualquiera puede implementar estas especificaciones, o bien implementar modificaciones de ellas. En Internet hay abundantes proyectos en los que se han implementado, con fines didácticos o científicos, modificaciones de las especificaciones del lenguaje, bytecode y/o máquina virtual Java [11]. Basándose en esto, en algunos trabajos [7] se afirma que las especificaciones de la plataforma java son completamente libres.
Acceder a una especificación, y realizar sobre ella las modificaciones que uno quiera no es realmente importante para la plataforma Java, más allá de permitir realizar interesantes experimentos e investigación sobre ésta [11]. Lo realmente importante son las auténticas especificaciones, las que guían la plataforma ¿Son ellas realmente libres?. Siguiendo las ideas del SL esta libertad se traduciría en que cada uno pueda modificar e implementar esas especificaciones sin restricciones, cosa que es cierta y poco relevante para la libertad de la plataforma. Aplicando el sentido común, la libertad exige además que la comunidad Java pueda, en igualdad de condiciones, participar en los procesos de creación, definición, y mantenimiento de estas especificaciones.
Como hemos explicado, cualquiera, incluso sin vinculación con una organización, puede tanto proponer una nueva especificación como participar en la creación de ésta. Además cualquier miembro de la comunidad puede descargar y analizar el trabajo que realiza el grupo de expertos de cualquier especificación, y enviar realimentación sobre ella. En este sentido parece que el JCP es bastante libre.
Sin embargo el máximo órgano del JCP, el PMO, está compuesto por miembros de Sun. Cada uno de los dos CE del JCP tiene siempre a un representante de Sun, y 10 de sus miembros son propuestos por el PMO, si bien han de pasar una ratificación de la comunidad. Finalmente Sun puede vetar cualquier cambio sobre un UJSR. Sun justifica sus privilegios diciendo que éstos le permiten velar por la compatibilidad hacia atrás, y el carácter multiplataforma de Java.
Para ser realmente libre ¿No debería ser la propia comunidad la que decida si quiere o no seguir siendo compatible hacia atrás, o soportar todas las plataformas?. Con esto los autores no estamos diciendo que estemos en contra de estos dos principios, pilares básicos de la plataforma en los cuales, al igual que la inmensa mayoría de la comunidad, creemos y estamos dispuestos a luchar por ellos. Sin embargo no creemos que estos principios sirvan de excusa para permitir a Sun esos privilegios, por más que él haya sido el padre de Java y su protector. Sin igualdad no puede haber libertad plena, por ello el JCP, y por extensión las especificaciones Java, no podrán considerarse completamente libres mientras haya desigualdades en la capacidad de participación de los miembros de la comunidad para gestionar, y para participar en la definición de las especificaciones.
Por otro lado, si bien es cierto que por ser un organismo grande y complejo es necesario que haya dentro del JCP una serie de comités ejecutivos que velen por el correcto funcionamiento, e incluso de un órgano semejante al PMO, estos no deberían estar nunca en manos de una empresa (recordemos que el PMO está formado exclusivamente por personal de Sun). Las empresas tienen sus propios intereses, y no siempre son los más adecuados para la comunidad. Por ello el proceso de creación de las especificaciones no debe estar liderado por una empresa, sino por una organización sin ánimo de lucro, lo que nos garantizaría que el JCP velará por los intereses de la comunidad, sin privilegiar intereses particulares. En cuanto a los miembros de los CE deberían ser elegidos democráticamente por los miembros del JCP, pudiendo cualquier miembro del JCP optar a este puesto en igualdad de condiciones, cosa que no sucede ahora, ya que el PMO elige a 10 de los miembros, y al representante de SUN.
Libertad de las IR y TC
En la libertad de las IR se basan actualmente la mayor parte de las críticas realizadas por parte de la comunidad del SL en contra de la plataforma. Esto no deja de ser curioso para los autores, ya que desde nuestro punto de vista lo más importante de la plataforma son las especificaciones, y no sus implementaciones. Quizás el motivo de centrar esas críticas en las IR sea el desconocimiento, por parte de los críticos, acerca del funcionamiento de la plataforma, o quizás sea que los críticos no comparten la filosofía de la plataforma Java, WORA, por lo que no dan tanta importancia a las especificaciones y TC.
Actualmente el líder del JSR decide qué licencia emplea para la IR y TC, pudiendo ser una licencia libre si así lo desea. No cabe duda de que la comunidad se beneficiaría si todas las IR fuesen libres, ya que podrían ser empleadas como base para otras implementaciones de las especificaciones, y permitiría una evolución más rápida y eficaz de la plataforma.
La IR que más críticas por parte de la comunidad del SL ha generado es, sin duda, la IR de J2SE, el conjunto de herramientas de desarrollo de Sun, conocido como jdk. Este se distribuye bajo licencia Sun Community Source License (SCSL) [12]. Esta licencia no es libre; permite ver el código fuente del jdk, e incluso modificarlo, pero sólo bajo ciertas condiciones, las cuales, en esencia, fuerzan a que el producto modificado siga cumpliendo las especificaciones de la máquina virtual, bytecode y lenguaje Java. Su objetivo es evitar que la plataforma se fragmente por causa de implementaciones del compilador o máquina virtual no compatibles con las especificaciones. Sun afirma que esta licencia "toma las ventajas de los modelos de código abierto y propietarios, y elimina sus inconvenientes" [12], ya que permite acceder al código fuente libremente, con todos los beneficios que para la comunidad y para la propia plataforma conlleva, siempre que el acceso no atente contra el principio básico de WORA.
Sin embargo, una vez que un individuo ha accedido al código licenciado SCSL su licencia le impide participar en proyectos de código abierto, ya que el código que ha visto es propiedad intelectual de Sun, y no puede emplear en proyectos libres lo que en él ha aprendido. Además, si desea cobrar a sus usuarios por el trabajo que ha realizado, está obligado a pagar unas cuotas a Sun. Evidentemente una licencia así dista mucho de poder considerarse libre.
¿Es necesaria una licencia de este tipo para algunas IR, para proteger a la plataforma Java de la fragmentación?. Es una pregunta difícil de responder. Sun afirma que sí; sin ella algunas empresas podrían aprovecharse de su posición privilegiada en el mercado para imponer una versión de la máquina virtual devaluada, o no compatible con las demás. Microsoft en su día desarrolló una versión de la máquina virtual y herramientas de desarrollo que permitían acceder a ciertos servicios de Windows, lo que permitía desarrollar aplicaciones que sólo funcionasen en Windows [13]. Si la plataforma Java hubiese sido completamente abierta nada hubiese podido detener a Microsoft. Hoy en día la plataforma estaría fragmentada; más de la mitad de los desarrolladores Java lo hacen bajo Windows, y probablemente buena parte de ellos emplearían las herramientas de Microsoft. Según Sun, SCSL vela para que esto no suceda.
Sin embargo, Microsoft, u otra gran empresa, tienen recursos suficientes para implementar la máquina virtual desde cero, sin necesidad de basarse en ningún código, con lo que esta licencia pierde bastante sentido. Si estas empresas lo desean pueden partir de las especificaciones del lenguaje y máquina virtual [9, 10] e implementar su propia variante de Java sin basarse en ningún código.
Danese Cooper, responsable de "Open Source Programs Office" de Sun, ha tenido múltiples entrevistas con los representantes del Software libre. A ambas partes les resulta evidente que la compatibilidad obligatoria (WORA), y SL no pueden coexistir. Compatibilidad opcional y SL sí podrían existir. Esto es obvio, si entendemos por SL lo que se recoge en [14].
La comunidad de SL acepta en su seno, e incluso promueve y aconseja [15], una serie de licencias que en cierto modo limitan la libertad del usuario del software, a costa de evitar que ese usuario pueda contravenir en algún modo las ideas de los promotores del SL. Son las licencias con "copyleft", encabezadas por la GNU GPL, la licencia recomendada por Free Software Foundation para el SL. Esta licencia obliga a que todo proyecto que emplee código GPL se rija también por la licencia GPL. Los autores de este trabajo creemos que la auténtica libertad debe nacer de la libre elección, y no de la imposición, en ese sentido preferimos licencias tipo Apache, o BSD y no la licencia GPL, licencia que "obliga a ser libre". Esto no quiere decir que no comprendamos el porqué de la licencia GPL, ni que no nos parezca una licencia adecuada; es un arma que el mundo del SL ha creado para defender sus principios.
¿Aceptaría el mundo del Software libre que la comunidad Java defendiese sus principios del mismo modo?, es decir, se podría considerar libre una licencia que permitiese acceder al código fuente de una IR, sin ningún tipo de restricciones, y modificarlo, siempre que la modificación supere el TC correspondiente. Esta licencia permitiría acceder con total libertad al código fuente, mientras que ese acceso no amenace los principios de la plataforma Java, del mismo modo que una licencia GPL permite acceder con total libertad al código fuente que la posee, siempre que el acceso no amenace los principios del SL.
Otra alternativa, que indudablemente el mundo del SL vería con buenos ojos, sería liberar todas las IR con licencias aceptadas como libres, y confiar en la propia comunidad Java para que ésta siga las especificaciones desarrolladas en el JCP, especificaciones creadas con el consenso de la mayoría de la comunidad. Danese Cooper cree que llegará el día en que la comunidad Java sea la que defienda la plataforma contra cualquier posible intento de fragmentación, y que entonces se podrán liberar todas las IR con licencias libres.
Los autores de este documento tenemos otra opinión, compartida por James Gosling [16]: creemos que ese día ya ha llegado. Vemos muy improbable que la plataforma Java pueda sufrir una fragmentación, ya que la mayoría de la comunidad no apoyaría esa iniciativa. Buena prueba del nulo interés en fraccionar la plataforma por parte de la comunidad Java son las múltiples implementaciones libres que de J2SE, y otras muchas tecnologías de la plataforma, existentes en la comunidad [7], todas ellas adhiriéndose a las especificaciones.
Sin embargo Sun no lo ve así, y consideramos improbable que actualmente esté dispuesto a liberar las IR que de él dependen (entre ellas el polémico jdk) bajo alguna licencia actualmente aceptada como libres por Open Source Iniciative y/o Free Software Foundation. En este sentido quizás la hipotética licencia que en este documento hemos definido fuese un buen punto de encuentro entre las posiciones de Sun y las del SL, o cuanto menos, un paso más de la plataforma Java hacia la libertad completa.
En líneas generales los razonamientos aplicados a la IR son extensibles al TC, si bien disponer de su código fuente no tiene más interés que el puramente investigador o académico. La libertad respecto a los TC, además de involucrar su código fuente, debería tener en cuenta también las tasas que hay que pagar para pasarlos. Actualmente las empresas han de pagar, y bastante, para pasar estos test, mientras que las organizaciones sin ánimo de lucro no. Si bien lo ideal sería que los test fuesen gratis para todo el mundo, un organismo como el JCP, en manos de una hipotética organización sin ánimo de lucro, requiere fondos para su subsistencia. El cobro de tasas, a las empresas que vayan a obtener beneficios de sus implementaciones de las especificaciones, por pasar el TC nos parece una fuente de ingresos adecuada.
Opinión de Sun Microsystems
La opinión de Sun Microsystems sobre la libertad de la plataforma, como organización, es que ciertas partes de la plataforma no deben de ser completamente libres para evitar la fragmentación, y la licencia SCSL y los UJSR son el arma ideal para evitarlo. No se prevé que a corto plazo Sun vaya a cambiar la licencia, por ejemplo, del jdk. Comentaremos, a modo de anécdota, que cuando escribimos este trabajo J2SE 1.5 se encuentra en desarrollo, el JSR que lo está definiendo es el 176, liderado por Sun. La versión del JCP que emplea es la 2.1, una versión de JCP que no permite implementar con licencia libre la IR y TC. Desconocemos si su líder tiene intenciones de actualizar la versión del JCP a la 2.6.
Internamente la posición de Sun dista de ser unánime; James Gosling reconoce que el tema de si Java debiera o no ser libre es un debate continuo [16]. Hay quien opina como Danese Cooper, principal responsable de la relación de Sun con el mundo del SL, quien cree que llegará el día en el que Java pueda ser libre y la propia comunidad, y no Sun, vigile por su compatibilidad y portabilidad. James Gosling, el padre de Java, opina que hace más de un año que llegó el día del que habla Danese Cooper [16]. Sin embargo las declaraciones de Jonathan Schwartz, vicepresidente ejecutivo de Sun, dan a entender que Java nunca debería ser libre [17]. Como vemos ambas posturas cuentan con partidarios de peso dentro de Sun.
Analizando los hechos, y no las palabras, Sun ha mostrado a lo largo de los años que el motivo de las restricciones que hay en la plataforma es hacer frente a la fragmentación, como sucedió en el caso de Microsoft, y no poner trabas al desarrollo de SL en la plataforma Java. Durante mucho tiempo Apache violó las normas del JCP, pudiendo haber sido demandado por Sun. Lejos de ocurrir esto Apache mantenía una excelente relación con Sun, quien le apoyaba y financiaba en sus desarrollos libres, y todos los problemas se zanjaron modificando el JCP para legalizar las actividades (desarrollo de IR y TC bajo licencias libres) que Apache llevaba tiempo realizando, pero que en ningún modo suponían un riesgo para la fragmentación de la plataforma.
Por otro lado, si bien Sun posee privilegios en el JCP, no hay ninguna evidencia de que los haya empleado con otro fin que no fuese proteger la compatibilidad y portabilidad de la plataforma. También es evidente que Sun empuja cada vez más la plataforma Java hacia la liberación: cada nueva versión del JCP "libera" un poco más la plataforma, siendo un paso más hacia la libertad plena.
Conclusiones
Es evidente que actualmente no se puede decir que la plataforma Java sea libre. Aunque la mayor parte de las críticas realizadas desde fuera de la plataforma en este sentido se dirigen hacia las licencias de las IR, en especial a IR del JSR que define J2SE, nosotros identificamos como más grave la falta de libertad plena en la creación y mantenimiento de las especificaciones de la plataforma. La rescisión de los privilegios de Sun, así como la gestión del JCP por una organización sin ánimo de lucro, evitando así que posibles intereses particulares de una empresa puedan llevar el JCP por el camino que no conviene a la mayor parte de la comunidad, son condiciones necesarias para lograr la libertad de la plataforma.
En cuanto a las IR y TC, la comunidad se beneficiaría si se pudiese acceder al código fuente de éstas, para basar en ese código sus propias implementaciones de la especificación, así como para poder participar activamente en el avance y corrección de bugs de las IR. Es poco probable que esto supusiese un riesgo de fragmentación en la plataforma: las implementaciones libres que la comunidad Java ha realizado hasta la fecha tratan de adherirse a las especificaciones, lo cual muestra un nulo interés de la comunidad del SL por fragmentar la plataforma. Por otro lado el protagonista del único intento de fragmentación en la historia de la plataforma, Microsoft, actualmente apuesta por una tecnología similar a Java, pero paralela, .NET, y es poco probable que en estas condiciones retomase Java y volviese a intentar fragmentar la plataforma.
Una forma de evitar el riesgo de fragmentación, sería proteger estas IR con una licencia que permitiese el libre acceso y la modificación del código fuente siempre que el nuevo software pasase el TC correspondiente. No tenemos claro si la comunidad del SL aceptaría esta licencia como libre, licencia que protege la filosofía de Java, WORA, del mismo modo que la licencia GPL protege la de esta comunidad. Esta licencia sería más fácilmente aceptada por Sun que cualquier licencia considerada como libre por la comunidad de SL, y aún cuando esta licencia no fuese aceptada como libre, siempre sería un paso más hacia la libertad plena.
En cuanto a Sun, hemos de reconocer que a pesar de ser el principal responsable de que Java no sea libre, hasta la fecha ha mostrado un buen criterio en la aplicación de sus privilegios, lo que hace que asociaciones como Apache, Blackdown, Kaffe, o javaHispano, asociaciones con una notable afinidad por el SL, defiendan y trabajen por la plataforma Java. Sin embargo esto no excluye que deseemos seguir caminando hacia la libertad total de la plataforma, y que esperemos que la opinión de gente como James Gosling se acabe imponiendo a la de Jonathan Schwartz, y Sun libere completamente la plataforma.
Notas
(1) Este trabajo se publicó originalmente en las actas dela Conferencia Internacional de Software Libre (páginas 126-131), celebrada en Málaga, España, del 18 al 20 de Marzo del 2004.
Abraham Otero Quintana Abraham Otero está realizando un doctorado en Ciencias de la Computación e Inteligencia Artificial en la Universidad de Santiago de Compostela y pertenece a la junta directiva de javaHispano.
Alvaro Sanchez-Mariscal Álvaro Sánchez-Mariscal es arquitecto de software experto en tecnología J2EE. Ha trabajado como analista para consultoras como Accenture, IT Deusto o IBM Business Consulting Services, para clientes del sector banca, consumo, industria y farmacéutico. Actualmente trabaja en Planet Media como consultor de servicios profesionales y preventa.
Cualquiera que esté más o menos informado de lo que se cuece en el mundo Java habrá notado la pujante popularidad de Hibernate.
Lo cual no deja de ser un poco chocante teniendo en cuenta que existe un estándar JCP de persistencia transparente como es el JDO, que aunque pretende ser agnóstico respecto al tipo de base de datos, realmente su aceptación está en el terreno de los mapeadores objeto-relacional, contando con unas cinco implementaciones Open Source y un buen número de implementaciones comerciales.
¿ Se debe a sus propios méritos?
¿ es que la comunidad suele preferir "estándares" de facto totalmente libres ?
¿ es que Hibernate es superior tecnológicamente a las implementaciones libres o comerciales JDO ?
Según se lee en Computer Business Review, los accionistas minoritarios de Symbian podrýan ejercer sus opciones sobre las acciones que van a ser vendidas por Psion Plc. De esta manera conseguirýan detener el control de Nokia, controlando un 63,3% de la comparáýa.
Desde que Nokia anuncrió sus intenciones de comprar el 31,1% de Psion por más de 250 millones de dýlares, han aparecido rumores sobre el descontento de los accionistas minoritarios.
La ýnica declaracrión pýblica en este sentido vino por parte del responsable de la divisrión de móviles de Siemens, quien dijo la semana pasada que "el control del 60% por parte de Nokia es algo que no nos gusta mucho."
El resto de accionistas de Symbian son Ericsson (17.5%), Panasonic (7.9%), Samsung (5%), Siemens (4.8%), y Sony Ericsson (1.5%).
miércoles, febrero 25, 2004 at 7:36AM 