Recriaram seu jogo ou app sem copiar o código: o que ainda protege a empresa

A onda tem nome e número. Um toolkit de código aberto que acopla agentes de inteligência artificial a ferramentas de engenharia reversa saltou de menos de dez mil para mais de cem mil estrelas no GitHub em cerca de uma semana, e com ele vieram os projetos que recriam e fundem software. No lado dos jogos, alguém reconstruiu a partir do binário compilado o código de um Call of Duty de 2009 usando agentes de IA, a ponto de muitas funções coincidirem com o original byte a byte; um mod público colocou o Minecraft rodando dentro do GTA V; e um jogo de navegador gerado por IA, um Fallout não oficial, viralizou. No lado da produtividade, apareceram alternativas abertas ao Photoshop e até ao pacote de escritório, montadas com IA em poucos dias. Ao mesmo tempo, fabricantes de software passaram a vender proteção específica contra a engenharia reversa assistida por IA.

O que levava uma equipe e meses agora cabe num fim de semana, e os titulares já estão reagindo: o Fallout não oficial saiu do ar depois de uma notificação extrajudicial da Bethesda, e o projeto do Call of Duty foi derrubado. O fenômeno não é só entretenimento, atinge o app de uma fintech, o SaaS de gestão, a API que integra sistemas, qualquer produto cuja vantagem esteja no software. A pergunta tem duas pontas que convém separar. Uma é até onde recriar ou fundir o produto de um terceiro é lícito. A outra, mais útil para quem tem o que proteger, é o que de fato resta de proteção quando alguém faz isso com o seu, sobretudo no caso em que não há uma linha de código copiada para apontar.

O que a engenharia reversa com IA mudou, e o que não mudou

A engenharia reversa sempre existiu, e nem sempre foi ilícita. Compreender a interoperabilidade de um sistema, preservar software antigo ou pesquisar falhas de segurança são usos legítimos da técnica. O que a IA alterou foi a escala: observar o comportamento de um programa, inferir a lógica e reconstruir a função em outra base de código ficou rápido e barato, e deixou de exigir o especialista raro. A consequência prática é que a reconstrução tende a não copiar o código original, e sim a reproduzir o que ele faz, muitas vezes reescrito do zero numa linguagem diferente. É aí que a proteção clássica do software encontra o seu limite, e é aí que o titular precisa entender onde está exatamente a linha entre o lícito e a infração.

O limite da engenharia reversa: observar a função é uma coisa, copiar a expressão é outra

O programa de computador é protegido pelo regime das obras literárias, por força do art. 2º da Lei 9.609/1998, e o que a lei resguarda é a expressão, o código tal como foi escrito, não a ideia nem a funcionalidade que ele realiza. A própria Lei 9.609, no art. 6º, III, diz que não há ofensa quando a semelhança entre dois programas decorre das características funcionais da aplicação, da observância de preceitos técnicos ou da limitação de formas alternativas de expressão. Fazer a mesma coisa, portanto, não é por si copiar, e a engenharia reversa que apenas observa o comportamento externo do programa para entender o que ele faz fica, em regra, do lado lícito.

A infração começa quando a reconstrução deixa de reproduzir a função e passa a reproduzir a expressão. Reconstruir o código a ponto de ele coincidir com o original byte a byte, como no caso do shooter de 2009, deixa de ser semelhança funcional e vira a própria expressão protegida, reescrita ou não. E a violação não se limita à cópia literal: quando a reimplementação reproduz a estrutura, a sequência e a organização internas que refletem escolhas criativas do autor, e não imposições da função, também há cópia da expressão. A reprodução não autorizada do software, ainda mais com finalidade comercial, é punida pelo art. 12 e seu § 1º da Lei 9.609/1998. O teste que separa o lícito do ilícito é sempre o mesmo: o que a função obriga é livre, o que o autor escolheu entre alternativas é protegido.

Clean room: o método que torna a reimplementação defensável, e por que a IA o ameaça

A forma consagrada de recriar a função de um software sem infringir a expressão é a sala limpa, o clean room. A técnica separa o trabalho em duas equipes estanques: uma analisa o programa original e descreve apenas o que ele faz, produzindo uma especificação funcional sem reproduzir código; a outra, que nunca teve acesso ao código nem ao material da primeira além dessa especificação, implementa do zero. Como a equipe que escreve nunca viu a expressão protegida, a semelhança do resultado se explica pela função, e não por cópia. É a tradução prática do princípio de que o direito autoral proíbe copiar, não criar de forma independente algo parecido.

O que a prova de infração persegue, no fundo, são dois elementos somados: acesso à obra protegida e semelhança substancial. A sala limpa ataca o primeiro, documentando que quem implementou não teve acesso à expressão. É por isso que o registro do processo importa tanto quanto o resultado: sem a trilha que comprove a separação, a mesma semelhança que seria explicada pela função passa a sugerir cópia.

A engenharia reversa com IA tensiona justamente esse ponto. Um modelo que foi treinado no código-fonte original, ou alimentado com o código descompilado para acelerar a reescrita, não é uma sala limpa: é uma sala contaminada. A reimplementação que sai dali pode carregar a expressão que a equipe humana juraria não ter copiado, porque quem a copiou foi a ferramenta. A rapidez que seduz é também o risco, e a empresa que reconstrói função alheia com IA precisa saber de onde o modelo tirou o que sabe, sob pena de achar que fez clean room quando fez o contrário. Do lado de quem defende o produto original, é exatamente essa a pergunta que desmonta a tese de criação independente: o modelo teve acesso ao código protegido?

A brecha que sobra: função e regra de jogo não são obra

Feita a separação corretamente, há um espaço que a lei de fato não reservou a ninguém. A Lei 9.610/1998, no art. 8º, exclui da proteção autoral, como tais, as ideias, os procedimentos, os sistemas e os métodos (inciso I) e, no inciso II, os esquemas, planos ou regras para realizar atos mentais, jogos ou negócios. A mecânica de um jogo, o fluxo de telas de um aplicativo, a regra que governa a interação, tudo isso é método e sistema, e a lei os deixou de fora de propósito, para que ninguém se aproprie da função em si. Quem reconstrói o comportamento por sala limpa, sem reaproveitar a expressão, trabalha dentro desse espaço livre.

Essa é a brecha que o titular precisa enxergar antes de montar qualquer reação: na frente da cópia de código pode simplesmente não haver o que apontar, se a outra parte fez o dever de casa. Insistir só nessa tese é construir a defesa sobre a prova que não existe, e o erro não é jurídico apenas, é de estratégia, porque consome tempo e credibilidade perseguindo o que a lei não protege e deixa de lado o que ela protege.

Antes da cópia: como a pessoa obteve e usou o software muda tudo

Há frentes de responsabilidade que não dependem de provar violação de obra, e a primeira pergunta a fazer é se houve termo de uso aceito. A licença e os termos de uso quase sempre proíbem engenharia reversa, descompilação, modificação e criação de trabalhos derivados, mas essa proibição só alcança quem os aceitou. O licenciado que reconstrói o produto a partir da cópia que contratou descumpre o que assinou, e o descumprimento rende pretensão própria, sem exigir a demonstração de cópia que falta na frente autoral. Já o terceiro que nunca licenciou nem aceitou nada não está preso ao contrato, e contra ele a reação tem de se apoiar nas outras frentes. Saber de que lado está o infrator, dentro ou fora do contrato, define desde o início quais cartas o titular tem na mão.

A segunda pergunta é como ele obteve o software. Se chegou ao produto, ao binário ou ao código invadindo sistema alheio, sem autorização, a conduta é, por si, o crime de invasão de dispositivo informático do art. 154-A do Código Penal, que a Lei 14.155/2021 agravou para reclusão de um a quatro anos e multa, independentemente de qualquer cópia posterior. E o código-fonte, na quase totalidade dos casos, é segredo de negócio: quem o divulga, explora ou usa tendo tido acesso por relação contratual ou de emprego comete concorrência desleal pelo art. 195, XI, da Lei 9.279/1996, e quem o obtém por meio ilícito ou fraude, pelo inciso XII do mesmo artigo. O ex-funcionário ou o parceiro que sai com a fonte no bolso é o caso clássico, e ali a discussão sobre semelhança de código nem precisa começar: a ilicitude está no modo de obter.

A terceira frente é a medida técnica de proteção. Quando o software embute mecanismo para impedir a cópia ou a inspeção, como as camadas de ofuscação e anti-descompilação que o mercado passou a vender contra a análise por IA, contornar ou neutralizar esse mecanismo é conduta reprovada pelo art. 107, I, da Lei 9.610/1998, que responsabiliza por perdas e danos quem altera, suprime ou inutiliza os dispositivos técnicos introduzidos para restringir a cópia. A violação aqui não é copiar a obra, é arrombar a fechadura, e existe mesmo que o resultado final não reproduza o código. É também a frente que a descompilação quase sempre aciona, porque abrir um binário protegido passa, antes, por vencer a proteção.

O que ainda protege, mesmo com reimplementação limpa

O software e o jogo não são só código. São um conjunto de ativos que a engenharia reversa normalmente não alcança, porque não estão na lógica do programa, e sim na sua aparência, no seu nome e na sua camada criativa. Não por acaso, as reações de maior efeito nos casos recentes se apoiaram menos na linha de código e mais na franquia: o jogo não oficial do universo Fallout e a reconstrução do Call of Duty não caíram por uma perícia de código, caíram pelo peso da marca, dos personagens e do mundo audiovisual que carregavam. É nessa frente que a reação costuma ter lastro real, inclusive contra a reimplementação feita por sala limpa, que isola o código, não a arte.

O primeiro ativo é o trade dress, o conjunto-imagem do produto: a identidade visual, o arranjo da interface, a combinação de cores, tipografia e elementos que, somados, fazem o usuário reconhecer de quem é o aplicativo antes de ler o nome. O trade dress não tem registro próprio no Brasil, mas é protegido pela repressão à concorrência desleal, com base penal no art. 195, III, da Lei 9.279/1996 e reparação civil no art. 209, quando a imitação cria confusão no público ou se aproveita parasitariamente do esforço alheio. Uma recriação que reproduz a cara do produto para capturar a mesma clientela entra nesse terreno, ainda que o código por baixo seja outro e tenha nascido limpo.

O segundo é a marca. O nome do jogo ou do aplicativo, o logotipo e os títulos registrados no INPI dão ao titular o uso exclusivo (art. 129 da Lei 9.279/1996), e a cópia que se apresenta ao mercado com o mesmo sinal, ou com sinal que gere confusão, infringe esse direito de forma autônoma, independentemente de qualquer discussão sobre software. É a proteção mais simples de provar e, não raro, a mais esquecida no desespero de achar a linha de código copiada.

O terceiro é o direito autoral dos elementos criativos destacáveis da função. Personagens, roteiro e diálogos, trilha, arte, e a própria sequência audiovisual do jogo são obras protegidas de forma independente do código, a audiovisual expressamente no art. 7º, VI, da Lei 9.610/1998. A regra do jogo não é protegida, mas o personagem que a protagoniza, o roteiro que a conduz e a identidade audiovisual que a veste são, e reaparecem reconhecíveis mesmo numa reimplementação que não tocou no código original. Vale também para o aplicativo de produtividade: quando surgem alternativas abertas que imitam a suíte de um fabricante conhecido, o código pode ser próprio, mas o nome, a identidade visual e a comunicação que evocam o original é que medem o risco.

A estratégia muda de “provar cópia” para “mapear ativos”

Para quem desenvolve software, aplicativo ou jogo, a lição da engenharia reversa barata é de preparação, não de pânico. A defesa deixa de depender da linha de código copiada e passa a depender de quanto dos outros ativos a empresa constituiu e documentou antes do problema. Registrar as marcas do produto, inclusive o título, no INPI; documentar o trade dress com material datado que prove a anterioridade e a distintividade do conjunto-imagem; registrar as obras criativas relevantes, dos personagens ao roteiro e à identidade audiovisual; redigir termos de uso que vedem com clareza a engenharia reversa e a modificação; e tratar o código como segredo de negócio, com controle de acesso documentado, que é o que sustenta a tese de confidencialidade se a fonte vazar. Cada um desses passos é barato perto do litígio e é o que transforma uma reclamação sem prova de cópia numa reação com fundamento.

Dois cuidados completam o quadro. O primeiro é que muitos desses projetos nascem fora do Brasil, com desenvolvedor, servidor e plataforma de distribuição em outra jurisdição, o que pesa na escolha do foro e da medida; ainda assim, a marca registrada no INPI e o trade dress construído no mercado brasileiro dão ao titular um ponto de apoio local contra a versão que chega aqui. O segundo é do outro lado do balcão: a empresa que recria função alheia se protege com o mesmo rigor de método, sala limpa de verdade, com a separação documentada, controle sobre o que as ferramentas de IA usaram como insumo, e a certeza de não ter acessado o que não devia. A engenharia reversa com IA não revogou a proteção do software, apenas deslocou o seu centro de gravidade, do código, que ficou mais fácil de recriar sem copiar, para a disciplina do processo e para os ativos que a reconstrução não alcança: a marca, o trade dress, a obra criativa, o contrato, o segredo de negócio e a medida técnica.

Perguntas frequentes

Fazer engenharia reversa de um software é lícito no Brasil?
Depende de como e até onde. Observar o comportamento do programa para entender a sua função, inclusive para interoperabilidade, preservação ou pesquisa de segurança, costuma ser lícito, e a mera semelhança funcional não é ofensa (art. 6º, III, da Lei 9.609/1998). Deixa de ser lícito quando descompila e copia o código, contorna a proteção técnica (art. 107, I, da Lei 9.610/1998), descumpre os termos de uso aceitos ou obtém o software por acesso não autorizado.

O que é clean room e por que ele importa?
É a sala limpa: separar quem analisa o software original e descreve só a sua função de quem implementa do zero, sem acesso ao código. Como quem escreve nunca viu a expressão protegida, a semelhança se explica pela função, não por cópia, o que sustenta a criação independente. Uma IA treinada ou alimentada com o código original quebra essa separação e contamina a reimplementação.

O que viola direito autoral ao recriar um software?
Copiar o código, de forma literal, byte a byte, ou pela reprodução da estrutura e organização que refletem escolhas criativas e não imposições da função. A reprodução não autorizada do software, sobretudo para comércio, é punida pelo art. 12 da Lei 9.609/1998. Também viola carregar os elementos criativos protegidos, como personagens, roteiro e identidade audiovisual. Não viola, por si, reconstruir a função por sala limpa, porque ideias, métodos e regras de jogo não são protegidos (art. 8º, I e II, da Lei 9.610/1998).

Muda algo se quem recriou aceitou ou não os termos de uso, e como obteve o software?
Muda bastante. A proibição de engenharia reversa nos termos de uso só alcança quem os aceitou; o terceiro que nunca licenciou não responde por contrato, mas segue sujeito às frentes de direito autoral, marca e acesso. E o modo de obtenção é frente autônoma: invadir sistema para conseguir o software é crime (art. 154-A do Código Penal, com pena agravada pela Lei 14.155/2021), e usar código-fonte confidencial obtido por relação de trabalho ou por meio ilícito é concorrência desleal (art. 195, XI e XII, da Lei 9.279/1996).

Recriar a função sem copiar o código deixa a empresa original sem saída?
Não. Mesmo com a reimplementação limpa, seguem protegidos o trade dress (art. 195, III, e art. 209 da Lei 9.279/1996), a marca (art. 129) e os elementos criativos destacáveis. A sala limpa isola o código, não a arte, o nome nem a aparência do produto.

Leia também

• Proteção de know-how e de APIs, sobre outros ativos intangíveis que a empresa precisa documentar antes da disputa.
• Cessão de marca em M&A e portfólio, sobre a marca forte como ativo que se negocia e se defende.

Fontes

Lei nº 9.609, de 19 de fevereiro de 1998 (proteção da propriedade intelectual de programa de computador; regime de obra literária no art. 2º; semelhança por características funcionais no art. 6º, III; violação e reprodução para comércio no art. 12 e § 1º): https://www.planalto.gov.br/ccivil_03/leis/l9609.htm

Lei nº 9.610, de 19 de fevereiro de 1998 (direitos autorais; obras protegidas no art. 7º; exclusões no art. 8º, I e II; dispositivos técnicos de proteção no art. 107): https://www.planalto.gov.br/ccivil_03/leis/l9610.htm

Lei nº 9.279, de 14 de maio de 1996 (Lei da Propriedade Industrial; uso exclusivo da marca no art. 129; concorrência desleal no art. 195, III, XI e XII; perdas e danos no art. 209): https://www.planalto.gov.br/ccivil_03/leis/l9279.htm

Decreto-Lei nº 2.848, de 7 de dezembro de 1940 (Código Penal; invasão de dispositivo informático no art. 154-A, incluído pela Lei 12.737/2012 e alterado pela Lei 14.155/2021): https://www.planalto.gov.br/ccivil_03/decreto-lei/del2848compilado.htm

Este conteúdo tem caráter informativo e não constitui opinião legal para caso concreto.