El código abierto hace que el mundo de la tecnología gire y tome forma hasta 90% de la pila de software moderna que utiliza marcos; bibliotecas; bases de datos; sistemas operativos; e innumerables aplicaciones independientes.
Los beneficios del software de código abierto se conocen bien, lo que garantiza un mayor control y transparencia. Sin embargo, existe una lucha constante entre el código abierto y los dominios propietarios, 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 corresponden al código abierto oficial. definición Según lo determinado por la Iniciativa de Código Abierto (OSI). Las licencias “permisivas” conllevan pocas restricciones sobre cómo los usuarios pueden modificar y distribuir el software, lo que las hace populares entre las empresas que buscan utilizarlo comercialmente. Luego están las licencias “copyleft”, que ofrecen libertades similares pero con una importante advertencia: cualquier versión modificada del software debe distribuirse bajo la misma licencia copyleft original. Esto no resulta tan atractivo para las empresas que quieren proteger su trabajo patentado.
Pero hay más que eso, con diferentes licencias que existen dentro de cada segmento. Además, existen innumerables licencias que no son estrictamente de código abierto, pero que también vale la pena conocer.
permitiendo
con
Se originó en el Instituto Tecnológico de Massachusetts en la década de 1980 y recibió el acertado nombre con La licencia es la licencia de código abierto más popular según la mayoría de las métricas, ubicándose en primer lugar Entre la comunidad de desarrollo de GitHub para muchos años.
Utilizado por proyectos que incluyen responder (una biblioteca de JavaScript frontal) f enrojecimiento (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ía, lo que significa que los autores quedan exentos de cualquier responsabilidad derivada 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 expresamente derechos de patente. Esto significa que si un software determinado se basa en tecnología patentada, puede crear inseguridad jurídica para los desarrolladores que implementan el software sin obtener permisos separados para la tecnología patentada.
Sin embargo, esto resalta uno de los principales puntos de venta de la licencia MIT: con solo 200 palabrasEl lenguaje es simple y conciso. Ofuscar las cosas con patentes vagas y sopa de palabras agregará 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 propietarias, como el software centrado en hardware como Android.
licencia apache 2.0
La Apache Software Foundation publicó el licencia apache 2.0 En 2004, se actualizó una licencia anterior con una concesión expresa de patente 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 Android de Google, repleta de una tienda de aplicaciones y un conjunto de herramientas y servicios locales. Pero el Proyecto de Código Abierto de Android (AOSP) subyacente está esencialmente disponible bajo la licencia Apache 2.0, un movimiento deliberado de Google en 2008 para luchar contra Apple y alentar a los fabricantes de teléfonos a usar Android sobre otros titulares propietarios (por ejemplo, Symbian) en ese momento. 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 Cinco veces el número de palabras. del MIT, debido al texto de concesión de la patente, incluidas adiciones y aclaraciones. Pero esa es la compensación, e ilustra las principales diferencias entre las dos licencias permisivas de código abierto más comunes.
Otras licencias permiten
Licencia BSD de 2 cláusulas Similar al MIT, pero con diferencias clave en cuanto al lenguaje utilizado. Por ejemplo, especifica que se debe incluir una copia de la licencia tanto en el código fuente como en el formato binario compilado. Y luego estás tú Licencia BSD de 3 cláusulasque tiene una cláusula adicional de “no permiso” que restringe el uso de los nombres de los titulares de derechos de autor y de los contribuyentes con fines promocionales en cualquier proyecto derivado.
También estás tú 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 de uso general.
Las licencias copyleft suelen ser más adecuadas para proyectos que requieren la participación de la comunidad, a diferencia de 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 alguna modificación). violaciones 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 trajo actualizaciones notables sobre GPL 2.0Incluye disposiciones sobre 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 de software con licencia GPL impiden a los usuarios instalar versiones modificadas de ese software, utilizando mecanismos de gestión de derechos digitales (DRM).
Los esfuerzos notables de GPL incluyen WordPress, que está disponible bajo la licencia GPL 2.0 “o posterior”, lo que deja al desarrollador decidir bajo qué licencia distribuye los cambios.
Linux, por su parte, se encuentra entre los proyectos de código abierto más exitosos de todos los tiempos, utilizado en servidores, infraestructuras en la nube, sistemas integrados e incluso Android. Sin embargo, el kernel de Linux subyacente sólo está disponible bajo la licencia GPL 2.0, dado que El creador de Linux, Linus Torvalds, se opone a algunas de las instrucciones Agregado en la versión 3.0 de la licencia, incluida la sección Tivoización.
Publicado bajo la Licencia Pública General GNU (AGPL) 3.0
La Licencia Pública General de Afero (AGPL) es similar a GPL 3.0, en la medida en que es una licencia copyleft “fuerte” que promueve la libertad 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 ejecutables.
Según la licencia GPL 3.0, los desarrolladores no están obligados a publicar el código fuente del software modificado si se ejecuta en una red, como lo hacen las aplicaciones SaaS. La licencia AGPL cierra este vacío legal, al exigir que terceros pongan a disposición el código fuente incluso si el software modificado sólo se ejecuta desde un servidor.
La licencia AGPL 3.0, publicada en 2007 por la Free Software Foundation, ganó popularidad debido al auge de la computación en la nube y SaaS, y hoy 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 el sentido de que es más amigable para los negocios con condiciones 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 debe 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 Índice 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 disfrutar 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 funciona en un nivel de archivo individual que requiere que el usuario comparta un conjunto más pequeño de código.
Dominio público y creative commons
Si bien una “licencia de código abierto” otorga derechos específicos, siempre existen condiciones adjuntas. Sin embargo, aquellos que deseen poner su software en el dominio público sin reservas pueden hacerlo por 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 ayudar una “dedicación al dominio público”.
Diseñado específicamente para software, el Cancelación de licencia Es la novena licencia más popular en GitHub (aunque es discutible si realmente se puede llamar “licencia”). A pesar de la OSI aprobado Esto como licencia en 2020, señaló que el documento estaba “mal redactado” y cuestionó su efectividad legal en jurisdicciones (por ejemplo, Alemania) donde el trabajo no puede contribuir al dominio público.
Al igual que la falta de licencia, Creative Commons’ CC0-1.0 También es una herramienta de dedicación de dominio público, aunque se ha centrado más ampliamente en obras creativas. Utiliza un lenguaje jurídico más claro y profesional que puede estar más en consonancia con el derecho internacional. Cabe señalar que Creative Commons Solicitar CC0-1.0 como licencia compatible con código abierto en 2012, pero retiró la solicitud Después de que la OSI expresara su preocupación por haber excluido expresamente la concesión de patentes.
Existen otras herramientas de dedicación pública, como Sección Cero BSDLo cual puede resultar atractivo ya que tiene un lenguaje aún más sencillo. Sin embargo, no existe consenso sobre cuál es el mejor mecanismo para otorgar todos los derechos a un determinado software.
Fuente de “pluma artificial”.
Existen innumerables otros paradigmas de licencias en todo el espectro del software.
En algunos casos, las empresas lanzarán software bajo una Modelo con doble licenciaCuando el usuario puede 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 puede agregar una cláusula de los Comunes a una licencia de código abierto que de otro modo sería permisiva, imponiendo restricciones comerciales.
También hay muchas licencias que parecen y huelen a código abierto, pero que en última instancia no cumplen con la definición de código abierto.
En 2018, el gigante de las bases de datos MongoDB cambió de la licencia copyleft AGPL a la licencia pública del lado del servidor (SSPL), a Licencia de autocreación 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, es decir Un gran no-no En términos de OSI.
La gente de MariaDB ha desarrollado un camino similar con la Business Source License (BUSL), que impone restricciones comerciales antes de realizar la transición a una verdadera licencia de código abierto después de un número determinado de años. Hay otro movimiento similar en la forma que se busca hacerfuente justa“La licencia existe. Esto incluye la licencia de fuente funcional, que se presenta como una alternativa más sencilla a BUSL.
También puede encontrarse con el llamado “fuente ética”licencias de vez en cuando, como la licencia hipocráticaque prohíbe el uso del software en violación de los derechos humanos internacionalmente reconocidos. De manera similar, el estándar abierto JSON El formato de archivo tiene una licencia muy permisiva, sin una cláusula graciosa al final: “El software se utilizará para bien y no para mal.“.
