El código abierto hace girar el mundo de la tecnología, formando tanto como 90% de la base de software moderna 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 los requisitos formales de definición de código abierto según lo establecido por la Iniciativa de Código Abierto (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. Por otro lado están las licencias “copyleft”, que ofrecen libertades similares pero con una importante advertencia: 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
Originado en el Instituto de Tecnología de Massachusetts en la década de 1980, el bien llamado MIT la licencia es la licencia de código abierto más popular según la mayoría de las métricas, ubicándose en el primer puesto entre la comunidad de desarrollo de GitHub durante muchos años.
Utilizado por proyectos que incluyen React (biblioteca de JavaScript de front-end) y Ruby (lenguaje de programación de propósito general), la licencia MIT permite a los desarrolladores utilizar 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 MIT: con solo 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ó el 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. 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) en cada época en el pasado. 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 el número de palabras del MIT, debido al texto de concesión de patentes, 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 al 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á el 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 está el Licencia MIT sin atribución (MIT-0), que es más simple que el MIT, ya que no existe ningún requisito de atribución en el software derivado. Usar esto equivale a 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 Fundación para el Software Libre (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 todas las modificaciones.
Lanzado 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 sobre 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 añadidas 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 de Affero (AGPL) es similar a 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, el Licencia pública general reducida GNU (LGPL) 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
Publicado por la Fundación Mozilla en 2012, el 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 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 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ñado específicamente para software, el Sin licencia (Unlicense) es la novena licencia más popular en GitHub (aunque es discutible si realmente se puede llamar «licencia»). Aunque la OSI la aprobó al presentarlo 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.
Como la Sin licencia (Unlicense), Creative Commons CC0-1.0 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ó la aprobación CC0-1.0 como una licencia compatible con código abierto en 2012, pero retiró la solicitud después de que la OSI expresara su preocupación de que excluía explícitamente la concesión de patentes.
Existen otras herramientas de dedicación pública, como BSD de cláusula cero que podría resultar atractivo ya que 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.
Fuentes “Faux-pen” o «Fauxpen»
Existen innumerables otros paradigmas de licencias en todo el espectro del software.
En algunos casos, las empresas lanzan software bajo una modelo de doble licencia pudiendo el usuario 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 la base de datos MongoDB pasó de una licencia AGPL copyleft a una licencia pública del lado del servidor (SSPL), a 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 una gran no-no en lo que respecta a la 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 “fuente justa“ al licenciar algo. Esto incluye la licencia de fuente funcional, que se promociona como una alternativa más sencilla a BUSL.
También podemos encontrar en alguna ocasión con las llamadas Licencias de «fuentes éticas”, como la Licencia hipocrática que prohíbe el uso de software que viole los derechos humanos internacionalmente reconocidos. De manera similar, existe el estándar abierto JSON el formato de archivo tiene una licencia extremadamente permisiva, salvo una cláusula hilarante al final: «El software se utilizará para el bien, no para el mal..”
