Examen de las implicaciones y clasificaciones de las licencias

Comprender los términos de licencia es solo el primer paso: las organizaciones deben evaluar cómo afectan las licencias a sus modelos empresariales específicos, prácticas de desarrollo y estrategias de distribución de productos. Las implicaciones de licencia determinan si los componentes de código abierto son adecuados para casos de uso concretos y qué obligaciones deben cumplir las organizaciones.

Implicaciones de licencia para el software comercial

Los distintos tipos de licencia tienen implicaciones considerablemente diferentes para el desarrollo de software comercial:

Implicaciones de licencia permisiva

Software que usa componentes con licencia permisiva (MIT, Apache 2.0, BSD):

Restricciones mínimas:

• Distribución propietaria: Puede incorporar componentes en software propietario sin abrir el código.
• Productos comerciales: Puede crear y vender productos comerciales que incorporan componentes con licencia permisiva.
• Distribución cerrada: No es necesario proporcionar código fuente a los clientes.
• Licencias secundarias: Normalmente, puede distribuirse bajo sus propios términos de licencia.

Obligación principal:

• Atribución: Debe conservar los avisos de copyright y el texto de la licencia, lo cual se logra generalmente mediante la inclusión de avisos en la documentación, cuadros de diálogo de 'Acerca de', o archivos de recopilación de licencias.

Consideraciones sobre patentes:

• MIT y BSD: No incluya concesiones explícitas de patentes, lo que crea una posible ambigüedad sobre los derechos de patente.
• Apache 2.0: Incluye la concesión explícita de patentes, lo que proporciona una protección más clara y una terminación defensiva para los litigios de patentes.

Implicaciones empresariales:

• Opción segura: Las licencias permisivas suponen un riesgo mínimo para los productos comerciales.
• Cumplimiento simple: Los requisitos de atribución son sencillos de cumplir.
• Máxima flexibilidad: Habilite cualquier modelo de negocio, incluidas las ventas de software propietario.

Implicaciones de licencia de copyleft débiles

Software que usa componentes de copyleft débiles (LGPL, MPL):

Se permite el uso de la biblioteca:

• Aplicaciones propietarias: puede usar bibliotecas de copyleft débiles en aplicaciones propietarias.
• Vinculación permitida: Puede vincular código propietario con bibliotecas de copyleft débiles (especialmente mediante la vinculación dinámica).
• Sin copyleft completo: el uso de bibliotecas no desencadena el requisito de código abierto de toda la aplicación.

Requisitos de modificación:

• Las modificaciones de biblioteca deben compartirse: si modifica el propio componente de copyleft débil, esas modificaciones deben ser de código abierto.
• Seguimiento de nivel de archivo (MPL): Para MPL, los requisitos se aplican en el nivel de archivo, lo que hace que los límites sean más claros.
• Trabajos derivados: La creación de trabajos derivados de la biblioteca desencadena los requisitos de código abierto.

Consideraciones de cumplimiento:

• Aprovisionamiento de código fuente: debe proporcionar código fuente para la biblioteca de copyleft débil (incluidas las modificaciones).
• Conservación de licencias: Debe mantener los términos de licencia de la biblioteca.
• Separación clara: Mantenga límites claros entre el código de biblioteca y el código propietario.

Implicaciones empresariales:

• Generalmente aceptable: la mayoría de las empresas pueden usar bibliotecas de copyleft débiles en productos propietarios.
• Carga de modificación: La modificación de bibliotecas crea obligaciones de cumplimiento continuas.
• Problemas de vinculación estática: La vinculación estática puede crear requisitos más estrictos; prefiere la vinculación dinámica.

Implicaciones de licencia de copyleft sólidas

Software que usa componentes de copyleft seguros (GPL, AGPL):

Propagación de copyleft:

• Trabajos derivados: La creación de trabajos derivados o la combinación de código con software de GPL activa los requisitos de copyleft.
• Toda la aplicación: GPL normalmente se aplica a toda la aplicación, no solo al componente GPL'd.
• Requisito de código fuente: Debe proporcionar código fuente completo al distribuir archivos binarios.
• Misma licencia: Los trabajos derivados deben distribuirse bajo GPL.

Desencadenadores de distribución:

• Distribución binaria: La distribución de archivos binarios ejecutables requiere proporcionar código fuente.
• Uso de red (AGPL): Para AGPL, simplemente hacer que el software esté disponible a través de una red activa requisitos específicos.
• Uso interno: El uso del software GPL internamente sin distribución no desencadena los requisitos.

Problemas de vinculación:

• Vinculación estática: Crea claramente trabajo derivado que requiere cumplimiento de GPL.
• Vinculación dinámica: La interpretación legal varía: algunos consideran que es seguro, otros creen que crea trabajo derivado.
• Separación de procesos: La ejecución de software GPL'd como proceso independiente (microservicios) podría evitar el estado de trabajo derivado.

Implicaciones empresariales:

• Incompatible con el software propietario: No se pueden incorporar componentes de GPL en software propietario que distribuya.
• Productos de código abierto: Puede usar GPL para los productos que desee liberar como código abierto.
• Excepción de SaaS: GPL v2 y v3 no requieren divulgación de origen para las ofertas de SaaS (AGPL sí).
• Alto riesgo: GPL presenta un riesgo significativo para el software propietario comercial.

Clasificaciones de riesgo de licencia

Las organizaciones suelen calificar licencias en función del riesgo que suponen para el desarrollo de software comercial:

Marco de clasificación de riesgos

Bajo riesgo (verde):

• Licencias: MIT, BSD, Apache 2.0, ISC, otras licencias permisivas.
• Características: Restricciones mínimas, principalmente requisitos de atribución.
• Casos de uso: Seguro para cualquier uso comercial, incluido el software propietario.
• Carga de cumplimiento: Bajo: principalmente mantener los avisos de atribución.

Riesgo medio (amarillo):

• Licencias: LGPL, MPL, EPL, otras licencias de copyleft débiles.
• Características: Permitir el uso en software propietario con restricciones en las modificaciones.
• Casos de uso: Aceptable para usar bibliotecas sin modificar; precaución necesaria al modificar.
• Carga de cumplimiento: Moderado: debe realizar un seguimiento del origen de la biblioteca y proporcionarlo a petición.

Alto riesgo (Rojo):

• Licencias: GPL v2, GPL v3, AGPL, otras licencias fuertes de copyleft.
• Características: Requerir trabajos derivados de aprovisionamiento abierto y aplicaciones combinadas.
• Casos de uso: Incompatible con la distribución de software propietaria; aceptable para proyectos de código abierto.
• Carga de cumplimiento: Alto: debe proporcionar código fuente completo para toda la aplicación.

Riesgo desconocido (Naranja):

• Licencias: Licencias personalizadas, licencias poco claras, información de licencia que falta, licencias obsoletas.
• Características: Términos poco claros, no seguros de compatibilidad, revisión legal requerida.
• Casos de uso: Evite hasta que una revisión legal aclare los términos y las implicaciones.
• Carga de cumplimiento: Desconocido hasta que se aclaran los términos de licencia.

Factores que afectan a la evaluación de riesgos

Modelo de negocio:

• Productos de código abierto: GPL es un riesgo aceptable.
• Software propietario: GPL es un riesgo inaceptable.
• Ofertas de SaaS: GPL v2/v3 aceptable, AGPL inaceptable.
• Herramientas internas: Normalmente, todas las licencias son aceptables, ya que no hay ninguna distribución.

Método de distribución:

• Distribución binaria: Desencadena los requisitos de GPL.
• Implementación de SaaS: Desencadena los requisitos de AGPL.
• Solo uso interno: No desencadena la mayoría de los requisitos.
• Provisión de biblioteca: Desencadena los requisitos de LGPL/MPL.

Extensión de modificación:

• Componentes sin modificar: Menor carga de cumplimiento.
• Componentes modificados: aumenta las obligaciones, especialmente para copyleft.
• Integración profunda: Hace que el cumplimiento sea más complejo.

Entorno legal:

• Diferencias jurisdiccionales: La interpretación de licencias varía según el país o la región.
• Historial de cumplimiento: Algunas licencias tienen un precedente de cumplimiento más sólido.
• Consideraciones sobre patentes: Las cláusulas de patente interactúan con las estrategias de patentes organizativas.

Consideraciones sobre la propiedad intelectual

Las opciones de licencia afectan a la propiedad intelectual de la organización:

Protección de IP propietaria

Licencias permisivas:

• Ip conservada: El código propietario sigue siendo propietario.
• Secretos comerciales protegidos: No es necesario revelar los detalles de implementación.
• Ventaja competitiva mantenida: No es necesario compartir innovaciones con competidores.

Licencias de copyleft seguras:

• Divulgación de IP requerida: GPL requiere abrir el código de los trabajos derivados, lo que puede exponer algoritmos propietarios, lógica empresarial e innovaciones.
• Secretos comerciales perdidos: La divulgación de código fuente elimina la protección de secretos comerciales.
• Ventaja competitiva reducida: Los competidores pueden usar sus innovaciones.

Consideraciones sobre patentes

Concesiones de patentes:

• Apache 2.0: Incluye la concesión explícita de patentes que proporciona derechos claros y terminación defensiva.
• GPL v3: Incluye las disposiciones sobre concesión de patentes y anti-tivoización.
• MIT/BSD: No hay disposiciones explícitas sobre patentes, lo que crea una posible ambigüedad.

Terminación defensiva de patente:

• Apache 2.0 y GPL v3: Las concesiones de patente finalizan si el licenciatario demanda a los colaboradores por infracción de patentes.
• Implicación estratégica: Las organizaciones con estrategias agresivas de patentes podrían enfrentar complicaciones.

Grupos de patentes:

• Algunas licencias se integran con grupos de patentes: Las licencias pueden interactuar con los contratos de patentes del sector.

Implementación de cumplimiento

La implementación correcta del software de código abierto requiere procesos de cumplimiento sistemáticos:

Inventario de dependencias

Seguimiento completo:

• Lista de materiales: Mantenga un inventario completo de todos los componentes de código abierto.
• Dependencias transitivas: Siga tanto las dependencias directas como las de las dependencias.
• Seguimiento de versiones: Registre versiones específicas, ya que las licencias a veces cambian entre versiones.
• Supervisión de actualizaciones: Supervise continuamente las actualizaciones de las dependencias y sus licencias.

Herramientas automatizadas:

• Administradores de paquetes: npm, pip, Maven realiza un seguimiento automático de las dependencias directas.
• Herramientas SBOM: Las herramientas de lista de materiales de software generan inventarios de dependencias completos.
• Escáneres de licencias: Herramientas como FOSSA, WhiteSource, Black Duck identifican licencias entre árboles de dependencia.

Comprobación de compatibilidad de licencias

Comprobación de compatibilidad:

• Examen automatizado: Las herramientas identifican automáticamente las incompatibilidades de licencias.
• Revisión legal: Los casos complejos requieren experiencia legal para evaluar la compatibilidad.
• Flujos de trabajo de aprobación: Establezca procesos para revisar las nuevas dependencias antes de su uso.

Incompatibilidades comunes:

• GPL + Apache 2.0 (GPL v2): Incompatible: no se puede combinar.
• GPL + Propietario: Incompatible con el software distribuido.
• Varias licencias de copyleft: Por lo general, no es compatible entre sí.

Cumplimiento de atribución

Cumplir los requisitos de atribución:

• Agregación de licencias: Recopile todos los textos de licencia en un solo archivo (a menudo LICENSES.txt o THIRD_PARTY_NOTICES).
• Acerca de los diálogos: incluya atribuciones en la aplicación Acerca de los diálogos o la configuración.
• Documentación: Incluya información de licencia en la documentación del producto.
• Generación automatizada: Use herramientas para generar automáticamente archivos de atribución a partir de datos de dependencia.

Aprovisionamiento de código fuente

Para las licencias copyleft:

• Acceso de origen: Proporcione código fuente completo para los componentes de GPL y los trabajos derivados.
• Mismo medio: Históricamente necesario proporcionar el origen en el mismo medio que los archivos binarios; descarga de Internet ahora aceptable.
• Oferta escrita: Puede ofrecer proporcionar el código fuente en lugar de incluirlo en el paquete.
• Instrucciones de compilación: Incluya instrucciones de compilación para que los usuarios puedan volver a generar desde el origen.

Seguridad de la cadena de suministro de software

El cumplimiento de licencias y la seguridad son problemas interconectados:

Administración de vulnerabilidades

La seguridad es igual a un componente más débil:

• Dependencia de cadena: La seguridad de la aplicación depende de todos los componentes del árbol de dependencias.
• Propagación de vulnerabilidades: La vulnerabilidad en cualquier dependencia afecta a todas las aplicaciones que lo usan.
• Urgencia de actualización: Las vulnerabilidades de seguridad requieren actualizaciones rápidas en todas las aplicaciones afectadas.

Examen de vulnerabilidades:

• Detección automatizada: Herramientas como Snyk, Dependabot, WhiteSource examinan las dependencias de vulnerabilidades conocidas.
• Supervisión de CVE: Realice un seguimiento de los identificadores comunes de vulnerabilidades y exposiciones para las dependencias.
• Puntuación del CVSS: Utilicen el Sistema de Puntuación de Vulnerabilidades Comunes para priorizar la remediación.
• Respuesta rápida: Establecer procesos para actualizar rápidamente las dependencias cuando se divulgan vulnerabilidades críticas.

Ataques de cadena de suministro

Mitigación de riesgos:

• Comprobación del paquete: Compruebe las firmas de paquete y las sumas de comprobación.
• Reputación de origen: Prefiere paquetes con mantenimiento activo, bases de usuarios grandes y mantenedores de reputación.
• Registros privados: Reflejar paquetes públicos en registros privados para controlar lo que usan los desarrolladores.
• Anclaje de dependencias: Bloquear versiones específicas para evitar actualizaciones automáticas en versiones en peligro.

Evaluación de calidad de componentes

Indicadores de calidad:

• Mantenimiento activo: Las actualizaciones regulares indican el proyecto mantenido.
• Tamaño de la comunidad: Las grandes comunidades proporcionan una mejor sostenibilidad.
• Calidad de la documentación: Buena documentación sugiere mantenimiento profesional.
• Cobertura de pruebas: Las pruebas automatizadas indican el foco de calidad.
• Prácticas de seguridad: Los procesos de divulgación responsable y los avisos de seguridad muestran el compromiso de seguridad.

Directivas organizativas

La administración eficaz de código abierto requiere directivas organizativas claras:

Flujos de trabajo de aprobación

Evaluación previa al uso:

• Revisión de seguridad: Busque vulnerabilidades conocidas antes de la aprobación.
• Revisión de licencias: Compruebe la compatibilidad de licencias con el uso previsto.
• Evaluación de la calidad: Evalúe la calidad del código, el estado de mantenimiento y el estado de la comunidad.
• Análisis alternativo: Considere si existen alternativas aprobadas.

Listas de paquetes aprobadas:

• Componentes previamente examinados: Mantenga listas de paquetes aprobados para necesidades comunes.
• Adopción más rápida: Los desarrolladores pueden usar paquetes aprobados inmediatamente.
• Nueva evaluación periódica: Revise periódicamente los paquetes aprobados para el estado de seguridad y mantenimiento.

Educación para desarrolladores

Programas de entrenamiento:

• Reconocimiento de licencias: Educar a los desarrolladores sobre los tipos de licencia y las implicaciones.
• Prácticas de seguridad: Entrene para evaluar la seguridad de los componentes.
• Procesos de cumplimiento: Explicar cómo solicitar aprobación para las nuevas dependencias.
• Reconocimiento del riesgo: Ayude a los desarrolladores a comprender las preocupaciones de la organización.

Supervisión continua

Cumplimiento continuo:

• Actualizaciones de dependencias: Supervise las nuevas versiones y las revisiones de seguridad.
• Cambios de licencia: Realice un seguimiento cuando los proyectos cambien las licencias.
• Divulgación de vulnerabilidades: Suscríbase a avisos de seguridad para las dependencias.
• Auditorías de cumplimiento: Audite periódicamente las aplicaciones para el cumplimiento de licencias.

Comprender las implicaciones de licencia e implementar procesos de cumplimiento sistemático permite a las organizaciones aprovechar las ventajas de código abierto al tiempo que administran los riesgos de forma eficaz. En la unidad siguiente se proporciona un resumen de los conceptos clave que se tratan en este módulo.