De BSD a GPL, tipos de licencias de software de código abierto

Aunque tendemos a hablar de conceptos como 'software libre' como un todo homogéneo, lo cierto es que sólo son etiquetas genéricas que se aplican a docenas de licencias de software diferentes, cada una con sus ventajas y restricciones particulares, basadas en filosofías, en ocasiones, contrapuestas. Estas diferencias, que podrían ser irrelevantes para el usuario de a pie, resultan sin embargo fundamentales para el programador que empieza a desarrollar su propio software libre y se plantea la pregunta de "¿Qué licencia escoger?". Para ello resulta fundamental conocer las principales opciones disponibles, así como las ventajas y desventajas de cada una de ellas.

No parece, por desgracia, que los desarrolladores estén muy concienciados sobre el papel y la importancia de las licencias de software: en diferentes momentos de 2013, tanto la compañía Black Duck Software como Aaron Williamson (abogado senior del Software Freedom Law Center) analizaron los proyectos alojados el principal repositorio de código fuente del mundo: GitHub. Y descubrieron que entre el 77% y el 85,1% de dichos proyectos carecían de cualquier clase de licencia de uso. Esa despreocupación por los aspectos legales del desarrollo de software puede ser el origen de toda clase de problemas tanto para el creador como para los usuarios de dicho código.

El principal criterio de diferenciación entre licencias de código abierto es su naturaleza 'copyleft' (a menudo denominada también 'viral'). Decimos que una obra de código abierto (es decir, que otorga permisos de uso, copia, modificación y redistribución de la obra protegida) es además 'copyleft' cuando contiene una cláusula que promueve que las copias y obras derivadas dispongan de una licencia equiparable a la original. De ahí que a las licencias copyleft de software se las denomine también en ocasiones 'virales', en el sentido de que optar por ellas 'infecta' todas las versiones posteriores y derivadas del software que licenciemos con ellas. Así, cabe dividir el catálogo entre licencias copyleft fuertes, licencias copyleft débiles y licencias permisivas.

Licencias copyleft 'fuertes': el ejemplo de la GPL

Richard Stallman, hoy día polémico gurú del software libre, ideó la 'GPL' (de ' GNU Public License'), una alternativa a las licencias comerciales de software que buscaba impedir por todos los medios que la labor realizada en pro de proyectos sujetos a esta licencia repercutiera en favor del software propietario.

De este modo, no es posible ni insertar fragmentos de código GPL en código propietario, ni tampoco permite al creador de un software licenciado como GPL relicenciarlo con otra licencia. Ni siquiera es legal compilar un código fuente vinculado a un biblioteca GPL si dicho código no se encuentra también bajo la misma licencia.

Sin embargo, su oposición a lo comercial se limita al propio software, por lo que la licencia GPL no pone ningún obstáculo a que un proveedor de esta clase de software tenga ánimo de lucro, siempre y cuando haga público el código libre y lo que se cobre sea el soporte técnico, la documentación o el medio de distribución.

La actual versión de la GPL es la 3.0. Su principal diferencia con respecto a la anterior son las nuevas clásulas que cubren ciertos agujeros legales o que otorgan protecciones contra las leyes de DRM.

Licencias copyleft 'débiles': el ejemplo de la LGPL

La LGPL es otra de las licencias ideadas por la Free Software Foundation de Stallman. Su nombre significa ' Lesser General Public License' (GPL reducida), si bien antes era acrónimo de ' Library General Public License ' (GPL para librerías).

Dotada de características muy similares a la anterior, la diferencia fundamental entre ambas radica en el hecho de que la que nos ocupa permite enlazar librerías LGPL a software sujeto a otras licencias (libres o no). Tal y como recoge el texto legal de la LGPL:

"Un programa que no contiene derivado de ninguna porción de la biblioteca, pero está diseñado para trabajar con la biblioteca al ser compilado o enlazado con ella se denomina un 'trabajo que usa la biblioteca'. Dicho trabajo, por separado, no es un trabajo derivado de la biblioteca, y por tanto cae fuera del ámbito de esta Licencia."

Tal como explica la web del proyecto GNU, la LGPL es tan sólo una concesión pragmática cuando la GPL resulta difícil de aplicar:

"Esta es la razón por la que usamos la LGPL para la biblioteca C de GNU. Después de todo, hay otras bibliotecas de C en abundancia, utilizando la GPL para la nuestra habría llevado a los programadores de software a utilizar otra".

Otras licencias, como la Mozilla Public License (MPL) o la Eclipe Public License (EPL)también entrarían en esta categoría.

Las licencias libres permisivas: BSD, MIT, Apache...

Lo que caracteriza a este grupo de licencias (también conocidas humorísticamente como 'copycenter', por situarse entre las copyleft y el copyright) es que son flexibles con respecto a la redistribución del código, de modo que permite publicar software tanto libre como propietario. Los defensores de estas licencias sostienen que esta característica maximiza la libertad de los desarrolladores a la hora de producir algún producto derivado, permitiéndoles elegir entre un amplio abanico de licencias.

Las diferencias entre todas ellas son bastante sutiles para los legos en derecho. Por ejemplo, la MIT y la BSD son casi equivalentes, con la diferencia de la adición de dos cláusulas en la segunda licencia.

En la BSD original, hoy en desuso, esta licencia rezaba lo siguiente:

"Todo material publicitado que mencione características o use este software debe mostrar la siguiente advertencia: 'Este producto contiene software desarrollado por la [ORGANIZACIÓN]'".

Además, tanto la BSD original como la BSD revisada añaden:

"Ni el nombre de la [ORGANIZACIÓN] ni los nombres de sus colaboradores deben usarse para apoyar o promocionar productos derivados de este software sin permiso previo por escrito explícito."

Por su parte, el proyecto GNU recomienda el uso de la licencia Apache 2.0 cuando "cuando el código fuente de un paquete de software tiene menos de 300 líneas" y "los beneficios que proporciona el copyleft no ameritan el esfuerzo".