Cómo elegir una licencia para su obra

Esta es una traducción de la página original en inglés.

El mantenimiento de esta página está a cargo de la Oficina de Licencias y Cumplimiento de la FSF. Puede apoyar nuestros esfuerzos mediante una donación a la FSF. Si no encuentra aquí la respuesta a alguna duda, consulte nuestros otros recursos para licencias o póngase en contacto con nosotros enviando un correo a licensing@fsf.org.

Para saber si una licencia es libre o no, consulte nuestra lista de licencias y la definición de software libre.

Introducción

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.

Veamos ahora las excepciones.

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 laxa (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 (una licencia de software no puede hacerlo), 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.

Entre las licencias permisivas, la Apache 2.0 es la mejor. Así que, si por cualquier motivo va a emplear una licencia permisiva, esta es la que recomendamos.

Bibliotecas

Para las bibliotecas, distinguimos tres tipos de casos.

Algunas bibliotecas implementan estándares libres que compiten con estándares restrictivos, como Ogg Vorbis (que compite con MP3) y WebM (que compite con MPEG-4). En estos proyectos, un amplio uso del código es vital para promover la causa del software libre y aporta más beneficios que licenciar el código bajo copyleft.

En estas situaciones especiales recomendamos la Licencia Apache 2.0.

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 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 (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.