Conformidade com licenças de código aberto: um guia prático para empresas de software

O aplicativo comercial médio contém 77% de código-fonte aberto, distribuído por mais de 500 dependências. Cada dependência carrega sua própria licença com obrigações específicas. A violação dessas obrigações expõe sua empresa a ações judiciais, divulgação forçada de código e danos à reputação. No entanto, a maioria das empresas não possui processos para rastrear ou cumprir licenças de código aberto.

Este guia fornece uma estrutura prática para conformidade de licenças de código aberto, desde a categorização de licenças até a verificação automatizada e geração de SBOM.

Principais conclusões

• Nem todas as licenças de código aberto são iguais: licenças permissivas permitem quase tudo, licenças copyleft exigem que você compartilhe modificações
• Uma Lista de Materiais de Software (SBOM) está se tornando um requisito legal em compras governamentais (Ordem Executiva dos EUA 14028)
• A verificação automatizada de licenças em CI/CD evita que dependências não compatíveis entrem em sua base de código
• O risco de "infecção" do Copyleft é real: uma dependência da GPL pode obrigá-lo a abrir o código-fonte de todo o seu aplicativo

---

Categorias de licença

Licenças Permissivas (Baixo Risco)

Seguro para uso comercial. Inclua o texto da licença e o aviso de direitos autorais em sua distribuição. O Apache 2.0 também exige a observação de quaisquer alterações no código original e inclui uma licença de patente.

Copyleft fraco (risco médio)

Use com cuidado. Mantenha as bibliotecas LGPL como bibliotecas compartilhadas (dinâmicas), não vinculadas estaticamente. Mantenha o código licenciado MPL em arquivos separados do seu código proprietário.

Copyleft forte (alto risco)

Maior risco para software comercial. O uso do código GPL em seu aplicativo pode exigir que você libere todo o seu aplicativo sob a GPL. A AGPL estende isso ao software do lado do servidor – mesmo que você nunca distribua binários, fornecer o software como um serviço web aciona a obrigação de copyleft.

---

Fluxo de trabalho de conformidade

Etapa 1: gerar um 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

Etapa 2: verificar a conformidade da licença

# 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 .

Etapa 3: categorizar e aprovar

Crie uma lista de licenças aprovadas:

{
  "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"
  ]
}

Etapa 4: Integração 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 materiais de software)

Por que os SBOMs são importantes

• Ordem Executiva 14028 dos EUA exige SBOMs para software vendido ao governo dos EUA
• Lei de Resiliência Cibernética da UE exigirá SBOMs para software vendido na UE
• Segurança da cadeia de suprimentos: SBOMs permitem resposta rápida à vulnerabilidade (quando o log4j acontece, você sabe se foi afetado)
• Confiança do cliente: Os compradores empresariais solicitam cada vez mais SBOMs durante as compras

Padrões SBOM

Recomendação: CycloneDX para a maioria das empresas de software. É mais simples, tem melhor suporte de ferramentas e está se tornando o padrão do setor.

---

Cenários comuns de conformidade

Cenário 1: aplicativo da Web Node.js

O diretório node_modules típico contém de 500 a 2.000 pacotes. A grande maioria usa licenças MIT ou ISC. Problemas comuns:

• Dependências transitivas usando GPL (você não as adicionou diretamente)
• Campos de licença UNKNOWN que requerem investigação manual
• Múltiplas licenças em um único pacote (por exemplo, "MIT OR Apache-2.0")

Ação: Execute npx license-checker --production semanalmente. Investigue quaisquer licenças não permissivas. Substitua as dependências da GPL por alternativas permissivas.

Cenário 2: Desenvolvimento do Módulo Odoo

Odoo Community Edition é LGPL v3. Odoo Enterprise é proprietário. Seus módulos personalizados:

• Módulos da comunidade: devem ser LGPL v3 ou compatíveis (se distribuídos)
• Módulos internos privados: Não distribuídos, portanto LGPL não se aplica
• Complementos empresariais: devem estar em conformidade com os termos de licenciamento do Odoo Enterprise

Cenário 3: SaaS com dependências AGPL

Se o seu aplicativo SaaS usar código licenciado AGPL (por exemplo, MongoDB antes de mudar para SSPL), você deverá:

1. Libere todo o código-fonte do seu aplicativo sob AGPL
2. Remova a dependência AGPL e use uma alternativa
3. Obtenha uma licença comercial do projeto AGPL (se disponível)

O uso do código AGPL no servidor aciona a obrigação de copyleft, mesmo que você nunca "distribua" binários.

---

Perguntas frequentes

O uso de uma biblioteca GPL em nossa API nos obriga a abrir o código-fonte de nossa API?

Depende de como você o usa. Se a biblioteca GPL estiver vinculada ao seu aplicativo (estaticamente ou dinamicamente), a posição da FSF é que seu aplicativo é uma “obra derivada” e deve ser licenciado sob a GPL. Se você se comunicar com o software GPL por meio de uma API de rede (por exemplo, usando um servidor de banco de dados licenciado pela GPL), isso geralmente não será considerado um trabalho derivado. Consulte um advogado para o seu caso específico.

E se uma dependência alterar sua licença?

Você está vinculado à licença sob a qual obteve o código, e não a futuras alterações de licença. No entanto, se você atualizar para uma nova versão com uma nova licença, a nova licença será aplicada a essa versão. É por isso que os SBOMs com fixação de versão são importantes – eles documentam exatamente qual versão (e licença) você está usando.

Como lidamos com dependências com licenças "DESCONHECIDAS"?

Verifique o repositório do pacote em busca de um arquivo LICENSE. Se nenhuma licença for especificada, o código está tecnicamente sob proteção total de direitos autorais – você não tem o direito de usá-lo, modificá-lo ou distribuí-lo. Encontre a licença (pode estar em um local fora do padrão), solicite ao autor que adicione uma ou substitua a dependência por uma alternativa claramente licenciada.

Precisamos fornecer atribuição para pacotes licenciados pelo MIT?

Sim. O MIT e a maioria das licenças permissivas exigem que você inclua o aviso de direitos autorais e o texto da licença ao distribuir o software. Para aplicativos da web, isso normalmente significa incluir um arquivo THIRD-PARTY-NOTICES ou uma página listando todos os componentes de código aberto e suas licenças.

---

Construindo um Programa de Conformidade

Revisão Trimestral de Conformidade

1. Regenerar SBOM para todos os projetos
2. Procurar novas dependências adicionadas desde a última revisão
3. Verifique se há alterações de licença em pacotes atualizados
4. Revise quaisquer licenças "DESCONHECIDAS" que apareceram
5. Atualize a lista de licenças aprovadas se novas licenças forem encontradas
6. Arquivar instantâneos SBOM para trilha de auditoria

Funções de conformidade

Um programa de conformidade leve leva de 2 a 4 horas por trimestre para uma equipe pequena e evita o custo muito maior de descobrir um problema de conformidade após o lançamento do produto ou durante a devida diligência.

---

O que vem a seguir

A conformidade com licenças é um aspecto da governança de software. Combine-o com proteção de IP para seu próprio código, fundamentos do contrato de SaaS para software de fornecedor e requisitos regulatórios de segurança cibernética para conformidade de segurança.

Entre em contato com a ECOSIRE para auditoria de conformidade de código aberto e serviços de geração de SBOM.

---

Publicado pela ECOSIRE – ajudando as empresas a usar o código aberto de forma responsável.