martes, 18 de octubre de 2016

Swing vs SWT respecto a la libertad del software

Fui advertido, en el sitio https://gna.org/, de las contraindicaciones a la libertad de software de las aplicaciones que dependieran de Swing, por medio de un mensaje dispuesto en los formularios de alta de nuevos proyectos.


Lo investigué.


Si bien no hay conflicto con crear software libre que depende en otro no libre (http://stackoverflow.com/questions/3111455/releasing-code-containing-java-swing-what-license), la respuesta no me satisfacía. Yo quería que fuera libre íntegramente, incluidas las dependencias. GNU había acusado a Java de ser una trampa a la libertad, sin embargo, esta acusación fue retirada (no sin dejar una advertencia de peligro latente) tras aparecer varias implementaciones libres de la plataforma: https://www.gnu.org/philosophy/java-trap.html.


La historia reconstruida por mí: Sun Microsystems no había liberado el código de Swing desde el principio, GNU trabajó (probablemente ambos en conjunto) para en el proyecto CLASSPATH (http://www.gnu.org/software/classpath/) para tener una implementación libre de las clases Java core (incluido Swing), luego el proyecto GCJ (GNU Compiler for Java, https://gcc.gnu.org/java/) absorbió al proyecto CLASSPATH, pero si bien el compilador evolucionó muy rápido, el mantenimiento de la librería Java es muy bajo comparado al del proyecto OpenJDK (http://openjdk.java.net/).


SWT, el framework de GUI de aplicaciones de escritorio, históricamente no atravesó tantos vaivenes y fue libre desde siempre (https://www.eclipse.org/swt/).