GitHub libera conformidade de licenças open source para o Enterprise Cloud, com API para agentes de código

Fala aí, beleza? Se na tua empresa alguém sempre trava quando entra um pacote com licença esquisita no projeto, essa notícia é pra você 😀

Em 16/10/2026 o GitHub anunciou no changelog oficial a disponibilidade geral da conformidade de licenças open source para clientes do GitHub Enterprise Cloud, incluindo o GHEC com residência de dados, em repositórios com GitHub Code Security ativo

Na prática, é uma política de licenças centralizada para a empresa inteira, aplicada direto no pull request

E tem um detalhe que interessa MUITO a quem programa com IA: um endpoint novo que permite a agentes de código checar se um pacote cumpre a política antes de sugerir ele 🙂

O que muda com a disponibilidade geral da conformidade de licenças do GitHub

O recurso saiu do preview e virou GA, com quatro novidades em relação à fase de testes

O public preview foi anunciado em 30/06/2026 para clientes do Enterprise Cloud com licença do GitHub Code Security

De lá pra cá, segundo o anúncio da GA, entrou:

• Dados de licença para o GHEC com residência de dados: isso liga o recurso pra esses clientes e também preenche o dependency graph e as exportações de SBOM com informação de licença
• Eventos no audit log: mudanças na política de licenças agora geram eventos, pra integrar com sistemas externos de registro
• Endpoints REST para a política: dá pra baixar, atualizar e substituir a política de licenças da enterprise pela API, com documentação na seção "REST API endpoints for the dependency graph"
• Endpoint de checagem de pacotes: verifica se pacotes cumprem a política, pensado justamente pra agentes de código

Que SBOM? É o Software Bill of Materials, a "lista de ingredientes" do software, com as dependências que ele carrega

Quem precisa entregar esse tipo de relatório agora recebe ele com a licença de cada pacote preenchida, no caso do GHEC com residência de dados

Como funciona a política de licenças no pull request

Resumindo: a empresa define quais licenças aceita, um ruleset liga a checagem nos repositórios e cada PR que mexe em dependência passa por essa régua

A política fica no nível enterprise e é construída em cima das capacidades da dependency review action

As licenças permitidas são escolhidas de uma lista embutida ou adicionadas à mão pelo identificador SPDX, que é o código padronizado usado pra nomear licenças

Qual condição de ruleset ativa a checagem?

A política entra em vigor por um ruleset aplicado aos repositórios com a condição nova Require license compliance results before merging

Se liga num detalhe: o anúncio da GA usa esse nome, mas a documentação escreve Requires license compliance results before merging, então não estranhe a diferença de grafia

Se você já usa as condições de code scanning nos rulesets, a lógica é bem semelhante

E os rulesets podem ser definidos nos escopos de enterprise, organização e repositório

O que acontece quando o PR mexe em dependências?

Segundo a documentação do recurso, o fluxo é este:

1. O PR adiciona ou altera manifestos de pacotes
2. O GitHub compara as mudanças entre a branch base e a branch do PR
3. As licenças detectadas são avaliadas contra a política
4. O PR recebe uma anotação para cada dependência fora da política

Com o ruleset em modo Active usando essa condição, o PR que traz dependência fora da política fica bloqueado até as violações serem resolvidas. Em modo Evaluate, a checagem roda e anota o PR, mas não bloqueia o merge

Tome cuidado! Como o modo Active barra o merge de verdade, vale revisar a política antes de ligar, senão o time inteiro pode acordar com PR travado haha

O passo a passo oficial de configuração está nas páginas "About open source license compliance" e "Configuring open source license policies" da documentação do GitHub

Como resolver uma dependência bloqueada e quem aprova exceções

Quando o PR é anotado, tem três saídas: remover ou trocar a dependência, ajustar a política de licenças ou criar uma exceção de pacote

A primeira é a mais simples pro dev: troca o pacote por outro com licença aceita e segue a vida

As outras duas dependem de quem cuida da política

E pra isso o GitHub criou um papel predefinido no nível enterprise: o Enterprise Open-Source License Manager

Ele é atribuído a pessoas ou times que revisam e aprovam os pedidos de fechamento, ou seja, as exceções

Esses gestores recebem notificação por e-mail sobre pedidos pendentes e revisam tudo pelo console da enterprise

E como as mudanças na política agora geram eventos no audit log, fica uma trilha de quem alterou o quê, que dá pra mandar pra sistemas externos de registro

O que a API de checagem de licenças muda para quem usa agentes de código

O novo endpoint REST verifica se pacotes cumprem a política, para que agentes de código deixem de recomendar ou incluir pacotes com licença proibida pela organização

Pensa no cenário clássico do vibe coding: tu pede uma feature, o agente sai instalando biblioteca e só no PR alguém descobre que uma delas não podia entrar

A ideia do endpoint é inverter isso: checar a licença ANTES de sugerir a dependência, em vez de descobrir no bloqueio do PR

É mais um guardrail (limite) pra agente, na mesma linha de outras camadas de controle que vêm aparecendo, tipo o sandbox local do GitHub Copilot

Um ponto importante: o anúncio não cita integração pronta com nenhum agente específico, só diz que o endpoint permite isso a agentes de código

Rota, parâmetros e formato de resposta desse endpoint de checagem ficam na documentação "REST API endpoints for repositories": e não na seção do dependency graph, que é onde fica a API de gerenciamento da política de licenças: , então é ali que você deve conferir antes de plugar em qualquer ferramenta

E pra cada perfil?

Dev em empresa com GHEC e Code Security: a política pode começar a anotar e barrar teus PRs assim que o ruleset entrar em Active, então vale saber quais licenças a empresa aceita

Time de compliance ou jurídico: ganha uma política central, um papel próprio pra aprovar exceções e eventos no audit log pra auditoria

Quem não está no Enterprise Cloud: por enquanto o recurso não é pra você, e a seção abaixo explica o porquê

Limitações: quem fica de fora da conformidade de licenças

O recurso vale só para o GitHub Enterprise Cloud, em repositórios com GitHub Code Security ativo

No GitHub Enterprise Server a história é outra: segundo a documentação de SBOM do GHES, ele não busca informação de licença das dependências, então esses campos não vêm preenchidos na exportação de SBOM

O anúncio também não detalha preço nem quais ecossistemas e gerenciadores de pacotes a checagem cobre

Se isso pesa na tua decisão, confere na documentação oficial do GitHub antes de planejar a adoção

Agentes de código open source: OpenCode 2.0

Já que o assunto é agente de código e open source, aqui no canal tem um vídeo sobre o OpenCode 2.0 😛

Se tu curte esse universo de agentes, bora dar o play 🙂

Próximo passo para adotar a política de licenças

O caminho mais seguro é ir em etapas, sem sair ligando o bloqueio de cara:

1. Confirma se a organização está no GitHub Enterprise Cloud e com GitHub Code Security ativo nos repositórios
2. Lê as páginas "About open source license compliance" e "Configuring open source license policies" da documentação oficial
3. Define quem vai receber o papel Enterprise Open-Source License Manager pra cuidar das exceções
4. Se o time usa agentes de código, avalia o endpoint de checagem de pacotes na documentação "REST API endpoints for repositories"
5. Só depois disso ativa o ruleset em modo Active

E aí, tua empresa já tem alguma política de licenças ou isso fica no "vai que dá"? xD

Até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.