Plágio de software: como investigar uma cópia com código diferente

A existência de um código-fonte diferente não encerra, por si só, uma investigação de plágio de software. Uma reescrita, uma mudança de linguagem ou uma reorganização dos arquivos pode eliminar coincidências textuais superficiais, mas não necessariamente as correspondências presentes na arquitetura, nas dependências, nas regras de negócio, nas exceções ou no comportamento do sistema.

A resposta tecnicamente responsável também precisa evitar o extremo oposto: lógica semelhante, arquitetura parecida ou um percentual elevado de similaridade não comprovam isoladamente uma cópia. A análise deve comparar camadas diferentes, preservar as versões disponíveis, registrar as diferenças e testar explicações alternativas, como requisitos comuns, frameworks, bibliotecas, APIs, padrões de mercado e desenvolvimento independente.

É essa combinação de correspondências específicas, histórico técnico e exclusão de hipóteses plausíveis que pode tornar uma conclusão mais consistente. O objetivo da perícia não é transformar um score em veredito, mas explicar o que foi encontrado, como foi encontrado e quais limites permanecem.

Plágio de software: código-fonte diferente pode indicar uma possível cópia?

Pode indicar uma hipótese que merece investigação, mas não uma conclusão automática. O ponto central é saber se existem correspondências específicas e difíceis de explicar por fatores independentes, distribuídas em diferentes camadas do software.

Duas aplicações podem apresentar funcionalidades semelhantes porque atendem ao mesmo requisito, utilizam a mesma API ou seguem uma prática comum de mercado. Por outro lado, a combinação pouco usual de módulos, sequências de validação, mensagens internas, tratamentos de exceção, erros e decisões de arquitetura pode justificar uma análise mais aprofundada, especialmente quando há evidências históricas de acesso, reutilização ou evolução relacionada.

Na prática, a pergunta “o código é igual?” é estreita demais. Para investigar uma possível cópia, é necessário perguntar também:

• Quais materiais existiam em cada versão e quando foram produzidos?
• As estruturas de dados e os fluxos apresentam combinações específicas?
• As dependências, mensagens e exceções são impostas pela tecnologia ou foram escolhidas livremente?
• Há sinais de uma ancestralidade comum, de reutilização de componentes ou de desenvolvimento independente?
• O comportamento observado permanece semelhante em cenários que não são explicados apenas pelo requisito funcional?

Essa abordagem pode ser aprofundada em uma perícia em plágio de software, desde que o escopo seja delimitado aos materiais efetivamente disponíveis.

O que precisa ser preservado antes da comparação

A comparação começa antes da ferramenta. Se os materiais forem alterados, selecionados de forma incompleta ou apresentados sem contexto, a análise posterior pode perder justamente os elementos necessários para reconstruir a origem e a evolução do sistema.

Entre os itens potencialmente relevantes estão:

• repositórios completos, incluindo branches, tags e histórico de commits;
• cópias do código-fonte e versões entregues ou distribuídas;
• executáveis, instaladores, pacotes e artefatos de build;
• arquivos de configuração e versões das dependências;
• ambientes de desenvolvimento, compilação e execução;
• documentação técnica, especificações, diagramas e modelos de dados;
• registros de testes, tickets, logs e documentação de implantação;
• registros de acesso, distribuição, alterações e revisões;
• amostras de entrada, saídas esperadas e resultados de testes.

A preservação deve permitir explicar a origem de cada arquivo, sua relação com os demais materiais e as operações realizadas durante a análise. Hashes, registros de coleta, controle de acesso, cópias de trabalho e documentação das transferências contribuem para a rastreabilidade, mas não substituem a descrição do procedimento.

A ISO/IEC 27037:2012 oferece orientação para identificação, coleta, aquisição e preservação de evidências digitais. Em uma disputa de software, esse raciocínio pode ser aplicado a repositórios, executáveis, versões, dependências e demais artefatos relacionados.

Também é importante preservar o contexto negativo: o que não foi localizado, quais versões não estavam disponíveis, quais branches foram excluídas e quais ambientes não puderam ser reproduzidos. A ausência de um material pode limitar a conclusão, mas não deve ser silenciosamente tratada como se o material jamais tivesse existido.

Em disputas envolvendo ambientes em nuvem, dispositivos corporativos ou desligamento de profissionais, a preservação pode ser distribuída entre diferentes fontes. A discussão sobre evidências digitais em disputas envolvendo software ajuda a compreender por que contratos, registros de implantação, materiais de aceitação, comunicações e ambientes técnicos também podem ser importantes para reconstruir o desenvolvimento.

Quais camadas do software podem ser comparadas

Nenhuma técnica responde sozinha a todas as perguntas. A seleção depende do material disponível, do estágio de desenvolvimento, das linguagens envolvidas e da hipótese que se pretende testar.

Código, tokens, AST e estruturas de implementação

A comparação textual ou baseada em tokens é útil para localizar trechos semelhantes, mas pode ser afetada por renomeação de variáveis, reordenação de instruções, inserção de código morto, alteração de comentários e transformações sintáticas. Ela funciona melhor como triagem ou como parte de um conjunto de evidências, não como medida autossuficiente.

A análise baseada em AST, ou árvore sintática abstrata, permite comparar estruturas do código depois de normalizar determinados elementos, como nomes e literais. Isso pode revelar que duas implementações conservam uma organização semelhante mesmo quando a aparência textual mudou. Ainda assim, uma reestruturação semântica profunda pode produzir árvores diferentes, e uma estrutura semelhante pode decorrer da própria linguagem ou do framework utilizado.

Abordagens baseadas em grafos de dependência, como o Program Dependence Graph, procuram representar relações de controle e de dependência de dados. Elas podem ser úteis para examinar se determinadas operações, decisões e fluxos permanecem relacionados depois de transformações superficiais. O resultado continua dependente da ferramenta, da configuração, do corpus comparado e da interpretação do especialista.

Arquitetura, módulos, dependências e integrações

A análise arquitetural examina a organização do sistema: módulos, camadas, interfaces, chamadas, integrações, serviços, modelos de dados e dependências. O objetivo não é afirmar que uma arquitetura semelhante seja indevida, mas distinguir o que é imposto por tecnologia ou requisito daquilo que representa uma combinação particular de escolhas.

Uma aplicação construída sobre determinado framework pode ter diretórios, componentes e padrões de inicialização semelhantes a muitas outras. Da mesma forma, uma API pode exigir formatos, nomes de campos e sequências específicas. Porém, dependências incomuns, versões específicas, combinações de bibliotecas e formas particulares de contornar limitações podem merecer correlação com outras evidências.

A análise precisa registrar também as diferenças. Um módulo ausente, uma camada criada para substituir outra ou uma dependência incompatível pode enfraquecer uma hipótese de cópia direta, embora não resolva sozinho uma hipótese de reutilização, adaptação ou desenvolvimento a partir de especificações comuns.

Regras de negócio, exceções e comportamento

A análise de regras de negócio examina cálculos, validações, permissões, estados, sequências de aprovação, tratamentos de exceção e condições de erro. Mensagens internas, erros raros ou sequências pouco usuais podem ser relevantes, mas somente depois de confrontados com bibliotecas, templates, geradores, requisitos e documentação compartilhada.

A comparação comportamental utiliza entradas controladas, saídas, traces, testes instrumentados ou observação do sistema em execução. Para ser interpretável, precisa definir os cenários, o ambiente, as versões, os oráculos e a cobertura dos testes. Duas aplicações podem apresentar a mesma saída em um cenário simples e divergir significativamente em condições de exceção; ou podem divergir na interface e conservar regras internas semelhantes.

Quando o código-fonte não está disponível, executáveis e pacotes podem ser examinados por técnicas de comparação binária e engenharia reversa. Essas técnicas podem correlacionar funções, chamadas e estruturas, mas os resultados são influenciados por compiladores, otimizações, bibliotecas incorporadas e configurações de build. O fato de uma ferramenta ser capaz de realizar essa análise não significa que ela tenha sido utilizada em um caso concreto nem que seu resultado seja conclusivo.

Como separar coincidência natural de correspondência específica

Uma matriz de análise ajuda a evitar conclusões intuitivas. Para cada achado, convém responder a quatro perguntas:

1. O que coincide? Código, estrutura, dependência, fluxo, mensagem, erro, exceção, modelo de dados ou comportamento?
2. Quão específico é o achado? Trata-se de uma solução comum, de uma exigência técnica ou de uma combinação incomum de escolhas?
3. Quais explicações alternativas existem? Requisitos compartilhados, documentação pública, framework, biblioteca, gerador, API, norma técnica ou ancestralidade comum?
4. Como o achado se relaciona com os demais? Ele aparece isoladamente ou integra um padrão em versões, módulos, regras e comportamentos diferentes?

Essa matriz não calcula uma “probabilidade jurídica” de cópia. Ela organiza o raciocínio técnico e torna visíveis as premissas. Uma mensagem rara pode ter valor investigativo maior quando aparece junto de uma sequência incomum de validações, do mesmo tratamento de erro e de uma dependência pouco usual. Mesmo assim, será necessário investigar se esses elementos vieram de uma biblioteca, de um gerador ou de uma especificação comum.

O percentual de similaridade deve ser lido dentro desse contexto. Sistemas como o MOSS podem auxiliar a localizar correspondências, mas o resultado depende do material submetido, da normalização, do conjunto comparado e da interpretação. Um percentual não informa, sozinho, a origem do código, a autoria, o acesso ao sistema anterior ou a existência de reprodução juridicamente ilícita.

Como testar hipóteses de desenvolvimento independente

Uma análise que procura somente sinais de cópia corre o risco de ignorar explicações plausíveis. O teste deve incluir, desde o início, a hipótese de desenvolvimento independente e outras fontes comuns.

É necessário verificar, por exemplo:

• se os sistemas atendem aos mesmos requisitos funcionais;
• se há padrões regulatórios ou técnicos que limitam as alternativas;
• se as APIs ou formatos de integração impõem campos e sequências;
• se as bibliotecas produzem mensagens, erros ou estruturas semelhantes;
• se frameworks e geradores criam arquivos ou componentes padronizados;
• se o modelo de dados decorre de uma norma ou prática setorial;
• se a documentação pública orienta a mesma solução;
• se há histórico de versões compatível com desenvolvimento autônomo;
• se as diferenças são coerentes com equipes, linguagens e arquiteturas distintas.

Quando os sistemas foram escritos em linguagens diferentes, a comparação pode migrar da superfície textual para estruturas, dependências, fluxos, regras e comportamento. Isso não significa que a preservação da lógica demonstre automaticamente origem indevida. Significa apenas que a pergunta técnica mudou: em vez de procurar linhas iguais, busca-se verificar se decisões específicas foram reproduzidas em diferentes representações.

Em casos envolvendo suspeita de cópia por acesso a ambientes corporativos ou saída de profissional, a preservação deve ser rápida e abrangente. O material pode estar distribuído entre repositórios, serviços em nuvem, dispositivos, ferramentas de colaboração e contas de acesso. A preservação de evidências digitais quando há suspeita de cópia apresenta riscos que também podem ocorrer em disputas de software, sem significar que todo caso envolva apropriação por empregado.

Como documentar uma conclusão técnica reproduzível

Uma conclusão pericial precisa permitir que outro especialista compreenda o caminho percorrido e, quando possível, reproduza ou critique os resultados. Para isso, o relatório deve indicar:

• escopo da análise e perguntas respondidas;
• materiais recebidos, origem, versões e eventuais lacunas;
• hashes, procedimentos de preservação e cópias utilizadas;
• linguagens, compiladores, dependências e ambientes examinados;
• ferramentas, versões, configurações e critérios de normalização;
• unidades de comparação e justificativa da seleção;
• correspondências identificadas e diferenças relevantes;
• hipóteses alternativas consideradas e como foram testadas;
• resultados de testes, entradas, saídas, traces e limitações;
• pontos que não puderam ser concluídos por falta de material ou reprodutibilidade.

A ISO/IEC 27042:2015 trata da análise e interpretação de evidências digitais, incluindo aspectos de continuidade, validade, reprodutibilidade, repetibilidade e documentação. A aplicação prática não elimina o julgamento técnico, mas exige que o método e suas limitações sejam expostos ao escrutínio.

Guias de preservação, como o Digital Evidence Preservation do NIST, também reforçam a importância de origem, integridade, armazenamento, transferências e documentação dos objetos digitais. Em uma disputa, esses elementos ajudam a diferenciar um arquivo originário de uma exportação sem contexto ou de uma cópia cuja cadeia de obtenção não foi registrada.

No contexto judicial, a assistência técnica pode atuar na formulação de perguntas, na revisão de laudos, na avaliação de configurações e na identificação de materiais ausentes. A elaboração de quesitos técnicos para investigar cópia de software deve transformar a alegação genérica de cópia em questões verificáveis.

Também é importante distinguir os papéis processuais. A diferença entre perito judicial e assistente técnico não muda a necessidade de método, mas ajuda a compreender quem produz o exame, quem o acompanha e como os achados podem ser tecnicamente questionados.

O que a perícia pode e não pode concluir juridicamente

A perícia pode identificar correspondências, diferenças, relações de dependência, padrões de comportamento, evolução de versões e limitações do material. Também pode avaliar se determinadas semelhanças parecem impostas por requisitos ou se, ao contrário, formam uma combinação específica que exige explicação adicional.

Ela não deve converter automaticamente esses achados em afirmação de reprodução ilícita, violação de direitos, autoria, intenção ou responsabilidade. Essas conclusões dependem de elementos jurídicos e documentais, como titularidade, autorização, licenças, contratos, acesso ao código, origem dos materiais e circunstâncias da utilização.

A Lei nº 9.609/1998 estabelece o regime brasileiro de proteção dos programas de computador e prevê que essa proteção independe de registro. A mesma lei, em seu art. 6º, III, considera que determinada semelhança não constitui ofensa quando decorrer de características funcionais, preceitos normativos ou técnicos ou limitações de forma alternativa de expressão. A consulta ao texto oficial da Lei nº 9.609/1998 é indispensável para a análise do enquadramento aplicável.

Assim, a sequência adequada é: constatação técnica, explicação das limitações, avaliação das hipóteses e posterior análise jurídica. Uma falha de documentação pode reduzir a força explicativa de um achado; não produz automaticamente nulidade ou inadmissibilidade. Do mesmo modo, uma correspondência relevante pode subsidiar o debate, mas não substitui a decisão jurídica sobre reprodução, adaptação, distribuição ou autorização.

Perguntas frequentes

Código-fonte diferente pode ser considerado cópia de software?

Pode justificar uma investigação, mas não permite concluir automaticamente que houve cópia. A análise deve verificar arquitetura, dependências, regras, exceções, histórico, comportamento e explicações alternativas, além do código propriamente dito.

Um percentual de similaridade prova plágio de software?

Não. O percentual é um indicador dependente da ferramenta, da configuração e da base comparada. Ele pode ajudar a localizar correspondências, mas precisa ser interpretado junto com diferenças, contexto, histórico e outras evidências.

O que analisar além dos trechos de código-fonte?

Podem ser examinados módulos, interfaces, modelo de dados, dependências, fluxos, cálculos, validações, exceções, mensagens, erros, executáveis, versões, logs e comportamento em testes controlados. A relevância de cada elemento depende do escopo e das hipóteses examinadas.

Como investigar uma possível cópia quando os sistemas foram escritos em linguagens diferentes?

A comparação pode se concentrar em estruturas, relações de dependência, regras de negócio, fluxos, exceções, modelos de dados e comportamento. Ainda assim, semelhanças funcionais podem decorrer de requisitos comuns e não devem ser tratadas como prova isolada.

Quais materiais devem ser preservados antes de uma perícia de software?

Sempre que disponíveis, devem ser preservados repositórios, commits, branches, versões, executáveis, dependências, ambientes de build, documentação, logs, testes, registros de acesso e artefatos de distribuição. A origem, a integridade e as limitações de cada material também precisam ser documentadas.

A principal implicação é que uma reescrita muda a forma da comparação, mas não elimina a necessidade de investigação. O exame mais informativo não procura apenas linhas idênticas: correlaciona escolhas arquiteturais, estruturas, dependências, regras, exceções, versões e comportamentos, enquanto testa hipóteses de requisitos comuns e desenvolvimento independente.

Quando esses elementos são documentados com método, diferenças e limitações, a perícia oferece algo mais útil do que um score: uma explicação auditável sobre o que os materiais permitem afirmar e sobre o que permanece tecnicamente indeterminado. É essa separação entre achado, hipótese e conclusão jurídica que preserva a confiabilidade da análise.