Software libre en la Ley de Transparencia de La Rioja. Una buena noticia.

El acceder a las aplicaciones que utiliza la administración facilita que otras administraciones con menos recursos puedan usarlas, que se puedan localizar errores y mejorarlas, pero también que empresas informáticas puedan adaptar aplicaciones para que interactúen mejor con las de la administración pública creando negocio y facilitando el trabajo a usuarios y administrados.

Todas estas ventajas, que se dan con el software libre, tienen reflejo en la Ley 3/2014, de 11 de septiembre, de Transparencia y Buen Gobierno de La Rioja publicada hoy en el BOR.

Esta Ley además contiene cuestiones sobre reutilización de la información del sector público y transparencia.

f) Software libre: Programa informático de acceso completo a su código con permiso para ser usado en cualquier máquina y en cualquier situación, para modificarlo y para ser redistribuido, normalmente aplicándole de nuevo las características de software libre.

Así se define en su artículo 3 la Ley 3/2014, de 11 de septiembre, de Transparencia y Buen Gobierno de La Rioja. Creo que sin concretar en una licencia es una adecuada definición.

Una definición que además tiene un título entero de desarrollo.

En 3 artículos en el Título V se establece la posibilidad de que mediante la publicación en el portal de transparencia se ponga a disposición de todos tanto el código fuente de las aplicaciones como los materiales (documentación, etc.) que sean propiedad de la Administración Pública de la Comunidad Autónoma de La Rioja (también la Universidad de La Rioja por ejemplo).

Me gusta especialmente que no se empleen eufemismos como "software de fuentes abiertas" o similares para lo que es software libre.

La Ley no indica una licencia concreta a emplear, reservando a la consejería competente establecerá las condiciones de libre uso y distribución, pero siempre con carácter de software libre.

Es decir, que las opciones serán o establecer una licencia propia que permita el acceso al código y las condiciones de reutilización o bien acogerse a alguna de las exisntentes, tipo GPL, por ejemplo.

Siendo una administración pública española, lo razonable a mi juicio sería emplear una licencia en castellano (aunque sea la traducción de la GPL) o mejor aún, emplear la European Union Public License que cuenta con una versión en castellano aprobada por la UE (pdf).

Además se ha previsto, con el fin de evitar problemas con la legislación sobre patrimonio, el régimen de las cesiones gratuitas (que rige fundamentalmente entre administraciones) para que la administración pueda "desprenderse" del software que libera.

El único pero que podría considerarse es que no haya un procedimiento específico para solicitar la liberación de las aplicaciones o que no se concrete más los supuestos en que se dará esta liberación, siendo sólo potestativo.

"Previo informe favorable del Comité de Seguridad de la Información del Gobierno de La Rioja, se podrá poner a disposición pública el código fuente de los programas y aplicaciones informáticas y la documentación asociada a los mismos que sean propiedad de la Administración Pública de la Comunidad Autónoma de La Rioja, que tendrán el carácter de software libre."

Es decir, que en mi opinión, todas las aplicaciones deberían someterse obligatoriamente a ese informe y las que lo superen ser liberadas como software libre.

Hecha esta precisión al margen, creo que es un buen movimiento del gobierno de La Rioja para que lo que es creado con el dinero de todos sea reutilizado para crear valor para todos.

Nombres de dominios y la GPL, el caso Jdownloader

El compañero Jorge Campanillas, miembro del despacho "Iurismatica", comenta la defensa que brillantemente han realizado para el titular del dominio "jdownloader.com" consiguiendo conservar el dominio para su cliente frente a la pretensión del titular de la marca "jdownloader" y del dominio "jdownloader.org" y creador del popular programa de gestión de descargas.

Este programa está licenciado bajo la GPL v3.

Por su parte el demandante pone a disposición en internet tanto el código fuente de la versión original del programa “Jdownloader” (en un enlace identificado como JD Source) como una versión modificada.

Esta versión modificada incluye la instalación de una barra de herramientas del traductor en linea de Babylon, por la que, al parecer, recibe dinero.

Las disputas en relación a nombres de dominio tiene en general un mismo esquema de análisis, requiriéndose para la estimación de la demanda la concurrencia de 3 requisitos:

1. "Que el nombre de dominio registrado por el demandado sea idéntico o similar hasta el punto de crear confusión con una marca de productos o servicios sobre la que el demandante tiene derechos;
2. Que el demandado carezca de derechos o intereses legítimos en relación con el nombre de dominio; y
3. Que el nombre de dominio haya sido registrado y se use de mala fe."

Pues bien, en este caso la defensa, entre otras cosas, alegó para acreditar la existencia de derechos e intereses legítimos que:

"La denominación “Jdownloader”, referida al programa del mismo título, es de libre utilización en virtud de la licencia GNU-GPL v.3 otorgada por la Demandante (titular del copyright) para el uso del programa de software “Jdownloader”.[...]"

"[...]Como la Demandante declara públicamente que el programa “Jdownloader” es software libre licenciado con una licencia GNU-GPL, está pues permitiendo a cualquiera – también al Demandado – la utilización, copia, distribución, modificación y la distribución del mismo y el uso de la denominación “jdownloader” como identificador del programa, por lo que ningún reproche cabe realizar al Demandado sobre su actividad actual bajo el dominio en disputa, que no es otra que la distribución autorizada del citado software."

La OMPI en otros casos de nombres de dominios de distribuidores de productos bajo una misma marca, ha señalado que estos pueden hacer una oferta de buena fe y tener interés legítimo si se cumplen ciertos requisitos, como que se ofrezcan efectivamente los bienes de que se traten y la relación del titular del dominio con el de la marca.

Y en esta resolución se acreditan esos y el resto de requisitos exigibles para supuestos similares.

En este punto el experto de la OMPI empieza a analizar cuestiones sobre los derechos que concede la GPL y las marcas y los nombres de dominio, para terminar dando la razón al demandado.

"En opinión del Experto, considerando que uno de los usos permitidos por la licencia GNU GPL es la distribución del software originalmente creado por la Demandante, sin modificaciones de terceros, es razonable que el Demandado utilice el término “jdownloader” para referirse al software original. Asimismo, como ya se ha indicado, la licencia GNU GPL v.3 permite tanto la distribución de la versión original del programa como la de versiones modificadas"

Y añade que:

"De todos modos, dado que hacer versiones modificadas y distribuirlas está permitido expresamente por la licencia GNU GPL, parece que el Demandado está haciendo un uso legítimo del término “jdownloader” al referirse con ese nombre a su propia distribución del software combinada con un producto de software de otro origen, la barra de herramientas de traducción en línea de “Babylon”

Además dice que el apartado 7.e) de la GPL indica que:

"[...] la Demandante podía haber incluido en la licencia una “negativa con respecto al otorgamiento de derechos conforme a las leyes de marcas para el uso de ciertos nombres comerciales, marcas de productos o marcas de servicios”, pero no lo hizo. De haber incluido la Demandante ese “término adicional” limitando o prohibiendo el uso del término “jdownloader”, otra pudiera haber sido la solución de este caso."

No puedo compartir la opinión del experto en relación al análisis que hace de la GPL; no discuto que puedan existir otras razones para no atender la demanda (como las relativas a la fecha de dominio, contenido en el sitio, etc.) pero las que hacen referencia a la GPL me parecen erróneas y ,de todas formas, esta resolución debería hacer reflexionar a los responsables de la GPL sobre la introducción de algunos cambios en relación a marcas y nombres de dominios en la licencia.

En primer lugar porque lo que la GPL v3 dice en ese párrafo es que:

"Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:

e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks;"

Que según lo entiendo yo es que, para aquellos que añaden algo al programa cubierto por la licencia, pueden modificar esta incluyendo términos que supongan la no concesión de derechos marcarios, como  nombres comerciales, etc.

Pero eso no es algo que en principio pueda hacer el titular del programa original ya que se supone que esa previsión debe operar para el caso de obras derivadas, por lo que ese apunte del experto no me parece correcto.

De hecho las inclusiones de esta cláusula se mencionan en el apartado 5 que trata sobre la transmisión de versiones modificadas del Código Fuente.

En segundo lugar porque la protección del nombre del programa debería impedir que compilar el código fuente y añadir una opción en la instalación del mismo permita que se siga utilizando el mismo nombre en el instalador, por ejemplo (cuando tratamos de descargar el programa de "jdownloader.com" el archivo se llama "installer_jdownloader.exe") lo que sin duda me parece un aprovechamiento de la reputación ajena.

Creo que ello perjudica al usuario que busca una cosa y obtiene otra diferente.

Además esta resolución genera inseguridad puesto que cualquiera podrá crear una herramienta maliciosa, añadirla a un programa de software libre y difundirla bajo un dominio similar, con los consiguientes problemas que ello acarrearía para la correcta identificación del origen del software (en este caso se menciona el origen).

La FSF, responsable de la GPL, debería analizar este caso y plantearse si deben incluirse en las nuevas versiones de la licencia algunas limitaciones relacionadas con el uso de elementos marcarios que protejan mejor al autor del software original.

Al fin y al cabo, en este caso, no podemos hablar ni de una mejora ni de nada similar en el programa, sino que simplemente estamos ante un instalador que permite añadir algo diferente y no vinculado y dudo que eso pueda ser considerado como obra derivada, ni en los términos de la LPI ni en los de la propia GPL.

Esta resolución puede hacer que algún desarrollador que aspire a obtener ingresos desde su página web se lo piense antes de liberar software bajo GPL.

La GPL, Google, Bionic y Android

Desde hace unos días se viene discutiendo una cuestión que afecta a los "header files" o archivos cabecera del kernel de Linux, la licencia GPL y el uso que de los mismos hace Google para el desarrollo de Android.

Algunos han sacado conclusiones abolutamente, a mi juicio, desenfocadas, como quienes dicen que Google está robando el código de Linux

Incluso el diario El País se ha hecho eco de esta cuestión si bien el análisis carece de ciertos elementos y provoca confusión.

En mi opinión estamos ante una cuestión bastante compleja y es necesario hacer un recorrido por todos los elementos para tratar de alcanzar una opinión minimamente informada sobre la cuestión. Por supuesto que agradeceré cualquier comentario sobre este tema con las correcciones o matizaciones necesarias.

Los archivos de cabecera o header files

De acuerdo a la wikipedia, los "header files" o archivos de cabeceras son archivos que permiten a a los programadores separar ciertos elementos del código fuente de un programa en archivos reutilizables.

Estos archivos contendrían elementos comunes para el uso por varias otros programas. 

En términos muy simples sería como disponer de un diccionario de gramática a la hora de escribir una novela. Podemos recurrir al contenido de ese tercero para que se entienda la historia, pero no forma parte de esta. (El ejemplo es al nivel más básico, seguro que hay diferencias)

Cuando alguien compila algo para ser ejecutado en ese sistema puede acudir a esos archivos de cabecera para verificar que la compilación es coherente con las definciones que se contienen en el resto del sistema, sin tener que incluir en todo caso las mismas definiciones dentro de su propio código.

Lo que Google hace

Los "header files" del nucleo de Linux son modificados por Google mediante un proceso automatizado que realiza una limpieza del contenido.

Según la compañía este proceso lo que hace es retirar elementos de los "header files" que no son necesarios y provocarían inconsistencias o problemas de compilación con elementos que no son necesarios en el entorno de Android. Lo que tiene sentido, tal y como explican en el readme.txt

Y aquí viene una de las cosas extrañas, para mi, de todo esto.

Google alega que retira todo el material sujeto a derechos de los headers, dejando sólo material sin copyright.

Los headers modificados se publican bajo una licencia BSD junto con libc, no bajo la GPL como obligaría la cláusula vírica.

¿Puede Google hacer eso?

Pero no entiendo como es eso posible, si tenemos en cuenta la definición de programa de ordenador desde el punto de vista legal, tanto en la ley de Estados Unidos como en la española:

"A “computer program” is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result"

 "A los efectos de la presente Ley se entenderá por programa de ordenador toda secuencia de instrucciones o indicaciones destinadas a ser utilizadas, directa o indirectamente, en un sistema informático para realizar una función o una tarea o para obtener un resultado determinado, cualquiera que fuere su forma de expresión y fijación."

De acuerdo a estas definiciones es posible entender que estos archivos constituyen un programa de ordenador en los términos legales.

Pero es que además para la GPL v3 un programa es:

“The Program” refers to any copyrightable work licensed under this License.

 Y para la licencia  que no ocupa, la GPL v2, la definición es similar:

The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law

Ambas definiciones se remiten a la consideración lo que diga la legislación de propiedad intelectual, por lo que parece claro que las definiciones legales son las que marcan la interpretación que debe hacerse.

Si partimos de esa premisa, la modificación de los headers originales sujetos a la GPL seguirían resultando, a tenor de las definiciones, en programas de ordenador. Esto es, para poder modificar una obra con copyright sujeta a licencia se deben respetar las condiciones de esta.

Entiendo que en lógica aplicación del contenido de la GPL esos "headers" sólo podrían licenciarse bajo la GPL por aplicación de la cláusula vírica.

No sé que material con "copyright" puede quitar Google que haga que eso deje de ser un programa. Esta podría ser una de las claves, pero no veo por donde acercarse a esto.

¿A qué obliga la GPL?

En este caso hablamos de la GPL v2 y respecto de las modificaciones establece que:

You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: 

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. 

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

Esto significa que las modificaciones que vayan a ser distribuidas o publicadas, en lo que a estos efectos interesa,  que contengan en gran parte o deriven del programa original sean licenciadas con la misma licencia.

No que usen o enlacen con el header, sino que lo contengan o deriven de este.

Creo que lo que hace Google es precisamente eso, no sólo usar los headers sino modificarlos, aunque sea para mejorarlos.

La interpretación de Stallman

En este punto es interesante recoger lo dicho por Richard Stallman en el año 2003 sobre los headers, porque pudiera parecer que lo que he señalado se contradice, pero creo que no:

Someone recently made the claim that including a header file always makes a derivative work.
That's not the FSF's view. Our view is that just using structure  definitions, typedefs, enumeration constants, macros with simple   bodies, etc., is NOT enough to make a derivative work. It would take  a substantial amount of code (coming from inline functions or macros with substantial bodies) to do that.

Lo que dijo Stallman, asesorado por sus abogados, es que usar el contenido de un header no es hacer una obra derivada, ni tampoco que incluir un header siempre suponga hacer una obra derivada.

Y estoy plenamente de acuerdo.

Siguiendo con el ejemplo simple anterior, el incorporar el diccionario no es hacer una obra diferente y el usar la estructura gramatical propuesta por el diccionario en nuestra novela no es hacer una obra derivada.

Sin embargo Google no hace esto, lo que hace Google es modificar unos ficheros (que se consideran a efectos legales programas de ordenador) y a los ficheros resultantes les cambia la licencia por una BSD, lo que a mi juicio vulnera el contenido de la GPL de los ficheros originales como se ha expuesto.

¿Esto significa que todas las aplicaciones android deben ir con la GPL?

No, en absoluto, creo que afirmar eso es ir mucho más allá del contenido de la GPL.

Como se ha expuesto, usar las definiciones de los headers no supone modificarlos o incorporarlos a un programa en tales términos que obliguen al resultado de que todo lo creado deba ser GPL. No se puede considerar que utilizar unas expresiones concretas constituya una obra derivada.

Esto se hace con fines de interoperabilidad y "estadnarización" del lenguaje dentro de un entorno, pero en ningún caso es un problema de reutilización que suponga la obtención de una obra derivada.

De acuerdo a nuestra ley de propiedad intelectual, por ejemplo, una obra derivada es, artículo 11.5 LPI:

"Cualesquiera transformaciones de una obra literaria, artística o científica."

Y es evidente que usar los headers originales sin modificar para que otro programa compile no es una alteración de los mismos que resulte en una obra derivada.

Conclusiones.

A mi juicio sí que Google está haciendo algo aparentemente contrario a la GPL, cual es poner en ciruclación los headers modificados por ella misma con una licencia que no es la GPL.

Pero afirmar que todo lo que compila contra unos determinados headers es una obra derivada y por lo tanto debe ser licenciado como GPL no tiene mucho sentido.

Y tú, ¿qué opinas?

[Más información sobre este tema]:

Barrapunto

Florian Mueller

Bradley M Kuhn

Importante sentencia sobre licenciamiento de contenidos

Aunque ya hay varias sentencias a nivel internacional que reconocen de una u otra manera la viabilidad del modelo de licencias empleados por el software libre y el movimiento copyleft, tengo noticias hoy de una importante sentencia recaida en un asunto en Estados Unidos.

La sentencia (pdf) es del 13 de agosto (n. d. a.: alucinante, un juzgado sacando sentencias en agosto y disponibles en internet el mismo día. Calculo que esto llegará a España en 100 o 200 años)

El comentario del propio Lawrence Lessig da muestra de la importancia de la misma:

"So for non-lawgeeks, this won't seem important. But trust me, this is huge." (Para los no-geeks del derecho, esto no parecerá importante. Pero creanme, lo es)

La cuestión versaba sobre el uso de la una de las licencias ofrecidas por la OSI (Open Source Initiative), en concreto la "Artistic License".

El objeto del pleito, en apelación, era fallar sobre la facultad de un titular de derechos de propiedad intelectual para dedicar una cierta obra al uso público y además emplear una licencia "open source" para controlar las modificaciones y distribución de esa obra.

Como pueden comprobar el objeto del litigiio es la cuestión clave en lo que a las licencias libres se refiere. De ahí la importancia del fallo, pues el Tribunal a entrado de lleno a analizar el problema concreto de las licencias "libres" como un isntrumento válido para proteger los derechos del autor.

El caso es el siguiente:

Robert Jacobsen creó un software, el Java Model Railroad Interface o JMRI, que puso en libre descarga bajo la licencia "Artistic License" en SourceForge. Este programa contenía una aplicación, DecoderPro, que permite programar los chips de los trenes de modelismo.

Por su parte Matthew Katzer and Kamind Associates, Inc., que desarrollan software comercialmente para maquetas de trenes y aficionados emplearon parte de su software en su producto sin respetar las condiciones de la licencia "Artistic License". En concreto no incluyeron:

Los nombres de los autores, las notas de "copyright" del JMRI, referencias al archivo COPYING que venía con el software original, una identificación de SourceForge o JRMI como la fuente original de los archivos, y una descripción de como los archivos o el código habían sido cambiados desde el código fuente original.

El autor, R. Jacobsen, presentó una acción preliminar que el juzgado del distrito rechazó la acción sobre la base de que la licencia empleada es "intencionalmente amplia", no exclusiva, que era ilimitada en cuanto al objeto y que por ello no creaba perseguibilidad por infracción del copyright.

Lo que venía a expresarse es que Jacobsen tenía derecho a accionar unicamente por una ruptura del contrato, en lugar de por una infracción del copyrigth con base en el quebrantamiento de las condiciones de la "Artistic License" y dado que un contrato no crea una presunción de que daño irreparable, la Corte del Distrito denegó la acción preliminar.

Como puede verse esta cuestión es trascendental, puesto que determina las reglas para pelear en el caso de vulneraciones de las licencias. Esto es si podemos valernos de las reglas procesales del derecho de la propiedad intelectual o hay que acudir a las reglas generales de los incumplimientos contractuales.

Frente a esta resolución se alza la parte en apelación y, además, se suman a la misma como "amica curiae" varias instituciones importantes, entre ellas Creative Commons. (Aquí el texto de los "amigos en la corte" (pdf))

La Corte de Apelación reconoce el valor de las licencias "open source", como las llama, y su importancia para una forma de desarrollar las ciencias y las artes de una manera y con una paz que muy pocos pudieron imaginar hace tan sólo unas decadas:

"For example, the Massachusetts Institute ofTechnology (AMIT) uses a Creative Commons public license for an OpenCourseWare project that licenses all 1800 MIT courses. Other public licenses support the GNU/Linux operating system, the Perl programming language, the Apache web server programs, the Firefox web browser, and a collaborative web-based encyclopedia called Wikipedia. Creative Commons notes that, by some estimates, there are close to 100,000,000 works licensed under various Creative Commons licenses. The Wikimedia Foundation, another of the amici curiae, estimates that the Wikipedia website has more than 75,000 active contributors working on some 9,000,000 articles in more than 250 languages."

Además la Corte de Apelación reconoce un hecho esencial, como es que el Código se ditribuya gratuitamente bajo una licencia "open source" no quiere decir que el mismo no deba tener una consideración económica. Existen beneficios sustanciales, incluyendo los económicos en la creación y distribución de obras reconocidas por la propiedad intelectual bajo licencias públicas que van mucho más allá de los royalties por el licenciamiento tradicional. Y cita el caso de un asunto del Distrito Undécimo:

"The Eleventh Circuit has recognized the economic motives inherent in public licenses, even where profit is not immediate. See Planetary Motion, Inc. v. Techsplosion, Inc., 261 F.3d 1188, 1200 (11th Cir. 2001) (Program creator Aderived value from the distribution [under a public license] because he was able to improve his Software based on suggestions sent by end-users. . . . It is logical that as the Software improved, more end-users used his Software, thereby increasing [the programmer=s] recognition in his profession and the likelihood that the Software would be improved even further)."

En el presente asunto nadie discutía la titularidad del software ni que la empresa había copiado y empleado el software JMRI. Lo que la empresa argumentaba es que no habían vulnerado la propiedad intelectual porque tenían una licencia para emplear el código.

Generalmente, un titular de derechos que concede una licencia no exclusiva para emplear su material renuncia al derecho para demandar por infracción del "copyright" y sólo puede pleitear por incumplimiento contractual. (Sun Microsystems, Inc., v. Microsoft Corp., 188 F.3d 1115, 1121 (9th Cir. 1999))

Sin embargo, para el Tribunal, si la licencia establece un ámbito limitado de uso y los usos exceden el mismo si ha lugar a una denuncia por infracción del copyright.

Lo que se dilucidaba pues era si los términos de la licencia se debían considerar "condiciones" o meros "pactos".

Para el Tribunal son condiciones puesto que así se reconocen en el propio texto de la licencia y reconoce el derecho de los titulares que emplean licencias "open source" a controlar la modificación y distribución del material.

Además la imporancia de incluir en el software las menciones de atribución y de las modificaciones tienen como objetivo reconducir a los usuarios e interesados a la página del proyecto lo que tiene undudables beneficios para el titular de los derechos, yq que aumentan los potenciales colaboradores y se aprende de las modificaciones efectuadas.

Por todo ello acepta la apelación y remite de nuevo las actuaciones a la Corte del Distrito.

En definitiva una sentencia muy importante , si bien no es directamente extrapolable al supuesto español, que clarifica de una manera trascendental la forma en la que se puede defender el autor que utiliza las licencias libres.

Las patentes de software no se discutiran en Europa, de momento...

La página web de la Oficina Europea de Patentes (curiosamente EPO) analiza la reunión de alto nivel mantenida en Bruselas en la que han participado Parlamentarios Europeos, especialistas en Propiedad Intelectual y representantes de la industria para analizar la situación dos años despues del rechazo a la patentabilidad de las invenciones implementadas por ordenador, o patentes de software que era lo que en el fondo subyacía.

La mayoría de los intervinientes estaban de acuerdo en que la actual situación es insatisfactoria pero que, sin embargo, reabrir ahora mismo otra vez el debate no era deseable.

La situación de patentabilidad en la Oficina de Patentes de Estados Unidos es que da demasiadas patentes de muy baja calidad, que son muy baratas de obtener pero en la mayor parte de los casos triviales y la situación de China es que su oficina de patentes está financiando las patentes de pequeñas y medianas empresas e impulsando enormemente el crecimiento de la innovación, ante lo que la EPO ve como una amenaza al sistema de patentes europeo.

Sin embargo las voces críticas han manifetado sus dudas acerca de que "las patentes sean la solución para el crecimiento de la economía en la Unión Europea, incluso aunque sea en colaboración con China y Estados Unidos." Eva Lichtenberger, es miembro del Parlamento Europeo por los Verdes Austríacos.

La conclusión a la que todos los presentes llegaron, al parecer, fue que estaba muy bien discutir la cuestión al máximo nivel pero que un nuevo debate sobre la patentabilidad de las invenciones implementadas por ordenador seguido de una modificación legal era tan innecesario como indeseable en estos momentos.

Como se ve no es un problema de querer o no querer que el software sea patentable, pues si siempre está bien comentar y hablar sobre los temas, si la EPO hubiese sacado otra conclusión diferente se hubiese lanzado al debate y reforma legal una vez más.

Simplemente han declarado una tregua, pero seguro que volveran a plantear una nueva reunión en el futuro hasta que se obtenga un respaldo que buscan y promover nuevamente el debate para impulsar una directiva acorde a sus intereses.

Lo que no cabe duda es que la movilización ciudadana surtió sus efectos pues politicamente no están dispuestos a reabrir el debate a pesar de no gustarles la situación actual.

[Otras cuestiones] Me gustaría recomendar, en otro orden de cosas, la lectura del artículo de este blog, cuyo autor es Francisco de Zavalía, que se hace eco de un artículo (pdf) del Catedrático de Economía de Cambridge Rufus Pollock en el que determina que el plazo ideal de protección de las obras de Propiedad Intelectual es de 14 años, con datos y cifras. Un estudio científico y riguroso que deberían aplicarse nuestros queridos legisladores.

¿Es necesario traducir la GPL?

La publicación oficial de la GPL v3 que se acaba de producir no lleva consigo una traducción “oficial” proporcionada por la propia organización.

A mi entender esto es no es correcto y a continuación expondré porqué es un error que la FSF no proporcione un texto traducido al castellano (español) a los creadores de software españoles.

El artículo 144 de la Ley de Enjuiciamiento Civil establece que:

“1. A todo documento redactado en idioma que no sea el castellano o, en su caso, la lengua oficial propia de la Comunidad Autónoma de que se trate, se acompañará la traducción del mismo.

2. Dicha traducción podrá ser hecha privadamente y, en tal caso, si alguna de las partes la impugnare dentro de los cinco días siguientes desde el traslado, manifestando que no la tiene por fiel y exacta y expresando las razones de la discrepancia, se ordenará, respecto de la parte que exista discrepancia, la traducción oficial del documento, a costa de quien lo hubiese presentado.

No obstante, si la traducción oficial realizada a instancia de parte resultara ser sustancialmente idéntica a la privada, los gastos derivados de aquélla correrán a cargo de quien la solicitó.”

Así se ha visto que los tribunales no tienen en consideración documentos o requieren la traducción a quien los aporta para que puedan ser tenidos en cuenta.

Por ejemplo ha sucedido en el famoso caso del Puente de Bilbao de realizado por Santiago Calatrava y la posible lesión de los derechos morales del autor. Su señoría en el fundamento tercero de su Auto de 1 de marzo establece que:

“No cumple el demandante con el requisito que dispone el art. 144.1 LECn , pues aporta una revista en idioma inglés sin traducción. La omisión de traducción al idioma castellano o euskera, oficiales en la Comunidad Autónoma Vasca, hace que el doc. núm. 1 de la demanda no pueda ser admitido, en tanto se pretende tenga eficacia probatoria sin cumplir con la exigencia de traducción, oficial o privada, que dispone la norma citada. En consecuencia el mismo y sus copias será devuelto al demandante y no se entregará a los demandados.”

Pero otras resoluciones así lo atestiguan como por ejemplo Sentencias de la Audiencia Provincial de Salamanca de 30 noviembre 2005, o de Madrid de 17 mayo 2005, entre otras.

Es cierto que un Tribunal Alemán ha considerado válida la licencia sin traducir por entender que el inglés es idioma de uso común entre ambas partes del pleito y que por ello no habría problema con la versión alemana no oficial, la situación en España puede no ser la misma. Para más información sobre esta sentencia, en inglés, Groklaw

Como se ve en las sentencias estudiadas la documentación no traducida no será tenida en cuenta en el proceso, no tendrá valor probatorio alguno. Cierto es que se puede acudir a una de las no oficiales disponible en español, pero según la propia FSF hay hasta cuatro.

La no existencia de traducción puede suponer un problema para el usuario-creador de software que, en un eventual pleito, tiene que recurrir a demostrar las condiciones en las que obtuvo el software y una mala praxis de su defensa puede dejarle sin la documentación que acredite como accedió al software o en otro caso a correr con los gastos de una traducción.

Las razones para no tener una traducción proporcionada por la FSF se basan en el riesgo de tener traducciones para cada jurisdicción y que alguna de ellas contenga algún error que de al traste con la finalidad de la misma, además del coste de contar con abogados bilíngües que las traduzcan.

Sin embargo hay un error a este respecto y es que el tener la traducción proporcionada por los propios creadores se dota de mayor seguridad jurídica a los usuarios-creadores de software, pero esta traducción solo debe utilizarse en caso de necesidad legal, pudiendo perfectamente distribuirse el software bajo la GPL en inglés.

La traducción actuaría como un mecanismo de protección ante los jueces, sin que sea el documento utilizado en el tracto cotidiano del software libre.

No digo que haya que tener una licencia para cada país, no es necesario “trasponer” la GPL al ordenamiento jurídico español, como se ha hecho con las Creative Commons, simplemente es disponer de una versión “buena” avalada por la FSF.

Otro argumento que reforzaría este argumento partiría de la consideración de la GPL como un contrato para el ordenamiento jurídico español y por lo tanto el pleno sometimiento de la licencia a la Ley de Condiciones Generales de la Contratación, lo que supondría la necesidad de cumplir con el requisito de que las condiciones del contrato sean comprensibles, legibles, etc. (artículo 7.1.b LCGC), para las partes y los problemas de garantizar el cumplimiento de ese requisito con un texto en inglés.

Este punto iría más allá y provocaría la necesidad de que el software distribuido o puesto a disposición en España incorpore la licencia traducida en todo momento.

En cualquier caso, personalmente, lo que queda claro es que sería una buena medida que la FSF “ampare” oficialmente una traducción a nuestro idioma, visto el ordenamiento jurídico actual.

¿Migración obligatoria a la GPL v3?

Puede que en España no pueda darse el debate entre partidarios de continuar con la GPL v2 y aquellos que pretenden acogerse a la nueva GPL v3.

En el texto actual "vigente" de la licencia, que se corresponde con la versión 2, puede leerse, a modo de resumen de lo que aquí interesa:

"Activities other than copying, distribution and modification are not covered by this License; they are outside its scope."

Pero, en España y para los autores españoles, la distribución sólo es posible en soportes tangibles, por lo tanto el envío de archivos a través de redes no queda cubierto bajo éste concepto.

"Se entiende por distribución la puesta a disposición del público del original o de las copias de la obra, en un soporte tangible, mediante su venta, alquiler, préstamo o de cualquier otra forma."

En ese caso, la GPL V2, no autoriza a comunicar obras a través de Internet. La descarga de software libre GPL desde servidores externos al del autor, sin el consentimiento por escrito de éste de éste, vulnera la LPI.

Esto significa que un programa creado por un español, licenciado bajo la GPL v2, no permitiría que terceras personas pongan ese progama en la red sin contar con un permiso directo del autor al margen de la licencia. Tampoco las obras derivadas o mejoras del programa pueden ser colocadas en internet, sin vulnerar el contenido de los derechos en exclusiva del autor original.

El segundo borrador de la versión 3 de la GPL, ha reunido todas las acciones objeto de derecho de exclusiva de los autores (reproducción, distribución y comunicación pública) bajo la palabra "propagate" mediante la siguiente formulación:

"To "propagate" a work means doing anything with it that requires permission under applicable copyright law, except executing it on a computer, or making modifications that you do not share. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well. To "convey" a work means any kind of propagation that enables other parties to make or receive copies, excluding sublicensing."

Como se ve, ya se recoge la puesta a disposición del público como forma de comunicación pública,fórmula por la que se quiere reconducir todo lo que tenga que ver con la difusión de obras en Internet.

Lo anterior obligaría a que todos los programadores sujetos a la LPI licencien con la GPL v3 sus obras, so pena de provocar un caos importante, o solicitar a la FSF un cambio en la redacción de la GPL v2. (o al Ministerio de Cultura...)

Pero si en mi artículo acerca de la reforma del concepto de reproducción es acertado, y realmente hay un bug en la LPI...

Nada de lo anterior entorpecería la GPL v2, ya que ningún derecho tienen los programadores sobre el envío de sus obras a través de redes y teniendo permitido por la GPL la reproducción de las mismas, hecho que se produce por la copia de la obra a nuestro disco duro, la conducta sería perfectamente lícita.