Licencia del proyecto

[Almorca]

Estudiando de dónde obtener los gentilicios y listados de municipios veo que la opción más sencilla es usar Wikipedia. Sin embargo, legalmente la licencia de nuestro proyecto GPL es incompatible con la CC BY de Wikipedia.
¿Cómo veis migrar la licencia de los ficheros hunspell a CC BY y dejar la licencia del resto del código en la GPL?

[olea]

¿Cómo veis migrar la licencia de los ficheros hunspell a CC BY y dejar la licencia del resto del código en la GPL?

A mi me parece una decisión ma*ra*vi*llo*sa.

[cosmoscalibur]

En mi caso apoyo la migración. Siempre he sido partidario de usar licencias flexibles que faciliten el uso de los resultados por terceros pero al mismo tiempo nos permita usar otros resultados sin dificultad. En código me agrada bastante la licencia MIT y para los ficheros excelente que fuera CCBY40.

[RickieES]

Ojo a cambiar licencias de archivos. Es una tarea muy delicada que no puede abordarse a la ligera:

• Para cambiar la licencia de un archivo, teóricamente, habría que pedir permiso al autor y todos los colaboradores del mismo. Mozilla se vio en esas cuando quiso migrar de MPL 1.1 a MPL 2.0 y le dio muchas vueltas; creo que finalmente decidió arriesgarse a que algún colaborador le denunciara, porque cumplir estrictamente la legalidad era totalmente inviable.
• El proyecto no está solo en GPL, sino trilicenciado en GPL3/LGPL3/MPL1.1. Hay que ver las implicaciones del cambio.
• También hay que ver las implicaciones para los complementos. Por ejemplo, al menos el diccionario para Mozilla es-ES está publicado bajo MPL 1.1.

[cosmoscalibur]

Completamente de acuerdo @RickieES , no es un cambio para tomar a la ligera pero hay que abrir los espacios de discusión para ello.
Respecto a los complementos, la verdad no veo una implicación directa, porque los ficheros de diccionario compilados no se encuentran en el repositorio que es cobijado por las licencias mencionadas y realmente si se analiza, son el equivalente a cualquier archivo de entrada o parámetros, y por ende no estaría sujeto a protección. ¿Donde esta el valor que aplica para protegerse en el proyecto? Los códigos fuente y binarios de las utilidades para generación de los diccionarios, y los complementos específicos de LibreOffice que son oficialmente soportados por el proyecto. Cualquier complemento no oficial al usar los ficheros compilados y no empaquetar las utilidades ni empaquetar un complemento oficial, no se vería afectado y podría tener cualquier licencia. Igualmente los ficheros de diccionario al ser colecciones de voces tampoco les aplicaría la protección en un sentido estricto (más allá de un formalismo para dar constancia del equipo que trabajo en el fichero usado).
De la misma manera, vale la pena retomar el tema de derechos de autor, y considerar una migración como proyecto y una remisión a una lista de colaboradores.

[RickieES]

De acuerdo en que no pasa nada por hablar de ello. 👍

Los ficheros del diccionario compilados son, claramente, una obra derivada del código fuente y, por tanto, están sujetos por la misma licencia (por una de las tres que usamos, en este caso). Por tanto, no comparto tu afirmación de que los complementos no están sujetos a la misma licencia. Que pueda resultar difícil, o incluso imposible, para nosotros demostrar si un tercero ha partido o no de nuestro proyecto para su proyecto o producto, no significa que debamos incumplir nosotros mismos las licencias sobre las que aportamos contenido a RLA-ES.

Dicho lo cual, lo que realmente hay que verificar son dos cosas:

• Si podemos variar la licencia de algunos o todos los archivos que componen el proyecto, para facilitar la inclusión de contenido a los mismos. O, alternativamente, si añadir una licencia más a esos archivos sería compatible o no con las que hay y con las colaboraciones previas.
• Si variar la licencia, en caso de que fuera factible, podría afectar a la posibilidad de generar o alojar los complementos en los respectivos sitios de extensiones.

No sé por cuál queréis comenzar. Yo, a priori, creo que las licencias CC-By son excesivamente simples comparadas con, sobre todo, la licencia GPL 3.0, y posiblemente no sean compatibles, pero también creo que @olea controla mucho más de ese tema que yo. 😄

[cosmoscalibur]

@RickieES, ¿todo lo producido con un cierto código es considerado como una obra derivada?
Ninguna de las 3 licencias considera que el resultado de ejecución de un software sea sujeto a las restricciones de licencia del mismo, de su código fuente o de los datos de entrada. Tal como queda en los textos de las licencias, se entienden las obras derivadas o basadas como modificaciones o copias de los códigos o datos originales, no de la salida.
Creo que algo fundamental en toda discusión siempre es evitar los claramente, salvo que exista una referencia claramente documentada que muestre el punto (y no encontré referencia alguna que soporte porque la salida de una ejecución se considere una obra derivada). ¿Puedes aportar documentación que lo soporte? Yo no lo veo claro y me parece importante ver esa claridad del concepto antes de continuar con una discusión posterior.
Y como último detalle, los ficheros originales en si mismos poseen anotaciones de licencia y hay algunos que son GPL, lo cual imposibilitan el uso de LGPL y MPL aplicada en el proyecto (por ser más laxas que la GPL) y LGPL sin mención a un licenciamiento múltiple. La estrategia de múltiple licenciamiento aplicaría si no hubieran anotaciones a nivel de archivo. MPL 2 en el caso de trabajos combinados lleva a usar la licencia GNU y solo los archivos MPL les aplicaría el múltiple licenciamiento.

[RickieES]

Bueno, es que creo que estamos considerando de manera diferente lo que son los complementos respecto de lo que hay en el repositorio. Me parece entender que, para ti, los OXT y XPI que generamos son el resultado de la ejecución del código objeto del proyecto, de la misma forma que un JPEG sería el resultado de la ejecución del binario de GIMP. Entendido así, efectivamente eso no son obras derivadas.

Pero no es mi interpretación. Para mí, los OXT y XPI son el código objeto del proyecto, sus binarios y, desde ese punto de vista, no me queda la menor duda de que están sujetos a una de las tres licencias del proyecto.

En cuanto a lo que comentas de las cabeceras de licencia en los archivos, tienes razón en términos generales. Pero si nos retrotraemos a tiempos antiguos del proyecto y miramos quién hizo los commit hasta ese momento (en una copia local, haciendo git log --since=2008-01-01 --until=2008-12-02), vemos que fue únicamente @sbosio. Por tanto, aunque los ficheros no tengan declarada la triple licencia, el conjunto del proyecto sí la tenía antes de que nadie más hiciera contribuciones (o, al menos, pueda demostrar que las hizo), lo que nos obliga a respetar que nuestros aportes desde aquel cambio están sujetos al triple licenciamiento. Y, por supuesto, el autor de una obra, Santiago en aquel momento, puede cambiar su licenciamiento en cualquier momento, aunque, eso sí, sin efecto retroactivo.

Como nota al pie, observad que 2008 no es la fecha en que este proyecto se migró a GitHub, sino que comprende también el historial de su anterior alojamiento, la Forja de RedIRIS, el primer hogar que yo conozco del proyecto.

[cosmoscalibur]

Hola @RickieES , de mi parte entiendo que como colectividad se respete la decisión de licencia de @sbosio , pero desde el marco legal la MPL2 es muy clara, para trabajos donde hay este tipo de marcas, el proyecto debe quedar con la licencia GNU que exista (en este caso, al estar GPL y LGPL, debería quedar GPL por ser la más restrictiva).
Por otro lado, también hay un espacio sujeto a interpretación y que ante lo no explícito que es, diría que estamos en posición de decidir y tomar la interpretación que más flexibilidad nos de, para usar una licencia más permisiva en los archivos de diccionario finales y los complementos (claro esta, si ese es nuestro interés). Pienso que un proyecto como este debería estar abierto al beneficio de toda la comunidad, y en ese punto licencias que impongan restricciones más allá de reconocer nuestra autoría se traducen en que el proyecto no pueda tener un impacto mayor.

[sbosio]

Este tema, a lo largo de la vida del proyecto creo recordar que ha surgido algunas veces. El tema es que al menos yo no soy un experto en el tema de licenciamiento. Pero sí puedo hablarles de la historia que dio lugar a esta forma de licenciar y el "espíritu". Creo que para el momento en que inicié el proyecto, ese espíritu se reflejaba en ese esquema de licenciamiento, si bien quizá con el tiempo transcurrido haya quedado desactualizado.

Mi objetivo primordial al iniciar este proyecto fue ofrecer una alternativa al único diccionario disponible para OpenOffice.org, que en esa época era el creado por Santiago Rodríguez y Jesús Carretero, llamado COES (http://www.datsi.fi.upm.es/~coes/espell_leame/espell_leame.html). El problema con COES justamente era el licenciamiento. No se podía integrar en la distribución de OpenOffice.org porque se distribuía bajo licencia GPL y OpenOffice.org te exigía que cualquier colaboración tuviera licencia LGPL. Esto obligaba a que tuvieras que descargarlo e instalarlo manualmente, cosa que para la época no era tan sencillo, dada la escasa disponibilidad de acceso a Internet y conocimientos específicos sobre cómo modificar los ficheros de configuración de la instalación de OpenOffice.org (todavía figuran esas instrucciones en el fichero README que se incluye en el paquete, las cuales creo que ya podría eliminarse).

El espíritu del que hablo tiene dos lógicas diferenciadas:
· Para el caso de los ficheros "fuente", que vendrían siendo los listados de palabras, afijos, herramientas de compilación, etc., la idea era mantener todo en GPL ya que es la licencia que obliga a que cualquier trabajo derivado desde el nuestro también deba ser publicado bajo GPL y entonces el proyecto nuestro puede incorporar cualquier avance o mejora disponible en cualquier otro proyecto derivado sin incurrir en problemas con los autores de los trabajos derivados.
· Para el caso de los ficheros de extensión compilados que publicamos, y específicamente haciendo referencia a los ficheros es_XX.dic y es_XX.aff incluidos en el paquete en forma "compilada" que se encuentran dentro del fichero de extensión .oxt se permite el licenciamiento con las tres licencias disjuntas GPL / LGPL / MPL. Esto es para permitir que se pueda distribuir con cualquier software sin que quienes lo publican incurran en problemas con nuestra autoría.

Si se quieren añadir las licencias de Creative Commons, y repito que sin ser un experto, creo que ese mismo espíritu se mantendría si en los ficheros fuente se utiliza una licencia CC-BY-SA, y en las extensiones compiladas una CC-BY.

[olea]

Si se quieren añadir las licencias de Creative Commons, y repito que sin ser un experto, creo que ese mismo espíritu se mantendría si en los ficheros fuente se utiliza una licencia CC-BY-SA, y en las extensiones compiladas una CC-BY.

Donde yo haría la excepción es con todo lo que sean listas de palabras puras, sin ninguna clase de codificación spell y es para que sean lo más reutilizables posibles, en este caso usando la licencia CC-BY. Lo justifico por aquello de que la lengua es un procomún (lo que es de todos y de nadie al mismo tiempo). Y me atrevería a decir que tanto para listas de palabras usadas como fuentes para el diccionario como aquellas que puedan generarse automáticamente.

Para el código fuente codificado hay un trabajo extra más allá de la mera compilación y es específico para unas tecnologías y, aunque pueda sonar raro a algunos oídos, con un aspecto ideológico que además comparto. En este sentido el licenciamiento GPL/LGPL/MPL me sigue pareciendo oportuno.

[Almorca]

Retormo este hilo.
¿Se podrían añadir los gentilicios y listados de municipios como CC-BY y esta licencia no tendría problemas en convivir con las GPL/LGPL/MPL?

[cosmoscalibur]

Retormo este hilo.
¿Se podrían añadir los gentilicios y listados de municipios como CC-BY y esta licencia no tendría problemas en convivir con las GPL/LGPL/MPL?

En teoría no hay incompatibilidad @Almorca , dado que CC-BY es una licencia para contenido y la lista de municipios es simplemente una colección de lemas sin labor adicional distinta a la recopilación (CC-BY la recomiendan para conjuntos de datos). Sin embargo, los gentilicios tendrían la acotación que menciona @olea sobre el trabajo extra y por ende sería posible asociar CC-BY y de hacerlo, no habría un criterio de porqué aplica para gentilicios y no para el resto de lemas.
Yo veo que en general, cualquier lema asociado a un nombre propio, por ser solo una recopilación, puede cumplir el criterio para ser CC-BY.

[olea]

Me vais a disculpar que me desdiga en una cosa, que no sé por qué la expresé mal:

listas de palabras puras, sin ninguna clase de codificación spell y es para que sean lo más reutilizables posibles, en este caso usando la licencia CC-BY.

debería haber dicho CC0, que, por ejemplo, uso en lemarios, por el mismo argumento que presentaba:

la lengua es un procomún (lo que es de todos y de nadie al mismo tiempo).

Además CC0 es compatible con la familia GPL/LGPL/MPL.

Aunque se entiende que el espíritu viene a ser el mismo.

Disculpad el ruido.

[Almorca]

Vuelvo al inicio del issue y al fondo del asunto. El objetivo es buscar un método que nos permita usar la información de la Wikipedia para ahorrar trabajo con los gentilicios, apellidos, ciudades, etc.

Actualmente la Wikipedia está bajo Creative Commons Atribución-CompartirIgual 3.0 Unported

[olea]

Vuelvo al inicio del issue y al fondo del asunto. El objetivo es buscar un método que nos permita usar la información de la Wikipedia para ahorrar trabajo con los gentilicios, apellidos, ciudades, etc.

Actualmente la Wikipedia está bajo Creative Commons Atribución-CompartirIgual 3.0 Unported

Entiendo.

Personalmente creo que no se tendría ninguna restricción legal: no se estarían modificando contenidos ni produciendo trabajos derivados. Supongo que tal vez sí pudiera haber condiciones de copyright para las propias colecciones de palabras, que sería el trabajo original de rla-es en este caso.