¿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).


Publicidad

Aviso: Los siguientes comentarios pertenecen a las personas que los han enviado.
El administrador de este sitio web no es responsable de los mismos.

[comentarios] Hay 3 comentarios:

Gravatar
16/05/2006 17:41:58
2.c
por JarFil (IP: 85.84.234.*)
Comentario de JarFil
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).
Gravatar
16/05/2006 17:43:22
A buenas horas
por r0sk (IP: 217.130.44.*)
Comentario de r0sk
¡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).
Gravatar
16/05/2006 17:49:58
Re: 2.c
por Juanjo (IP: 192.168.0.*)
Comentario de Juanjo
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.

! Esta entrada no permite nuevos comentarios.

Los comentarios se bloquean automáticamente tras 15 días desde la publicación del artículo.

Si deseas comentar algo relacionado con el texto, puedes enviarme un e-mail.