Validador de Licença SPDX

O que e SPDX e por que importa

SPDX e a sigla de Software Package Data Exchange, padrão aberto mantido pela Linux Foundation e ratificado como ISO/IEC 5962:2021. Dentro do SPDX vive a Lista de Licencas SPDX — catálogo curado de mais de 600 identificadores aprovados que permite a desenvolvedores, juristas e ferramentas automatizadas referenciar uma licença 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 padrão vai muito além 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 legíveis por máquina deixaram de ser opcionais — e SPDX e um dos três formatos oficialmente reconhecidos (junto com CycloneDX e SWID).

Anatomia de um identificador SPDX

Identificadores SPDX seguem padrão 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 — não OSI-approved, mas catalogadas pelo SPDX.

Atenção a mudança 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 cláusula de upgrade. Linters como spdx-correct avisam sobre as formas depreciadas.

Expressões compostas: AND, OR, WITH e parenteses

Uma string basta para uma licença isolada, mas projetos reais frequentemente combinam licencas. O SPDX define uma gramatica enxuta para expressar dual licensing, multi licensing e exceções:

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 licença dual canônica do Rust.
• AND = todas as licencas listadas se aplicam simultaneamente (projeto agrega componentes sob cada uma).
• WITH = licença base mais uma exceção nomeada (Classpath, GCC, Bison, Autoconf, LLVM, etc.).
• Parenteses = obrigatórios 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 inválidos desde 2017.
• Cargo: license = "MIT OR Apache-2.0" em Cargo.toml — sintaxe completa de expressão SPDX suportada.
• Python: PEP 639 (aceito em 2024) padroniza License-Expression em pyproject.toml usando expressões SPDX.
• Go modules: go.mod não carrega metadado de licença, mas o pkg.go.dev le SPDX a partir dos arquivos LICENSE via classificadores.
• Cabeçalho por arquivo: // SPDX-License-Identifier: Apache-2.0 — compatível 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 NÃO checa

Uma validação SPDX bem-sucedida confirma apenas que a string esta bem formada e bate com um registro da lista oficial. Ela não responde as questoes juridicas mais difíceis:

• Compatibilidade: distribuir código GPL-3.0 dentro de um binario proprietário fechado e violacao de licença, mesmo que ambas as strings sejam individualmente validas. Ferramentas como FOSSology e FOSSA mantém matriz de compatibilidade.
• Concessao de patentes: Apache-2.0 contem concessao expressa de patentes; MIT não. A escolha afeta estratégia 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 licença 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 política no seu SCA, e por fim revisão humana do jurido para a decisão 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 várias vezes por ano conforme novas licencas são submetidas e aprovadas.

SBOM realmente e obrigatório agora?

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

Qual a diferença entre OR e AND nas expressões?

OR deixa o licenciado escolher uma das alternativas (licenciamento dual). AND significa que todas as licencas listadas aplicam ao mesmo tempo — típico ao empacotar vários componentes de terceiros num único 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 cláusula de upgrade.

A ferramenta diferencia licencas comerciais de open source?

Não. Apenas confere o formato e se a string esta na lista oficial SPDX. Status OSI, força do copyleft e restrições de uso comercial exigem motor de política como FOSSA, Snyk Open Source ou Mend.