Conformidade de licenças do GitHub agora está disponível para todos

O GitHub tornou a conformidade de licenças de código aberto disponível para todos em 16 de outubro de 2026, para repositórios do GitHub Enterprise Cloud que têm o GitHub Code Security ativado. O recurso verifica a licença de cada dependência que um pull request adiciona e pode bloquear o merge quando essa licença viola a política da empresa. Isso importa porque a revisão de licenças costuma acontecer tarde, à mão, depois que o código já foi escrito.

O que a conformidade de licenças faz

Todo pacote de código aberto vem com uma licença, os termos legais para usá-lo. Algumas licenças, como MIT ou Apache 2.0, pedem pouco de quem usa. Outras acrescentam condições que os advogados de uma empresa podem não aceitar. "Quase todo software tem algum tipo de contrato de licença", escreveram Jeff Luszcz e Eric Sorenson, gerentes de produto do GitHub, segundo citação da Help Net Security.

O changelog do GitHub diz que o recurso amplia a dependency review action com uma única política de licenças para toda a enterprise. Uma enterprise é a conta de nível mais alto do GitHub, que reúne muitas organizações. As verificações rodam automaticamente em qualquer pull request que adiciona ou altera uma dependência. Cada dependência cuja licença não é permitida recebe uma anotação, uma nota anexada ao pull request.

O desenvolvedor então tem três saídas, segundo o changelog. Ele pode remover ou substituir o pacote, mudar a política de licenças ou pedir uma exceção só para aquele pacote.

O que mudou desde a prévia de junho

O GitHub abriu o recurso como prévia pública em 30 de junho de 2026. A versão geral acrescenta quatro coisas, segundo o changelog.

Adicionado na disponibilidade geral	O que faz
Suporte a residência de dados	Os dados de licença agora preenchem o gráfico de dependências e as exportações de SBOM no Enterprise Cloud com residência de dados
Eventos no log de auditoria	Mudanças na política de licenças são registradas, para que sistemas externos possam acompanhá-las
API REST da política	Novos endpoints baixam, atualizam e substituem a política de licenças da enterprise
Endpoint de verificação de pacotes	Informa a uma ferramenta se os pacotes estão em conformidade, para que agentes de programação possam evitar os que não estão

Um SBOM, ou software bill of materials (lista de materiais de software), é uma lista de todos os componentes dentro de um software. A última linha é a que mais importa para ferramentas de programação com IA. Um agente agora pode perguntar ao GitHub se um pacote é permitido antes de adicioná-lo.

Como funciona a aplicação da política

A política lista as licenças permitidas. A documentação do GitHub diz que quem administra escolhe de uma lista embutida ou adiciona outras pelo identificador SPDX, o código curto padrão de uma licença. A verificação também cobre dependências transitivas, ou seja, os pacotes que os seus pacotes puxam.

Os rulesets aplicam a política no nível da enterprise, da organização ou do repositório. Um ruleset é a forma do GitHub de definir regras para muitos repositórios de uma vez. A documentação descreve dois modos:

• Active: um ruleset com a condição "Requires license compliance results before merging" bloqueia o merge até que o problema seja corrigido.
• Evaluate: a mesma verificação roda e anota o pull request, mas não o bloqueia.

Os pedidos de exceção vão para uma nova função predefinida da enterprise. O changelog a chama de Enterprise Open-Source License Manager. Esses revisores recebem avisos por e-mail e aprovam os pedidos pelo console da enterprise.

A documentação do GitHub sugere uma política central ampla, com exceções por repositório. As equipes podem adicionar uma propriedade personalizada de repositório com os valores inactive, evaluate e active. Os rulesets então miram esses valores para definir a aplicação repositório por repositório.

Como o GitHub usa o recurso internamente

O próprio escritório de programas de código aberto do GitHub usa a ferramenta, informou a Help Net Security em julho. Esse escritório deixou as ferramentas internas cerca de dois meses antes da reportagem. Ele manteve repositórios no modo Evaluate por cerca de um mês antes de ativar a aplicação. A maioria dos pedidos de licença foi revisada "em poucas horas", segundo a reportagem. A lista inicial de licenças permitidas era MIT, Apache 2.0 e BSD-3-Clause.

A mesma reportagem aponta uma válvula de segurança. Uma equipe pode passar um repositório de Active de volta para Evaluate para uma correção crítica e depois voltar.

O GitHub vem reforçando o pull request neste mês. Ele lançou o AI Scan para pull requests com disponibilidade geral em 15 de outubro. Um dia depois, os lockfiles de workflow para o GitHub Actions entraram em prévia pública.

O que isso significa para desenvolvedores

Se a sua empresa usa o GitHub Enterprise Cloud com Code Security, você pode ativar isto hoje. Nenhuma das fontes informa um preço separado. Confira o que o seu contrato atual de Code Security cobre antes de planejar a implantação.

Comece no modo Evaluate, como fez a própria equipe do GitHub. Um mês de anotações mostra de quais licenças a sua base de código já depende antes que qualquer coisa bloqueie um merge. Depois passe os repositórios para Active, um grupo de cada vez, com a propriedade personalizada.

Combine primeiro a lista de licenças permitidas. MIT, Apache 2.0 e BSD-3-Clause são um ponto de partida comum. Decida quem vai ter a função de gerente de licenças, porque os pedidos de exceção travam sem um revisor definido.

Se você cria ferramentas internas ou agentes de programação, veja o novo endpoint de verificação de pacotes. Um agente que verifica um pacote antes de instalá-lo evita um pull request bloqueado mais tarde.

Nenhuma das fontes informa quais ecossistemas de pacotes são cobertos. Teste um repositório de cada linguagem que a sua empresa usa antes de contar com cobertura total.