En vista de lo controvertido del asunto, la gente de XFree86 han colgado un Faq sobre la nueva licencia. Lo podéis leer en el mismo enlace de "XFree86 licenses" y dice, al respecto de la incompatiblidad con GPL:
"The 1.1 license is not GPL-compatible. To avoid new issues with application programs that may be licensed under the GPL, the 1.1 licence is not being applied to client side libraries."
Es decir, zanja la cuestión explicando que la nueva licencia no se aplica en modo alguno a las bibliotecas del lado del cliente con lo que las aplicaciones, GPL o no, enlazadas con las X no se ven afectadas por la licencia. Era lo que dictaba el sentido común.
El problema estaba en que, desde el punto de vista de la GPL, enlazar sí es redistribuir el código de la libreria (todo código enlazado se considera "trabajo derivado" en los términos de esa licencia) y, por lo tanto, nuestras aplicaciones deben cumplir la licencia de lo que enlazan. Yo siempre pense que esa interpretación del "trabajo derivado" era exclusiva de GPL pero al parecer o es algo general, por ley, o es algo que quiere generalizar la FSF. La gente estaba entendiendo que la nueva licencia de XFree86 también tiene ese punto de vista sobre lo que es trabajo derivado (cosa que desmienten en su faq).
De todas formas, la GPL deja fuera de esa definición de biblioteca el runtime de compiladores y a las ambiguas "bibliotecas de sistema": la base sobre la que programar en un plataforma... De manera que, según tenga el día el programador, se puede considerar que las bibliotecas de Java son runtime igual que el Apache o las X de Solaris. Se puede programar con ellas y cumplir con la GPL simultaneamente, a pesar de que sus licencias sean incompatibles, pero notablemente en la FSF no parece que consideren que las XFree86 sean "bibliotecas de sistema" en Linux: el porqué en Solaris las X sí lo son y en Linux no, se me escapa.
|
