052.2 Lección 1

Richard Stallman, entonces desarrollador del renombrado MIT, fundó el Proyecto GNU en 1983 para desarrollar lo que él consideraba un sistema operativo “libre”. Pronto quedó claro que el código desarrollado por el proyecto tenía que estar protegido legalmente para que no pudiera simplemente ser asumido por proveedores comerciales y así convertirse en “no libre”.

Por lo tanto, Stallman fundó la Free Software Foundation (FSF) sin fines de lucro en 1985, que resume su misión en su sitio web de la siguiente manera: “La Free Software Foundation está trabajando para asegurar la libertad de los usuarios de computadoras promoviendo el desarrollo y el uso de software libre (como en libertad) software y documentación…​”

Un instrumento clave para esta misión es una licencia que respete la ley aplicable (especialmente la ley de derechos de autor) por un lado y que implemente sus propias ideas de libertad de manera legalmente limpia, por el otro. El resultado fue la primera versión de la Licencia Pública General GNU (GPLv1) en 1989. Esta licencia y numerosos artículos, como “¿Qué es el software libre?”, escrito por Stallman en 1992, dejan en claro las motivaciones y valores de desarrolladores de software libre, que ahora también se ven a sí mismos como un “movimiento”.

El núcleo programático sigue formado por las “cuatro libertades esenciales” formuladas por Stallman en el citado artículo, cuya numeración comienza con 0:

A diferencia de las licencias para productos comerciales, que imponen restricciones de uso en primer plano, el software libre implica la máxima libertad para usuarios y desarrolladores.

El preámbulo de GNU GPLv1 lo resume de la siguiente manera:

Esto significa que todos tienen derecho a usar, distribuir y modificar software bajo la GPL sin restricciones (lo cual es posible porque el código fuente es accesible, es decir, “abierto”) y, a su vez, distribuir las modificaciones. Incluso es posible cobrar dinero por transmitir el software:

Pero si las libertades son de tan amplio alcance, ¿hasta qué punto está protegido el software bajo esta licencia ejemplo, contra su incorporación a productos propietarios?

Esta es la función del principio copyleft mencionado anteriormente, que la GPL ya aplica en la versión 1 aunque el término aún no aparezca explícitamente:

Esto significa que todas estas libertades están vinculadas a la condición de que los usuarios las preserven en todo lo que hacen con el software.

Por lo tanto, el copyleft no sólo garantiza libertades, sino que también exige que todos los usuarios concedan estas libertades a otros. Esto se logra estipulando que el software bajo una licencia copyleft (como la primera GPLv1) puede modificarse y redistribuirse sólo si las cambios se publican en las mismas condiciones, es decir, bajo la misma licencia.

Por lo tanto, el ideal del software libre, es decir, el uso colectivo y el desarrollo posterior del software, tiene prioridad sobre las necesidades personales que los individuos puedan tener en relación con el software. El principio de reciprocidad es crucial: quienes utilizan las libertades también deben otorgarlas. Por lo tanto, las licencias copyleft a menudo se denominan recíprocas.

Este enfoque completamente nuevo de una licencia de software ya demostró ser legalmente sólido y practicable en la versión 1 de la GPL, por lo que la GPL sólo ha pasado por dos revisiones importantes en los casi 40 años durante los cuales se ha desarrollado el mercado moderno de TI.

Con la creciente disponibilidad y velocidad de Internet, están surgiendo cada vez más servicios en los que el software simplemente se instala en los servidores del proveedor, — el Application Service Provider (ASP) --, y cuyos clientes interactúan con los servicios a través de Internet. La tendencia ha ganado el nombre de Software como servicio (SaaS).

En tales casos, la GPLv2 no proporcionó ninguna claridad sobre si el código fuente (posiblemente modificado por el proveedor) debería estar disponible y cómo. La versión 3 de la GPL cierra esta laguna jurídica (loophole), conocida como la laguna ASP, al hacer referencia explícita en la sección 13 a otra licencia emitida por la FSF en 2007: la Licencia pública general GNU Affero versión 3 (GNU AGPLv3). El nombre se remonta a la empresa Affero, que desarrolló y publicó las dos primeras versiones de esta licencia.

Esta AGPLv3 corresponde básicamente a la GPLv3, pero regula explícitamente el problema ASP en el apartado “interacción de red remota”. Además, ambas licencias establecen explícitamente que se pueden combinar entre sí sin restricciones.

En resumen, GNU AGPL es un suplemento complementario de la GPL. La AGPL amplía el alcance de la GPL aplicando el copyleft al software que ya no se utiliza en instalaciones locales, sino exclusivamente en forma de servicios transmitidos a través de redes.

El desarrollo de software libre prospera basándose en el trabajo conjunto, es decir, integrando, modificando y compartiendo el código fuente de otros. Si todas las partes de un software modificado o recién compilado están bajo la misma licencia copyleft, como: GPLv3, esto no tendrá ningún problema legal. Ya que la licencia simplemente requiere que el resultado se distribuya bajo la misma licencia.

Las cosas se vuelven más complicadas cuando el software consta de partes que tienen licencias diferentes. Aquí es necesario tener en cuenta varios factores.

A veces el software libre se crea en condiciones muy diferentes. Los cambios van desde simples correcciones de errores hasta proyectos complejos con millones de líneas de código. Independientemente del alcance, se hace una distinción básica entre dos tipos de trabajos cuando se trata de licencias: derivadas y combinadas.

Supongamos, que al proyecto de software A le falta una determinada funcionalidad. En lugar de desarrollar esta funcionalidad desde cero, tiene sentido combinar el código de otro, por ejmeplo el proyecto B, que ofrece exactamente esta funcionalidad. El software de B ni siquiera tendría que cambiarse para esto, sino que simplemente podría agregarse a A. Por tanto, se trata, de una obra combinada. Si tanto A como B están bajo la misma licencia copyleft, no hay problemas para el trabajo combinado.

Si A y B están bajo diferentes licencias copyleft, se requiere precaución: ¿la combinación de A y B ya es un trabajo separado? Y, en caso afirmativo, ¿bajo qué licencia se puede o se debe licenciar? ¿O se puede evitar un conflicto asegurando que ambas partes A y B permanezcan separadas con sus respectivas licencias y no constituyan una obra nueva?

Se vuelve aún más difícil con trabajos derivados, es decir, cuando el proyecto A puede hacer uso de la funcionalidad de B, sólo incorporando su código directamente en el de A. Esta integración crea un nuevo trabajo derivado cuyas partes ya no se pueden separar.

El copyleft entra en juego para una obra derivada. Por ejemplo, A está bajo una licencia copyleft como la GPLv3, el nuevo trabajo derivado también debe estar bajo la GPLv3 de acuerdo con el principio de reciprocidad. Pero ¿qué pasa si B tiene una licencia diferente? ¿Es una licencia copyleft y es compatible con GPLv3? O, si se trata de un tipo diferente de licencia, ¿B también puede publicarse bajo una licencia diferente, es decir, volver a obtener la licencia? ¿O las licencias de A y B son categóricamente excluyentes entre sí?

El objetivo de esta lección no es enumerar las posibles combinaciones y posibles soluciones. Lo importante es ilustrar la complejidad del problema resultante de la combinación de cuestiones muy diferentes.

Técnicamente, lo primero que hay que aclarar es cómo funcionan juntas las diferentes partes del software (en nuestro caso A y B): ¿Se pueden separar entre sí o hay procesos cuya ejecución ya no se puede asignar claramente a una parte o a la otra?

Desde un punto de vista jurídico, surgen dudas sobre la relación entre las licencias de A y B. ¿Son compatibles entre sí, o sólo en partes o sólo en una dirección? ¿Volver a obtener la licencia es una opción?

Aquí sólo podemos insinuar la complejidad de estas cuestiones. Estas decisiones requieren sólidos conocimientos jurídicos. Por lo tanto, las decisiones sobre licencias para obras nuevas, pero especialmente para obras combinadas y derivadas, deben tomarse pronto, cuidadosamente y siempre después de un asesoramiento legal detallado.

El copyleft ha demostrado en las últimas décadas ser extremadamente robusto, especialmente en las versiones 2 y 3 de la GPL. Sin embargo, las exigencias técnicas han llevado a la FSF a reaccionar adaptando sus licencias. La Licencia Pública General GNU Affero es un ejemplo de ello. Discutimos otros ejemplos en las siguientes subsecciones.