A história chega ao laboratório em duas versões espelhadas. Na primeira, a empresa vê seu produto renascer no mercado meses depois da saída de um desenvolvedor-chave: mesmas funções, mesmas telas, até os mesmos defeitos, agora com outra marca. Na segunda, uma empresa recebe a notificação acusando-a de contrafação: o software que ela desenvolveu seria cópia do concorrente, e a indenização pedida tem muitos zeros. Nos dois cenários, a pergunta técnica é idêntica: até que ponto dois softwares são parecidos porque resolvem o mesmo problema, e a partir de que ponto a semelhança só se explica por cópia?
O que a comparação de código examina
Software se compara em camadas. Na superfície, a experiência: telas, fluxos, nomenclaturas visíveis. Abaixo, a arquitetura: como o sistema se organiza, como os módulos conversam, como os dados se estruturam. E no fundo, o código-fonte, onde mora a assinatura de quem escreveu: nomes de variáveis e funções, estilo de escrita, comentários, soluções idiossincráticas para problemas comuns. Dois sistemas do mesmo nicho podem legitimamente se parecer nas camadas de cima, porque o domínio impõe o formato. O que não se explica por coincidência é a identidade nas camadas de baixo, e é ali que o exame concentra o esforço.
Os achados decisivos costumam ser os herdados por descuido: o comentário em português idêntico, com o mesmo erro de digitação, nos dois códigos; a função com nome peculiar que só faz sentido na história interna da primeira empresa; o mesmo defeito, reproduzido com a mesma correção improvisada; a biblioteca modificada de forma única aparecendo modificada da mesma forma no software supostamente independente. Quem copia raramente reescreve tudo, e o que fica para trás funciona como o DNA do caso: elementos arbitrários demais para nascerem duas vezes por acaso.
"Sistemas do mesmo ramo se parecem por natureza. O que não nasce duas vezes por acaso é o mesmo comentário com o mesmo erro de digitação, na mesma função, resolvendo o mesmo problema do mesmo jeito torto."
O caminho do código também é prova
Além do confronto entre os dois softwares, o exame reconstrói a rota da cópia. Repositórios de código registram quem acessou o quê e quando; os artefatos da estação de trabalho guardam vestígios de dispositivos USB conectados e volumes copiados; servidores documentam clonagens completas do repositório às vésperas do desligamento; serviços de nuvem pessoal recebem uploads que os registros de rede datam e medem. O mesmo método da investigação de vazamento interno se aplica aqui, com um alvo específico: demonstrar que o acervo saiu, quando saiu e com quem estava. A correlação entre a rota da cópia e a identidade do código fecha o circuito probatório.
O alcance vai além do código: bases de clientes, planilhas de precificação e documentação técnica seguem a mesma lógica probatória, e os detalhes arbitrários que carregam (registros peculiares, formatações, erros herdados) denunciam o reaproveitamento com a mesma força.
A defesa técnica de quem não copiou
A perícia serve igualmente ao acusado injustamente, e esses casos existem em quantidade. A defesa se constrói demonstrando o desenvolvimento independente: o histórico do repositório com a evolução gradual do código desde a origem, as decisões de arquitetura divergentes nas camadas profundas, a ausência dos elementos arbitrários compartilhados. Quando a acusação se apoia apenas na semelhança de telas e funções, o exame que desce ao código desmonta a tese: parecido por fora e distinto por dentro é a assinatura do concorrente legítimo, não do contrafator.
Quando não há código-fonte: o confronto pelo binário
Nem sempre o suposto contrafator entrega o código, e nem sempre o juízo o obriga a tempo. O exame então desce ao produto compilado: o binário distribuído, o aplicativo instalado, o sistema em produção. Mesmo sem o fonte, o software conta sua história: as cadeias de texto embutidas (mensagens, rótulos, caminhos internos), as bibliotecas incorporadas e suas versões, a estrutura de funções que a análise técnica reconstrói, os recursos gráficos e arquivos auxiliares que viajam junto. A comparação de binários identifica coincidências tão arbitrárias quanto as do código: a mesma mensagem de erro com a mesma digitação peculiar, o mesmo conjunto de bibliotecas nas mesmas versões modificadas, artefatos internos com nomes que só existiam no projeto original. O resultado orienta inclusive a fase seguinte do processo: com indícios objetivos no binário, o pedido de exibição do código-fonte deixa de ser pescaria e vira diligência fundamentada.
Antes do litígio: o dever de casa das empresas
- Repositório com histórico íntegro e autoria rastreável: é o registro de nascimento do seu código;
- Controle de acesso documentado: quem pode clonar o quê, com trilha de auditoria preservada;
- Contratos com cláusulas claras de titularidade e confidencialidade, inclusive com prestadores;
- Desligamento de pessoal técnico com protocolo: revogação de acessos e preservação da estação de trabalho;
- Ao primeiro indício de cópia, preservação forense antes da notificação: o notificado apaga.
Disputas de software costumam ser narradas como duelos de opinião entre desenvolvedores, cada lado com seu especialista jurando o óbvio. A perícia bem-feita retira o caso desse terreno: transforma semelhança em medida, rota em linha do tempo e convicção em demonstração reprodutível. No fim, a pergunta "copiou ou não copiou?" tem resposta técnica na imensa maioria dos casos. O que ela exige é o que todo litígio de tecnologia exige: chegar cedo, preservar certo e examinar fundo.
Código é patrimônio que se copia num minuto e se disputa por anos. A diferença entre os dois desfechos é o que a empresa preservou no dia em que ainda não precisava.
