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 não é protegido
|
Elemento |
Protegido? |
Fundamento |
|
Código-fonte original |
Sim |
Art. 2º, Lei 9.609/98 |
|
Código-objeto compilado |
Sim |
Art. 2º, §1º, Lei 9.609/98 |
|
Algoritmo matemático subjacente |
Não |
Ideia não protegida |
|
Funcionalidade / o que o programa faz |
Não |
Art. 8º, I, Lei 9.610/98 |
|
Interface gráfica (UI/UX) |
Controvertido |
Ver jurisprudência abaixo |
|
Semelhança por características funcionais |
Não |
Art. 6º, III, Lei 9.609/98 |
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.
Clique aqui e confira o artigo na íntegra.