Código-Fonte: Cópia, Derivação e Criação Independente

Quando classificar um caso como LS-03

Use a LS-03 quando se alega que um software reproduz outro, no todo ou em parte — literalmente ou pela lógica. Pergunta de enquadramento: "a controvérsia exige comparar dois códigos (ou um código contra uma versão anterior dele)?" Se sim, é LS-03 — ainda que combinada com LS-02 (titularidade) ou com concorrência desleal.

Tipologia (com critério)

• LS-03.1 — Cópia literal. Trechos idênticos/quase idênticos além do explicável por framework, template ou geração automática.
• LS-03.2 — Derivação (cópia não-literal). Estrutura, sequência e organização reproduzidas com o texto reescrito — o "parafraseado" do código.
• LS-03.3 — Criação independente. Semelhanças explicáveis por padrões de mercado, mesmo requisito funcional, mesma biblioteca. Também é uma conclusão possível e deve ser dita quando for o caso.

Protocolo executável — 6 etapas

1. Etapa 1 — Aquisição forense dos dois lados.
   Objetivo: congelar os artefatos comparandos com integridade demonstrável.
   Execução: cópia integral (repositório com histórico, binários, banco, configs) de ambos os códigos; hash SHA-256 por arquivo e do conjunto; registro de data/hora, origem e responsável pela entrega; princípios da ISO/IEC 27037.
   Entregável: pacote forense lacrado (hashes + termo de coleta) — sem ele, tudo o que vem depois é atacável.
2. Etapa 2 — Inventário e normalização.
   Objetivo: saber exatamente o que será comparado.
   Execução: listar arquivos por tipo/linguagem/tamanho; identificar versões de frameworks e dependências (package.json, pom.xml, requirements.txt, copybooks); normalizar formatação para não comparar diferenças cosméticas.
   Entregável: inventário lado A × lado B.
3. Etapa 3 — Filtragem do trivial.
   Objetivo: remover o que é igual "por natureza" para não inflar similaridade.
   Execução: excluir da comparação: código de framework e bibliotecas de terceiros; código gerado (scaffolding, ORMs, protobuf); boilerplate notório. Registrar o critério de exclusão — a parte contrária vai perguntar.
   Entregável: corpus comparável = a lógica proprietária de cada lado.
4. Etapa 4 — Análise em 5 camadas.
   Objetivo: medir semelhança de formas independentes que se corroboram.
   Execução:
   • Camada 1 · Léxica: nomes de variáveis, funções, classes, tabelas, constantes. Nomes proprietários coincidentes (WS-CALC-JUROS-X, tbl_cliente_score_v2) valem mais que nomes genéricos (i, total, GetUser).
   • Camada 2 · Estrutural: árvore de diretórios, módulos, hierarquia de pacotes, assinatura de funções.
   • Camada 3 · Semântica: a lógica — fluxos de decisão, ordem de operações, algoritmos, regras de negócio. É a camada decisiva para derivação (LS-03.2).
   • Camada 4 · Metadados: comentários (inclusive erros de grafia repetidos), strings, mensagens de erro, TODOs, cabeçalhos de autoria.
   • Camada 5 · Cronologia: histórico de versionamento dos dois lados — quem existia primeiro; commits que importam código em bloco; datas incompatíveis com a versão da criação alegada.
   Entregável: mapa de similaridade por camada, com cada achado ancorado em arquivo/linha dos dois lados.
5. Etapa 5 — Classificação e teste de hipóteses.
   Objetivo: transformar achados em conclusão honesta.
   Execução: para o conjunto de achados, testar as três hipóteses (cópia, derivação, independência): quais achados cada hipótese explica e quais ela não explica? A conclusão é o cenário que melhor explica TODOS os achados — nunca a tese do contratante por default.
   Entregável: conclusão fundamentada com grau de convicção e limites declarados.
6. Etapa 6 — Laudo com demonstração lado a lado.
   Objetivo: permitir que o juízo VEJA a similaridade.
   Execução: quadros comparativos (trecho A × trecho B) dos achados mais fortes, com explicação em linguagem leiga do porquê aquela coincidência não é acaso; anexos técnicos completos para o contraditório.
   Entregável: laudo/parecer + quadros comparativos + pacote forense.

Checklist do advogado

• Preservação IMEDIATA dos dois códigos (liminar/ata notarial se necessário) — código muda todo dia;
• Repositórios com histórico, não apenas o código compilado;
• Se só houver acesso ao binário do adversário: avaliar cabimento de busca e apreensão ou exibição judicial.

Erros comuns

• Rodar uma ferramenta de similaridade e tratar o percentual como conclusão — sem filtragem (Etapa 3) o número é lixo;
• Ignorar a hipótese de criação independente — laudo parcial cai na contradita;
• Comparar versões de épocas diferentes sem controlar a cronologia.

Base legal

Lei 9.609/98 (proteção do programa; independe de registro). Lei 9.610/98 (obra derivada). Art. 195 da Lei 9.279/96 quando combinada com concorrência desleal. ISO/IEC 27037 (evidência digital). Art. 342 CP.

Quesitos-modelo

• "Queira o Sr. Perito, após excluir código de frameworks, bibliotecas de terceiros e trechos gerados automaticamente, informar se os códigos apresentam, na camada de regras de negócio, similaridades que não se explicam por padrões de mercado — exemplificando com trechos lado a lado."
• "Queira o Sr. Perito informar se é possível determinar, pelos históricos de versionamento, qual dos códigos é anterior, e se há registros de importação de código em bloco compatíveis com transferência entre os projetos."