GPL para el software como servicio
19 diciembre 2008
Hace unos días publicaban en reddit una noticia titulada Does SaaS render GPL ineffective? SaaS son las siglas de Software as a Service, software como servicio. La pregunta que se hacen es ¿hace el software como servicio inefectiva la licencia GPL? Pongamos un poco de perspectiva.
El software libre
Richard Stallman creó la Free Software Foundation porque entendía que era un abuso que le limitaran el acceso al código del software. De esta forma, puso en marcha el proyecto GNU para hacer un sistema operativo Unix libre, y lanza la licencia GPL que establece la libertad de copia, modificación y distribución del software. Era una época en la que el reino de Microsoft y el concepto de ordenador personal se extendía. En los 90, la filosofía del software libre comienza a popularizarse gracias a Linux y las posibilidades de colaboración que brinda Internet.
El software como servicio
En los 80 y 90, el concepto de ordenador personal tenía toda la vigencia. Pero actualmente un ordenador sin conexión a la Red es tan útil como un teléfono móvil sin cobertura. Con la penetración de la Red en la población, la banda ancha y el empuje de Google, cada vez instalamos menos programas y usamos más servicios web. Gmail para el correo y chat, Google Docs para documentos, hojas de cálculo, Twitter para el microblogging...
Llegados a este punto, la FSF se replantea la licencia GPL para responder al reto de que el software ya no se ejecute en el ordenador, como un programa tradicional, sino en servidores (web) remotos. La respuesta es la Affero GPL, una licencia que entre otras cosas, obliga a hacer público el código fuente del web. Es una apuesta interesante, pero ¿afronta la AGPL los principales retos del software como servicio? En opinión de algunos, no.
La disponibilidad del código de un web no es el principal problema. Con software libre, si escribo un documento con un programa cerrado, y la empresa cierra, aún tengo la posibilidad de usar el software. Si el programa era libre, la comunidad de usuarios podrá hacerse cargo de su futuro desarollo. Pero, por ejemplo, ¿cómo nos afectaría el cierre de Google Docs? ¿Qué ventaja ofrecería la AGPL en el supuesto caso que Google publicara ese código? Sí, quizás podríamos ver el código fuente de Google Docs. Pero, en primer lugar, sería muy difícil disponer de la infraestructura técnica y humana para hacerlo funcionar, porque estamos hablando de software pensado para ejecutarse en granjas de ordenadores. En segundo lugar, y lo más importante: dejaríamos de tener acceso a nuestros documentos. ¿De qué me sirve el código fuente si además mis datos se han esfumado?
Software como servicio libre
La solución que da Stallman es ignorar el problema y simplemente advertir a los usuarios de que usar servicios web es perder el control, como en el software cerrado. De esta forma también se desaprovecha la oportunidad de redefinir el concepto de libertad a la luz de los avances informáticos. Por eso, la comunidad de software libre debería enfrentar el problema en forma de una licencia similar a la GPL, que defina la libertad no solo en términos del acceso al código, sino también a los datos.
La Free Software Foundation establece cuatro libertades básicas en su definición de software libre:
- Libertad 0: La libertad de usar el programa, con cualquier propósito.
- Libertad 1: La libertad de estudiar cómo funciona el programa, y adaptarlo a tus necesidades.
- Libertad 2: La libertad de distribuir copias, con lo que puedes ayudar a tu vecino.
- Libertad 3: La libertad de mejorar el programa y hacer públicas las mejoras a los demás, de modo que toda la comunidad se beneficie.
Sin embargo, estos puntos no se pueden transponer directamente a los servicios en línea, porque ya no hablamos simplemente del derecho del programador a modificar el código fuente, y del usuario a copiar el programa. En cambio, se podría definir que un servicio en línea sería libre si combinara las premisas del software libre con la del libre acceso a los datos:
- Libertad 0: La libertad para usar el servicio, con cualquier propósito.
- Libertad 1: La libertad para acceder a los datos y contenidos.
- Libertad 2: La libertad de migrar los datos a/desde otros servicios.
- Libertad 3: La libertad de mejorar el servicio.
No todas estas libertades son igual de útiles y prioritarias. Como usuario de Flickr, lo importante sería que tuviera garantizado el acceso a mis fotografías y que fuera fácil descargarlas para hacer una copia de seguridad, y que mis datos siguieran siendo míos. Pero pensando a lo FSF, y dando un uso extenso del concepto libre (como se hace en software libre), además de obligar a la publicación del código fuente, probablemente debería obligar a usar formatos libres y licencias libres que permitieran la viralidad de sus contenidos. De esta forma, un servicio libre, incluso podría permitir la clonación del interfaz (bien por completo, al estilo Ning, bien por mashups al estilo Google Maps) o bien permitir la creación de otros otros interfaces de acceso, a través de APIs.
Hacia una definición de servicios abiertos
Todo este debate sobre lo libre y lo abierto en los servicios web no es exactamente nuevo, a pesar de que tenga creciente urgencia. Tim O'Reilly (el padre del concepto Web 2.0), ya avisaba en 2006 que las licencias abiertas estaban obsoletas (incluída la GPL) y que era necesario redefinir el concepto de abierto.
En 2007, algunas personas relacionadas con la comunidad de software libre se pusieron manos a la obra y desarrollaron una propuesta de definición de Open Service (OSD). Según ésta:
- Los contenidos son abiertos según la definición de Conocimiento Abierto -tiene la excepción de los datos privados del usuario.
- El código fuente es libre/abierto, según definición de OSI o FSF, y está disponible públicamente.
La definición de Conocimiento Abierto obligaría al servicio a que los datos estuvieran accesibles de una forma automatizable (p.e. APIs). Como ejemplo de servicio que cumple esta definición, está la Wikipedia, cuyos contenidos y software son libres. Google Maps, en cambio, no la cumple.
Uno de los problemas de estas definiciones es que en la GPL, los datos de los usuarios deben estar en formato libre, pero no hay obligación de que los contenidos sean libres. Un Google Docs que obligara a hacer públicos, y libres, los contenidos tendría un éxito limitado. En este sentido, quizás sea más interesante bien distinguir los conceptos (Open Data / Open Service) o bien utilizar un sistema similar al de Creative Commons para informar qué libertades se ofrecen.
Epílogo
Sin duda alguna, la comunidad de software libre ha inspirado a muchas otras a compartir y colaborar en la creación de obras intelectuales. La Wikipedia es probablemente su hijo intelectual más brillante. Y resulta paradójico que sea el mismo software libre quien necesite una revisión de su concepto por haberse superado asi mismo (como motor de Google, Amazon, y otros tantos sitios que usan Linux y otras herramientas para construir servicios en granjas de miles de ordenadores).
En el pasado, la ética hacker inspiró a muchos a trabajar a favor de los ciberderechos. No deberíamos descuidar ahora esta causa por desconocimiento y miedo a los nuevos avances.