El tema de las licencias de software es un tema bastante aburrido, no nos vamos a engañar, pero también es importante y hay mucha gente que no lo tiene claro, así que voy a dedicar un post a explicar un poco qué significan todas esas cosas de GPL, LGPL, MIT, Apache, etc.
Además, en España parece que la creencia popular es que si algo es gratis puedo hacer con ello lo que me dé la gana, y si es open source ya ni te cuento. Pues bien, esto no es así, y si quieres ser respetuoso (y legal) no está de más que entiendas qué tipos de licencia de software existen, qué implicaciones tiene cada una y qué nos permiten hacer sin infringir el acuerdo de licencia.
OJO: ni yo soy un abogado, ni éste es un blog sobre temas legales, así que no te tomes al pie de la letra lo que voy a contar. El objetivo es entender un poco como funciona todo esto, si necesitas una rigurosidad mayor, hay fuentes mucho mejores que este blog para obtenerla.
¿Qué es una licencia de software?
Una licencia de software es un contrato que se establece entre el «dueño» del software y el usuario del mismo que marca las condiciones bajo las cuales se puede usar. Pongo «dueño» así, entre comillas, porque realmente habría que entrar en temás más complicados sobre autoría, propiedad intelectual, derechos de explotación y cosas del estilo, pero creo que todos nos hacemos una idea de a lo que se refiere.
Cualquier usuario está familiarizado con este concepto. Casi todas las aplicaciones te obligan a aceptar un acuerdo de licencia en algún momento durante la instalación o antes de empezar a usarlas y, aunque nadie se lo lea, ese contrato está marcando lo que se puedes hacer y lo que no puedes hacer con esa aplicación.
En el caso de las librerías o componentes que usamos para desarrollar software, pasa exactamente lo mismo. Cuando instalas un paquete con NuGet, npm o gem, o descargas una librería de internet, ésta lleva asociadas unas condiciones de uso que deberías respetar. El problema es que, como decía antes, cuando algo es gratis, parece que automáticamente te da derecho a usarlo como quieras, pero no es así.
¿Qué se controla con la licencia de una librería?
Es fácil imaginarse qué se restringe con las licencias de las aplicaciones para usuarios finales. Por ejemplo, tu licencia de Windows te permitirá instalarlo en un equipo, no te permitirá copiarlo ni revenderlo y no te permitirá desensamblarlo ni hacer ingeniería inversa.
Cuando compras componentes comerciales para desarrollo, las condiciones suelen ser similares, aunque además se debe establecer cómo funciona la redistribución (si es gratis o tienes que pagar por cada copia del componente que distribuyes).
Sin embargo, cuando piensas en un componente de software que instalas con NuGet, por ejemplo, log4net o NHibernate, ¿qué cosas me puede marcar o restringir, si se trata de un software gratuito y de código abierto?
Lo que se puede restringir con una licencia es algo muy abierto y, supongo que mientras no vulnere las leyes de cada país (por ejemplo, no discrimine a nadie por cuestión de raza), podrás hacer más o menos lo que quieras, como impedir que tu software se ejecute los martes y 13 si eres triscaidecafóbico, pero al final todas las licencias marcan más o menos los mismos puntos.
Por una parte, una licencia puede permitir o no el uso comercial. Hay librerías que son de código abierto pero no se pueden usar en proyectos comerciales. Hay otros casos en que existe una licencia dual, generalmente para permitir el uso gratuito en proyectos open source y el uso de pago para proyectos comerciales. Un ejemplo de esto es el modelo de licenciamiento de RavenDB.
También se pueden limitar las plataformas de uso. Esto es más frecuente en el caso de librerías procedentes de fabricantes que, por algún motivo, deciden que sólo se pueden usar una plataforma concreta, aunque técnicamente sea posible utilizarlas en más. Es el caso de Microsoft y algunas librerías que, aunque podrían funcionar sin problemas en iOS y Android a través de MonoTouch y MonoDroid, no se pueden usar legalmente.
Otro factor fundamental es la «viralidad» de la licencia. Hay algunas licencias (la más conocida es la GPL) que, entre sus condiciones de uso, marca que una aplicación que use componentes GPL debe ser licenciada también como GPL.
Además, se pueden establecer restricciones a la forma en que se puede modificar (no usar) el software, por ejemplo forzando a que las modificaciones sean publicadas bajo una licencia concreta (caso de LGPL) o distribuyan una copia de la licencia original, o citen a los autores, etc.
Tipos de licencias
En base a los puntos explicados anteriormente, vamos a ver algunas de las licencias más habituales y cómo nos afectan:
- Dominio Público / Public Domain
Puedes hacer lo que quieras, sin ningún tipo de restricción. Puedes usarlo, copiarlo, modificarlo, venderlo. En serio, cualquier cosa que se te ocurra.
- MIT
Es una licencia muy permisiva que admite el uso comercial, la redistribuición, la modificación, etc. La única condición es que proporcionemos una copia de la licencia con el software que hemos distribuido.
- Apache
A efectos prácticos, muy similar a la licencia MIT, aunque otorga algunas garantías más al usuario del software.
- GPL / GNU General Public License
Esta licencia permite el uso, la modificación y la comercialización del software pero obliga a que cualquier modificación del software o aplicación que use el software y sea distribuida sea licenciada también con licencia GPL, lo que implica, entre otras cosas, que el código fuente esté disponible.
Es la licencia viral por excelencia y seguramente haya sido determinante para que el software libre haya llegado tan lejos y, a la vez, para que muchas empresas no quieran usar librerías open source ya que piensan que todo lo que use open source debe ser liberado también como open source.
Si estás trabajando en un producto con código cerrado y piensas distribuirlo, una librería con licencia GPL no te sirve para nada. Si no piensas distribuirlo, por ejemplo porque es de uso interno o está instalado en tu servidor (aunque éste sea accesible de forma externa, caso de servicios como Facebook), no tienes obligación de ofrecer el código fuente.
- AGPL / GNU Affero General Public License
La licencia AGPL es similar a la GPL, pero cubre el caso de que instales tu aplicación basada en un componente AGPL en un servidor accesible de forma externa. En ese caso, deberás liberar también tu aplicación bajo licencia AGPL.
- LPGL / GNU Lesser General Public License
La licencia LGPL es una versión suavizada de la GPL y, aunque a la GNU Software Fundation no le guste mucho, me parece una licencia más racional.
Está pensada para librerías y establece que cualquier modificación de la librería debe ser también licenciada como LGPL, pero no impone ningún tipo de licencia a las aplicaciones que usen la librería. Es decir, mantiene el componente de viralidad sobre el trabajo derivado (modificaciones), pero no sobre el uso.
Hay muchos más tipos de licencias, entre ellos algunos creados por Microsoft (MS-PL, MS-RL), pero estos son los que más suelo ver. En la página de la Open Source Initiative hay una lista de licencias con sus características por si quieres profundizar en el tema.
Resumen
El mundo de las licencias de software no es la parte más divertida de nuestra profesión, pero es importante ser responsable y comprenderlas lo suficiente como para respetarlas. A fin de cuentas, si nosotros, que se supone que nos ganamos la vida haciendo esto, no respetamos las condiciones de licencia, ¿quién lo va a hacer?
Por cierto, todo esto de las licencias es aplicable no sólo a las librerías, sino también a esos iconos tan bonitos que te has bajado de internet o esas fotos que coges en flicker para tu página web. Ténlo en cuenta a la hora de usarlos.
Como curiosidad, la licencia del contenido de este blog (que seguro que nadie se ha parado a mirar, aunque esté puesta en el pie desde casi el primer día) es Attribution-NonCommercial-ShareAlike 3.0. Eso quiere decir que puedes compartir y/o modificar lo que quieras siempre y cuando cites la fuente original, no sea para fines comerciales y además las modificaciones las compartas con una licencia similar.
Gracias Juanma, eres un libro abierto, te explicas perfectamente. Reconozco ser de aquellos que no tenía claro el tema de las licencias, lo mas importante del post es como has trasmitido la importancia de entender y respetar los tipos de licencia, a partir de ahora prestare mas atención a la letra pequeña :-)
Buen artículo introductorio a un tema al que se le dá, lamentablemente, poco importancia. Sin embargo, hay una distinción importante que no mencionas y es que la viralidad de las licencias GLP/LGPL, y en general casi todas de este tipo, afectan a lo que has de hacer cuando DISTRIBUYES tu software. Es decir, si no distribuyes nada (es codigo propio que no vendes o pones a disposición de nadie) no tienes por que poner tu código bajo una licencia GLP o LGPL y «ofrecérsela al mundo».
Lo digo por que mucha gente cree que si usa una librería GPL, entonces tendrá que coger sus aplicaciones internas y publicarlas bajo la GPL para todo el mundo las vea. Y eso no es cierto. De hecho, esto genera un problema para las aplicaciones SAAS, que no se distribuyen (las aplicaciones web vamos), y de ahí la creación de la AGPL.
Y sólo añadir, y esto no va por el artículo, que hay que pensar «lo que se pide», por que es común ver a la gente diciendo que es «un rollo» esto de que alguien use la GPL o similar y «¿Por que no usa la MT o la Apache? Venga vaaaa». Con la Apache, y similares, básicamente estás regalando tu trabajo para que cualquiera se lucre con él, si puede, obviamente. Así que antes de pedirle a alguien que regale su trabajo, quizá habría que pensar lo que implica :).
S!
Muy buena puntualización sobre la distribuición del código cubierto con licencias GPL/LGPL, además no queda nada claro en el post, lo actualizaré en cuanto tenga un rato.
Con respecto a «pedir», pues bueno… por pedir que no quede. A mi la GPL me parece excesiva para una librería, la verdad, aunque la LGPL la encuentro razonable. Al final depende de lo que estés buscando cuando liberas el código.
Supongo que cuando Google libera angularjs con licencia MIT, es porque le interesa más la publicidad y las contribuciones externas que pueda conseguir (a base de pull request, bug reports, etc.) que evitar que otro pueda crear algo derivado y cobrar por ello.
Si, estoy de acuerdo contigo que para una librería, la GLP suele ser excesiva, a no ser que sea un bombazo que no quieras que caiga en malas manos, y de hecho yo suelo usar la LGPL. Pero vamos, al fin y al cabo es el trabajo de otro y aunque pedir es gratis, al fin y al cabo es el otro, el que la ha creado, el que tiene libertad de poner las condiciones que quiera. Pedir la LGPL me parece razonale, pedir la Apache, como se hace mucho ahora, no.
Google, Apache (IBM et al detrás) usan este tipo de licencias por que luego ellos mismos o sus clientes se lucran con los productos (IBM te vendía el Apache con otro nombre y código cerrado + soporte, no se si lo sigue haciendo), y a ver quien es el mindundi que les hace la competencia. En el eclipse es para no asustar a la gente y crear un ecosistema de plugins de pago. Etc.
Pero para una compañía pequeña o un mindundi solo, en cuanto despuntes un poco puede venir cualquiera de los anteriormente mencionados, coger tu código, cerrarlo, venderlo y ponerse las botas sin necesidad de «acquihire» ni leches. Cuanto más éxito la librería, más dulce el premio para el gorrón :).
Cierto, al final lo importante es respetar lo que decida el autor por muy ilógico/injusto que nos parezca. Si quiere licenciar la librería como GPL, o como código cerrado y cobrar por ella 15.000 euros, como tú dices, está en su derecho.
hola,
Tengo una duda respecto a la licencia MIT. Al leer esto: «La única condición es que proporcionemos una copia de la licencia con el software que hemos distribuido» no acabo de entender lo que significa.
Si pongo una copia de la licencia ¿mi programa también tendrá una licencia MIT? La aplicación que haga yo, ¿será propiedad mia o de la empresa de la que haya utilizado código con licencia MIT?
gracias ;-)
Buenas yo tengo una duda similar. “La única condición es que proporcionemos una copia de la licencia con el software que hemos distribuido” Esto que quiere decir exactamente. Es decir, que es lo que tengo que proporcionar.
En cuanto a tu licencia Attribution-NonCommercial-ShareAlike 3.0. Afecta también a los beneficios que pueda obtener por publicidad. Es decir, ¿podría mencionar este articulo en mi blog (que lleva publicidad, por la que obtengo unos ingresos) ?
Hola miquel y Nomelocremix,
No soy un abogado, pero creo que a lo que se refiere la licencia MIT es a que debes distribuir una copia de la licencia con tu software, indicando qué partes están sujetas a esa licencia.
Por ejemplo si tu software usa una librería SuperCool.dll licenciada bajo licencia MIT, y tu despliegas esa librería con tu software, deberías proporcionar también la licencia MIT indicando que se aplica a SuperCool.dll.
No es necesario que tu software tenga también licencia MIT (eso sólo pasa con las licencias «víricas» tipo GPL).
Un saludo.
Nomelocremix,
Independientemente de las licencias, hay algunos derechos que son irrenunciables y algunos usos que se consideran justos (o al menos lo eran hasta hace poco en España, que con las últimas leyes vete tú a saber).
Uno de ellos es (¿era?) el derecho a la cita. Si enlazas o mencionas un post mío, aunque tengas publicidad en el blog, se consideraría una cita y no habría problema.
Otra cosa es que copies un post mío entero en tu blog, o que recopiles varios posts y edites un libro con ellos.
Pero vamos, si tienes algún caso complicado de esos, podemos discutirlo por email.
Saludos.
Muchas gracias por contestar. Creo que no me he explicado bien.
En el primero comentario a lo que me refiero es a que si debo poner todo el chorro de lo que viene en http://opensource.org/licenses/MIT o sólo la parte del Copyright y ahora me surge otra pregunta al respecto. ¿dónde debo ponerla? Es decir, supongamos que utilizo jquery. ¿no basta con la mención de la licencia dentro de la libreria?.
En cuanto a lo otra pregunta era mera curiosidad, al leer las condiciones de la licencia (nunca había oido de esta licencia), he entendido que yo no podría utilizar este articulo por dos razones, porque utilizo mi página con fines comerciales (publicidad) y por que no utilizo una licencia similar
En el caso de una librería como jQuery, si el código fuente está «disponible» en tu aplicación web (por ejemplo, con botón derecho, ver código fuente), entiendo que mientras mantengas la información de licencia que aparece en el código, bastaría.
Si fuese una aplicación compilada que usase, por ejemplo, NHibernate, podrías añadir la información de licencia en el «Acerca de…» de tu aplicación, al estilo de lo que hace Firefox (en about:license) o podrías incluir un fichero con tu aplicación que se llamase nhibernate.license.txt con su información de licencia. Luego en tu manual, EULA o lo que tengas puedes indicar que se usan componentes de terceros con las licencias contenidas en los ficheros X, Y y Z.
Insisto, no soy abogado, pero creo que con eso debería bastar.
Con respecto a la licencia CC del blog, hay una diferencia entre citar y copiar. Si tú citas, da igual la licencia que tenga el post porque el derecho a la cita, al menos en la legislación española, no se puede evitar (tampoco tendría sentido). Si tu copias el texto entero, entonces sí estarías sujeto a la parte de «no comercial, compartir igual».
gracias juan maria
no se si pondré un About o license. Si lo pongo, el copyright de terceros los pondré ahí
Hola,
primero darle las gracias al autor por el fantástico trabajo que ha realizado y segundo me gustaría como actuar en librerías que tienen doble licencia, una GPL y otra MIT.
¿Podría utilizar la librería de forma gratuita en mi producto y este no tener licencia GPL? Es un producto en modo SaaS donde se cobra por usuario.
Gracias por vuestras respuestas.
Por ejemplo, este plugin de jquery utiliza doble licencia http://github.com/coderifous/jquery-localize
Copyright (c) Jim Garvin (http://github.com/coderifous), 2008.
Dual licensed under the GPL (http://dev.jquery.com/browser/trunk/jquery/GPL-LICENSE.txt) and MIT (http://dev.jquery.com/browser/trunk/jquery/MIT-LICENSE.txt) licenses.
Hola Antonio,
Lo de la licencia dual depende de cómo la haya establecido el propietario de los derechos.
Puede que existan restricciones (por ejemplo, que sea necesario pagar por el producto) para usar una de las dos licencias.
En el caso que mencionas, no veo que especifique nada, así que se supone que puedes aplicar la licencia que prefieras.
Un saludo,
Juanma
Gracias por tu respuesta Juanma.
Pingback: LICENCIA DE SOFTWARE | software135
Hola muchas gracias por el post, una pregunta, ¿cómo incluyo una librería con licencia apache en mi aplicación?
Hola Mario,
En principio, debería bastar con que indicaras que estás usando la librería X que tiene licencia Apache, e incluir el texto de la licencia (o al menos un enlace) junto a la aplicación.
Juan muchas gracias por la información, esta muy clara sin embargo traigo este reactivo que me trae de cabeza y quiero saber si tu sabes algo al respecto. Muchas gracias.
Para reducir los costos de licenciamiento en una empresa, su gerente ha solicitado al departamento de TI que realice una propuesta para disminuirlos, por lo que se implementa el uso de software con licencia GPL. ¿Cuál es el problema al cual se enfrentarán?
a) El tiempo excesivo en la instalación
b) Los sistemas operativos tienen más errores
c) La curva de aprendizaje es mayor para el usuario final
d) Los requerimientos técnicos de los equipos
Hola Rolas,
Nada de lo que mencionas está realmente ligado al tipo de licencia que tenga el software. Puedes encontrar software con licencia GPL complejo de instalar, y puedes encontrar software con licencia propietaria complejo de instalar.
En realidad, lo que comentas está más relacionado con la formación de la gente de implantación (ya sean empleados internos o proveedores externos) y con las características propias de cada software, que con el modo de licenciamiento elegido.
Un saludo,
Juanma.
Hola Rolas,
Si por ejemplo yo me descargo un proyecto ajeno de GitHub con Licencia Apache 2.0 y lo integro en mi proyecto, ¿cual sería el proceso?
Es decir, dejo la parte de su proyecto con su licencia (lo modifique o no) y en las partes que he creado yo sumo una copia propia de la Licencia Apache 2.0 con mi nombre. O por el contrario, al integrar su proyecto en el mio adjunto mi copia de Licencia Apache 2.0 y listo.
Gracias por la información, buen artículo.
Aingeru
Que sucede con los programas para hacer musica, especificamente de la plataforma linux, la musica creada pierde los derechos a ser explotada comercialmente? En todo caso puede alguien agarrarlo y modificarlo y hacerla de su propiedad?
Normalmente la licencia se refiere al software y a su código fuente, no a o que produzcas usando ese software.
Cordial saludo, en el caso del nombre del blog «Koalite» tambien se debe aplicar alguna licencia o con la Attribution-NonCommercial-ShareAlike 3.0 es sucifiente?
Hola Alan,
Es una buena pregunta, la verdad es que no lo había pensado nunca. Por mi puedes aplicar la misma licencia que al resto del blog.
¿Para qué querría alguien usar el nombre?
Respecto a la licencia AGPL el articulo menciona lo siguiente: «el caso de que instales tu aplicación basada en un componente AGPL en un servidor accesible de forma externa. En ese caso, deberás liberar también tu aplicación bajo licencia AGPL. »
Sin embargo, en foros (en ingles) se menciona algo distinto:
https://softwareengineering.stackexchange.com/a/314908
por ejemplo que se puede usar como librería, sin tener que cambiar la licencia…
¿Alguien acá podría aclararme esto?