Guía del desarrollador para licencias de código abierto

No todas las licencias de código abierto son iguales. Algunos de ellos obligan al proveedor del software a otorgar licencias de patentes a los usuarios y desarrolladores del software. Otras licencias obligan al desarrollador que utiliza el producto o biblioteca licenciada a ofrecer el código fuente de dicho producto o biblioteca en los mismos términos. Otros simplemente regalan el código, sin garantía de ningún tipo ni preocupaciones. En este artículo intentaré resaltar las principales diferencias entre las licencias de código abierto más utilizadas desde la perspectiva de un usuario de software y de un desarrollador de software.

Cuando en 1984 Richard Stallman inició el proyecto GNU para crear un sistema operativo libre, recuperó la idea de que el software debía ser compartido entre desarrolladores, ingenieros y usuarios; y deberían poder mejorarlo de forma colaborativa de la misma manera que se suele hacer ciencia.

Esta opción contrastaba con el concepto habitual de software con licencia elegido por la mayoría de las corporaciones y desarrolladores de software para distribuir y vender sus programas. Hoy, más de treinta años después, el software de código abierto sigue conquistando lentamente amplios sectores de nuestra industria: Linux, Android, Apache y Git son ejemplos de productos de código abierto líderes en sus categorías.

¿Software libre o de código abierto?

En este artículo, usaré los términos "código abierto" y "gratuito" como sinónimos al referirme a software o licencias. En mi opinión, ambos términos expresan la misma idea. “Open-source” lo expresa de manera práctica y técnica, y usar “Free” pone el foco en un significado filosófico y político del concepto.

Lamentablemente la palabra “free” en inglés, además de ser el adjetivo asociado a “libertad”, también significa “sin costo”. Esta es la razón por la que normalmente prefiero decir "código abierto".

Propiedades comunes del software de código abierto

Supongo que ya tienes una idea aproximada de lo que es el software libre. Pero como vamos a hablar sobre los detalles de las diferentes licencias, primero debemos hablar sobre las propiedades específicas que definen el software de código abierto.

En primer lugar: no soy abogado, y esto no es un consejo legal. En caso de duda, consulte el texto real de las licencias de las que hablo y a su asesor legal.

Todo el software de código abierto, según la Iniciativa de código abierto, se distribuye bajo una licencia que otorga a sus usuarios y desarrolladores (los licenciatarios) algunos derechos. La lista completa se puede consultar en la Definición de código abierto, pero aquí hay un resumen básico:

1. Redistribución gratuita del software: el software puede venderse o regalarse como producto o incluirse en un paquete de software. Esto se puede hacer sin pagar regalías.
2. El código fuente del software con licencia está incluido en la distribución o, al menos, existen medios bien publicitados para obtener el código fuente. Este código fuente se puede utilizar para desarrollar versiones modificadas del software.
3. Se permite la creación de trabajos derivados, y la licencia permite distribuirlos bajo los mismos términos y licencia que el software original. Dependiendo de la licencia del software original, en algunos casos estos trabajos derivados deben diferenciarse del software original cambiando su nombre o número de versión, o solo pueden distribuirse en forma de parches de código fuente.
4. El software puede ser utilizado por cualquier persona o grupo de personas, y en cualquier campo de actividad, sin limitaciones.

Pero debe tener en cuenta que las licencias de software hablan solo sobre el uso o distribución de los permisos otorgados por los titulares de los derechos de autor. Las licencias de código abierto pueden permitirle redistribuir el software o los trabajos derivados libremente, pero esa concesión también puede estar restringida en algunos países donde está prohibida la exportación de software criptográfico. De manera similar, las licencias de código abierto le permiten usar el software para cualquier propósito, pero eso no significa que le permitan piratear un banco usando un software con licencia de código abierto. Las patentes de software son otro ejemplo de esto: algunas licencias de código abierto otorgan permisos para usar patentes libremente, pero no todas.

Entonces, ¿podemos utilizar un software de código abierto en el desarrollo de un producto o proyecto? Básicamente, depende de la licencia del software utilizado y de la licencia prevista para el producto final. Las diferentes licencias también son importantes cuando desea publicar su propio código como código abierto y está decidiendo qué licencia debe usar.

copyleft

Un concepto bastante interesante sobre las licencias de código abierto es lo que suele llamarse copyleft, lo opuesto a los derechos de autor. Cuando los derechos de autor se utilizan para proteger la propiedad intelectual (incluido el software) de su copia o distribución, el copyleft se utiliza para garantizar que la propiedad intelectual y el software de fuente abierta puedan copiarse o distribuirse como fuente abierta.

Según su fuerza, hay dos tipos de copyleft:

• Fuerte copyleft: cuando las obras derivadas de otras obras con licencia strong-copyleft, o vinculadas a estas obras, deben seguir teniendo licencias strong copyleft, o incluso exactamente la misma licencia. Es decir, esas obras de código abierto no se pueden cerrar en el futuro.
• Copyleft débil: cuando las obras que utilizan obras con licencia copyleft débil, o vinculadas a él, pueden licenciarse bajo otras licencias, incluso licencias de código cerrado. En este caso, el copyleft solo afecta al trabajo original con licencia copyleft débil.

También hay licencias de código abierto sin copyleft: simplemente no les importa la apertura futura del software derivado.

Permisividad

Según su permisividad, las licencias también pueden clasificarse en:

• Licencias estrictas: cuando no se puede mezclar un software fuerte con licencia con un código cerrado, o incluso con un software con licencia más permisiva.
• Licencias permisivas: cuando los productos generalmente se pueden mezclar con software de código cerrado o software con una licencia de código totalmente abierto.

Por lo general, las licencias copyleft fuertes también son estrictas y las licencias copyleft débiles son más permisivas, pero no tiene por qué ser así.

Diferencias de licencias de código abierto

Existen muchas licencias de código abierto. La Open Source Initiative ya ha aprobado más de 80 de ellos. Algunos son redundantes y podrían considerarse equivalentes a otros. Otros son específicos de los intereses del editor de software (como la licencia de la NASA), o para un entorno o propósito determinado (como la Licencia de Comunidad Educativa o la Licencia de Fuente Abierta).

Esta proliferación de licencias se basa en términos específicos en la licencia que, sumada a las propiedades básicas de código abierto, permite o no permite otros usos. Los ejemplos de estas condiciones adicionales pueden incluir:

• Tipo de copyleft: débil o fuerte o inexistente.
• Tipo de permisividad: permisiva o estricta.
• La obligación de agregar un aviso de derechos de autor en el código fuente o en la interfaz de usuario.
• Concesión automática de patentes a los licenciatarios.
• Considerando como licenciatarios no solo a las partes a las que se distribuye el software, sino también a los usuarios del software (de modo que las personas que utilizan un servicio en la nube que utiliza este tipo de software de código abierto deberían tener la opción de descargar el código fuente de El software)

Problema de mezclar código con diferentes licencias

De acuerdo con lo que ya hemos dicho antes, algunas licencias son permisivas, lo que permite a los usuarios combinar el código con código fuente con licencia diferente (quizás con condiciones adicionales). Este caso permitiría mezclar este tipo de software con licencia de código abierto con software de código cerrado. Un ejemplo de este tipo de licencia es la Licencia MIT.

Otros son más restrictivos, por lo que el código fuente solo puede combinarse con código que tenga una licencia similar, y el resultado final debe estar licenciado con la misma licencia original. Un ejemplo de este tipo de licencia es la Licencia Pública General (GPL).

Tal vez desee combinar el código con licencia con dos licencias de código abierto restrictivas diferentes. Usando la libertad de código abierto para usar el software como quieras, puedes hacer esto. Pero el programa final no se puede redistribuir, ya que debería distribuirse bajo dos licencias que no son compatibles entre sí.

Un ejemplo de esta situación fue ZFS. ZFS es un sistema de archivos muy avanzado e innovador que se incluyó en OpenSolaris en 2005. Es un software de código abierto con licencia según los términos de la Licencia de desarrollo y distribución común (CDDL). Aunque es un código de fuente abierta, no se puede integrar en el kernel de Linux porque el código fuente de Linux se distribuye bajo los términos de la Licencia pública general, otra licencia restrictiva de fuente abierta. Los archivos binarios del kernel de Linux compilados con compatibilidad con ZFS no se pueden distribuir debido al conflicto de licencias.

Este tipo de conflicto solo se puede resolver si todos los propietarios de uno de los programas de código abierto acuerdan cambiar la licencia o agregar términos de excepción en la licencia del software. Por ejemplo: muchos programas con licencia GPL están vinculados con la biblioteca OpenSSL. La distribución de la biblioteca OpenSSL tiene licencia y requiere que aparezca una frase en el material publicitario y en cualquier redistribución. Estas condiciones adicionales no son compatibles con la GPL, y debido a esto, los desarrolladores de productos GPL que usan OpenSSL han incluido una excepción en su licencia que permite específicamente la vinculación con OpenSSL.

Características diferenciales de las licencias de código abierto

Ahora intentaré analizar las licencias de código abierto más populares, destacando sus características diferenciales, con una pequeña guía sobre cuándo usarlas o no. Los he ordenado de más a menos usados, según Black Duck Knowledgebase.

Licencia Pública General GNU (GPL)

La GPL es la licencia de código abierto más popular. Fue creado por la FSF como licencia para el proyecto GNU, y también es la licencia del kernel de Linux.

Sus características diferenciales:

• Fuerte copyleft.
• Licencia muy estricta.
• Por lo general, se denomina licencia 'viral': si vincula su código a otra pieza de código con licencia GPL y desea distribuir los resultados, todo el producto debe tener licencia GPL.
• También es una licencia 'acogedora': si está desarrollando un software y desea licenciarlo bajo la GPL, puede vincularlo o incluir otro software de código abierto siempre que este software tenga una licencia compatible con la GPL. No requiere ninguna obligación no exigida por la GPL.

Por lo general, el texto de la licencia utilizada incluye el texto que dice que el software se distribuye bajo los términos de la versión N de GPL (o cualquier versión posterior).

Actualmente existen dos versiones de licencia GPL en uso: v2 y v3. La versión 3 se lanzó en 2007 para abordar algunos problemas que habían aparecido desde el lanzamiento de la versión 2 en 1991.

La GPL v3 incluye algunas cláusulas y términos adicionales, abordando las regulaciones de compatibilidad con otras licencias de código abierto, obligando a otorgar licencias de patentes, definiendo las condiciones para usar software con licencia GPL como firmware en dispositivos y teniendo en cuenta conceptos como la gestión de derechos digitales.

Licencia MIT

La licencia de código abierto generalmente conocida como Licencia MIT, también conocida como licencia X11, es una licencia sin copyleft muy permisiva que permite que todos usen básicamente el código con licencia para lo que quieran, siempre que mantengan el mensaje de derechos de autor y sepan que el software viene sin garantía de ningún tipo.

Esta licencia es muy popular y es utilizada por varios proyectos como X Window System, Ruby on Rails, jQuery o Node.js.

Es compatible con la GPL, por lo que puede mezclar código con licencia MIT en software GPL.

Licencia Apache 2.0

La licencia de Apache fue creada por Apache Software Foundation (ASF) como la licencia para su servidor Apache HTTP.

Al igual que la licencia MIT, es una licencia sin copyleft muy permisiva que permite usar el software para cualquier propósito, distribuirlo, modificarlo y distribuir trabajos derivados sin preocuparse por las regalías. Su principal diferencia respecto a la Licencia MIT son:

• Usando la Licencia Apache, los autores del software otorgan licencias de patentes a cualquier usuario o distribuidor del código. Las licencias de esta patente se aplican a cualquier patente que, siendo licenciable por cualquiera de los autores del software, sería infringida por la pieza de código que han creado.
• La Licencia de Apache requería que las partes no modificadas en trabajos derivados mantuvieran la Licencia.
• En cada archivo con licencia, se deben conservar todos los avisos originales de derechos de autor, patentes, marcas registradas o atribuciones.
• En cada cambio de archivo con licencia, debe haber una notificación que indique que se han realizado cambios en el archivo.
• Si el software con licencia de Apache incluye un archivo de AVISO, este archivo y su contenido deben conservarse en todos los trabajos derivados.
• Si alguien envía intencionalmente una contribución para un software con licencia de Apache a sus autores, esta contribución se puede usar automáticamente bajo la licencia de Apache.

Esta licencia es interesante por la licencia de patente automática y la cláusula sobre la presentación de contribuciones.

Es compatible con la GPL, por lo que puede mezclar el código con licencia de Apache en el software GPL.

Licencia BSD

Hay 3 licencias BSD diferentes. Todas ellas son licencias muy permisivas sin copyleft.

La Licencia BSD de 2 cláusulas (o Licencia BSD Simplificada) es totalmente equivalente a la Licencia MIT que se explicó anteriormente.

La Licencia BSD de 3 cláusulas (o Nueva Licencia BSD) agrega una cláusula, especificando que ni el nombre del titular de los derechos de autor ni los nombres de sus colaboradores pueden usarse para respaldar o promocionar productos derivados del software sin un permiso previo específico por escrito. Esta versión es compatible con la GPL, lo que le permite combinar código con licencia BSD de 3 cláusulas en el software GPL.

La Licencia BSD de 4 cláusulas (o Licencia BSD Original) agrega otra cláusula, especificando que todos los materiales publicitarios que mencionen funciones o el uso del software deben mostrar un reconocimiento que diga que el producto incluye software desarrollado por el titular de los derechos de autor. Esta Licencia BSD de 4 cláusulas no es compatible con la GPL. El código con esta licencia no se puede volver a otorgar según los términos de la GPL, ya que la cuarta cláusula agrega un requisito que no se requiere en la GPL.

Licencia pública general reducida de GNU (LGPL)

La LGPL fue creada por la FSF como una modificación de la GPL con un copyleft más débil, lo que permite vincular el software con licencia LGPL con cualquier otro software. En sus orígenes, LGPL significaba "Licencia pública general de biblioteca", pero luego tomó su nombre actual "Licencia pública general menor" que representa la opinión de la FSF que dice que todo el software debe ser libre, y por eso la LGPL no debe ser generalmente usado.

Puede vincular el código fuente cerrado con una biblioteca o software LGPL y distribuir los resultados finales siempre que:

• Usted proporciona el código fuente de la parte LGPLed, con todas las modificaciones que le haya hecho.
• Cualquier usuario con suficiente conocimiento puede reemplazar la parte LGPLed del programa con una versión modificada. Esto se puede hacer distribuyendo la parte LGPLed del programa como una biblioteca dinámica (DLL en Windows, .so en Linux/Unix), o proporcionando el código objeto de la parte no LGPLed del programa.

LGPL v3 es compatible con GPLv3, por lo que puede ingresar el código LGPLv3 en el software GPL.

Licencia Artística

La Licencia Artística, en su versión actual 2.0, es una licencia permisiva de código abierto sin copyleft similar a la licencia MIT.

La principal diferencia entre la licencia MIT y la Licencia Artística es que esta última requiere que cualquier modificación que se realice en el código debe quedar claramente establecida.

Esta licencia se usa casi exclusivamente en la comunidad de Perl.

La Licencia Artística 2.0 actual es compatible con GPL: puede mezclar código con Licencia Artística en software GPL.

Licencia pública de Microsoft (MS-PL)

La Licencia Pública de Microsoft fue creada en 2008 por esta empresa como una de las licencias de código abierto creadas por su Iniciativa de Fuente Compartida.

Es una licencia copyleft estricta y débil: permite la creación y distribución de programas de código cerrado con código MS-PLed, pero obliga a usar MS-PL como licencia de obras derivadas si estas se distribuyen en código fuente.

Personalmente, creo que esta licencia es un poco perversa y contraria al espíritu del código abierto, ya que permite cerrar el código para que, en cierto modo, al titular de los derechos de autor no le importe lo que puedes hacer con el software, pero no puedes. comparte el código para mezclarlo con otro código fuente copyleft. Entonces, de otra manera, el propietario de los derechos de autor realmente se preocupa por lo que puede hacer, y no quiere que use el código por razones como mejorar Linux.

El MS-PL es incompatible con la GPL.

Licencia pública de Eclipse (EPL)

La Licencia Pública de Eclipse es la licencia creada por la Fundación Eclipse para su Entorno de Desarrollo Integrado. Es una licencia de copyleft restrictiva y débil, similar en muchos aspectos a la LGPL. También incluye cláusulas para la concesión automática de licencias de patentes.

La EPL es incompatible con la GPL.

Licencia pública de Mozilla (MPL)

La licencia pública de Mozilla versión 2.0 es una licencia permisiva de copyleft débil creada por la Fundación Mozilla para sus productos.

Podríamos considerar esta licencia como similar a LGPL, pero con la principal diferencia de que MPL también permite la vinculación estática de las piezas de código MPLed en software de código cerrado.

La MPL, en su actual versión 2.0 es compatible con la GPL. Esto no es cierto para las versiones anteriores de la MPL.

Licencia común de desarrollo y distribución (CDDL)

La CDDL es una licencia permisiva con copyleft débil creada por Sun (ahora Oracle) basada en MPL versión 1.1. Básicamente, tiene las mismas propiedades que el MPL. Se aclararon sus términos, pero no se modificaron sustancialmente.

La CDDL es la licencia de código abierto elegida por Sun (ahora Oracle) para muchos de sus productos, como OpenSolaris o NetBeans, entre otros.

Como esta licencia se basó en MPLv1.1, esta licencia no es compatible con GPL, por lo que no puede mezclar una fuente con licencia CDDL en un software con licencia GPL. Mucha gente dice que esto fue intencional, por lo que el código fuente de OpenSolaris no se puede introducir en el kernel de Linux.

Licencia pública general GNU Affero (AGPL)

La AGPL es una versión de la GPL con un copyleft aún más fuerte y restrictivo. Obliga a proporcionar el código fuente de la aplicación no solo a las personas que reciben una copia del software, sino también a las personas que usan este software a través de una red informática.

Esta licencia fue creada por la FSF para dar a los desarrolladores los medios para evitar el cierre práctico del software de código abierto cuando se ejecuta en servidores de red o en la nube, ya que la GPL no puede obligar a los proveedores de servicios a dar el código fuente a los usuarios. . En este caso el software no se distribuye.

La AGPLv3 es compatible con la GPL3. Puede poner el código AGPLv3 en el código GPLv3, siempre que el resultado final tenga la licencia AGPLv3.

Licencia ISC

La Licencia ISC es una licencia permisiva de software libre escrita por Internet Software Consortium (ISC). Es funcionalmente equivalente a las licencias BSD y MIT de 2 cláusulas, después de eliminar algunos términos que se consideraron innecesarios.

Inicialmente utilizada para las versiones de software propias de ISC, desde entonces se ha convertido en la licencia preferida de OpenBSD (a partir de junio de 2003), entre otros proyectos.

Es compatible con la GPL: puede mezclar código con licencia ISC en software GPL.

Licencia recíproca de Microsoft (MS-RL)

La Licencia recíproca de Microsoft fue creada en 2008 por esta empresa como una de las licencias de código abierto creadas por su Iniciativa de código compartido.

Es similar al MS-PL explicado anteriormente, pero tiene un copyleft un poco más fuerte, que se asemeja a las condiciones de LGPL, CDDL y EPL. Requiere que si mezcla su código con el código fuente con licencia de MS-RL y desea distribuir los resultados finales, al menos la parte original con licencia de MS-RL debe continuar con esta licencia.

No es compatible con la GPL.

Dominio público (CC0)

Según Wikipedia, “las obras de dominio público son aquellas cuyos derechos de propiedad intelectual han expirado, perdido o son inaplicables”. Al dedicar una obra al dominio público, el autor renuncia a todos sus derechos sobre ella bajo la ley de derechos de autor.

Hay varios proyectos de software bajo dominio público, por ejemplo SQLite, la biblioteca que implementa un motor de base de datos SQL simple e integrable que se incluye en varios otros proyectos, como proyectos de Mozilla, Android, etc.

Hay muchas maneras de dedicar una pieza de software al dominio público. Creative Commons ha creado CC0 Public Domain Dedication, una forma universal de regalar una obra al dominio público. La FSF recomienda usar este texto para dedicar el software al dominio público.

Las obras de dominio público son compatibles con cualquier licencia de código abierto o cerrado y se pueden combinar con cualquier otro software.

Licencias Múltiples

Hay algún software de código abierto que tiene doble o incluso triple licencia. Esto significa que una persona que recibe este software con múltiples licencias puede elegir bajo qué licencia desea distribuirlo. Como cada licencia otorga diferentes permisos e impone diferentes obligaciones, se debe hacer una selección para elegir la licencia que mejor se adapte a las necesidades.

Este es un caso habitual para algunas bibliotecas. Por ejemplo, NSS es una biblioteca creada por Mozilla que implementa compatibilidad con SSL/TLS, entre otras funciones relacionadas con la seguridad. Tiene triple licencia bajo las licencias MPL, GPL y LGPL.

Por favor, elija una licencia

Mucha gente publica código en plataformas como GitHub sin ninguna licencia escrita. Nadie debería usar ese código. No tenemos idea de qué permisos tenemos para usarlo. Si lo usa, podría ser demandado por eso. Es como si estas personas se estuvieran burlando de nosotros, diciendo “¡Oye, mira lo que he hecho! Genial, ¿no? ¡Pero no puedes usarlo, solo quería mostrártelo!”.

Por favor, no seas uno de ellos. Si carga su código en GitHub o sitios públicos similares, permita que otros lo usen y lo mejoren. Si no quieres pensar mucho, estas son mis recomendaciones:

• Si desea mantenerlo simple y permisivo, permitiendo que todos hagan lo que quieran con su código, siempre y cuando le devuelvan la atribución y no lo hagan responsable, use la licencia MIT.
• Si desea mantenerlo permisivo, permitiendo que todos hagan lo que quieran con su código, pero enumerando sabiamente los derechos bajo la ley de derechos de autor y otorgando esos derechos, además de proporcionar una concesión explícita de derechos de patente de los contribuyentes a los usuarios, use la Licencia Apache 2.0 .

• Si le interesa compartir modificaciones y no desea que su código se use en desarrollos cerrados (ni en productos de software cerrados ni en dispositivos de hardware cerrados), use GPL v3.

  • Si no le importa la posibilidad de que su software se use en un dispositivo cerrado, use GPL v2. Pero por favor con la oración "o cualquier versión posterior", para que su código también se pueda usar en proyectos GPLv3.
  • Si no le importa la posibilidad de que su software se use en software cerrado, siempre que su software o la parte que lo use siga siendo de código abierto bajo los mismos términos, use la LGPL v3.
  • Si desea que todos los que utilicen su software a través de una red tengan derecho a obtener su código fuente, utilice AGPL v3.

Después de todo esto, es posible que esté agotado de todas estas tonterías cuasi-legales casi sin sentido. Pero, ¿sabes qué? es necesario Porque sin una licencia, no tienes los derechos para usar o distribuir ningún código.