Librebits - jordila_@i-ching:~/

Bits aleatorios de Software Libre / Libre Software ...

GNU: 'Como Escoger Una Licencia Para Tu Propia Obra ?' V2

Traducción para el Proyecto GNU

original : https://gnu.org/licenses/license-recommendations.html

Como escoger una licencia para tu propia obra?

El Free Software Foundation’s Licensing and Compliance Lab. mantiene esta página. Puedes dar apoyo a nuestro esfuerzo mediante una donación a la FSF. ¿Quedó acá alguna pregunta si responder al respecto? Comprueba algunos de nuestros recursos sobre licencias o contacta al Compliance Lab en licensing@fsf.org

Introducción

A menudo nos preguntan que licencia recomendamos para usar en un determinado proyecto. Hemos escrito públicamente sobre esta cuestión con anterioridad, pero la información está diseminada en varios documentos, FAQ y comentarios sobre licencias. Este artículo recolecta toda esa información en única fuente, para simplicar el acceso a ella y facilitar su referenciado a la comunidad. Estas recomendaciones se orientan a obras diseñadas para la realización de tareas prácticas. Incluyendo software, documentación y más. Obras artísticas, o que promuevan un punto de vista son cuestiones de diferente ámbito; el Proyecto GNU no tiente una postura general de como deberían publicarse más allá de que deberían ser todas utilizables sin software que no sea libre (particularmente libre de DRM). Sin embargo, puede resultar útil seguir estas recomendaciones para obras artísticas que acompañen a un determinado programa.

Las recomendaciones aplican a la licenciamiento de una obra creada por tí—tanto si es una modificación de una obra existente, o una nueva obra original. No cubren el caso en que se combina material existente bajo diferentes licencias. Si buscas ayuda en este aspecto, por favor consulta nuestra GPL FAQ. Después de ver nuestras recomendaciones, si quieres asesoramiento, puedes escribir a licensing@gnu.org. Resaltar que probablemente tome varias semanas la respuesta por parte del equipo de licenciamiento; si en un mes no recibiste respuesta, por favor, escríbenos de nuevo.

Contribuyendo a un nuevo proyecto Al contribuir a un proyecto existente, deberías habitualmente publicar las modificaciones realizadas bajo la misma licencia que la obra original. Es positivo cooperar con los que mantienen el proyecto, y usar una licencia diferente para tus modificaciones a menudo convierte la cooperación en algo muy dificultoso. Deberías hacer eso únicamente por motivos de fuerza mayor. Un caso en el que puede justificarse el uso de una licencia diferente es cuando realizas cambios en una obra que no es copyleft. Si la versión creada es considerablemente más útil que la original, entonces merece la pena hacer tu obra copyleft. Si te encuentras en esta situación, por favor sigue las recomendaciones más abajo para el licenciamiento de un nuevo proyecto. Si eliges licenciar tus contribuciones bajo una licencia diferente, por el motivo que sea, debes comprobar antes que la licencia original permite el uso de material bajo tu licencia de elección. Para minimizar el posible impacto en otros, muestra explicitamente que partes de la obra están bajo que licencia.

Software

Recomendamos diferentes licencias para diferentes proyectos, dependiendo principalmente en el propósito del software. Generalmente, recomendamos usar la licencia más restrictiva que no interfiera con dicho propósito. Nuestro ensayo “Qué es el copyleft?” explica el concepto de copyleft en más detalle, y porque es de forma general la mejor estrategia de publicación. Hay sólo un par de tipos de proyectos en los que pensamos sería mejor no usar copyleft de ningún tipo. El primero es en proyectos muy pequeños. Usamos 300 líneas como umbral: cuando el código fuente es menor que esto, los beneficios generados por el copyleft son usualmente inapreciables para justificar la inconveniencia de asegurarse de que una copia de la licencia siempre acompañe al software. El segundo caso es en proyectos que implementan estándares que están en confrontación con estándares propietarios, como Ogg Vorbis (que compite con el audio MP3) y WebM (que compite frente a video MPEG-4). Para estos proyectos, extender el uso del código es vital para avanzar en la causa del software libre, y en si mismo hace mucho más que el copyleft del código del proyecto pudiera hacer. En estas situaciones especiales en las que el copyleft es inapropiado, recomendamos usar la Apache License 2.0 . Está es una licencia software no copyleft que incluye términos para prevenir denuncias de infracción de patentes por parte de distribuidores y contribuyentes. Ello no inmuniza al software de las amenazas de las patentes, pero impide que los que ostentan las patentes establezcan la dinámica de publicar ese software en términos libres para luego requerir a los receptores un acuerdo en términos no libres en una licencia de patente (licencia laxa,“bait and switch”).

En todos los otros casos, recomendamos alguna forma de copyleft. Si tu proyecto es una librería, y los desarrolladores ya están usando un librería alternativa establecida publicada bajo una licencia no libre o una licencia laxa como la mencionada anteriormente, entonces recomendamos usar la GNU Lesser General Public License (LGPL). Al contrario que en el caso discutido anteriormente, en el que el proyecto implementa un estándar, acá la adopción por si misma no alcanza ningún objetivo particular, por lo que no hay motivo para evitar el copyleft por completo, Sin embargo, si requieres a los desarrolladores que usan tu librería para publicar su obra bajo una licencia enteramente copyleft, simplemente usarán una de las alternativas disponibles, y ello no permitirá avanzar tampoco en nuestra causa. La Lesser GPL fue diseñada para cubrir el término medio entre ambos casos, permitiendo a los desarrolladores de software propietario usar la librería cubierta, pero proporcionando cierto beneficio copyleft que revierta en los usuarios en su caso. Para saber más sobre el razonamiento subyacente en estos casos, lee “ “Why you shouldn’t use the Lesser GPL for your next library” Si tu proyecto pudiera ser ejecutado en un servidor después de haber sido mejorado por otros, interactuando con sus usuarios a través de una red, y te preocupa que se reduzca el número de desarrolladores contribuyendo a las versiones publicadas como resultado, recomendamos la GNU Affero General Public License (AGPL). Los términos de la AGPL son prácticamente idénticos a los de la GPL; la única diferencia sustancial es que se agrega una condición extra para asegurar que aquellos que usen el software en red tendrán la facilidad de obtener su código fuente. Esta condición no resuelve todos los problemas que pueden derivar cuando los usuarios realizan su computación en un servidor—no evitará que los usuarios se vean afectados por el Software como Servicio—por cumple con todo aquello que puede cumplir una licencia. Para saber más sobre estas cuestiones, lee “Why the Affero GPL”. En cualquier otro caso, recomendamos que uses la versión más reciente de la GNU General Public License (GPL) para tu proyecto. Su restrictivo copyleft es apropiado para cualquier tipo de software, incluyendo numerosas protecciones para la libertad de los usuarios.

Documentación

Recomendamos la GNU Free Documentation License (GFDL) para tutoriales, manuales de referencia y otros complejas obras de documentación. Es una restrictiva licencia copyleft para obras educativas, inicialmente escritas como manuales de software, incluyendo términos que espefícamente resuelven cuestiones típicas que derivan de la distribución y modificación de estas obras. En pocas palabras, en obras de documentación derivadas, como tarjetas de referencia, es mejor el uso de una licencia GNU permisiva, ya que la copua de GFDL difícilmente podría abarcar una tarjeta de referencia. No uses CC-BY, puesto que es incompatible con la GFDL. Para páginas de manual, recomendamos la GFDL si la página es larga, y la licencia GNU permisiva si es una página corta. Cierta documentación incluye código fuente. Por ejemplo, un manual para un lenguaje de programación podría incluir ejemplos para seguir por parte de los lectores. Deberías incluir estos en el manual bajo términos FDL, y publicarlos bajo otra licencia apropiada para el software. Al hacerlo, se facilita el uso del código en otros proyectos. Recomendamos que dediques pequeñas piezas de software al dominio público usando CC0, y distribuir piezas más amplias bajo la misma licencia que usa el proyecto software asociado.

Otros datos para programas

Esta sección trata el resto de obras para uso práctico que pudieras incluir con el software. Para darte algunos ejemplos, ello incluiría iconos y otros gráficos, fuentes, y datos geográficos funcionales o útiles. También se podría aplicar a artes, a pesar de que no se criticaría el hecho de no hacerlo. Si estás creando estas obras específicamente para usar en un proyecto software, generalmente recomendamos que publiques tu obra bajo la misma licencia que el software. No hay problema ninguno en hacerlo con las licencias recomendadas : GPLv3, LGLPv3, AGPLv3, y GPLv2 pueden ser aplicadas a cualquier tipo de obra—no únicamente software—susceptible de copyright y que denote claramente la predisposición a la modificación. Al usar la misma licencia que el software facilitará el cumplimiento por parte de los distribuidores, y evita cualquier duda sobre potenciales cuestiones de compatibilidad. El uso de una licencia libre diferente podría ser apropiado si provee de algún beneficio práctico específico, como una mejor cooperación con otros proyectos libres. Si tu obra no se crea para el uso en un proyecto software específico, o si pudiera ser inapropiado usar la misma licencia que el proyecto, entonces únicamente recomendamos la elección de una licencia copyleft apropiada para tu obra. Algunas de ellas se muestran en nuestra lista de licencias. Si ninguna licencia parece especialmente apropiada, la licencia Creative Commons Atribution-ShareAlike es una licencia copyleft que puede ser usada para una variedad de obras.

#license:CC-by-nd-3.0