Exploración de licencias comunes de código abierto

  • 8 minutos

Existen cientos de licencias de código abierto, pero la mayoría del software de código abierto usa un número relativamente pequeño de licencias populares. Comprender estas licencias comunes, sus términos y sus implicaciones ayuda a las organizaciones a tomar decisiones fundamentadas sobre qué componentes de código abierto pueden incorporar de forma segura en su software.

El espectro de licencias

Existen licencias de código abierto en un espectro desde la alta permisividad a copyleft:

Captura de pantalla del espectro de licencias.

Licencias permisivas (atribución)

En el lado izquierdo del espectro hay licencias permisivas que imponen restricciones mínimas:

  • Características: Permitir el uso de código en software propietario sin necesidad de que el software propietario sea de código abierto.
  • Requisito principal: Atribución: conserve los avisos de copyright y el texto de la licencia.
  • Uso comercial: Totalmente compatible con la creación y venta de software comercial propietario.
  • Libertad downstream: Los usuarios pueden elegir si desean que las obras derivadas sean de código abierto.

Ejemplos: Licencia MIT, Apache License 2.0, BSD Licenses.

Licencias de Copyleft

En el lado derecho del espectro se encuentran las licencias copyleft con fuertes requisitos recíprocos.

  • Características: Requerir trabajos derivados y trabajos combinados para usar la misma licencia.
  • Naturaleza viral: La licencia "propaga" al software que incorpora o se combina con el código con licencia.
  • Requisito de código fuente: La distribución de archivos binarios requiere que el código fuente esté disponible.
  • Conservación de la libertad: Asegúrese de que el software sigue siendo de código abierto a medida que evoluciona y se incorpora a otros proyectos.

Ejemplos: Licencia pública general de GNU (GPL v2 y v3), Licencia pública general de GNU Affero (AGPL).

Licencias de copyleft débiles

En el centro del espectro hay licencias copyleft débiles que equilibran la apertura con la viabilidad comercial:

  • Características: Requerir modificaciones en el componente con licencia para que sean de código abierto, pero permitir la incorporación del componente en trabajos de propiedad más grandes.
  • Compatible con la biblioteca: Diseñado para bibliotecas que se pueden usar en aplicaciones propietarias.
  • Copyleft de nivel de archivo o de nivel de módulo: Los requisitos se aplican al propio componente con licencia, no a toda la aplicación.
  • Equilibrio práctico: Habilite el uso comercial al tiempo que garantiza que las mejoras en el componente sigan siendo de código abierto.

Ejemplos: Gnu Lesser General Public License (LGPL), Mozilla Public License (MPL), Eclipse Public License (EPL).

Licencias permisivas comunes

Licencia MIT

La licencia MIT es una de las licencias de código abierto más sencillas y permisivas:

Términos clave:

  • Permisos: Use, copie, modifique, combine, publique, distribuya, sublicense y venda el software.
  • Condiciones: Incluya el aviso de copyright y el texto de la licencia en todas las copias o partes sustanciales.
  • Limitaciones: Ninguna garantía, sin responsabilidad por daños.

Por qué los proyectos eligen MIT:

  • Adopción máxima: Las restricciones mínimas fomentan el uso generalizado.
  • Simple y claro: Texto corto de licencia que es fácil de entender.
  • Comercial: No hay barreras para incorporar código con licencia MIT en software propietario.
  • Flexibilidad: Los usuarios tienen toda la libertad de uso y distribución del software.

Proyectos populares con licencia MIT: React, Angular, Node.js, jQuery, Rails, .NET Core.

Implicaciones para las organizaciones:

  • Seguro para uso comercial: Puede incorporar componentes con licencia MIT en software propietario sin restricciones.
  • Atribución requerida: Deben conservarse los avisos de copyright, lo cual normalmente se satisface mediante la inclusión del texto de la licencia en la documentación de la aplicación o en los diálogos 'Acerca de'.
  • Sin concesión de patentes: La licencia MIT no aborda explícitamente las patentes, lo que crea una posible ambigüedad.

Licencia de Apache 2.0

La licencia de Apache 2.0 es una licencia permisiva con protección explícita de patentes:

Términos clave:

  • Permisos: Usar, reproducir, preparar trabajos derivados, mostrar, realizar, sublicense y distribuir.
  • Condiciones: Incluir aviso de copyright, texto de licencia y aviso de modificaciones; conservar los avisos de patente; proporcionar atribución.
  • Concesión de patentes: Concesión explícita de derechos de patente de colaboradores.
  • Represalias de patentes: Las concesiones de patentes finalizan si el licenciatario inicia un litigio de patentes contra colaboradores.
  • Limitaciones: Sin garantía, sin responsabilidad, sin derechos de marca comercial.

Por qué los proyectos eligen Apache 2.0:

  • Claridad de patentes: Las concesiones explícitas de patentes proporcionan seguridad jurídica.
  • Transparencia de modificación: El requisito de documentar modificaciones promueve la transparencia.
  • Confianza corporativa: Los términos claros y las protecciones de patentes hacen que las corporaciones se sientan cómodas contribuyendo.
  • Compatibilidad: Compatible con GPL v3 (pero no con GPL v2).

Proyectos populares de Apache 2.0: Kubernetes, TensorFlow, Android, Spring Framework, Apache Hadoop, Apache Kafka.

Implicaciones para las organizaciones:

  • Protección de patentes: La concesión explícita de patentes reduce el riesgo de litigio por patentes de los colaboradores.
  • Aviso de modificación: Debe indicar cuándo se han modificado los archivos.
  • Requisitos de atribución: Un poco más complejo que MIT, que requiere la conservación de los archivos NOTICE.
  • Terminación defensiva: Las concesiones de patentes finalizan si demanda a los colaboradores por infracción de patentes, fomentando la coexistencia pacífica.

Licencias BSD (Cláusula 2 y Cláusula 3)

Las licencias de BSD (Berkeley Software Distribution) son licencias permisivas similares a MIT:

Cláusula BSD 2 (BSD simplificado):

  • Permisos: Redistribución y uso en formularios binarios y de origen, con o sin modificaciones.
  • Condiciones: Conservar el aviso de copyright, la lista de condiciones y la declinación de responsabilidades; conservar la atribución en la documentación de distribuciones binarias.
  • Limitaciones: Sin garantía, sin responsabilidad.

Cláusula BSD 3 (BSD modificada):

  • Condición adicional: No se pueden usar los nombres de los titulares de derechos de autor para aprobar productos derivados sin permiso.
  • Protección de marcas comerciales: Evita la implicación de la aprobación por parte de los autores originales.

Proyectos populares con licencia BSD: FreeBSD, OpenBSD, partes de macOS e iOS.

Implicaciones para las organizaciones:

  • Similar a MIT: Restricciones mínimas, compatible con usos comerciales.
  • Restricción de uso de nombres: BSD de tres cláusulas impide el uso de nombres del proyecto para marketing sin permiso.
  • Bien establecido: Larga historia en software académico y comercial.

Licencias comunes de copyleft

Licencia pública general de GNU (GPL) v2 y v3

La licencia pública general gnu es la licencia de copyleft más conocida:

Términos de clave de GPL v2:

  • Permisos: Use, modifique y distribuya el software.
  • Condiciones: Distribuir código fuente con archivos binarios; las obras derivadas deben usar GPL v2; conservar los avisos de copyright.
  • Ámbito de copyleft: se aplica a trabajos derivados y combinados que se vinculan con el código bajo GPL (Licencia pública general).
  • Limitaciones: Sin garantía, sin responsabilidad.

Mejoras de GPL v3:

  • Protección de patentes: Concesión explícita de patentes similar a Apache 2.0.
  • Prevención de Tivoización: Impide el uso de restricciones de hardware para evitar que los usuarios ejecuten software modificado.
  • Compatibilidad internacional: Mayor claridad jurídica para las jurisdicciones internacionales.
  • Compatibilidad de Apache 2.0: Puede combinar código GPL v3 con código apache 2.0.

Por qué los proyectos eligen GPL:

  • Garantizar la libertad: GPL garantiza que las modificaciones sigan siendo de código abierto, lo que impide bifurcaciones propietarias.
  • Creación de comunidad: Fomenta compartir mejoras de nuevo con la comunidad.
  • Alineación filosófica: Se alinea con la filosofía de software libre que el software debe permanecer libre.

Proyectos populares con licencia GPL: Kernel de Linux (GPL v2), Git (GPL v2), WordPress (GPL v2), GCC (GPL v3), Bash (GPL v3).

Implicaciones para las organizaciones:

  • Requisitos de trabajo derivados: Si modifica el código GPL o crea trabajos derivados, debe abrirlos en GPL cuando se distribuya.
  • Problemas de vinculación: La vinculación de código propietario con bibliotecas de GPL puede desencadenar requisitos de copyleft (la interpretación varía).
  • Distribución comercial: Puede vender software GPL, pero debe proporcionar código fuente a los clientes.
  • Consideraciones de SaaS: GPL v2 y v3 no requieren divulgación de código fuente para software como servicio a menos que se use AGPL.

Licencia pública general de GNU Affero (AGPL)

AGPL amplía GPL v3 con un aprovisionamiento de uso de red:

Requisito adicional de AGPL:

  • Copyleft de red: si modifica el software bajo licencia AGPL y los usuarios interactúan con él mediante una red (SaaS), debe facilitar el código fuente a esos usuarios.
  • Cierre de la laguna de ASP: Impide que las empresas modifiquen el software y lo ofrezcan como servicio sin compartir las modificaciones.

Por qué los proyectos eligen AGPL:

  • Protección de SaaS: Garantiza que los servicios en la nube no pueden usar software de código abierto sin contribuir.
  • Copyleft más estricto: la máxima protección contra el uso privado.

Proyectos populares con licencia agPL: MongoDB (cambiado de AGPL), RocketChat, Grafana.

Implicaciones para las organizaciones:

  • Evitar para SaaS: la mayoría de las organizaciones evitan el software con licencia AGPL para las ofertas de servicio porque requiere modificaciones de aprovisionamiento abierto.
  • Uso interno: Puede usar internamente sin desencadenar requisitos si no se expone a los usuarios a través de una red.
  • Evaluación de riesgos: Evalúe cuidadosamente si el software se califica como "interactuando a través de una red".

Licencias de copyleft débiles comunes

Licencia Pública General de GNU Aferior (LGPL)

LGPL permite vincular a bibliotecas sin desencadenar requisitos completos de GPL:

Términos clave:

  • Uso de la biblioteca: Puede vincularse a bibliotecas LGPL desde software propietario sin abrir la aplicación propietaria.
  • Modificaciones de biblioteca: Las modificaciones de la propia biblioteca LGPL deben ser de código abierto.
  • Vinculación dinámica: LGPL permite explícitamente la vinculación dinámica con código propietario.
  • Trabajos derivados: Las aplicaciones completas no son consideradas trabajos derivados simplemente porque utilizan bibliotecas con licencia LGPL.

Por qué los proyectos eligen LGPL:

  • Adopción de la biblioteca: Fomenta el uso en software propietario a la vez que protege la propia biblioteca.
  • Posición de compromiso: Equilibra la apertura con viabilidad comercial.
  • Idoneidad de la biblioteca estándar: Adecuado para las bibliotecas diseñadas como componentes estándar.

Proyectos populares con licencia LGPL: Qt (con licencia doble con opción comercial), GTK, GStreamer, muchas bibliotecas de C.

Implicaciones para las organizaciones:

  • Puede usarse en aplicaciones propietarias: Es seguro usar bibliotecas LGPL en aplicaciones comerciales.
  • Debe proporcionar el origen de la biblioteca: Si modifica la biblioteca LGPL'd, proporcione código fuente para modificaciones.
  • Complejidad de la vinculación estática: La vinculación estática podría desencadenar requisitos más estrictos; la vinculación dinámica es más segura.

Licencia pública de Mozilla (MPL) 2.0

MPL 2.0 proporciona copyleft de nivel de archivo:

Términos clave:

  • Copyleft de nivel de archivo: los requisitos se aplican solo a los archivos originalmente bajo MPL.
  • Exención de trabajo mayor: Puede combinar archivos MPL'd con archivos propietarios en la misma aplicación.
  • Divulgación de código fuente: Debe proporcionar código fuente para los archivos MPL.
  • Concesión de patentes: Incluye la concesión explícita de patentes y la terminación defensiva.
  • Compatibilidad con GPL: MPL 2.0 es compatible con GPL.

Por qué los proyectos eligen MPL 2.0:

  • Equilibrar: Más fuerte que las licencias permisivas, más flexibles que GPL.
  • Uso comercial: Habilita el uso comercial al proteger el componente de código abierto.
  • Seguimiento de archivos: Copyleft a nivel de archivo hace que sea más fácil el seguimiento del cumplimiento.

Proyectos populares con licencia MPL: Firefox, Thunderbird, LibreOffice.

Implicaciones para las organizaciones:

  • Puede mezclarse con código propietario: Integración más sencilla con software propietario que GPL.
  • Seguimiento de nivel de archivo: Debe mantener límites claros entre los archivos MPL y los archivos propietarios.
  • Modificaciones compartidas: Los cambios en los archivos MPL deben compartirse, pero las adiciones en archivos independientes no.

Compatibilidad de licencias

Las distintas licencias tienen reglas de compatibilidad diferentes:

Combinaciones compatibles

  • MIT + Apache 2.0: Compatible: puede combinarse en el mismo proyecto.
  • MIT + GPL v3: Compatible: puede incorporar código con licencia MIT en proyectos de GPL v3.
  • Apache 2.0 + GPL v3: Compatible: GPL v3 puede incorporar código apache 2.0.
  • LGPL + GPL: Compatible: puede actualizar LGPL a GPL.

Combinaciones incompatibles

  • GPL v2 + Apache 2.0: Incompatible: no se puede combinar en el mismo trabajo.
  • GPL + propietario: Incompatible: GPL requiere que los trabajos derivados estén bajo licencia GPL.
  • Diferentes licencias de copyleft: Por lo general, no es compatible: normalmente no puede combinar código GPL, AGPL y LGPL con distintas licencias de copyleft de maneras que cumplan ambos.

Consideraciones de compatibilidad

Al seleccionar dependencias:

  • Inventario de licencias: Conozca las licencias de todas las dependencias.
  • Comprobación de compatibilidad: Compruebe que las licencias de distintos componentes son compatibles.
  • Revisión legal: Los casos complejos requieren experiencia legal para evaluar la compatibilidad.

Estrategias de licencias duales

Algunos proyectos ofrecen varias opciones de licencia:

Código abierto + Comercial

  • Estrategia: Oferta bajo GPL (copyleft) o licencia comercial.
  • Fundamento: Las empresas que deseen incorporar software propietario deben adquirir una licencia comercial; la comunidad de código abierto utiliza la versión GPL.
  • Ejemplos: Qt, MySQL, MongoDB (enfoque cambiado).

Varias licencias de código abierto

  • Estrategia: Permitir que los usuarios elijan entre varias licencias compatibles.
  • Fundamento: Maximizar la compatibilidad entre diversos proyectos.
  • Ejemplos: Algunas bibliotecas ofrecen opciones de licencia de Apache 2.0 o MIT.

Comprender las licencias comunes de código abierto, sus términos y su compatibilidad ayuda a las organizaciones a tomar decisiones informadas sobre qué componentes de código abierto usar y cómo estructurar su software para mantener el cumplimiento de licencias. En la siguiente unidad se exploran las implicaciones y clasificaciones de licencia que ayudan a evaluar los riesgos y tomar decisiones.