Eligiendo una licencia

Cuando eliges una licencia para aplicarla a tu proyecto, si es posible usa una licencia existente en vez de crear una nueva. Hay dos razones por la que licencias existentes son una mejor opción:

Para aplicar una de estas licencias a tu proyecto, lee “Cómo aplicar una licencia a nuestro software” en Capítulo 2, Primeros Pasos.

La MIT / X Window System License

Si tu objetivo es que tu código sea accesible para el mayor número de desarrolladores y trabajos derivados posible, y no te importa que el código se pueda utilizar en software propietario, elije la MIT / X Window System license (llamada así debido a que es la licencia bajo la cual el Massachusetts Institute of Technology lanzó el código original del sistema de ventanas X). El mensaje básico de esta licencia es "Eres libre para usar este código como quieras.". Es compatible con la GNU GPL, y es corta, sencilla, y fácil de entender:

Copyright (c) <año> <propietarios del copyright>

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

(Tomada de http://www.opensource.org/licenses/mit-license.php.)

La GNU General Public License

Si prefieres que tu código no sea utilizado en software propietario, o si, al menos, no te importa si puede o no usarse en éstos, elije la GNU General Public License (http://www.fsf.org/licensing/licenses/gpl.html). La GPL es probablemente la licencia de software libre más utilizada en el mundo a día de hoy; este capacidad de reconocerse en ella es una de las mayores ventajas de la GPL.

Cuando programamos una biblioteca cuyo fin es ser usada en otros programas, considera detenidamente si las restricciones que la GPL impone concuerdan con los objetivos de tu proyecto. En algunos casos — por ejemplo, si intentas desbancar una biblioteca propietaria competidora que realiza la misma función — tiene un sentido más estratégico el licenciar tu código de modo que pueda ser utilizada en software propietario, incluso aunque no lo desearas. La Free Software Foundation preparó una alternativa a la GPL para esas circunstancias: la GNU Library GPL, después renombrada como GNU Lesser GPL (la mayoría de la gente utiliza directamente el acrónimo LGPL, de todos modos). La LGPL tiene restricciones menos estrictas que la GPL, y puede mezclarse más fácilmente con código no libre. Sin embargo, también es más compleja y toma más tiempo entenderla, por lo que si no vas a utilizar la GPL, te recomiendo utilizar una licencia tipo MIT/X.

¿Es la GPL libre o no?

Una consecuencia de elegir la GPL es la posibilidad —pequeña, pero no infinitesimal— de encontrarte a ti o a tu proyecto envueltos en una disputa acerca de si la GPL es o no realmente libre, dado que exige ciertas restricciones en qué puedes hacer con el código—a saber, la restricción de que el código no puede ser redistribuído bajo ninguna otra licencia. Para algunos, la existencia de esta restricción significa que la GPL es "menos libre" que otras licencias más permisivas como la licencia MIT/X. El fin de este argumento generalmente es, por supuesto, que dado que "más libre" debe ser mejor que "menos libre" (después de todo, ¿quién no está a favor de la libertad?), esas licencias son mejores que la GPL.

Este debate es otra guerra santa (veáse “Evitando las Guerras Santas” en Capítulo 6, Comunicaciones) muy popular. Evita participar en ella, al menos en foros del proyecto. No intentes probar que la GPL es menos libre, tan libre o más libre que otras licencias. En vez de eso, explica las razones específicas por las que elegiste la GPL para tu proyecto. Si fue el conocimiento de la licencia, di eso. Si también fue por las restricciones de licencia libre para trabajos derivados, dilo también, pero niégate a discutir acerca de si esto hace al código más o menos libre. La libertad es un tema complejo, y no tiene mucho sentido hablar de ella si la terminología que va a ser utilizada como alimento para un caballo de acecho.

Dado que esto es un libro y no un hilo de una lista de correo, sin embargo, admitiré que nunca entendí el argumento "la GPL no es libre". La única restricción que la GPL impone previene a la gente de imponer mayores restricciones. Decir que eso significa tener menos libertad siempre me ha parecido como decir que la abolición de la esclavitud reduce la libertad, porque previene que cierta gente posea esclavos.

(Oh, y si te ves inmerso en un debate sobre ello, no subas la apuesta haciendo analogías incendiarias.)

¿Qué tal la licencia BSD?

Una gran cantidad de software libre se distribuye bajo la licencia BSD (o algunas veces una licencia estilo BSD). La licencia original BSD fue usada por la Berkeley Software Distribution, en la que la Universidad de California lanzó partes importantes de una implementación de Unix. Esta licencia (el texto exacto puede verse en la sección 2.2.2 de http://www.xfree86.org/3.3.6/COPYRIGHT2.html#6) era similar en esencia a la licencia MIT/X, excepto por una claúsula:

Todo material publicitado que mencione características o use este software debe mostrar la siguiente advertencia: "Este producto contiene software desarrollado por la Universidad de California, Lawrence Berkeley Laboratory.

La presencia de esta claúsula no sólo hace a la BSD incompatible con la GPL, sino que también sienta un peligroso precedente: mientras otras organizaciones pongan claúsulas publicitarias similares en su software libre —sustituyendo su propio nombre en lugar de "la Universidad de California, Lawrence Berkeley Laboratory"— los redistribuidores del software se enfrentan a una creciente carga en cuanto a lo que se ven requeridos a mostrar. Afortunadamente, muchos de los proyectos que usaron esta licencia se percataron del problema, y simplemente eliminaron esa claúsula. En 1999, incluso la Universidad de California lo hizo.

El resultado es la licencia BSD revisada, que es simplemente la licencia BSD original sin la claúsula publicitaria. Sin embargo, la historia hace a la expresión "licencia BSD" un poco ambigua: ¿se refiere a la original, o a la versión revisada? Por esto es por lo que prefiero la licencia MIT/X, que es equivalente en esencia, y no sufre ninguna ambigüedad. Sin embargo, quizá hay una razón para preferir la BSD revisada frente a la licencia MIT/X, que es que la BSD incluye esta claúsula:

Ni el nombre de la <ORGANIZACIÓN> ni los nombres de sus contribuyentes debe usarse para apoyar o promocionar productos derivados de este software sin permiso previo por escrito explícito.

No queda claro que sin esa claúsula, un receptor del software podría tener el derecho a usar el nombre del autor, pero esa claúsula borra cualquier tipo de duda. Para organizaciones preocupadas por el control de marcas registradas, por lo tanto, la licencia BSD puede ser preferible a la MIT/X. En general, sin embargo, una licencia de copyright liberal no implica que los receptores tengan ningún derecho a usar sus marcas — las leyes de copyright y las leyes de marcas son dos cosas diferentes.

Si quieres utilizar la licencia BSD revisada, una plantilla está disponible en http://www.opensource.org/licenses/bsd-license.php.