1001Ferramentas
📜Validadores

Validador de Licença SPDX

Valida identificadores SPDX (MIT, Apache-2.0, GPL-3.0-only, CC-BY-4.0, …) contra a lista oficial reduzida (~150 entradas).

O que e SPDX e por que importa

SPDX e a sigla de Software Package Data Exchange, padrao aberto mantido pela Linux Foundation e ratificado como ISO/IEC 5962:2021. Dentro do SPDX vive a Lista de Licencas SPDX — catalogo curado de mais de 600 identificadores aprovados que permite a desenvolvedores, juristas e ferramentas automatizadas referenciar uma licenca sem ambiguidade por uma string curta como MIT, Apache-2.0 ou GPL-3.0-or-later, em vez de colar textos completos ou rotulos vagos como "estilo BSD".

O padrao vai muito alem de uma lista. O SPDX define um modelo de dados completo para descrever componentes de software, copyrights, licencas, hashes criptograficos e relacionamentos — a base do SBOM (Software Bill of Materials) moderno. Com o EU Cyber Resilience Act (CRA) em vigor a partir de 2027 e a Ordem Executiva 14028 dos EUA ja valendo para fornecedores federais, SBOMs legiveis por maquina deixaram de ser opcionais — e SPDX e um dos tres formatos oficialmente reconhecidos (junto com CycloneDX e SWID).

Anatomia de um identificador SPDX

Identificadores SPDX seguem padrao determinista, com hifens. Os mais comuns:

  • Permissivas: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, Zlib, Unlicense, 0BSD, BSL-1.0.
  • Copyleft fraco: MPL-2.0, LGPL-2.1-only, LGPL-3.0-or-later, EPL-2.0, CDDL-1.0.
  • Copyleft forte: GPL-2.0-only, GPL-3.0-or-later, AGPL-3.0-only.
  • Creative Commons: CC-BY-4.0, CC-BY-SA-4.0, CC0-1.0.
  • Source-available / fair-code: BUSL-1.1, SSPL-1.0, Elastic-2.0 — nao OSI-approved, mas catalogadas pelo SPDX.

Atencao a mudanca de nomenclatura GPL de 2018: os identificadores legados GPL-2.0 e GPL-3.0 foram depreciados em favor das variantes explicitas -only e -or-later, tornando inequivoca a clausula de upgrade. Linters como spdx-correct avisam sobre as formas depreciadas.

Expressoes compostas: AND, OR, WITH e parenteses

Uma string basta para uma licenca isolada, mas projetos reais frequentemente combinam licencas. O SPDX define uma gramatica enxuta para expressar dual licensing, multi licensing e excecoes:

MIT                                  // licenca unica
MIT OR Apache-2.0                    // o usuario escolhe uma
(MIT AND BSD-3-Clause)               // ambas aplicam ao mesmo tempo
GPL-2.0-only WITH Classpath-exception-2.0  // GPL com excecao nomeada
(LGPL-2.1-only OR BSD-3-Clause) AND MIT    // aninhamento livre
  • OR = o licenciado escolhe entre as alternativas. O idioma do Cargo MIT OR Apache-2.0 e a licenca dual canonica do Rust.
  • AND = todas as licencas listadas se aplicam simultaneamente (projeto agrega componentes sob cada uma).
  • WITH = licenca base mais uma excecao nomeada (Classpath, GCC, Bison, Autoconf, LLVM, etc.).
  • Parenteses = obrigatorios quando AND e OR se misturam, para remover ambiguidade.

Onde os identificadores SPDX aparecem no dia a dia

  • npm: "license": "MIT" em package.json; o registry rejeita identificadores invalidos desde 2017.
  • Cargo: license = "MIT OR Apache-2.0" em Cargo.toml — sintaxe completa de expressao SPDX suportada.
  • Python: PEP 639 (aceito em 2024) padroniza License-Expression em pyproject.toml usando expressoes SPDX.
  • Go modules: go.mod nao carrega metadado de licenca, mas o pkg.go.dev le SPDX a partir dos arquivos LICENSE via classificadores.
  • Cabecalho por arquivo: // SPDX-License-Identifier: Apache-2.0 — compativel com REUSE, usado no kernel Linux e na maioria dos projetos modernos.
  • Containers e SBOMs: Syft, Trivy, Anchore e Microsoft SBOM Tool emitem documentos SPDX 2.3 que times de compliance ingerem em FOSSA, Black Duck, Snyk Open Source, Tidelift e Mend.

Compatibilidade de licencas, CLAs e o que o validador NAO checa

Uma validacao SPDX bem-sucedida confirma apenas que a string esta bem formada e bate com um registro da lista oficial. Ela nao responde as questoes juridicas mais dificeis:

  • Compatibilidade: distribuir codigo GPL-3.0 dentro de um binario proprietario fechado e violacao de licenca, mesmo que ambas as strings sejam individualmente validas. Ferramentas como FOSSology e FOSSA mantem matriz de compatibilidade.
  • Concessao de patentes: Apache-2.0 contem concessao expressa de patentes; MIT nao. A escolha afeta estrategia defensiva de IP.
  • Escopo do copyleft: AGPL estende copyleft ao uso em rede, sendo incompativel com a maioria dos modelos SaaS.
  • CLA / DCO: o Contributor License Agreement ou Developer Certificate of Origin governa contribuicoes entrando, separado da licenca sob a qual o projeto e distribuido saindo.

Trate esta ferramenta como o primeiro guardrail num pipeline de compliance em camadas: checagem de formato aqui, depois checagem de politica no seu SCA, e por fim revisao humana do jurido para a decisao final de licenciamento.

FAQ

Onde fica a lista oficial de licencas SPDX?

Em spdx.org/licenses. A lista e versionada, publicada no GitHub e atualizada varias vezes por ano conforme novas licencas sao submetidas e aprovadas.

SBOM realmente e obrigatorio agora?

Para fornecedores federais dos EUA, sob a Ordem Executiva 14028, sim. Na UE, o Cyber Resilience Act torna SBOM obrigatorio progressivamente a partir de 2027. Fora dessas jurisdicoes, SBOMs ainda sao fortemente recomendados por times de compras.

Qual a diferenca entre OR e AND nas expressoes?

OR deixa o licenciado escolher uma das alternativas (licenciamento dual). AND significa que todas as licencas listadas aplicam ao mesmo tempo — tipico ao empacotar varios componentes de terceiros num unico pacote.

Por que o validador rejeita GPL-2.0?

Porque o identificador puro foi depreciado em 2018. Use GPL-2.0-only ou GPL-2.0-or-later para explicitar a clausula de upgrade.

A ferramenta diferencia licencas comerciais de open source?

Nao. Apenas confere o formato e se a string esta na lista oficial SPDX. Status OSI, forca do copyleft e restricoes de uso comercial exigem motor de politica como FOSSA, Snyk Open Source ou Mend.

Ferramentas Relacionadas