Kit do fornecedor fiscal no projeto: baixar a DLL não diz o que você pode redistribuir

Um cliente novo pede o instalador do sistema de vendas. Você vai empacotar e trava: dentro da pasta libs há uma DLL de emissão fiscal baixada em 2021, ninguém sabe qual versão é, se a licença permite entregar a terceiros, nem se ainda recebe correção. A resposta curta: o arquivo baixado não carrega a permissão de uso. Anote no dia do download o termo de licença, a versão, a origem e o hash, guarde tudo fora do repositório público e trate o componente como dependência com dono e data de revisão.

O exemplo deste guia é um sistema de PDV fictício, o pdv-loja, que usa um kit de fornecedor para emitir documento fiscal eletrônico. O mesmo raciocínio vale para qualquer SDK proprietário, driver de impressora ou componente de relatório.

Por que o download engana

Página de download costuma ter um botão grande e um link pequeno para os termos. O desenvolvedor clica no botão, referencia a DLL e o build passa. O build passar prova que o código compila, não que você pode redistribuir. A licença pode limitar o uso a um CNPJ, proibir redistribuição, exigir contrato comercial em produção ou valer só para homologação.

O segundo problema é o tempo. A página muda, o fornecedor reorganiza o site, a versão antiga some. Anos depois, a única cópia do termo que você aceitou está na memória de alguém que saiu da empresa. Quando o cliente ou um auditor pergunta, não há o que mostrar.

O terceiro é o leiaute fiscal. Documentos fiscais eletrônicos mudam por notas técnicas publicadas pelos órgãos responsáveis. Um kit parado na versão de anos atrás pode gerar arquivo rejeitado de um dia para o outro. Se ninguém sabe quem atualiza o componente, a rejeição vira incêndio.

Como registrar o componente do jeito certo

1. Leia e salve o termo no dia: baixe o PDF ou salve a página da licença com data. Anote o que ela diz sobre redistribuição, uso em produção e número de instalações.
2. Registre versão e hash do arquivo: o hash prova qual binário você recebeu e detecta troca acidental.
3. Crie um manifesto de terceiros no repositório: um arquivo pequeno com nome, versão, origem, licença, onde está guardada e quem é o responsável.
4. Guarde o binário num lugar controlado: feed privado de pacotes ou armazenamento interno com acesso restrito, nunca o repositório público.
5. Defina dono e data de revisão: uma pessoa confere a cada trimestre se há versão nova ou nota técnica que afete o kit.

Calculando o hash do arquivo

No Windows, o PowerShell já tem o comando. No Linux, sha256sum faz o mesmo:

# PowerShell
Get-FileHash .\vendor\KitFiscal.dll -Algorithm SHA256

# Linux
sha256sum vendor/KitFiscal.dll

O manifesto de terceiros

No pdv-loja, o manifesto fica na raiz como third-party.json. Ele não contém segredo nem binário, só a ficha do componente:

{
  "componentes": [
    {
      "nome": "KitFiscal",
      "versao": "4.2.1",
      "origem": "pagina de downloads do fornecedor",
      "baixado_em": "2026-03-10",
      "sha256": "coloque-aqui-o-hash-calculado",
      "licenca": "contrato comercial n. interno CT-2026-014",
      "redistribuicao": "permitida apenas junto ao instalador do pdv-loja para clientes com contrato",
      "termo_guardado_em": "drive juridico / fornecedores / kitfiscal / 2026-03-10.pdf",
      "responsavel": "time-fiscal",
      "proxima_revisao": "2026-06-10"
    }
  ]
}

Os valores acima são fictícios. O ponto é que qualquer pessoa da equipe, lendo esse arquivo, responde em um minuto às perguntas que antes levavam uma semana.

Tirando o binário do repositório

Instalador e DLL de fornecedor não devem ir para o Git, ainda mais em repositório público. Além do risco de licença, binário grande incha o histórico para sempre. Ignore a pasta:

# .gitignore
vendor/
*.msi
*.exe

Em projetos .NET, uma saída limpa é empacotar o kit como pacote NuGet interno e publicá-lo num feed privado (Azure Artifacts, GitHub Packages ou servidor próprio). O nuget.config aponta para o feed, e a credencial fica na máquina ou no cofre do CI, nunca no arquivo:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="interno" value="https://pacotes.exemplo.com.br/nuget/v3/index.json" />
  </packageSources>
</configuration>

Se o instalador já foi para um repositório público

Apagar o arquivo num commit novo não resolve: ele continua no histórico e em qualquer clone feito antes. Se junto com o kit foi uma chave de licença ou token do fornecedor, peça a troca da chave antes de limpar o histórico. A ordem importa pelo mesmo motivo explicado no guia sobre segredo vazado no Git. Depois, reescreva o histórico com uma ferramenta como git filter-repo e avise quem tem clone.

Se não houve segredo, mas a licença proíbe redistribuição, avise o fornecedor e o responsável jurídico. Esconder costuma sair mais caro que conversar.

Quando o fornecedor descontinua o kit

Com o manifesto em dia, você sabe exatamente qual versão roda, sob qual contrato e com qual prazo. Isso transforma "o fornecedor parou" de emergência em projeto de migração. Sem o manifesto, a primeira semana é só arqueologia. O raciocínio é o mesmo de outros recursos de terceiros, como em pacote de ícones gratuito que ainda tem licença e dados públicos que têm regra de uso.

Este texto não é orientação jurídica. A interpretação de um contrato de licença específico cabe a quem responde juridicamente pela empresa.

Erros comuns

• Confiar que "baixei do site oficial" é permissão: origem confiável não diz nada sobre redistribuição, e o cliente pode receber algo que você não podia entregar.
• Commitar o instalador no repositório: o histórico incha para sempre e, se o repositório for público, qualquer pessoa redistribui por você.
• Passar a chave do fornecedor no grupo de mensagens: a chave sai do controle e você não sabe mais quem a usa.
• Não registrar a versão: quando o leiaute fiscal muda, ninguém sabe se o kit atual já atende, e o diagnóstico começa do zero.
• Deixar o componente sem dono: nota técnica nova passa despercebida até a primeira rejeição em produção.
• Usar licença de homologação em produção: o sistema pode parar quando o período de teste expira, no pior dia possível.

Checklist

• O termo de licença está salvo com data, fora do repositório público.
• Existe um manifesto com nome, versão, origem, hash e licença de cada componente.
• A cláusula de redistribuição foi lida e resumida no manifesto.
• Nenhum instalador, DLL de fornecedor ou chave está no histórico do Git.
• O binário vem de um feed privado ou armazenamento com acesso restrito.
• Há uma pessoa responsável e uma data de próxima revisão.
• A licença de produção é diferente da de homologação, quando o fornecedor separa as duas.

Abra a pasta de dependências do seu projeto agora e escolha o arquivo de fornecedor mais antigo: você consegue dizer, sem perguntar a ninguém, qual versão ele é e se a licença permite entregá-lo ao próximo cliente?