16 de Mayo, 2006

¿Java se acerca a las distribuciones de Linux?

Imagino que todo el mundo se ha tenido que pelear de alguna forma u otra para poder tener un JRE (Java Runtime Environment, una máquina virtual que permite correr aplicaciones Java) en casa desde GNU/Linux.

En mi caso siempre ha sido así: en la distribuciones con las que he trabajado no se podía instalar dicho paquete a golpe de apt-get, y una vez que tienes todo el software al alcance de la mano de una forma tan cómoda, tener que dar vueltas para conseguir algo porque no lo soporta tu distribuidor se hace muy complicado :P (ya sea descargándolo de la web de SUN, o buscando a alguien que hubiera empaquetado el tema sin atender a temas legales).

El problema estaba en la licencia con la que SUN distribuía los paquetes. Del FAQ de Debian sobre Java, un fragmento de la licencia de la plataforma Java 2 SE:

Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes.

Según leo en el blog de Eric Boutilier, SUN cambia de estrategia, vía un programa llamado DLJ (Operating System Distributor License for Java).

Es pronto para sacar conclusiones (alguien comentaba que puede haber pegas con el apartado c) del segundo punto, y a falta de un análisis mejor: no soy abogado), pero la verdad... ¡ya iba siendo hora!

Este es uno de los ejemplos más claros de cómo una empresa es capaz de perjudicar a su propia tecnología por mantenerse en una postura propietaria. A ver si es verdad que rectificar es de sabios.

Actualización: Simon Phipps, la fuente que ha empleado Boutilier (JDK on GNU/Linux: Something Wonderful), explica en los comentarios de su anotación que el punto 2.c hace referencia a que parte del paquete de SUN no se combine con otro producto, y no a que no se pueda distribuir otro paquete con funcionalidad similar en paralelo (como el GJC, por ejemplo).

Anotación por Juan J. Martínez, clasificada en: java.

Hay 3 comentarios

Gravatar

Tampoco soy abogado, pero me parece que el 2.c se refiere a distribuir el el software "para que" se ejecute junto a otro que sea parecido, por ejemplo junto a interfaces propietarias o modificadas que romperían la compatibilidad de la máquina virtual.

Espero no equivocarme, pero creo que no debería haber problemas para distribuir software alternativo con interfaces de java (ej: kaffe), siempre y cuando lo que sea llamado "java" siga manteniendo su identidad y no se mezcle con lo(s) otro(s).

por JarFil, en 2006-05-16 17:41:58

Gravatar

¡Ya era hora!, al final los señores de Sun se rinden ante la evidencia del S.L. ¿o no?, vete tu a saber el trasfondo de la cuestión.

Podrían tomar nota los señores de Adobe/Macromedia con sus tecnologías estúpidamente cerradas (IMHO).

por r0sk, en 2006-05-16 17:43:22

Gravatar

JarFil: Creo que tienes razón, he actualizado la anotación.

Es para que, por ejemplo, no cojan las clases de swing y las añadan al GNU/Classpath creando otro paquete diferente.

por Juanjo, en 2006-05-16 17:49:58

Los comentarios están cerrados: los comentarios se cierran automáticamente una vez pasados 30 días. Si quieres comentar algo acerca de la anotación, puedes hacerlo por e-mail.