Auditoria de licenças open-source para repositórios herdados: um plano prático

Por que repositórios herdados criam risco de licenças

Quando um repositório muda de mãos, você herda mais do que código. Você herda cada escolha de licença, cada dependência e cada aviso que a equipe anterior deixou de lado. Se o projeto começou como um protótipo rápido (ou foi gerado por uma ferramenta de programação com IA), o licenciamento muitas vezes fica para “depois” — até que alguém de fora da equipe faça perguntas difíceis.

Os modos de falha costumam ser simples, porém caros:

• Uma dependência está sob uma licença que um cliente não aceitará.
• Textos de licença ou avisos de copyright exigidos não estão incluídos no que você distribui.
• O build puxa pacotes transitivos que ninguém revisou.
• Um trecho copiado, fonte, ícone ou ativo tem termos que não combinam com o uso pretendido.

Clientes e parceiros pedem provas porque estão protegendo a si mesmos. Se eles distribuírem seu software, embutirem seu SDK ou revenderem seu produto, podem também se tornar responsáveis pela conformidade. Equipes de compras empresariais costumam solicitar um Software Bill of Materials (SBOM), um arquivo de avisos de terceiros e uma declaração clara de como você atende às obrigações de licença. Se você não puder produzir isso, os negócios atrasam, as revisões ficam mais rigorosas e equipes jurídicas podem bloquear o rollout.

Um mal-entendido comum é tratar a posse do repositório como direitos de licença. Ser dono da organização no GitHub (ou receber o código de um contratado) não concede automaticamente permissão para usar, modificar ou distribuir tudo que está dentro. Licenças open-source são permissões com condições. Você quer saber quais condições se aplicam antes de distribuir, especialmente se você distribui binários, vende um SaaS pago ou dá uma cópia a parceiros.

O objetivo prático de uma auditoria é direto: descobrir o que está realmente incluído, identificar lacunas cedo e produzir artefatos de conformidade claros. Isso não substitui aconselhamento jurídico, nem resolve todos os casos marginais, mas pode trazer à tona problemas enquanto ainda é barato corrigi-los.

Noções básicas rápidas sobre licenças (sem juridiquês)

Uma licença é o livro de regras sobre como você pode usar o código de outra pessoa. Quando você herda um repositório, também herda suas regras e papelada. Uma primeira triagem útil é separar “licenças de baixa fricção” de “licenças share-alike” e então confirmar que você cumpriu as obrigações básicas.

Licenças permissivas (como MIT e Apache-2.0) geralmente permitem uso em praticamente qualquer produto, inclusive comerciais. A compensação é administrativa: mantenha avisos de copyright, inclua o texto da licença quando exigido e não diga que você escreveu a obra original.

Licenças copyleft (como GPL) também permitem uso, mas podem exigir que, se você distribuir um produto que inclui o código, você também compartilhe o código-fonte da obra combinada sob os mesmos termos. AGPL é similar, mas pode estender o gatilho de “compartilhar o código” para software oferecido pela rede, por isso equipes de SaaS costumam evitá-la.

Na prática, “obrigações de licença” muitas vezes significam trabalho pouco glamouroso:

• Incluir textos de licença e avisos de copyright exigidos com sua distribuição
• Fornecer atribuição em um arquivo THIRD-PARTY-NOTICES (ou similar)
• Rastrear modificações quando a licença exige
• Para copyleft, estar pronto para compartilhar o código quando exigido
• Evitar usar marcas registradas ou nomes de formas proibidas pela licença

Licenciamento duplo surpreende equipes porque o mesmo projeto pode ser oferecido sob dois conjuntos de regras. Uma biblioteca pode ser “GPL para projetos open-source” e “licença comercial para produtos closed-source”, ou pode conter arquivos sob licenças diferentes. Se alguém puxou código do lugar errado, você pode acabar com termos mais restritivos do que esperava.

Você não precisa decorar cada detalhe de licença. Precisa saber quais licenças são fáceis de cumprir, quais mudam suas obrigações de distribuição e quais podem bloquear um negócio quando a equipe de conformidade do cliente as encontra.

Onde as licenças se escondem em um repositório moderno

A maioria dos problemas de licença em código herdado não está na dependência que você lembra ter adicionado. Aparecem em lugares que as pessoas não revisam até que um cliente peça prova.

Comece por dependências diretas (pacotes listados em arquivos como package.json, requirements.txt, go.mod, Gemfile). A surpresa maior são as dependências transitivas: pacotes que suas dependências puxam. Uma biblioteca direta pode trazer dezenas de licenças transitivas, e elas podem mudar depois de um pequeno bump de versão.

Repositórios frontend adicionam outro esconderijo: ativos empacotados. Ferramentas de build muitas vezes juntam código em um único arquivo minificado, e esse processo pode remover cabeçalhos ou avisos que normalmente acompanhariam o código-fonte. Trechos copiados são parecidos: uma função auxiliar colada de um post de blog, um gist ou uma resposta do Stack Overflow ainda pode impor requisitos de licença.

Também verifique o que é entregue junto ao seu app, não apenas o app. Containers e imagens base podem incluir pacotes do sistema operacional (e suas licenças) que acabam em produção. Se você herdou um Dockerfile, herdou também sua bagagem de licenças.

Lugares comuns onde as licenças se escondem:

• Manifestos de dependência e lockfiles (diretos e transitivos)
• Pastas vendor, bibliotecas copiadas e diretórios “utils”
• Bundles frontend construídos e fontes/ícones embutidos
• Imagens base de container e pacotes do SO instalados
• “Código misterioso” adicionado rapidamente, incluindo código gerado por IA que pode espelhar fontes licenciadas

Sinais de alerta que você pode detectar em 10 minutos

Você não precisa de uma auditoria completa para encontrar problemas prováveis. Uma verificação rápida pode dizer se um repositório pode falhar numa revisão de cliente ou parceiro.

Olhe primeiro para manifestos de dependência e lockfiles. Centenas de dependências sem lockfile (ou lockfiles múltiplos que não batem) são um sinal de que você não conseguirá provar o que foi entregue. Fique atento a registros privados ou dependências puxadas direto de repositórios Git. Essas frequentemente não têm metadados de licença claros.

Em seguida, verifique por artefatos de build comitados no repositório. Pastas como dist, build, vendor, third_party ou bundles minificados copiados são fontes comuns de avisos faltantes. Se o código foi copiado em vez de instalado via gerenciador de pacotes, você pode não ter uma maneira automática de coletar textos de licença.

Se o repositório for um monorepo (por exemplo, packages/* ou libs/*), abra alguns pacotes internos. Arquivos LICENSE ausentes ou notas de propriedade pouco claras podem virar bagunça quando os pacotes são publicados separadamente.

Finalmente, verifique o que é realmente entregue. Se não há um arquivo de avisos de terceiros (geralmente THIRD_PARTY_NOTICES ou NOTICE) em releases, instaladores ou imagens de container, isso é uma lacuna comum de conformidade.

Uma triagem rápida:

• Lockfiles ausentes ou inconsistentes com o build
• Dependências Git-based ou com “licença desconhecida”
• Código vendor ou bibliotecas empacotadas comitadas
• Nenhum arquivo de avisos em qualquer parte do processo de release

Se mais de um desses sinais aparecer, planeje uma revisão mais profunda antes que outra pessoa encontre o problema primeiro.

Passo a passo: faça uma auditoria de licenças open-source

Auditorias de licença fluem melhor quando você as trata como inventário primeiro, papelada depois. Comece identificando o que você realmente entrega, porque obrigações frequentemente dependem da forma de distribuição.

1) Construa um inventário limpo do que é entregue

Liste todo entregável que sai do seu controle: um bundle web, um app móvel, um instalador desktop, uma imagem de container, um pacote on-prem, até um ZIP que você envia a um parceiro.

Em seguida, colete os arquivos que definem seu grafo de dependências. Versões importam.

• Manifestos de build como package.json, pyproject.toml, requirements.txt, Gemfile, go.mod
• Lockfiles como package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock, Gemfile.lock, go.sum, Cargo.lock, composer.lock
• Arquivos de container e deploy (Dockerfiles, charts Helm, pipelines de build)
• Pastas vendor ou código copiado (vendor/, third_party/, às vezes libs/)
• Metadados de app store ou telas “Sobre” (lugares comuns para exibir avisos)

2) Escaneie, confirme e registre obrigações

Um fluxo de trabalho prático que a maioria das equipes pode seguir:

1. Gere uma lista de dependências (diretas e transitivas) a partir dos lockfiles e da saída do build.
2. Identifique a licença de cada versão de dependência. Marque qualquer coisa como “desconhecida” ou “personalizada”.
3. Cruze dados de licença entre fontes (metadados do registro, LICENSE do repositório, cabeçalhos de arquivos).
4. Registre as obrigações que você deve satisfazer (atribuição, inclusão de texto de licença, local dos avisos, gatilhos de compartilhamento de código).
5. Decida o que é aceitável para a forma como você entrega software (apenas SaaS vs distribuição de binários ou pacotes on-prem).

Um app desktop geralmente precisa de avisos de terceiros incluídos no instalador. Distribuição apenas como SaaS pode ser diferente, mas clientes e parceiros ainda esperam registros limpos.

Repositórios herdados frequentemente vêm com lockfiles faltando e código copiado. Se você não consegue reproduzir o conjunto de dependências, corrija isso primeiro. Caso contrário, cada decisão de licença fica incerta.

Erros comuns que geram problemas de conformidade

A maioria dos problemas de conformidade não vem de má intenção. Acontecem porque equipes herdam um repositório, entregam rápido e nunca verificam o que está dentro.

Problemas recorrentes:

• Metadados não batem com a realidade. Um README diz “MIT”, mas os metadados do pacote estão errados ou sem identificador SPDX.
• Trechos copiados sem atribuição. “Só uma função auxiliar” ainda pode impor condições de licença.
• Copyleft forte no lugar errado. Dependências GPL/AGPL podem criar obrigações que não combinam com seu modelo de venda ou hospedagem.
• Ativos não-código ignorados. Fontes, ícones, imagens e kits de UI frequentemente têm licenças separadas.
• Alguém confiou em boatos. Um post de blog ou comentário não é uma licença. O texto da licença e os metadados da dependência é que importam.

Mesmo que sua dependência direta seja permissiva, uma transitiva que entrou sem alarde pode não ser. Verificar apenas pacotes de topo perde os problemas que clientes tendem a encontrar.

Um cenário comum: você herda um protótipo, vê um único arquivo LICENSE e assume que todo o repositório está coberto. Depois, um cliente corporativo pede avisos de terceiros e você descobre ativos empacotados com termos próprios e nenhuma atribuição em lugar nenhum.

Como corrigir achados: avisos, substituições e documentação

Depois de uma auditoria, o objetivo não é perfeição. É clareza: o que você usa, o que deve ser entregue com isso e o que você não deve fazer.

Comece criando (ou atualizando) um arquivo THIRD-PARTY-NOTICES. Mantenha-o sem frescura e completo. Para cada dependência, inclua nome, versão, licença e onde ela aparece (web app, servidor, mobile, imagem de container). Isso costuma ser a primeira coisa que parceiros procuram.

Em seguida, adicione os textos de licença exigidos. Se uma licença diz que o texto ou aviso de copyright deve acompanhar a distribuição, colete esses textos em uma pasta licenses/ e faça referência a eles no THIRD-PARTY-NOTICES.

Se você encontrar uma licença de alto risco para seu modelo de negócio (por exemplo, copyleft forte em uma biblioteca linkada a um produto closed-source), normalmente há três caminhos: substituir, isolar atrás de um limite de serviço, ou obter uma licença comercial. A escolha certa depende de como o componente é usado, não apenas do rótulo da licença.

Para tornar isso repetível, adicione um COMPLIANCE.md curto que explique como você gera o inventário e onde a papelada fica. Seja prático: quais lockfiles estão em escopo, o que você exclui (ferramentas dev-only, frameworks de teste) e por quê, e quais comandos reproduzem a varredura.

Por fim, defina uma regra leve de intake para novas dependências: não faça merge de um novo pacote até que sua licença seja conhecida (com um identificador SPDX real quando possível) e as atualizações de avisos sejam tratadas quando exigido.

O que parceiros normalmente querem ver em um pacote de conformidade

A maioria dos parceiros não pede um ensaio jurídico. Querem prova de que você sabe qual software de terceiros está dentro do seu produto, quais regras se aplicam e quem mantém isso atualizado.

Um bom pacote geralmente começa com um resumo curto: quais famílias de licença aparecem no que você entrega (permissivas como MIT/Apache, copyleft fraco como LGPL, copyleft forte como GPL/AGPL), mais escopo da varredura e data.

Depois vem a evidência: um inventário de dependências que alguém possa verificar, com nomes, versões exatas, licenças detectadas e onde cada item foi encontrado (lockfile, diretório vendor, camada de container, saída de build).

Você quase sempre precisará dos textos e das atribuições reais, não apenas dos rótulos.

Mínimo prático a incluir

• Um resumo curto de licenças para o produto entregue
• Uma lista de dependências com nomes, versões e licenças
• Avisos de terceiros (atribuições exigidas e textos completos de licença quando requeridos)
• Notas sobre exceções (licenças comerciais, aprovações por escrito)
• Um responsável nomeado e um ciclo de revisão simples

Um detalhe que reduz idas e vindas: destaque áreas cinzentas desde o início. Exemplos: “O pacote X não tinha arquivo de licença, então o substituímos” ou “Uma ferramenta GPL de dev foi removida da imagem de produção e está excluída do SBOM.”

Cenário de exemplo: protótipo herdado, revisão de cliente empresarial

Uma startup compra um protótipo funcional de um contratado e o coloca em produção rapidamente. Demos estão bons, então a equipe foca em recursos e vendas. Três meses depois, um cliente empresarial inicia uma revisão de segurança e compras e pede uma pergunta simples: “Podem fornecer uma lista de todo software de terceiros e licenças?”

A equipe roda uma auditoria e encontra uma dependência copyleft (GPL/AGPL) no fluxo principal. Economizou tempo no começo, mas os termos não combinam com como a startup planeja vender e distribuir o produto.

Eles pausam o negócio e fazem três coisas em paralelo: confirmam a dependência/versão exatas e onde é usada, substituem por uma alternativa permissiva e refatoram a integração, e organizam a papelada para que o cliente veja uma história completa e consistente.

O que eles retornam é curto e específico:

• Uma lista de dependências com nomes, versões e licenças
• Um arquivo de avisos de terceiros que corresponde ao que é entregue
• Uma nota documentando a dependência removida e a substituição
• Um registro da data da varredura e das configurações da ferramenta

Depois do fechamento do negócio, adicionam uma checagem de licença no CI, exigem atualizações de avisos antes das releases e mantêm uma lista de “licenças permitidas” que combina com seu modelo de negócio.

Checklist rápido e próximos passos

Trate o trabalho de licenças como um requisito de release, não como um remendo pontual. Antes de conversas sérias com clientes, você deve conseguir responder: “O que exatamente estamos entregando e sob quais licenças?”

Uma linha de base pré-release:

• Inventário completo do que você entrega (incluindo dependências transitivas e ativos empacotados)
• Versões travadas e licenças conhecidas (sem “desconhecido”, “personalizado” ou “veja README” sem solução)
• Avisos prontos para envio (third-party notices, avisos de copyright exigidos, textos de licença obrigatórios)
• Builds reprodutíveis (lockfiles comitados e realmente usados)
• Um responsável claro para atualizações contínuas

Se você tem um release nas próximas 1 a 2 semanas, priorize avisos e builds repetíveis primeiro. É isso que parceiros conseguem verificar rapidamente. Se tiver mais tempo, adicione uma regra de intake de dependências para que licenciamento não seja redescoberto durante procurement.

Se o repositório é herdado ou gerado por IA, espere lacunas: lockfiles faltando, pacotes não utilizados, código copiado sem cabeçalhos e artefatos de build que empacotam arquivos de terceiros. Quando a base de código já está instável, muitas vezes é mais rápido consertar o build e o inventário primeiro, depois fazer a papelada.

Pedir ajuda quando o repositório está bagunçado ou gerado por IA

Quando um repositório é herdado e meia-boca, trabalho de licença pode parecer um chute. Fica mais difícil quando o código foi produzido rapidamente por ferramentas de IA, porque dependências podem ter sido adicionadas sem muita revisão, trechos podem não ter cabeçalhos e artefatos entregues podem incluir arquivos de terceiros que ninguém lembra.

Ajuda dividir o trabalho em duas frentes:

• Decisões jurídicas: interpretar obrigações (por exemplo, se sua forma de distribuição aciona termos copyleft, ou como lidar com releases passados que perderam avisos).
• Limpeza de engenharia: inventário, automação e conserto do repositório para que você repita o processo a cada release.

Um padrão prático é engenheiros produzirem os fatos (lista de dependências, licenças, avisos) e o jurídico revisar casos marginais e aprovar a redação.

Se precisar de ajuda prática para transformar um protótipo herdado e quebrado em algo que você possa entregar e defender em revisões, FixMyMess (fixmymess.ai) se concentra em diagnosticar e reparar codebases geradas por IA ou herdadas, incluindo refatoração, hardening de segurança e preparação para deploy. Um build limpo e estável costuma ser o caminho mais rápido para um inventário de dependências confiável e um pacote de avisos que parceiros aceitem.

Antes de pedir ajuda a alguém, junte alguns básicos para que o trabalho seja preciso: acesso ao repositório (ou um export sanitizado), seus passos atuais de build e release, um artefato entregue de exemplo (imagem/zip/instalador/bundle) e quaisquer questionários de clientes que você já recebeu.