El código abierto hace girar el mundo de la tecnología, formando hasta el 90% del software moderno a través de marcos; bibliotecas; bases de datos; sistemas operativos; e innumerables aplicaciones independientes.
Los beneficios del software de código abierto se conocen bien y prometen un mayor control y transparencia. Sin embargo, existe una lucha constante entre el ámbito del código abierto y el propietario, lo que lleva a muchas empresas a retirarse del código abierto para proteger sus intereses comerciales. En el centro de todo esto está la espinosa cuestión de las licencias.
Hay dos tipos amplios de licencias que cumplen con la definición formal de código abierto establecida por la Open Source Initiative (OSI). Las licencias “permisivas” conllevan pocas restricciones en términos de cómo los usuarios pueden modificar y distribuir el software, lo que las hace populares entre las empresas que desean utilizarlo comercialmente. Y luego están las licencias “copyleft”, que ofrecen libertades similares pero con una advertencia notable: cualquier versión modificada del software también debe distribuirse bajo la misma licencia copyleft original. Esto no resulta tan atractivo para las empresas que desean proteger su trabajo patentado.
Pero hay más que eso, ya que existen varias licencias dentro de cada segmento. Además, existen innumerables licencias que, si bien no son estrictamente de código abierto, también vale la pena conocer.
Permisivo
MIT
Originada en el Instituto de Tecnología de Massachusetts en la década de 1980, la licencia MIT, bien llamada, es la licencia de código abierto más popular según la mayoría de las métricas y ocupa el primer lugar entre la comunidad de desarrollo de GitHub durante muchos años.
Utilizada por proyectos que incluyen React (biblioteca JavaScript frontal) y Ruby (lenguaje de programación de propósito general), la licencia MIT permite a los desarrolladores usar el software como quieran. Como ocurre con la mayoría de estas licencias, se proporciona sin garantías, lo que significa que los autores quedan exentos de cualquier responsabilidad resultante de los daños causados por su software (por ejemplo, pérdida de datos). Lo único de lo que deben preocuparse los desarrolladores es de incluir el aviso de derechos de autor original y la licencia MIT en cualquier trabajo derivado.
Pero la licencia del MIT tiene un inconveniente: no otorga explícitamente derechos de patente. Esto significa que si una determinada pieza de software se basa en tecnología patentada, esto podría crear inseguridad jurídica para los desarrolladores que implementan el software sin obtener permisos separados para dicha tecnología patentada.
Sin embargo, esto subraya uno de los puntos clave de venta de la licencia del MIT: con sólo 200 palabras, el lenguaje es simple y conciso. Enturbiar las cosas con peroratas ambiguas y de sopa de palabras sobre patentes agregaría complejidad innecesaria a proyectos que probablemente no estén relacionados con patentes, como lenguajes de programación de alto nivel o marcos web.
Pero muchos proyectos de código abierto se cruzan con tecnologías patentadas, como el software centrado en hardware como Android.
Licencia Apache 2.0
La Apache Software Foundation publicó la Licencia Apache 2.0 en 2004, una actualización de una licencia anterior con una concesión de patente explícita para proteger a los usuarios de litigios. Entonces, si un desarrollador, por ejemplo, contribuyera con un algoritmo de procesamiento de imágenes único a un proyecto con licencia Apache 2.0, cualquier patente que el desarrollador tenga sobre ese algoritmo se otorgará automáticamente a todos los usuarios del software.
La mayoría de la gente estará familiarizada con la marca de Android de Google, repleta de tiendas de aplicaciones y un conjunto de herramientas y servicios locales. Pero el Proyecto de Código Abierto de Android (AOSP) subyacente está sustancialmente disponible bajo la licencia Apache 2.0, una medida deliberada de Google en 2008 para combatir a Apple y alentar a los fabricantes de teléfonos a usar Android frente a otros titulares propietarios (por ejemplo, Symbian) de la época. Y funcionó. Samsung, HTC, LG y todos los demás se lanzaron a Android.
Sin embargo, una consecuencia de esto es que la licencia Apache 2.0 tiene aproximadamente cinco veces más palabras que el MIT, debido al texto de concesión de patente, entre otras adiciones y aclaraciones. Pero esa es la compensación, e ilustra las distinciones clave entre las dos licencias permisivas de código abierto más comunes.
Otras licencias permisivas
La licencia BSD de 2 cláusulas es similar a la MIT, pero con diferencias clave en términos del lenguaje utilizado. Por ejemplo, especifica que se debe incluir una copia de la licencia tanto con el código fuente como con el formato binario compilado. Y luego está la licencia BSD de 3 cláusulas, que tiene una cláusula adicional de “no respaldo” que restringe el uso de los nombres de los titulares de derechos de autor y contribuyentes con fines promocionales en cualquier proyecto derivado.
También existe la licencia MIT sin atribución (MIT-0), que es más simple que la MIT, ya que no existe ningún requisito de atribución en el software derivado. Usar esto está cerca de poner el software en el dominio público, excepto que el autor conserva los derechos de autor y la capacidad de cambiar las cosas en el futuro.
Copyleft
Licencia pública general GNU (GPL) v. 2.0 y 3.0
La Free Software Foundation (FSF) publicó la Licencia Pública General GNU (GPL) en 1989 y fue una de las primeras licencias copyleft para uso general.
Las licencias Copyleft suelen ser más adecuadas para proyectos que requieren aportes de la comunidad, en comparación con proyectos respaldados por una sola entidad corporativa. Al exigir que todas las modificaciones permanezcan disponibles bajo la misma licencia de código abierto, se garantiza a los contribuyentes que su arduo trabajo no se utilizará en software propietario sin beneficiar también a la comunidad en general (al menos en teoría, ya que puede ser difícil descubrir cada una de las modificaciones). contravención y luego hacer cumplir los términos de la licencia.
Lanzada en 2007, GPL 3.0 es la tercera licencia más popular, según datos de GitHub. La licencia marcó el comienzo de actualizaciones notables en GPL 2.0, incluidas disposiciones de concesión de patentes y compatibilidad mejorada con otras licencias de código abierto. También prohíbe lo que se conoce como “Tivoización”, donde los fabricantes de hardware que se benefician del software con licencia GPL impiden a los usuarios instalar versiones modificadas de ese software, utilizando mecanismos de gestión de derechos digitales (DRM).
Los adoptantes notables de la GPL incluyen WordPress, que está disponible bajo una licencia GPL 2.0 “o posterior”, dejando al desarrollador decidir bajo qué licencia distribuye cualquier modificación.
Linux, por su parte, se encuentra entre los proyectos de código abierto más exitosos de todos los tiempos, utilizado en servidores, infraestructura en la nube, sistemas integrados e incluso Android. Sin embargo, el kernel de Linux subyacente sólo está disponible bajo una licencia GPL 2.0, dado que el creador de Linux, Linus Torvalds, está en contra de algunas de las disposiciones agregadas en la versión 3.0 de la licencia, incluida la cláusula de tivoización.
Licencia pública general GNU Affero (AGPL) 3.0
La Licencia Pública General Affero (AGPL) es similar a la GPL 3.0, en la medida en que es una licencia copyleft “fuerte” que promueve las libertades del software y garantiza que las versiones modificadas sigan siendo de código abierto. Sin embargo, una distinción clave con AGPL es que se centra en servicios y aplicaciones basados en web, donde el software se ejecuta desde servidores en lugar de distribuirse como archivos ejecutables.
Bajo una licencia GPL 3.0, los desarrolladores no están obligados a publicar el código fuente del software modificado si se ejecuta a través de una red, como lo son las aplicaciones SaaS. La licencia AGPL cierra esta laguna, al exigir que terceros pongan a disposición el código fuente incluso si el software modificado sólo se ejecuta desde un servidor.
Publicada en 2007 por la Free Software Foundation, la licencia AGPL 3.0 ha ganado popularidad debido en gran parte al auge de la computación en la nube y SaaS, y hoy es la quinta licencia de código abierto más popular.
Licencia pública general reducida (LGPL) de GNU
También un producto de la Free Software Foundation, la Licencia Pública General Reducida (LGPL) de GNU es una licencia copyleft “débil”, en la medida en que es más amigable para los negocios con estipulaciones menos estrictas sobre lo que se comparte. LGPL se utiliza normalmente para bibliotecas de software donde los autores de proyectos desean fomentar las contribuciones de la comunidad, pero permite que el software propietario se vincule a las bibliotecas sin tener que abrir todo su código propietario. Si alguien modifica la biblioteca de código abierto, solo necesita publicar esas modificaciones bajo la licencia LGPL.
Licencia pública de Mozilla 2.0
Publicada por la Fundación Mozilla en 2012, la Licencia Pública de Mozilla (MPL) 2.0 es la décima licencia de código abierto más popular en la actualidad según la métrica de licencias de GitHub. MPL también es una licencia copyleft débil diseñada para proteger el código propietario y al mismo tiempo permitir a los desarrolladores beneficiarse del software de código abierto.
Sin embargo, mientras que LGPL se centra en el nivel de biblioteca y GPL en el nivel de proyecto, MPL opera a nivel de archivo individual y requiere que el usuario comparta un conjunto de código más limitado.
Dominio público y creative commons
Si bien una “licencia de código abierto” otorga derechos específicos, siempre hay estipulaciones adjuntas. Sin embargo, aquellos que quieran colocar su software completamente en el dominio público sin ninguna advertencia, pueden hacerlo a través de otros medios.
No basta con publicar software sin licencia; La ley de derechos de autor se aplica de forma predeterminada a la mayoría de las obras creativas, incluido el software. Aquí es donde puede resultar útil una “dedicación al dominio público”.
Diseñada específicamente para software, Unlicense es la novena licencia más popular en GitHub (aunque es discutible si realmente se puede llamar “licencia”). Aunque la OSI lo aprobó como licencia en 2020, señaló que el documento está “mal redactado” y cuestionó su eficacia legal en jurisdicciones (por ejemplo, Alemania) donde no es posible donar obras al dominio público.
Al igual que Unlicense, CC0-1.0 de Creative Commons también es una herramienta de dedicación de dominio público, aunque se centra más ampliamente en obras creativas. Utiliza un lenguaje jurídico más claro y profesional que podría estar más en sintonía con el derecho internacional. Vale la pena señalar que Creative Commons solicitó que se aprobara CC0-1.0 como una licencia compatible con código abierto en 2012, pero retiró la solicitud después de que la OSI expresó su preocupación de que excluía explícitamente la concesión de patentes.
Existen otras herramientas de dedicación pública, como Zero-Clause BSD, que pueden resultar atractivas porque tiene un lenguaje aún más sencillo. Sin embargo, no hay consenso sobre cuál es el mejor mecanismo para ceder todos los derechos sobre un determinado software.
Fuente de “pluma falsa”
Existen muchos otros paradigmas de concesión de licencias en todo el espectro del software.
En algunos casos, las empresas lanzarán software bajo un modelo de licencia dual, en el que el usuario podrá elegir entre una licencia de código abierto reconocida y una licencia comercial, según sus intenciones. Luego está el “núcleo abierto”, que ofrece el software bajo una licencia de código abierto, pero con funciones clave de pago. En otros casos, una empresa podría agregar un anexo a la Cláusula Común a una licencia de código abierto que de otro modo sería permisiva, estableciendo restricciones comerciales.
También hay muchas licencias que parecen y huelen a código abierto, pero que en última instancia son incompatibles con la definición de código abierto.
En 2018, el gigante de las bases de datos MongoDB pasó de una licencia AGPL copyleft a una licencia pública del lado del servidor (SSPL), una licencia de creación propia de MongoDB. Si bien el SSPL sigue siendo bastante «abierto», es lo que se conoce como «fuente disponible», en el sentido de que el código es accesible pero tiene importantes restricciones comerciales, lo cual es un gran no-no en lo que respecta al OSI.
La gente de MariaDB forjó un camino similar con la licencia de fuente comercial (BUSL), que impone restricciones comerciales antes de realizar la transición a una verdadera licencia de fuente abierta después de un número determinado de años. Hay otro movimiento similar en marcha que busca hacer que las licencias de “fuente justa” sean algo real. Esto incluye la licencia de fuente funcional, que se promociona como una alternativa más sencilla a BUSL.
También puede encontrarse de vez en cuando con las llamadas licencias de «fuente ética», como la Licencia Hipocrática, que prohíbe el uso de software que viole los derechos humanos internacionalmente reconocidos…
Continuar leyendo: Licencias de código abierto: todo lo que necesitas saber
