Copiou código de um repositório público? Como não herdar bug sem correção

Em 2025, a equipe de sistemas de uma prefeitura copiou o módulo de numeração de documentos de um projeto público de gestão documental. Baixou o zip, colou numa pasta, ajustou três arquivos e seguiu a vida. Em 2026, o projeto original publicou uma correção de segurança justamente nesse módulo. A equipe soube por acaso, num grupo de mensagens. Ao tentar aplicar a correção, descobriu que não sabia de qual versão tinha copiado, nem o que tinha mudado.

A resposta curta: código público copiado vira código seu, com o custo de manutenção junto. Antes de colar, leia a licença. Ao colar, registre o commit exato de origem e mantenha suas alterações separadas e documentadas. Depois, tenha uma rotina para olhar o que mudou no original e trazer as correções. Se não dá para fazer isso, assuma o fork por inteiro, com testes e responsável, em vez de fingir que é uma dependência.

Por que "é público" engana

Repositório público tem três coisas que o zip não traz: licença, histórico e uma comunidade que corrige. A licença diz o que você pode fazer com o código. O histórico diz de onde cada linha veio. A comunidade publica correções que só chegam a quem acompanha. Quando você copia o conteúdo sem esse contexto, fica com o código de um dia específico, congelado, e todas as correções futuras passam a ser trabalho seu.

Público também não significa suporte. A equipe do projeto não sabe que você existe e não tem obrigação de avisar. Abrir chamado de serviço no repositório não funciona, como explica organização pública no GitHub não é canal de chamado. E dado público tem as próprias regras, assunto de API de dados públicos tem licença.

Licença: o primeiro arquivo que você abre

Abra o arquivo LICENSE (ou COPYING) na raiz do projeto antes de copiar qualquer linha. Se ele não existir, o código não vem com permissão de uso, mesmo estando visível. As licenças se dividem em dois grandes grupos:

• Permissivas, como MIT e Apache 2.0: permitem usar e modificar dentro de sistema fechado, pedindo basicamente que você mantenha o aviso de copyright e o texto da licença. A Apache 2.0 também pede que arquivos modificados indiquem a modificação.
• Copyleft, como GPL e AGPL: quem distribui um trabalho derivado pode ter de disponibilizar o código desse trabalho sob a mesma licença. A AGPL estende essa obrigação a quem oferece o sistema para uso pela rede, o que pega em cheio sistemas web.

O enquadramento exato do seu caso depende de como o código é combinado e distribuído. Isto não substitui a análise de um profissional habilitado: se a licença for copyleft e o seu sistema for fechado ou vendido, leve a dúvida ao jurídico antes de colar.

Como trazer o código do jeito certo, passo a passo

1. Prefira usar a dependência como dependência. Se o projeto publica pacote (NuGet, npm, Maven, Composer), instale a versão fixa pelo gerenciador, com lockfile, como em dependência com cadeado. Atualizar vira trocar um número.
2. Se precisar copiar, clone em vez de baixar zip. O clone guarda o histórico e permite saber o commit.
3. Anote o commit de origem, a data, o caminho original e a licença num arquivo ao lado do código copiado.
4. Faça a cópia intacta num commit e as suas alterações em commits separados. Assim, o diff entre "original" e "seu" é sempre visível.
5. Exporte suas alterações como patches, para reaplicar sobre uma versão nova do original.
6. Assine as releases e os alertas de segurança do projeto. No GitHub, a opção personalizada do botão Watch permite receber só esses avisos.
7. Marque uma revisão periódica com responsável e data, para olhar o que mudou no original.

Se você já copiou sem anotar: descubra o commit de origem

Foi o caso da prefeitura. Dá para estimar de qual commit a cópia saiu comparando a pasta copiada com cada versão do original. Num clone do projeto original:

git clone https://github.com/orgao/sistema-publico.git
cd sistema-publico
mkdir -p /tmp/cand

for c in $(git rev-list --since=2025-01-01 main -- modulo/numeracao); do
  git archive "$c" modulo/numeracao | tar -x -C /tmp/cand
  echo "$c $(diff -r /tmp/cand/modulo/numeracao ../meu-sistema/src/numeracao | wc -l)"
  rm -rf /tmp/cand/modulo
done | sort -k2 -n | head -3

O commit com menos linhas de diferença é o candidato mais provável. As linhas que sobram são, em grande parte, as suas alterações locais. Ajuste a data e o nome do branch principal para o projeto real; nem todo repositório usa main.

O arquivo de origem, ao lado do código

# src/numeracao/ORIGEM.md
origem:            https://github.com/orgao/sistema-publico
caminho original:  modulo/numeracao
commit base:       3f9c2e1 (2025-04-11)
licença:           (nome exato do arquivo LICENSE do projeto)
alterações locais: patches/0001-numeracao-por-secretaria.patch
                   patches/0002-ano-fiscal.patch
responsável:       Renata (substituto: Diego)
última revisão:    2026-10-01

A revisão periódica

No clone do original, veja o que mudou no módulo desde o seu commit base:

git fetch origin
git log --oneline 3f9c2e1..origin/main -- modulo/numeracao

Se aparecer uma correção, gere a versão nova do módulo e reaplique os seus patches com git apply --3way patches/*.patch sobre ela, num branch. Conflito em patch é sinal de que o original mudou a parte que você alterou: resolva com calma e com teste. Depois atualize o commit base no ORIGEM.md.

Se a sua alteração for útil para todos, mande para o projeto original como pull request. Cada mudança aceita lá é uma mudança a menos para você manter.

Erros comuns

• Baixar o zip. Sem histórico, você não sabe de qual versão veio, e cada correção futura exige arqueologia.
• Misturar a cópia com as suas mudanças no mesmo commit. Ninguém consegue separar o que é original do que é local na hora de atualizar.
• Ignorar a licença. Código copyleft dentro de sistema fechado pode gerar obrigação de abrir o código, descoberta só quando alguém reclama.
• Apontar para a ponta do repositório. Submódulo ou script que sempre pega o último commit traz mudança não revisada para a produção.
• Não assinar os alertas. A correção de segurança sai, e você fica sabendo pelo grupo de mensagens, meses depois.
• Fork sem responsável. Ninguém revisa o original, e o módulo envelhece até virar o pedaço do sistema que ninguém quer tocar.

Checklist

• A licença do projeto de origem foi lida e é compatível com o seu uso.
• O código veio por pacote com versão fixa ou por clone, nunca por zip solto.
• Existe um arquivo de origem com URL, commit base, licença e responsável.
• A cópia intacta e as alterações locais estão em commits separados.
• As alterações locais existem como patches reaplicáveis.
• Releases e alertas de segurança do original chegam a alguém do time.
• Há uma data marcada para a próxima revisão do que mudou no original.

Escolha um trecho de código de terceiros dentro do seu sistema e responda olhando só o repositório: você sabe dizer de qual commit do projeto original ele veio e o que foi alterado desde então?