Traducido para Rebelión por Ricardo García Pérez
La Fundación de Software Apache (ASF, Apache Software Foundation) está entre la espada y la pared. No puede certificar que su Java de código abierto, Harmony, es compatible con Java. Igual que hiciera Sun con anterioridad, Oracle no va a realizar las pruebas de certificación necesarias. Sin ellas, Apache no puede acreditar que Harmony es una aplicación de Java realmente para fines legales. Añadiendo insultos a la ofensa, IBM, que ha sido la empresa más importante que ha respaldado Harmony, abandonó el proyecto conjunto con Oracle de apoyo de la versión libre de desarrollo de Java, Open JDK.
¿Qué debe hacer una fundación de código abierto? Puede intentar obligar a Oracle a cooperar utilizando su plaza en el Comité Ejecutivo del Proceso Colectivo de Java (JCP, Java Community Process), el grupo que, en teoría, dirige Java para que vote contra la aprobación de Java 7 cuando finalmente se solicite. Por sí sola, Apache no puede detenerlo, pero está apelando a otros miembros del JCP para que también voten en contra con el fin de protestar por la negativa de Oracle a trabajar con Apache en la certificación de Harmony.
En una declaración, Apache ha expuesto su posición:
Damos las gracias por el apoyo firme recibido de la comunidad y creemos que significa una confirmación del trabajo de ASF está haciendo en el JCP. Nuestro esfuerzo por transformar el JCP en un ecosistema de especificación auténticamente abierto contribuye a reforzar el valor de Java para todo el mundo; para los impulsores de proyectos de código abierto como los de ASF y otros, para estudiantes, para educadores y universitarios que utilizan Java en la enseñanza y la investigación, para los distribuidores independientes de software que desarrollan productos y servicios innovadores en Java y para los usuarios comerciales de todos los ámbitos de actividad económica que dependen de Java para gestionar y hacer crecer sus empresas.
Mediante el JSPA, el acuerdo bajo el que tanto Oracle como la ASF participan en el JCP, la ASF tiene derecho a una licencia para el paquete de prueba de Java SE (el «TCK») que le permita probar y distribuir una versión del proyecto Apache Harmony bajo la licencia de Apache. Cuando Oracle ofrece solo una licencia TCK que impone cláusulas y condiciones adicionales incompatibles con el código abierto o las licencias de software libre, viola su obligación contractual tal como se expone en el reglamento del JCP. La ASF cree que toda iniciativa de especificación que no cumpla la normativa de JCP no debería participar como miembro de pleno derecho y, en consecuencia, hemos depositado nuestros votos en los de las JSR (Java Specification Requests), nuestro único agente de fuerza efectiva en el JCP. Hemos votado contra la puesta en marcha y el desarrollo de JSR por parte de Sun, y hemos dejado patente que por estos motivos votaremos contra el JSR para Java SE 7.
En vista de que Oracle Corporation no ha conseguido cumplir con sus responsabilidades como impulsora de especificaciones bajo el acuerdo del JSPA y ha incumplido las cláusulas firmadas con la ASF, que representan las condiciones bajo las cuales aceptamos participar en el JCP, apelamos al Comité Ejecutivo del JCP para que no deje de prestar su apoyo claro, firme y público a Java como ecosistema de especificación abierto que constituye un terreno de juego equilibrado para que los participantes garanticen que cualquiera (ya sea un individuo o una iniciativa comercial, universitaria o sin ánimo de lucro) pueda impulsar y distribuir especificaciones de Java bajo las condiciones que les parezcan más convenientes. En concreto, animamos a los demás miembros del Comité Ejecutivo del JCP a seguir apoyando nuestra posición frente a Oracle y a votar en consecuencia en la próxima consulta sobre Java SE 7.
La ASF dará por concluida su relación con el JCP si nuestros derechos como impulsores de las especificaciones de Java no son defendidas hasta sus máximos extremos por el Comité Ejecutivo del JCP. La ausencia de una defensa activa, contundente y firme de estos derechos comporta que los acuerdos del JSPA no tienen valor, lo que confirmaría que las especificaciones del JCP no son más que documentación propietaria.
Apache no soporta que Oracle continúe con la política de Sun de negarse a permitir que un programa de código abierto extranjero opere en el mismo terreno de juego igualitario que programas de código abierto «oficiales» de Oracle, como OpenJDK.
A mi juicio, de esta confrontación se desprenderán varias cosas. En primer lugar, no creo que Oracle vaya a parpadear. Aun cuando Apache consiga bloquear la aprobación de JCP de Java 7, eso no va a impedir que Oracle lo lance.
A partir de esto, veremos una bifurcación en Java. Por una parte, tendremos el Java de código abierto «oficial» y, por otra, estará Apache y sus aliados. Poco después, imagino que Oracle demandará a Apache, igual que Oracle ha demandado a Google por utilizar Dalvik en Android.
Al final, los tribunales tendrán que intervenir en la contienda. De todas formas, mientras tanto, a quienes nos importa el código abierto tendremos que tomar nuestra propia decisión: «¿Cuánto de abierto es en realidad un programa o lenguaje de código abierto si una empresa puede decidir si se puede autorizar o no?» Estaría de acuerdo con Apache en que un programa así en realidad no es de código abierto en absoluto, al margen de los accesible que pueda ser de hecho su código.
Fuente: http://blogs.computerworld.com/17334/its_not_apache_vs_oracle_its_oracle_vs_open_source