La compatibilidad entre licencias y el relicenciamiento

por Richard Stallman

Si se quiere combinar dos programas libres en uno o introducir código de un programa en otro, surge la cuestión de si sus licencias permiten combinarlos o lo prohíben.[1]

No hay problema en combinar programas que tienen idéntica licencia si los términos de la misma son razonables, como lo son en casi todas las licencias libres.[2]

Pero, ¿qué sucede cuando las licencias son diferentes? En general, decimos que varias licencias son compatibles si es posible combinar código que se encuentra bajo esas diversas licencias, cumpliendo a la vez con todas ellas. Aunque no siempre, el resultado suele ser un programa cuyas partes están bajo varias licencias compatibles diferentes. Tal combinabilidad, o su imposibilidad, es una característica de un conjunto dado de licencias, y no depende del orden en que se mencionen. El conjunto de licencias determina también qué licencia debe utilizarse para el programa combinado.

Dividimos las licencias en tres tipos: laxas (también «permisivas» o «blandas»), intermedias y copyleft. Una licencia laxa no hace nada para evitar que el código se integre en un programa privativo. Una licencia copyleft lo prohíbe, pues exige que toda reutilización se produzca en programas que estén bajo la misma licencia. Una licencia intermedia pone ciertas condiciones para la adición de código privativo, pero no lo prohíbe.

En general, las licencias laxas y permisivas (BSD modificada, X11, Expat, Apache, Python, etc.) son compatibles entre sí. Esto es así porque no tienen requisitos con respecto a otro código que se añada al programa. Permiten incluso incluir el programa entero (quizá con cambios) en un producto de software privativo. Por eso las llamamos «licencias blandas», porque no pueden decir «no» cuando un usuario trata de negar libertad a otros usuarios.

En una combinación de programas con licencias laxas, cada parte está bajo la licencia que ya tenía. Cuando el código se combina de tal manera que las partes son indistinguibles, ese código unido deberá estar bajo todas las licencias de las partes combinadas. En cualquier caso, dado que todas las licencias son laxas, esto no provoca problemas prácticos, salvo que la lista de licencias será más larga.[3]

Del mismo modo, las licencias laxas son habitualmente compatibles con cualquier licencia copyleft. En el programa combinado, las partes que tenían licencias laxas siguen teniéndolas, y el programa combinado, en su conjunto, tiene licencia copyleft. Una licencia laxa, la Apache 2.0, tiene cláusulas sobre patentes que son incompatibles con la versión 2 de la GPL; como pienso que estas cláusulas son buenas, hice que la versión 3 de la GPL sea compatible con ellas.

La única excepción importante es la licencia BSD original, debido a la odiosa «cláusula publicitaria». Esta condición exigía una nota específica en todo anuncio de cualquier producto que contuviera cualquier código publicado bajo la licencia BSD original. Esto era, y es, incompatible con todas las licencias copyleft actuales. Era también un dolor de cabeza para cualquier distribución, que veía cómo se le acumulaban programas con requisitos publicitarios parecidos pero diferentes. Se llegaba al punto de que una distribución BSD exigía más de setenta notas diferentes.

Eliminé este problema casi por completo al convencer a un decano, Hal Varian, para que la Universidad de Berkeley publicara la «licencia BSD modificada» (sin la cláusula publicitaria) y volviera a publicar el código de la Berkeley System Distribution bajo ella. Hoy en día la licencia BSD original se utiliza poco (afortunadamente), pero debemos seguir teniendo cuidado de no hablar de «la licencia BSD».

En general, dos licencias copyleft son inevitablemente incompatibles a menos que tengan cláusulas explícitas de compatibilidad. Esto no se debe a un error en los detalles, es inherente a la idea de copyleft. La idea del copyleft es que las «Versiones modificadas y ampliadas deben estar bajo la misma licencia». Si la licencia A (del programa P) dice que las versiones ampliadas deben estar bajo la licencia A, y la licencia B (del programa Q) dice que las versiones ampliadas deben estar bajo la licencia B, entonces la disconformidad es irreconciliable; la licencia del programa combinado que contiene código de P más código de Q debería ser A y debería ser B.

Esta es la razón por la que la versión 2 de la GPL es incompatible con la versión 3; era inevitable. Del mismo modo, las condiciones de la licencia CC BY-SA 4.0 serían intrínsecamente incompatibles con las de la licencia CC BY-SA 3.0, y sus autores no podrían haberlo evitado.

Hay dos formas de evitar el problema de incompatibilidad causado por versiones diferentes de las licencias copyleft.

La FSF utiliza el método de pedir que los programas se publiquen bajo la «GPL de GNU versión N o cualquier versión posterior». De esta manera la licencia es compatible con la versión N y también con la versión N+1 (puesto que ofrece la versión N+1 como opción). Cuando se combina código bajo la «GPL 3 o posterior» con código bajo la «GPL 2 o posterior», la licencia de esa combinación es su intersección, es decir, la «GPL 3 o posterior».

Esperamos no tener que hacer nunca una GPL de GNU versión 4, pero nada es perfecto y no podemos dar por sentado que hayamos previsto todas las cuestiones. Al publicar código bajo la GPL versión 3 o posterior, se permite que ese código se actualice a la versión 4, en caso de que algún día la necesitemos.

El otro método consiste en hacer que cada versión de la licencia permita explícitamente la actualización a versiones posteriores. La Fundación Mozilla utiliza este método, como así también PHP. Creative Commons lo utiliza para la licencia CC BY-SA: la versión 4.0 (la versión actual) permite explícitamente a cualquier usuario actualizar las obras modificadas a versiones posteriores de CC BY-SA.

Solo las licencias de GNU ofrecen a los autores la opción de permitir o no la actualización a versiones futuras de la licencia. Cuando escribí la primera versión de la GPL de GNU, en 1989, consideré incluir una opción de actualización de la licencia similar a la que ahora se encuentra en las licencias CC, pero pensé que era más correcto dejar esa elección a los autores. De ese modo el autor podría publicar un programa bajo la «GPL 1 solo» o «GPL 1 o posterior».

Desde entonces me he venido cuestionando si tal decisión haya sido oportuna. Programas como Linux, que permite una sola versión de la GPL y rechaza actualizaciones de la licencia, provocan incompatiblidad en la práctica.[4] Si alguna vez publicamos una versión 4 de la GPL, quizá debamos incluir una cláusula de actualización que permita automáticamente el relicenciamiento a versiones posteriores, 5 y subsiguientes.

Algunas licencias copyleft se pueden combinar con otras del mismo tipo gracias a una cláusula explícita de relicenciamiento que permite poner el código bajo una licencia copyleft diferente. Por ejemplo, la licencia CeCILL da explícitamente permiso para relicenciar código bajo la GPL versión 2 o versiones posteriores. Si el programa P está bajo la licencia CeCILL y se quiere combinar ese programa con el programa Q que está bajo la GPL versión 3 o posterior, la licencia CeCILL dice que se puede hacer así y poner la combinación o código combinado bajo la GPL versión 3 o posterior.

El permiso explícito de relicenciamento no es lo mismo que la compatibilidad (aunque relicenciar un código puede hacerlo compatible con otro código) y no es simétrico. Por ejemplo, la licencia CeCILL da permiso explícito para relicenciar código a la GPL de GNU, pero la GPL de GNU no permite relicenciar a la CeCILL. Así, no se pueden combinar esos dos programas P y Q y distribuir la combinación bajo la licencia CeCILL; el uso del programa Q en esa combinación violaría la GPL. La única forma permitida de publicar ese programa combinado es bajo la versión (o versiones) apropiada(s) de la GPL.

De igual modo, la CC BY-SA 4.0 permite explícitamente relicenciar versiones modificadas a la versión 3 de la GPL, pero la versión 3 de la GPL no permite relicenciar a la CC BY-SA. Este problema nunca debería producirse con código informático; Creative Commons dice que sus licencias no están pensadas para código, y que la licencia que se debe utilizar para código es la GPL de GNU. Pero hay otros tipos de obras, como los diseños de hardware o los elementos visuales de los videojuegos, donde podría haber ocasión para combinar material publicado bajo la CC BY-SA con material publicado bajo la GPL. Esto puede hacerse en virtud del permiso explícito de relicenciamiento de la CC BY-SA.

Lamentablemente, la CC BY-SA 4.0 no permite relicenciar a versiones futuras de la GPL. Cuando el licenciador desea relicenciar a la GPL material que está bajo la CC BY-SA 4.0, lo que debe hacer es designarse a sí mismo como persona autorizada a señalar si las versiones futuras de la GPL están permitidas para ese material. Si algún dia existe una versión 4 de la GPL y Creative Commons decide permitir el relicenciamiento de la CC BY-SA a la versión 4 de la GPL, el licenciador, como persona autorizada, podrá conceder permiso retroactivamente para la utilización bajo la versión 4 de la GPL de ese material relicenciado. (Alternativamente, se puede pedir a los autores de ese material que otorguen permiso inmediatamente.)

La Licencia Pública General de GNU ordinaria y la Licencia Pública General Affero de GNU son dos licencias copyleft diferentes y son incompatibles por naturaleza. Por eso hemos dispuesto un tipo especial de compatibilidad explícita entre ellas: se permite incluir código fuente bajo la GPL de GNU versión 3 junto con otro código fuente bajo la GPL Affero de GNU en un único programa combinado. Esto está permitido porque ambas licencias así lo dicen explícitamente, y la consecuencia es que la AGPL se aplica al programa combinado. No obstante, no se puede simplemente relicenciar código de la GPL de GNU (con o sin «o posterior) a la GPL Affero de GNU, o viceversa; ninguna de las dos licencias lo permite. Adviértase también que la GPL Affero de GNU versión 3 no es una «versión posterior» de la GPL de GNU versión 2, puesto que la GPL Affero de GNU y la GPL de GNU son dos series de licencias diferentes.

La Licencia Pública General Reducida de GNU versión 3 es en realidad la Licencia Pública General de GNU versión 3 con algunos permisos adicionales. La GPL versión 3 (sección 7) dice que siempre se pueden revocar los permisos añadidos, y al hacerlo se obtiene ese mismo código bajo la GPL de GNU ordinaria versión 3. Si un programa permite su uso bajo la LGPL de GNU versión 3 o posterior, se puede relicenciar a la GPL versión 3 o posterior. Para toda futura versión N de la GPL (N > 3), haremos una versión N de la LGPL que consistirá en la GPL versión N más los permisos adicionales.

En cuanto a la GPL Reducida versión 2.1, esta permite explícitamente el relicenciamiento a la GPL versión 2 o posterior.

Licencias intermedias son aquellas que tienen requisitos sustanciales para la redistribución pero no son licencias copyleft. Ejemplos de tales licencias son la Eclipse Public License y la Mozilla Public License. Las licencias intermedias tienden a ser incompatibles con cualquier licencia copyleft, ya que sus requisitos no permiten que el programa combinado esté bajo una licencia copyleft. La Mozilla Public License permite relicenciar a la GPL de GNU, excepto cuando el código deniega explícitamente este permiso.

Por último, ¿qué sucede con las licencias duales?[5] Una licencia dual presenta una disyuntiva: significa que un mismo programa ofrece la posibilidad de elegir entre dos o más licencias diferentes. Por ejemplo, versiones antiguas de Perl llevaban una licencia dual: presentaban la disyuntiva entre la Artistic License y la Licencia Pública General de GNU. Esto significaba que cada usuario podía optar por una licencia o la otra para usar y distribuir Perl, o por ambas, como en la versión original de Perl. Una disyuntiva es compatible con un conjunto de licencias diferentes si alguna de las licencias presentes en la disyuntiva es compatible con ese conjunto.

Cuando elija una licencia para su código, elija la GPL de GNU versión 3 o posterior, o alguna licencia compatible con ella. Esta es la manera de hacer que su código sea combinable con casi todo el software libre. Elegir la GPL o la AGPL, versión 3 o posterior, también será lo óptimo para defender la libertad de todos los usuarios de todas las versiones de su código.

Cómo combinar código

En un conjunto de licencias se dice que estas son compatibles cuando es legal combinar o fusionar programas cada uno de los cuales está bajo una de esas licencias. ¿Cómo licenciar entonces el programa combinado?

Toda licencia de software libre dice que esta se debe conservar junto con el código que cubre. De modo que, en sentido estricto, la licencia del programa combinado incluye las licencias de todas sus partes. No obstante, a veces queremos una respuesta simple a la pregunta de cuál es la licencia del programa combinado. ¿A qué licencias tiene que prestar atención alguien que utiliza el programa combinado?

Para determinarlo hay que partir de una lista de todas las licencias pertinentes. Luego se puede borrar de la lista toda licencia que esté subsumida por otra de la lista.

Decimos que una licencia A subsume la licencia B cuando cumplir con la licencia A implica cumplir con la licencia B.

Por ejemplo, la GPL de GNU versión N y la GPL Affero de GNU versión N subsumen la GPL Reducida de GNU versión N, y todas y cada una de ellas subsumen la GPL Reducida de GNU versión 2.1.

Toda licencia de GNU, versión N, subsume la licencia Apache 2.0, siempre que N no sea menor de 3.

La GPL de GNU, versión N, subsume todas las versiones de la Mozilla Public License que son compatibles con ella.

La licencia Apache 2.0 subsume las licencias BSD, Expat, X11, ISC y CC-0. La licencia «BSD de 3 cláusulas» subsume la licencia «BSD de 2 cláusulas». Las licencias BSD subsumen las licencias Expat, X11 y ISC, y la CC0.

Esto no pretende ser una lista completa, pero si conocemos otros casos dignos de mención los añadiremos.

Cuando alguna licencia está subsumida, aún es necesario incluir una copia de ella en todas las distribuciones del programa combinado.

Notas

1. No se excluye que una particular combinación de programas pueda dar lugar a otras cuestiones legales, cuestiones que no están relacionadas con las licencias de los programas a combinar. Aquí nos ocupamos solo de las implicaciones de las propias licencias.

2. La principal licencia con términos que no son razonables y que realmente se utiliza es la licencia de TeX: si dos programas están licenciados de la misma forma que TeX, no hay manera legal de distribuir una versión combinada de ellos.

   La licencia de TeX permite la distribución de una versión modificada solo en forma de la versión original más un archivo con las diferencias. Si A y B están publicados por separado de esa manera y luego se combinan, distribuir el programa combinado como A más un archivo con las diferencias viola la licencia de B, mientras que distribuirlo como B más un archivo con las diferencias viola la licencia de A. Distribuirlo de cualquier otra manera viola ambas licencias.

   No es casualidad que TeX se publicara en 1982. Desde entonces nuestra comunidad ha aprendido a redactar licencias razonables.

3. Cuando la distribución se realiza en forma de código fuente, habitualmente es suficiente dejar las notas de licencia tal cual en el código fuente; los requisitos de notas de licencia adicionales aparecen normalmente solo en el caso de licencias laxas cuando se distribuyen los binarios sin el código fuente.

4. Además, la versión 2 de la GPL permite que archivos binarios se conviertan en privativos mediante un hardware que rechace todo lo que no sean binarios con una firma especial, y por otro lado no permite la distribución de binarios por torrent. Solucionamos estos y otros problemas en la versión 3, pero no podemos cambiar la versión 2.

5. Algunos emplean la expresión «licenciamiento dual» para referirse a la venta de excepciones, pero es una denominación errónea. Véase Venta de excepciones. Adviértase que si el programa para el cual se vende la licencia incluye algún código que no se encuentra en la edición libre, eso no es vender excepciones, es software privativo.