Perícia de cópia de código em sistemas legados: COBOL e Java sob análise comparativa

Disputas de cópia de código em sistemas legados têm uma particularidade: COBOL e Java antigos são verbosos e padronizados. Isso significa que é normal encontrar trechos semelhantes entre dois sistemas — copybooks padrão, patterns de acesso a DB2, estruturas de CICS comuns. A perícia precisa separar o que é coincidência trivial (padrões de mercado, templates da empresa, código gerado por ferramenta) daquilo que só se explica por cópia.

O que diferencia coincidência de cópia

Em COBOL, os sinais de cópia vão além da lógica:

• Nomes de variáveis e parágrafos: WS-CALC-JUROS-COMPOSTO e PARA-CALC-JUROS-COMPOSTO com a mesma grafia, no mesmo programa, com a mesma lógica — improvável por acaso;
• Comentários reproduzidos: inclusive com os mesmos erros de português;
• Sequência de parágrafos: a mesma ordem de execução, com os mesmos PERFORMs e GOTOs, no mesmo fluxo;
• Copybooks compartilhados: a presença do mesmo COPY com o mesmo nome e a mesma estrutura de dados.

Em Java, o exame é similar, mas olha para pacotes, classes, nomes de métodos, padrões de design (ou anti-patterns) idênticos, e metadados de versionamento (Git/SVN).

O método: apurar, não presumir

A análise comparativa apura — e não presume — cópia. O resultado pode ser: (a) cópia comprovável com alto grau de similaridade não-trivial; (b) obra derivada (aproveitamento parcial); ou (c) criação independente (coincidências explicáveis por padrões de mercado). A conclusão segue a prova, não uma tese pré-definida.

Cada achado é documentado com cadeia de custódia — imagem forense, hash e preservação conforme a ISO/IEC 27037 — para que a prova resista ao contraditório.