Cumplimiento de licencias de código abierto: una guía práctica para empresas de software

La aplicación comercial promedio contiene un 77% de código de fuente abierta, distribuido en más de 500 dependencias. Cada dependencia tiene su propia licencia con obligaciones específicas. La violación de estas obligaciones expone a su empresa a demandas, divulgación forzada de códigos y daños a la reputación. Sin embargo, la mayoría de las empresas no tienen ningún proceso para rastrear o cumplir con las licencias de código abierto.

Esta guía proporciona un marco práctico para el cumplimiento de licencias de código abierto, desde la categorización de licencias hasta el escaneo automatizado y la generación de SBOM.

Conclusiones clave

• No todas las licencias de código abierto son iguales: las licencias permisivas permiten casi cualquier cosa, las licencias copyleft requieren que usted comparta las modificaciones
• Una lista de materiales de software (SBOM) se está convirtiendo en un requisito legal en las adquisiciones gubernamentales (Orden ejecutiva de EE. UU. 14028)
• El escaneo automatizado de licencias en CI/CD evita que dependencias no conformes ingresen a su base de código
• El riesgo de "infección" por Copyleft es real: una dependencia de GPL puede obligarlo a abrir toda su aplicación

---

Categorías de licencia

Licencias permisivas (bajo riesgo)

Seguro para uso comercial. Incluya el texto de la licencia y el aviso de derechos de autor en su distribución. Apache 2.0 además requiere anotar cualquier cambio en el código original e incluye una licencia de patente.

Copyleft débil (riesgo medio)

Úselo con precaución. Mantenga las bibliotecas LGPL como bibliotecas compartidas (dinámicas), no vinculadas estáticamente. Mantenga el código con licencia MPL en archivos separados de su código propietario.

Copyleft fuerte (alto riesgo)

El riesgo más alto para el software comercial. El uso del código GPL en su aplicación puede requerir que libere toda su aplicación bajo la GPL. AGPL extiende esto al software del lado del servidor: incluso si nunca distribuye archivos binarios, proporcionar el software como un servicio web activa la obligación de copyleft.

---

Flujo de trabajo de cumplimiento

Paso 1: Generar un SBOM

# For Node.js projects (using CycloneDX)
npx @cyclonedx/cyclonedx-npm --output-file sbom.json --spec-version 1.5

# For Python projects
pip install cyclonedx-bom
cyclonedx-py environment --output sbom.json

# For multi-language projects (using Syft)
syft . -o cyclonedx-json > sbom.json

Paso 2: Buscar cumplimiento de licencia

# Using license-checker for Node.js
npx license-checker --production --json --out licenses.json

# Using scancode-toolkit (comprehensive, all languages)
scancode --license --copyright --output-json scan-results.json .

Paso 3: categorizar y aprobar

Cree una lista de licencias aprobadas:

{
  "approved": [
    "MIT", "BSD-2-Clause", "BSD-3-Clause", "Apache-2.0",
    "ISC", "0BSD", "Unlicense", "CC0-1.0"
  ],
  "conditional": [
    "LGPL-2.1", "LGPL-3.0", "MPL-2.0", "EPL-2.0"
  ],
  "prohibited": [
    "GPL-2.0", "GPL-3.0", "AGPL-3.0", "SSPL-1.0",
    "EUPL-1.2", "OSL-3.0"
  ]
}

Paso 4: Integración CI/CD

# .github/workflows/license-check.yml
name: License Compliance
on: [pull_request]

jobs:
  check-licenses:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: pnpm install --frozen-lockfile

      - name: Check licenses
        run: |
          npx license-checker --production --excludePackages "" \
            --failOn "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL-1.0" \
            --summary

---

SBOM (Lista de materiales de software)

Por qué son importantes los SBOM

• La Orden Ejecutiva de EE. UU. 14028 requiere SBOM para el software vendido al gobierno de EE. UU.
• La Ley de Resiliencia Cibernética de la UE exigirá SBOM para el software vendido en la UE
• Seguridad de la cadena de suministro: los SBOM permiten una respuesta rápida a la vulnerabilidad (cuando ocurre log4j, sabes si estás afectado)
• Confianza del cliente: los compradores empresariales solicitan cada vez más SBOM durante la adquisición

Estándares SBOM

Recomendación: CycloneDX para la mayoría de las empresas de software. Es más simple, tiene mejor soporte de herramientas y se está convirtiendo en el estándar de la industria.

---

Escenarios de cumplimiento comunes

Escenario 1: aplicación web Node.js

El directorio node_modules típico contiene entre 500 y 2000 paquetes. La gran mayoría utiliza licencias MIT o ISC. Problemas comunes:

• Dependencias transitivas usando GPL (no las agregaste directamente)
• UNKNOWN campos de licencia que requieren investigación manual
• Múltiples licencias en un solo paquete (por ejemplo, "MIT O Apache-2.0")

Acción: Ejecute npx license-checker --production semanalmente. Investigue cualquier licencia no permisiva. Reemplace las dependencias de GPL con alternativas permisivas.

Escenario 2: Desarrollo del módulo Odoo

La edición comunitaria de Odoo es LGPL v3. Odoo Enterprise es propietario. Tus módulos personalizados:

• Módulos comunitarios: deben ser LGPL v3 o compatibles (si están distribuidos)
• Módulos internos privados: No distribuidos, por lo que no aplica LGPL
• Complementos empresariales: debe cumplir con los términos de licencia de Odoo Enterprise

Escenario 3: SaaS con dependencias AGPL

Si su aplicación SaaS utiliza código con licencia AGPL (por ejemplo, MongoDB antes de cambiar a SSPL), debe:

1. Libere el código fuente completo de su aplicación bajo AGPL
2. Elimine la dependencia AGPL y utilice una alternativa
3. Obtener una licencia comercial del proyecto AGPL (si está disponible)

El uso del código AGPL por parte del servidor activa la obligación de copyleft aunque nunca "distribuya" archivos binarios.

---

Preguntas frecuentes

¿El uso de una biblioteca GPL en nuestra API nos obliga a abrir nuestra API?

Depende de cómo lo uses. Si la biblioteca GPL está vinculada a su aplicación (estática o dinámicamente), la posición de la FSF es que su aplicación es un "trabajo derivado" y debe tener licencia GPL. Si se comunica con el software GPL a través de una API de red (por ejemplo, utilizando un servidor de base de datos con licencia GPL), generalmente no se considera un trabajo derivado. Consulte con un abogado para su caso específico.

¿Qué pasa si una dependencia cambia su licencia?

Usted está sujeto a la licencia bajo la cual obtuvo el código, no a futuros cambios de licencia. Sin embargo, si actualiza a una nueva versión con una nueva licencia, la nueva licencia se aplica a esa versión. Es por eso que los SBOM con fijación de versión son importantes: documentan exactamente qué versión (y licencia) está utilizando.

¿Cómo manejamos las dependencias con licencias "DESCONOCIDAS"?

Consulte el repositorio del paquete para obtener un archivo de LICENCIA. Si no se especifica ninguna licencia, el código está técnicamente bajo plena protección de derechos de autor; usted no tiene derecho a usarlo, modificarlo o distribuirlo. Busque la licencia (puede que esté en una ubicación no estándar), solicite al autor que agregue una o reemplace la dependencia con una alternativa con licencia clara.

¿Necesitamos proporcionar atribución para paquetes con licencia MIT?

Sí. El MIT y la mayoría de las licencias permisivas requieren que incluya el aviso de derechos de autor y el texto de la licencia al distribuir el software. Para las aplicaciones web, esto normalmente significa incluir un archivo de AVISOS DE TERCEROS o una página que enumere todos los componentes de código abierto y sus licencias.

---

Creación de un programa de cumplimiento

Revisión trimestral de cumplimiento

1. Regenerar SBOM para todos los proyectos
2. Buscar nuevas dependencias agregadas desde la última revisión
3. Compruebe cambios de licencia en paquetes actualizados
4. Revise las licencias "DESCONOCIDAS" que aparecieron
5. Actualice la lista de licencias aprobadas si se encuentran nuevas licencias
6. Archivar instantáneas de SBOM para seguimiento de auditoría

Funciones de cumplimiento

Un programa de cumplimiento liviano requiere de 2 a 4 horas por trimestre para un equipo pequeño y evita el costo mucho mayor de descubrir un problema de cumplimiento después del lanzamiento del producto o durante la diligencia debida.

---

¿Qué viene después?

El cumplimiento de las licencias es un aspecto de la gobernanza del software. Combínelo con protección IP para su propio código, fundamentos del acuerdo SaaS para software de proveedores y requisitos normativos de ciberseguridad para cumplimiento de seguridad.

Comuníquese con ECOSIRE para obtener servicios de generación de SBOM y auditoría de cumplimiento de código abierto.

---

Publicado por ECOSIRE: ayuda a las empresas a utilizar el código abierto de forma responsable.