Cómo elegir una licencia para su obra

La gente nos pregunta a menudo qué licencia le recomendaríamos utilizar para su proyecto. Ya hemos escrito sobre esto antes, pero la información está dispersa por diferentes artículos, preguntas frecuentes y comentarios sobre las licencias. Toda esa información se recoge en este artículo, para facilitar la consulta y usarlo como referencia.

Estas recomendaciones se refieren a trabajos diseñados para uso práctico tales como software y documentación, entre otros. Las obras artísticas y las que exponen algún punto de vista son tema aparte; el proyecto GNU no tiene una postura general sobre cómo se deben publicar, excepto que se deben poder utilizar sin software privativo (en particular, sin DRM). Sin embargo, se pueden seguir estas recomendaciones para obras artísticas que acompañen a un programa determinado.

Las recomendaciones se aplican a la licencia de una obra que usted crea, ya sea la modificación de una obra existente o una nueva obra original. Estas recomendaciones no abordan el problema de combinar material existente bajo diferentes licencias. Si busca ayuda al respecto, consulte nuestra lista de preguntas frecuentes sobre la GPL.

Si luego de ver lo que recomendamos aquí desea asesoramiento, puede escribir a <licensing@gnu.org>. Recuerde que a la oficina de licencias probablemente le tomará varias semanas responder; si no obtiene respuesta en un mes, por favor escriba de nuevo.

Contribución a un proyecto existente

Cuando se contribuye a un proyecto existente, la versión modificada se debe publicar bajo la misma licencia que la obra original. Es bueno cooperar con quienes mantienen el proyecto, y usar una licencia distinta para las modificaciones suele dificultar la cooperación. Debe hacerlo únicamente cuando exista una razón de peso que lo justifique.

Un caso en el que se puede justificar el uso de una licencia distinta es cuando se realizan cambios significativos en una obra que está bajo una licencia sin copyleft. Si la versión que usted ha creado es considerablemente más útil que el original, entonces merece ser licenciada con copyleft, por los mismos motivos por los que habitualmente recomendamos el copyleft. Si se encuentra en esta situación, por favor siga las recomendaciones que señalamos más abajo para la licencia de un nuevo proyecto.

Si por cualquier motivo opta por publicar sus contribuciones bajo una licencia distinta, debe asegurarse de que la licencia original permita el uso del material bajo la licencia que ha elegido. Para ser honesto, indique explícitamente qué partes del trabajo se encuentran bajo qué licencia.

Software

Recomendamos diferentes licencias para diferentes proyectos, dependiendo principalmente del propósito del software. En general recomendamos usar la licencia con copyleft más fuerte que no interfiera con ese propósito. Nuestro artículo «¿Qué es el Copyleft?» explica el concepto de copyleft más detalladamente y por qué generalmente se lo considera como la mejor estrategia de licenciamiento.

Para la mayoría de los programas recomendamos utilizar la versión más reciente de la Licencia Pública General de GNU (GPL) para su proyecto. Su copyleft fuerte es apropiado para todo tipo de software, e incluye numerosas protecciones para la libertad de los usuarios. Para permitir la utilización de versiones futuras de la licencia, especifique «versión 3 o cualquier versión posterior». De ese modo su programa será compatible con el código que en el futuro pueda publicarse bajo las siguientes versiones de la GPL.

Aquí dispone de más información acerca de cómo publicar un programa bajo la GPL de GNU.

Nos referiremos ahora a las excepciones, los casos en los que es mejor utilizar alguna otra licencia en lugar de la GPL de GNU.

Programas pequeños

Para la mayoría de los programas pequeños, usar el copyleft no amerita el esfuerzo. Nosotros tomamos como referencia las 300 líneas: cuando el código fuente de un paquete de software tiene menos de 300 líneas, los beneficios que proporciona el copyleft suelen ser demasiado pequeños para justificar la inconveniencia de asegurarse que una copia de la licencia acompañe siempre al software.

Para esos programas recomendamos la Licencia Apache 2.0. Se trata de una licencia de software débil, laxa, «blanda» (sin copyleft), que contiene cláusulas para evitar que contribuidores y distribuidores sean demandados por violación de patentes. Esto no inmuniza al software frente a amenazas de patentes (ninguna licencia de software puede lograrlo), pero impide que los propietarios de las patentes utilicen el señuelo de publicar el software bajo términos libres y luego, en una licencia de patente, requieran que los destinatarios acepten términos que no son libres.

La licencia Apache 2.0 es la mejor de las licencias débiles (blandas). Así que, si por el motivo que sea va a emplear una licencia débil, esta es la que recomendamos.

Bibliotecas

Para las bibliotecas, distinguimos tres tipos de casos.

Algunas bibliotecas implementan formatos de datos libres que compiten con formatos de datos restrictivos, como Ogg Vorbis (que compite con MP3) y WebM (que compite con MPEG-4). El éxito del formato libre requiere que se permita que muchos programas de aplicaciones privativas enlacen con el código para manejar el formato. Por ejemplo, queríamos que los reproductores de audio privativos, especialmente los equipos de música, incluyeran código para Ogg Vorbis al igual que para MP3.

En estas situaciones especiales, si queremos convencer a los desarrolladores de aplicaciones privativas de que utilicen la biblioteca para el formato libre, tendremos que facilitárselo empleando para la biblioteca una licencia débil, como la Licencia Apache 2.0.

No obstante, hemos de reconocer que esta estrategia no tuvo éxito en el caso de Ogg Vorbis. Después de haber cambiado la licencia para facilitar la inclusión de esa biblioteca en las aplicaciones privativas, los desarrolladores de estas aplicaciones por lo general siguieron sin incluirla. El sacrificio que hicimos al elegir la licencia obtuvo al final escasa recompensa.

Para todas las demás bibliotecas recomendamos algún tipo de licencia con copyleft. Si los desarrolladores ya están utilizando una biblioteca alternativa bien establecida publicada bajo una licencia que no es libre o una licencia blanda, permisiva, entonces recomendamos usar la Licencia Pública General Reducida de GNU (GNU LGPL).

A diferencia del primer caso, donde la biblioteca implementa un estándar éticamente superior, aquí la adopción del código no servirá por si misma a ningún objetivo en particular, así que no hay motivo para evitar completamente una licencia con copyleft. No obstante, si a los desarrolladores que utilicen esa biblioteca usted les exige que publiquen sus programas completos bajo una licencia con copyleft, simplemente utilizarán alguna de las alternativas disponibles, y eso tampoco favorecerá nuestra causa. La GPL reducida se diseñó para colmar la brecha entre estos casos, ya que permite que los desarrolladores de software privativo utilicen la biblioteca en cuestión, pero manteniendo una forma débil de copyleft que da libertad a los usuarios con respecto al código de la biblioteca misma.

Para las bibliotecas que proporcionan funciones especiales y no están expuestas a la competencia de otras que no tienen copyleft o no son libres, recomendamos utilizar la GPL de GNU ordinaria. Si desea conocer los motivos, consulte «Por qué en su próxima biblioteca no debería utilizar la Licencia Pública General Reducida de GNU (GNU LGPL)».

Software para servidores

Si existe la probabilidad de que otros hagan versiones mejoradas de su programa para ejecutar en servidores sin distribuirlas a nadie más, y si le preocupa que esto ponga en desventaja la versión que usted ha publicado, recomendamos utilizar la Licencia Pública General Affero de GNU (AGPL). Los términos de la licencia AGPL son prácticamente idénticos a los de la GPL; la única diferencia sustancial es que incluye una cláusula adicional para garantizar que las personas que utilizan el software en red puedan obtener el código fuente correspondiente.

El requisito de la licencia AGPL no aborda los problemas que se les pueden presentar a los usuarios cuando confían sus tareas informáticas o sus datos a un servidor ajeno. Por ejemplo, no impedirá que el servicio sustitutivo del software (SaaSS) prive de su libertad a los usuarios, pero la mayoría de los servidores no utilizan SaaSS. Si desea saber más sobre estos asuntos, consulte «Por qué usar la licencia Affero GPL».

Documentación

Para tutoriales, manuales de referencia y otros trabajos extensos de documentación recomendamos la Licencia de Documentación Libre de GNU (GFDL). Es una licencia con copyleft fuerte para trabajos educativos, inicialmente escrita para manuales de software, que incluye cláusulas enfocadas específicamente a problemas comunes que surgen cuando se distribuyen o modifican esos trabajos.

Para trabajos de documentación breves y secundarios, como tarjetas de referencia, es mejor usar la Licencia completamente permisiva de GNU, dado que la licencia GFDL difícilmente podría caber en una tarjeta de referencia. No use la CC BY, pues es incompatible con la GFDL.

Para páginas de manual recomendamos la GFDL si la página es extensa, y la Licencia completamente permisiva de GNU si es corta.

Hay documentación que incluye código fuente de software. Por ejemplo, un manual de un lenguaje de programación puede incluir ejemplos que faciliten la comprensión. Se deben incluir dentro del manual bajo los términos de la licencia FDL, y publicarlos bajo otra licencia que resulte apropiada para software. Hacerlo de esta forma facilita el uso del código en otros proyectos. Recomendamos poner los fragmentos pequeños de código en el dominio publico empleando la CC0, y distribuir los más extensos bajo la misma licencia que utiliza el proyecto de software asociado.

Otros datos de programas

En esta sección nos ocupamos de todas las demás obras de utilidad práctica que podrían incluirse con el software. Por señalar algunos ejemplos, se incluyen aquí los iconos y otros gráficos útiles o funcionales, tipos de letra y datos geográficos. También puede aplicar estas recomendaciones a las obras artísticas, aunque no le censuraremos si no lo hace.

Si está creando estas obras para utilizarlas específicamente con un proyecto de software, generalmente recomendamos que las publique bajo la misma licencia que el software. No hay problema de hacerlo con las licencias que hemos recomendado: la GPLv3, la LGPLv3, la AGPLv3 y la GPLv2 se pueden aplicar a cualquier tipo de obra (no solo software) que pueda estar sujeta a copyright y que tenga una forma preferida y clara para su modificación. Emplear la misma licencia que en el software facilitará su cumplimiento a los distribuidores y evitará dudas sobre posibles cuestiones de compatibilidad. Utilizar una licencia libre distinta puede resultar apropiado si proporciona algún beneficio práctico, como una mejor cooperación con otros proyectos libres.

Si su obra no se ha creado para utilizarse con un proyecto de software en particular, o si no fuera apropiado utilizar la misma licencia que en el proyecto, entonces únicamente le recomendamos que elija una licencia con copyleft apropiada para su trabajo. Algunas de ellas se encuentran en nuestra lista de licencias. Si ninguna de ellas parece especialmente apropiada, la licencia Creative Commons Reconocimiento-CompartirIgual es una licencia con copyleft que puede utilizarse para varios tipos diferentes de obras.