El código abierto hace que el mundo de la tecnología avance, formando hasta un 90% de la pila de software moderno a través de marcos de trabajo; bibliotecas; bases de datos; sistemas operativos; y un sinfín de aplicaciones independientes.
Los beneficios del software de código abierto son bien comprendidos, prometiendo un mayor control y transparencia. Sin embargo, hay una lucha perenne entre los reinos de código abierto y propietario, lo que lleva a muchas empresas a alejarse del código abierto para proteger sus intereses comerciales. En el centro de todo esto está el espinoso problema de las licencias.
Existen dos tipos amplios de licencias que cumplen con la definición formal de código abierto establecida por la Iniciativa de Código Abierto (OSI). Las licencias 'permisivas' tienen 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 notable advertencia: cualquier versión modificada del software también debe distribuirse bajo la misma licencia copyleft original. Esto no es tan atractivo para las empresas que desean proteger su trabajo propietario.
Pero hay más que eso, con diversas licencias existentes dentro de cada categoría. Además, hay innumerables licencias que, aunque no son estrictamente de código abierto, también vale la pena conocer.
Permisivas
MIT
Originada en el Instituto Tecnológico de Massachusetts en la década de 1980, la licencia MIT, con su nombre apropiado, es la licencia de código abierto más popular según la mayoría de las métricas, ocupando el primer lugar entre la comunidad de desarrollo de GitHub durante muchos años.
Utilizada por proyectos como 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 deseen. Como la mayoría de estas licencias, se proporciona sin garantías, lo que significa que los autores quedan absueltos de cualquier responsabilidad derivada de los daños causados por su software (por ejemplo, pérdida de datos). Todo lo que los desarrolladores necesitan preocuparse es incluir el aviso de copyright original y la licencia MIT en cualquier trabajo derivado.
Pero la licencia MIT tiene una falla: no otorga explícitamente derechos de patente. Esto significa que si un determinado software se basa en tecnología patentada, esto podría crear incertidumbre legal para los desarrolladores que implementan el software sin asegurar permisos separados para dicha tecnología patentada.
Sin embargo, esto subraya uno de los puntos fuertes de la licencia MIT: con tan solo 200 palabras, el lenguaje es simple y conciso. Complicar las cosas con un discurso de patentes ambiguo y confuso agregaría una complejidad innecesaria para proyectos poco propensos a preocuparse por las patentes, como los lenguajes de programación de alto nivel o los marcos web.
Pero abundan los proyectos de código abierto que se cruzan con tecnologías patentadas, como el software centrado en hardware como Android.
Licencia Apache 2.0
La Fundación Apache publicó la Licencia Apache 2.0 en 2004, una actualización de una licencia anterior con una concesión de patentes explícita para proteger a los usuarios de litigios. Entonces, si un desarrollador, por ejemplo, contribuye con un algoritmo de procesamiento de imágenes único a un proyecto con licencia bajo Apache 2.0, cualquier patente que ese desarrollador posea sobre ese algoritmo se otorga automáticamente a todos los usuarios del software.
La mayoría de la gente estará familiarizada con la marca de Google, Android, repleta de tienda de aplicaciones y una suite de herramientas y servicios propios. Pero el Proyecto de Código Abierto de Android (AOSP) subyacente está sustancialmente disponible bajo la licencia Apache 2.0, un movimiento deliberado de Google en 2008 para combatir a Apple y alentar a los fabricantes de teléfonos a utilizar Android frente a los otros incumbentes propietarios (por ejemplo, Symbian) de la época. Y funcionó. Samsung, HTC, LG y todos los demás se unieron a Android.
Un subproducto de esto, sin embargo, es que la Licencia Apache 2.0 tiene alrededor de cinco veces el número de palabras de MIT, debido al texto de la concesión de patentes, entre otras adiciones y aclaraciones. Pero ese es el compromiso, y ilustra las diferencias clave entre las dos licencias de código abierto permisivas 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 una copia de la licencia debe incluirse tanto con el código fuente como con la forma binaria compilada. Y luego está la Licencia BSD de 3 cláusulas, que tiene una cláusula adicional de 'no promoción' que restringe el uso de los nombres de los titulares de derechos de autor y colaboradores con fines promocionales en cualquier proyecto derivado.
También está la Licencia MIT Sin Atribución (MIT-0), que es más simple que la MIT, en el sentido de que no se requiere atribución en el software derivado. Usar esto es casi como poner el software en el dominio público, excepto que el autor retiene los derechos de autor y la capacidad de cambiar las cosas en el futuro.
Copyleft
Licencia Pública General de GNU (GPL) v. 2.0 y 3.0
La Free Software Foundation (FSF) publicó la Licencia Pública General de GNU (GPL) en 1989, y fue una de las primeras licencias copyleft de uso general.
Las licencias Copyleft son más adecuadas para proyectos que requieren aportes de la comunidad, en comparación con proyectos respaldados por una sola entidad corporativa. Al requerir que todas las modificaciones permanezcan disponibles bajo la misma licencia de código abierto, esto asegura a los colaboradores que su arduo trabajo no se utilizará en software propietario sin beneficiar también a la comunidad en general, en teoría, al menos, ya que puede ser difícil descubrir cada infracción y luego hacer cumplir los términos de la licencia.
Lanzado en 2007, GPL 3.0 es la tercera licencia más popular, según datos de GitHub. La licencia introdujo actualizaciones notables en GPL 2.0, incluidas disposiciones de concesión de patentes y una mayor compatibilidad 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 evitan que los usuarios instalen versiones modificadas de ese software, utilizando mecanismos de gestión de derechos digitales (DRM).
Los adoptantes notables de GPL incluyen WordPress, que está disponible bajo una licencia GPL 2.0 'o posterior', dejando al desarrollador decidir bajo qué licencia distribuir cualquier modificación.
Linux, por su parte, es uno de 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 núcleo de Linux subyacente solo 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 de 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 de software y asegura que las versiones modificadas permanezcan como código abierto. Sin embargo, una distinción clave con AGPL es que está enfocado en servicios y aplicaciones basados en la 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 liberar 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 este resquicio legal, requiriendo que terceros pongan a disposición el código fuente incluso si el software modificado se está ejecutando solo desde un servidor.
Publicada en 2007 por la Free Software Foundation, la licencia AGPL 3.0 ha crecido en 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 Menor de GNU (LGPL)
También producto de la Free Software Foundation, la Licencia Pública General Menor de GNU (LGPL) es una licencia copyleft 'débil', en la medida en que es más amigable para los negocios con menos estipulaciones rigurosas sobre lo que se comparte. LGPL se usa normalmente para bibliotecas de software donde los autores del proyecto quieren fomentar contribuciones de la comunidad, pero permite que el software propietario se enlace a las bibliotecas sin tener que abrir todo su código propietario. Si alguien modifica la biblioteca de código abierto en sí, entonces 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 hoy 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 mientras permite a los desarrolladores beneficiarse del software de código abierto.
Sin embargo, mientras que LGPL se enfoca a nivel de biblioteca y GPL a nivel de proyecto, MPL opera a nivel de archivo individual requiriendo que el usuario comparta un conjunto más limitado de código.
Dominio público y Creative Commons
Mientras que una 'licencia de código abierto' otorga derechos específicos, siempre hay estipulaciones adjuntas. Aquellos que desean colocar su software completamente en el dominio público sin ningún tipo de restricciones, sin embargo, pueden hacerlo a través de otros medios.
No es suficiente simplemente publicar software sin una licencia; la ley de derechos de autor se aplica por defecto a la mayoría de las obras creativas, incluido el software. Aquí es donde una 'dedicación al dominio público' puede ayudar.
Diseñado específicamente para el software, el Unlicense es la novena licencia más popular en GitHub (aunque si realmente se puede llamar una 'licencia' es discutible). Aunque la OSI lo aprobó como licencia en 2020, señaló que el documento está 'pobremente redactado' y cuestionó su eficacia legal en jurisdicciones (por ejemplo, Alemania) donde no es posible donar el trabajo al dominio público.
Al igual que el Unlicense, el CC0-1.0 de Creative Commons es también una herramienta de dedicatoria al dominio público, aunque se enfoca más ampliamente en obras creativas. Utiliza un lenguaje legal más claro y profesional que podría estar más en sintonía con la ley internacional. Cabe destacar que Creative Commons solicitó que CC0-1.0 fuera aprobado como una licencia compatible con el código abierto en 2012, pero retiró la solicitud después de que la OSI planteara preocupaciones de que excluía explícitamente concesiones de patentes.
Existen otras herramientas de dedicación pública, como Zero-Clause BSD, que podrían ser atractivas ya que tienen un lenguaje aún más simple. Sin embargo, no hay consenso sobre el mejor mecanismo para renunciar a todos los derechos de un determinado software.
Software de "seudo" código abierto
Existen innumerables otros paradigmas de licencias en el espectro del software.
En algunos casos, las empresas lanzarán software bajo un modelo de doble licencia, con el usuario pudiendo 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 características clave bloqueadas por pago. En otros casos, una empresa podría agregar una cláusula de Commons Clause a una licencia de código abierto permisiva, imponiendo restricciones comerciales.
También hay muchas licencias que parecen y huelen a código abierto, pero son incompatibles con la definición de código abierto.
En 2018, el gigante de bases de datos MongoDB hizo la transición de una licencia copyleft AGPL a la licencia de servidor de código fuente público (SSPL), una licencia de creación propia de MongoDB. Aunque la SSPL sigue siendo bastante 'abierta', es lo que se conoce como 'fuente disponible', en el sentido de que el código es accesible pero tiene restricciones comerciales significativas, lo cual es un gran no-no según la OSI.
La gente de MariaDB siguió un camino similar con la licencia de código fuente comercial (BUSL), que impone restricciones comerciales antes de hacer la transición a una licencia de código abierto real después de un número determinado de años. También hay otro movimiento similar en marcha que busca hacer que la licencia 'fuente justa' sea una realidad. Esto incluye la Licencia de Fuente Funcional, que se promociona como una alternativa más simple al BUSL.
También puede encontrarse de vez en cuando licencias de 'código ético', como la Licencia Hipocrática, que prohíbe el uso del software en violación de los derechos humanos internacionalmente reconocidos. De manera similar, el formato de archivo JSON estándar abierto tiene una licencia extremadamente permisiva, salvo una hilarante cláusula al final: 'El Software se utilizará para el Bien, no para el Mal'.
