Les digo altiro que si están esperando ver un artículo sobre GPL 3, este no es. Para eso, pueden ver los excelentes artículos de Christian Leal en en su blog o en Mouse.cl.

¿De qué se trata esto entonces? De la GPL 2, y de los errores en los que es posible incurrir al “olvidar” algunos detalles que ésta implica, y que en definitiva hacen que no funcione como debería, o sea —parafraseando a Stallman— limitando ciertas libertades para otorgar otras: libertades de software libre “a la Free Software Foundation“.

¿Cómo? A través de la presentación de algunos casos de desarrollo de software relacionado con WordPress que logran dar cuenta de descuidos en relación a la aplicación y respeto a la [GPL->@wiki] —y ojo, que digo descuidos, porque desde ya quiero explicitar que no creo que se trate de tipos que se hayan “pasado de listos” con las licencias… después de todo, la GPL es un texto que presenta un cierto grado de complejidad tanto legal como informática, por lo que no es totalmente impensable el incurrir en algún error con respecto a su aplicación.

En definitiva, se puede pensar que este artículo es una ayuda para comprender una de las licencias de [Software Libre->@wiki] más utilizadas en la actualidad.

Qué implica la GNU GPL

No voy a presentar un análisis completo de la licencia (quizás solamente un equipo interdisciplinario pueda ser totalmente competente para dicha tarea), sino que me gustaría presentar un resumen basado en los puntos que Christian presenta en sus artículos.

Si aplicas una licencia GPL a tu software:

1. Debes publicar el código fuente: “Open Source”, traducido literalmente, significa “Fuente Abierta”. En este punto es necesario recordar la indicación que Carlos hizo en los comentarios: en el caso de modificar el código y querer distribuirlo, debes publicar el código; no si solamente quieres utilizarlo con tus modificaciones
2. Estás autorizando la modificación y distribución de tu programa (de acuerdo a los términos de la licencia). Para complementar el punto anterior: la GPL no se aplica a la utilización del software, el acto de correr el Programa no está restringido.
3. Las obras derivadas deben conservar la misma licencia, no hay ninguna otra posibilidad al respecto
4. No puedes restringir la utilización del software ni agregar ninguna nueva restricción a la licencia, es decir, no puedes indicar que un programa no sea utilizado con fines comerciales
5. Estás limitando tu responsabilidad respecto al uso del software, por lo que si la ejecución del software causa algún perjuicio al usuario, el desarrollador no es responsable por los daños
6. Retienes la “atribución” por tu trabajo original, a la misma vez que quien modifique el programa debe indicar que ha sido modificado y la fecha de los cambios

Si te interesa más el tema, lo más recomendable es leer el texto original (en inglés) de la licencia; por supuesto que si vas a publicar un software con ella, más que una recomendación es algo así como un deber. También puedes revisar las traducciones no oficiales al castellano de las licencias GNU.

Importante: debes tener en cuenta que la única versión que debiera ser usada legalmente es la versión original en inglés o alguna de las traducciones oficiales.

Bien, pasemos ahora a los casos.

Cuando la GPL no es GPL

Uno

Este primer caso afecta a la traducción al español de WordPress 2.1 publicada recientemente, y podría calificarse fácilmente de un simple descuido u olvido.

WordPress utiliza [gettext->@wiki] como [sistema de traducción->Localización con WordPress], lo que implica una serie de pasos para generar lo que constituye un catálogo de traducciones: básicamente, primero hay que marcar las cadenas que se habrán de traducir, luego juntarlas todas en un archivo .PO que finalmente deriva en un archivo optimizado para máquinas con extensión .MO —en este caso, el archivo .PO haría las veces de “código fuente” para el catálogo de traducciones… y en este caso, no lo publicaron.

¿Cómo aplicar una licencia de código abierto cuando sin otorgar acceso al código fuente? Simplemente no se puede.

Me contacté con Reyson sobre este asunto, y ha respondido lo siguiente:

Hola Felipe,

Asi es, realizaremos algunos ajustes finales en la traducción y gracias a los que están comunicando algunos errores podemos hacerla lo mejor posible para luego liberarla y sirva de base para futuras traducciones, un poco de paciencia.. 😉

Por otra parte, esto plantea una cuestión que no deja de ser interesante: si publicamos un tema con licencia GPL, ¿acaso deberíamos publica lo que haga las veces de “código fuente” de las imágenes también? Y en ese caso, ¿cuál sería el “código fuente” de las imágenes: los archivos para Photoshop o [GIMP->@wiki]? ¿O basta con incluir las imágenes “tal-cual”, como JPG, GIF o PNG? (considerando también que, por ejemplo, que JPG es un algoritmo de compresión con pérdida, y que en el caso de fotografías digitales a veces sería posible incluir los archivos raw).

De todos modos, hasta ahora el estándar de facto es incluir solamente los archivos JPG/GIF/PNG.

Dos

Hace algún tiempo publiqué una [versión en español de 281->281 – Tema de WordPress en español], basada en 281 de Paul Stamatiou.

Este tema está basado en K2, publicado bajo licencia GPL, por lo que se publica también por esta licencia. Sin embargo, existe una modifcación bastante popular (que incluso está disponible en WordPress.com) llamada 2813, a cargo de Eli Foner.

¿Y cuál es el problema con 281 o 2813? —se preguntarán.

El problema, es que Eli publica una licencia Creative Commons Attribution – NonCommercial – ShareAlike 2.5, y debería estar ocupando… sí, la GPL. En concordancia con esto, indica que su tema no debería utilizarse “con propósitos comerciales”, lo que ciertamente es algo ambiguo, pero si se refiere a la utilización en sitios comerciales está fuera de orden respecto a la licencia que debería tener.

A todo esto, a mí [me pasó lo mismo->Las licencias, son para leerlas] cuando publiqué [Satori->], que ocupa código de Kubrick.

Tres

Este primer caso lo ví por primera vez en What makes you happy?, y es quizás el más polémico de todos.

Se trata de un tema basado en una plantilla GPL y que utliza código de K2, que también es GPL, por lo que lógicamente, este tema también debería utilizar esta licencia. Y lo hace, ese no es el problema, sino que en la página de descarga agrega un párrafo que dice:

Anaconda viene con la GPL (Licencia Pública GNU). Tanto Mollio como K2 han sido publicados bajo GPL. La única cosa que exigimos es que mantengas las atribuciones y los enlaces en el pié de página sin ningún cambio.

Claro, exigen mantener atribuciones y enlaces, y una de las cláusulas de la GPL especifica claramente que no se pueden agregar nuevas restricciones, con lo que la exigencia es totalmente inválida. Por otra parte, bajo la GPL está permitido modificar el código, y solamente reglamenta la “modificación y distribución”, o sea que en la práctica la “modificación y utilización” (sin redistribución) no estaría limitada por la licencia.

Pero esto no acaba acá: como indica Mark, existe en el blog de quienes publican este tema un post llamado Cómo remover las atribuciones / enlaces del tema Anaconda para WordPress, en el que señalan que para poder sacar los enlaces es necesario pagar US$30. De acuerdo a la GPL, se puede cobrar una cuota por el acto físico de transferir una copia, por garantía o incluso por el mismo software, pero cobrar por algo que es incompatible con la licencia… eso sí que no.

Porque además de exigir manter la atribución, la forma en que insertan los enlaces a su sitio es mañosa, ya que no está simplemente incluída en el código del footer.php, sino a través de una función que inserta los enlaces a través del hook wp_footer.

Por si les interesa, les dejo el enlace al tema en cuestión: Anaconda, Ultimate 3 Column WordPress Theme