Software

Seu código tem histórico. Agora ele também tem prova.

Repositórios mudam de dono, sócios saem, freelancers entregam e somem, e às vezes um concorrente lança algo surpreendentemente parecido. O histórico do Git ajuda, mas pode ser reescrito e depende de quem controla o servidor. Registrar snapshots do seu código cria uma prova independente de que aquela versão existia naquela data.

Ver como funciona

O desafio

Onde a prova costuma falhar

Histórico do Git pode ser reescrito

Commits podem ter datas alteradas e o repositório depende de quem administra o servidor. Não é uma prova neutra.

Disputas entre sócios e ex-colaboradores

Quando a sociedade termina, a pergunta "quem criou o quê, e quando" vira o centro da discussão.

Entregas sem marco claro

Em projetos terceirizados, comprovar o que foi entregue em cada etapa evita discussões sobre escopo e pagamento.

Como o Docmint ajuda

Uma prova técnica, simples de criar e fácil de conferir

Marco independente

O hash do snapshot vai para uma blockchain pública. Nem você, nem o servidor do Git, nem o Docmint podem mudar a data.

Código confidencial continua confidencial

O código não é enviado. Só a impressão digital do arquivo é registrada.

Cada release, um registro

Registre o pacote de cada versão. Juntos, os registros formam uma linha do tempo verificável do produto.

Verificável por qualquer perito

SHA-256 é padrão de mercado: qualquer especialista confere o registro com ferramentas comuns.

O que registrar

Arquivos que valem um registro

  • Snapshots do código-fonte (ZIP, TAR)
  • Releases e binários publicados
  • Algoritmos, modelos e notebooks
  • Documentação técnica e de arquitetura
  • Especificações, PRDs e protótipos
  • Bases de dados e datasets de treino
  • Entregas de freelancers e fornecedores
  • Propostas técnicas para clientes

Qualquer formato serve: o Docmint registra a impressão digital do arquivo, não o conteúdo.

Na prática: registrando cada release

Sua equipe fecha uma versão importante do produto.

  1. 1

    Gere o pacote da release (por exemplo, git archive) e o PDF da documentação.

  2. 2

    Registre os arquivos em lote no Docmint, com o número da versão no título.

  3. 3

    Guarde os recibos junto com as tags da release.

  4. 4

    Em uma disputa futura, você mostra que aquele código exato existia naquela data.

Boas práticas

  • Registre um arquivo compactado gerado de forma reproduzível (ex.: git archive de uma tag).
  • Anote o hash do commit na descrição do registro (sem segredos).
  • Registre marcos: MVP, releases maiores, entregas de terceiros.
  • Nunca inclua chaves, senhas ou dados pessoais no título e na descrição.
  • Para pedidos de patente, procure um especialista: o registro não substitui o INPI.

O que diz a lei

A Lei 9.609/98 protege os programas de computador, e essa proteção independe de registro (art. 2º, § 3º). O registro de software no INPI é opcional e o Docmint não o substitui, mas oferece uma prova técnica rápida de autoria e data. Invenções que exigem patente seguem as regras próprias do INPI.

Perguntas frequentes

O commit do Git já não é uma prova?

Ajuda, mas datas de commit podem ser alteradas e o repositório depende de quem o controla. O registro em blockchain é um marco externo e neutro.

Preciso registrar o repositório inteiro?

Registre um arquivo compactado da versão (o que importa é o hash dele). Guarde esse arquivo exatamente como foi registrado.

Substitui o registro de software no INPI?

Não. O registro no INPI é opcional e tem efeitos próprios. O Docmint é uma prova técnica complementar, rápida e barata.

Veja também

Comece pelo seu próximo arquivo.

Crie sua conta em segundos e ganhe 3 registros para testar no seu dia a dia.