Plágio de Software: Como Provar, o que a Lei Protege e Como Agir Juridicamente

A proteção jurídica do software no Brasil é tema de crescente relevância no contencioso empresarial, sendo, ao mesmo tempo, um dos campos mais mal compreendidos pelos titulares de programas de computador. Quando um ex-sócio, ex-funcionário ou concorrente lança no mercado um produto que parece suspeitamente idêntico ao seu, a primeira pergunta é inevitável: isso é plágio de software, e é possível provar? A resposta exige compreender precisamente o que a lei 9.609/98 protege, o que ela deliberadamente deixa desprotegido, e qual é o caminho técnico-jurídico para construir uma prova robusta. Este artigo aborda cada um desses pontos com base na doutrina nacional e estrangeira mais qualificada e na jurisprudência mais recente dos tribunais superiores brasileiros.

1. O que a lei protege e o que ela não protege

A lei 9.609/98 assimila o programa de computador ao regime da obra literária (lei 9.610/98), protegendo a expressão (o código na sua literalidade), não a ideia, a funcionalidade ou o resultado produzido. Conforme magistério de Newton Silveira em sua obra clássica sobre direito autoral de software, a dicotomia ideia-expressão é o eixo sobre o qual orbita toda a matéria: protege-se como o programador disse algo, não o quê ele disse.

Denis Borges Barbosa aprofunda essa análise ao distinguir os diferentes níveis de abstração do software (da lógica do negócio ao código-objeto), concluindo que a proteção autoral incide sobre a expressão original em cada nível, mas nunca sobre o algoritmo subjacente enquanto regra matemática ou método de operação.

No plano norte-americano, Pamela Samuelson (UC Berkeley) e David Nimmer (Nimmer on Copyright) desenvolveram o chamado AFC test (Abstraction, Filtration, Comparison), metodologia que filtra do corpus a ser comparado tudo aquilo que não é protegível: elementos ditados pela eficiência, requerimentos externos (padrões de mercado, APIs), e domínio público. O que sobra, depois dessa filtragem, é o núcleo comparável. O teste é amplamente referenciado em laudos periciais brasileiros de alta complexidade.

Manoel Joaquim Pereira dos Santos e Marcos Wachowicz sublinham, no âmbito nacional, que a proteção jurídica do software abrange o código-fonte e o código-objeto na mesma medida, isto é, o executável compilado goza de proteção equivalente ao texto original, o que tem implicações diretas para as hipóteses em que o adversário não entrega voluntariamente o código-fonte.

O que é protegido e o que não é protegido em um software

Código-fonte original - Protegido pela Lei do Software (Lei nº 9.609/98).

Código-objeto compilado - Também recebe proteção legal como parte do programa de computador.

Algoritmo matemático subjacente - Não é protegido, pois a legislação não protege ideias ou conceitos abstratos.

Funcionalidade do software (o que o programa faz) - Não é protegida. A proteção recai sobre a forma de expressão do software, e não sobre sua finalidade.

Interface gráfica (UI/UX) - Tema controverso.

Dependendo do caso concreto e da jurisprudência, a cópia da aparência e da experiência de uso pode gerar discussão judicial.

Semelhanças decorrentes de características funcionais - Não configuram automaticamente plágio, desde que resultem apenas da necessidade de executar a mesma função.

Este último ponto (art. 6º, III) é frequentemente mal utilizado como escudo por contrafatores. O dispositivo afasta a infração quando a semelhança decorre das características funcionais da aplicação. Mas, como demonstrou o TJ/PR no caso Gear Up × Langowski (2024), há um limite: quando a imitação ultrapassa a semelhança funcional e alcança a experiência de interface (look and feel), o perito reconheceu "plágio por derivação" mesmo com códigos-fonte distintos. O STJ concedeu efeito suspensivo ao recurso especial, reconhecendo tensão com o art. 6º, III, o que sinaliza que a jurisprudência superior ainda não pacificou o tema.

2. Bibliotecas, código aberto e licenças

Um ponto frequentemente ignorado pelos clientes e até por advogados menos especializados é que a presença de componentes de código aberto no software objeto da disputa afeta diretamente a análise pericial e a extensão da proteção.

Bibliotecas de terceiros (open-source, domínio público ou licenciadas) devem ser excluídas do núcleo protegível antes de qualquer comparação. O perito que não realiza essa filtragem produz um laudo tecnicamente comprometido e facilmente atacável pela parte adversa.

As licenças de software livre variam enormemente quanto à permissão de derivações:

MIT / BSD / Apache 2.0: permissivas, ou seja, o código pode ser incorporado a software proprietário sem obrigação de abertura do código derivado. A cópia é permitida desde que mantidos os avisos de autoria.

GPL v2 / v3 (copyleft): o software derivado deve ser distribuído sob a mesma licença GPL; qualquer incorporação de código GPL em produto proprietário sem observância desta regra constitui violação contratual e de direito autoral.

LGPL: versão menos restritiva do GPL, admite uso em software proprietário com restrições menores.

Creative Commons: aplica-se a conteúdo, não a código, sendo sua invocação para software tecnicamente incorreta.

O advogado que assessora um cliente em caso de plágio de software deve, portanto, antes de qualquer notificação, mapear quais bibliotecas de terceiros foram utilizadas, sob quais licenças, e se o adversário as incorporou adequadamente. Descobrir que o código "plagiado" é, na verdade, uma biblioteca GPL pública enfraquece dramaticamente a tese autoral, embora possa revelar, por outro lado, uma violação de licença igualmente relevante.

3. Como provar o plágio

O maior obstáculo prático em todo caso de plágio de software é o acesso ao código-fonte do concorrente. Há quatro caminhos jurídicos, em ordem crescente de complexidade:

I. Entrega voluntária: ocorre quando há relação contratual anterior (contrato de trabalho, NDA, sociedade) que produza obrigação de confidencialidade. A existência do contrato fundamenta pedido de exibição (arts. 396-404, CPC).

II. Ação de exibição de documentos: cabível quando o detentor tem obrigação legal ou contratual de exibir o código. Requer indicação precisa do documento e demonstração do interesse jurídico.

III. Tutela de urgência para preservação de prova (art. 301, CPC): indicada quando há risco de que o código seja apagado, sobrescrito ou ofuscado antes da perícia. Permite busca e apreensão, acesso a servidores e depósito em juízo.

O caso PARADIGMA × IBID (STJ, REsp 2.228.760-SC, relator ministro Humberto Martins, 2026) demonstra a eficácia dessa via: a busca e apreensão dos servidores da ré, realizada sob contraditório com apresentação de quesitos pelo assistente técnico, produziu o laudo que sustentou a condenação em todas as instâncias.

IV. Engenharia reversa do binário: quando nenhum caminho anterior é viável, ferramentas como Ghidra (NSA, gratuita) e IDA Pro permitem descompilar executáveis e recuperar aproximações do código-fonte. O perito deve deixar explícito no laudo que trabalha sobre uma representação aproximada, uma vez que essa representação tem caráter indiciário, não conclusivo.

Fonte: Migalhas