En aras de la claridad, ¡no diga «bajo la GPL 2 de GNU»!

por Richard Stallman

Cuando en 1989 escribí la Licencia Pública General de GNU (GNU GPL), sabía que podrían ser necesarios algunos cambios, algún día la FSF podría tener razones para publicar una nueva versión. De modo que llamé a la licencia «versión 1» y establecí un marco que permitiera a los usuarios actualizar los programas a versiones posteriores de la licencia.

No había una manera habitual de hacer esto con una licencia libre; hasta donde yo sé, nunca antes se había hecho. Los desarrolladores habían publicado una versión de un programa bajo una licencia diferente, y quizás habían hecho nuevas ediciones de antiguas versiones ofreciendo utilizarlas bajo una licencia diferente, pero nunca habían establecido una manera sistemática de ofrecer a los usuarios la oportunidad de utilizar una futura versión de la licencia para versiones ya publicadas de un programa.

Yo no sabía cómo responderían los desarrolladores a esta innovación, de modo que decidí dejar a cada uno de ellos la elección de autorizar o no futuras versiones. Esto significaba que los desarrolladores podrían publicar un programa bajo la GPL de GNU versión 1 solo, o bajo la versión 1 de la GPL o cualquier versión posterior. Los desarrolladores declaran su elección en el aviso de licencia que figura al principio de cada archivo fuente. Ese es el lugar que indica la GPL para declarar la decisión.

La Free Software Foundation instó a los desarrolladores a elegir «o cualquier versión posterior», pues eso significaba que los usuarios tendrían la libertad de utilizar el programa bajo la versión 1 de la GPL de GNU, o bajo la versión 2 (una vez existiera una versión 2), o bajo la versión 3 (una vez existiera una versión 3). Y tendrían la libertad de utilizarlo bajo la versión 4, si alguna vez hacemos una versión 4.

Desde entonces, la FSF ha publicado dos versiones de la GPL de GNU: la versión 2 en 1991 y la versión 3 en 2007. Cada versión ofrece a los desarrolladores la opción de insistir en esa licencia concreta solo, o permitir el uso bajo versiones futuras de la licencia. (La GPLv3 permite también la opción «por procuración» [«proxy»], en la que una página web específica posteriormente puede dar permiso para utilizar una determinada versión futura).

Al publicar un programa es vital permitir la actualización de la licencia, pues así se evita la incompatibilidad entre programas publicados bajo diferentes versiones de la GPL.

En ausencia de algún mecanismo de compatibilidad explícito, dos licencias diferentes con copyleft son casi inevitablemente incompatibles. Esto es así porque cada una de ellas exige que las versiones modificadas de un programa se publiquen necesariamente bajo esa misma licencia. En consecuencia, el código publicado bajo la «versión 2 solo» de la GPL no se puede combinar con código publicado bajo la «versión 3 solo».

El mecanismo para la compatibilidad entre diferentes versiones de la GPL consiste en publicar el programa bajo la «versión N o cualquier versión posterior». Un programa publicado bajo la «GPL-2.0 o posterior» se puede combinar con código bajo la «GPL-3.0 o posterior», ya que «3.0 o posterior» es un subconjunto de «2.0 o posterior».

Algunos desarrolladores piensan: «Ahora publicaré mi programa bajo la GPL de GNU versión 3 solo. Cuando vea la versión 4 de la GPL, si me gusta, relicenciaré el programa para permitir su uso bajo la versión 4». Eso funcionará si él es el único autor del programa, a condición de que siga vivo, en buen estado de salud, localizable y esté prestando atención en ese momento. Pero hoy en día el copyright tiene una duración disparatada; si no hay reformas importantes, el copyright de su código durará, en EE. UU., 70 años tras su muerte (y 100 años en México). ¿Habrá dispuesto lo necesario para que sus herederos consideren la cuestión de relicenciar su código a la versión 4 de la GPL cuando él ya no esté aquí para hacerlo?

Pero también mientras viva habrá problemas. ¿Qué sucederá si dentro de diez años publicamos la versión 4 de la GPL de GNU, y para entonces otros cincuenta desarrolladores han hecho aportaciones a su programa y han publicado el código añadido bajo la «GPL-3.0 solo», simplemente porque así lo hizo él? El desarrollador podría aprobar la GPL 4 para el programa que publicó inicialmente, pero costaría mucho trabajo contactar con los otros 50 desarrolladores y obtener su autorización para utilizar la GPL 4 en el código añadido.

La manera de evitar estos problemas es autorizar versiones futuras de la GPL en el aviso de licencia desde el principio. Tenga a bien poner en todo archivo fuente que no sea trivial un aviso de licencia en la forma indicada al final de la versión de la GPL que esté utilizando.

Dado que gestionamos la compatibilidad de las licencias de esta manera, cuando alguien dice que un programa está publicado «bajo la GPL de GNU versión 2», la licencia no queda totalmente clara: ¿está publicado bajo la «GPL-2.0 solo», o bajo la «GPL-2.0 o posterior»? ¿Se puede combinar el código con paquetes publicados bajo la «GPL-3.0 o posterior»?

Cuando sitios web como GitHub invitan a los desarrolladores a elegir la «GPL 3» o la «GPL 2», entre otras licencias, sin plantear la cuestión de las versiones futuras, se da lugar a que miles de desarrolladores publiquen su código bajo una licencia poco clara. Pedirles en cambio que elijan entre «solo» y «o posterior» ayudaría a dejar clara la licencia de su código. Esto ofrece también la oportunidad de explicar que esta última opción evita futuras incompatibilidades.

Indicadores breves de licencia tales como «GPL-2.0» o «GPL-3.0» provocarán también confusión. Las personas y organizaciones que desconocen la diferencia entre «2 solo» y «2 o posterior» tenderán a escribir «GPL 2.0» en los dos casos, sin darse cuenta de que hay que hacer una distinción.

Por tanto, cuando utilice indicadores de licencia SPDX, tenga a bien utilizar los siguientes:

• GPL-2.0-only o bien GPL-2.0-or-later
• GPL-3.0-only o bien GPL-3.0-or-later
• LGPL-2.0-only o bien LGPL-2.0-or-later
• LGPL-2.1-only o bien LGPL-2.1-or-later
• LGPL-3.0-only o bien LGPL-3.0-or-later
• AGPL-3.0-only o bien AGPL-3.0-or-later
• GFDL-1.3-only o bien GFDL-1.3-or-later

No utilice los antiguos indicadores de licencia, que son ambiguos y van a quedar obsoletos:

• GPL-2.0
• GPL-3.0
• LGPL-2.0
• LGPL-2.1
• LGPL-3.0
• AGPL-3.0
• GFDL-1.3.

En 1989 parecía necesario ofrecer a los desarrolladores la elección entre la versión de la GPL «1 solo» y la versión «1 o posterior», pero esto ha creado una complejidad innecesaria. Mientras tanto, varias licencias que ofrecen incondicionalmente a los usuarios la opción de actualizarlas a versiones posteriores han tenido una amplia aceptación. Entre ellas se encuentran la Licencia Pública de Mozilla y la Licencia Pública de Eclipse. Cada versión dice que el usuario es libre de utilizar la obra bajo versiones posteriores de la misma licencia, si las hubiera. La licencia copyleft Creative Commons CC BY-SA permite a los usuarios actualizar la versión de la licencia cuando modifiquen la obra.

Quizás debiéramos adoptar esa estrategia en futuras versiones de la GPL de GNU. Pero eso es algo que habrá que plantearse en el futuro.

Agradecemos a SPDX la decisión de cambiar los identificadores breves del conjunto de licencias de GNU para hacer explícita la elección entre «o posterior» y «solo». La próxima versión de la Lista SPDX de licencias utilizará los identificadores arriba recomendados. Los identificadores confusos, tales como «GPL-2.0», quedarán obsoletos. Instamos a todo el mundo a reemplazarlos por los nuevos identificadores inequívocos tan pronto como sea posible.

Al utilizar identificadores explícitos como «solo» o «cualquier versión posterior», haremos que la comunidad sea consciente de la diferencia y animaremos a los desarrolladores a manifestar con claridad sus decisiones.