Como Proteger a Propriedade Intelectual do Seu Jogo: Guia Legal Completo

Levei anos pra entender que código não é a única coisa que a gente constrói quando faz um jogo. O nome, a logo, a arte, a trilha, as mecânicas, tudo isso é ativo. E ativo que não tem dono no papel é ativo que qualquer um pega.

Esse post não é consultoria jurídica (procure um advogado de PI antes de fechar contrato ou registrar algo). É o mapa que eu queria ter tido pra não errar feio: o que cada tipo de proteção cobre, o que realmente vale registrar, e onde a maioria dos devs indie escorrega.

Os quatro tipos de proteção (e o que cada um cobre de verdade)

A confusão começa aqui. Direito autoral, marca e patente não são a mesma coisa, e cada um protege uma camada diferente do seu jogo. Misturar isso é o erro número um.

Direito autoral (copyright)

Cobre a expressão criativa: código-fonte, arte, música, diálogos, roteiro. No Brasil, direito autoral é automático: nasce no momento em que você cria a obra, sem precisar registrar nada. A Lei 9.610/98 garante isso.

Então pra que registrar? Pra prova. Se um dia você precisar mostrar que criou aquilo primeiro, um registro datado vale muito mais que um "confia em mim". Software no Brasil se registra no INPI (programa de computador é regido pela Lei 9.609/98). Arte, música e texto podem ir pra Biblioteca Nacional.

O que o direito autoral NÃO cobre: a ideia. Você não protege "jogo de plataforma com cogumelo que cresce". Protege o seu código, a sua arte, o seu personagem específico. Mecânica e conceito ficam de fora, e é por isso que clone de gameplay é tão difícil de combater na Justiça.

Na prática, a única coisa de código que faz sentido aqui é deixar o aviso de direito autoral no projeto. Não tem segredo, é uma linha:

// Copyright (c) 2024 Seu Estúdio. Todos os direitos reservados.
// Distribuição ou reprodução não autorizada é proibida.

Esse comentário não "protege" nada por si só (a proteção é a lei). Ele só sinaliza autoria e ano, o que ajuda em disputa. Não invente sistema de "verificação de integridade do build" achando que isso é proteção legal: não é, é DRM, e a gente fala disso lá embaixo.

Marca registrada (trademark)

Aqui mora o ativo mais subestimado pelo dev indie: o nome do jogo e a logo. Marca protege o que identifica seu produto no mercado, o título, o logotipo, às vezes um slogan.

E marca, diferente de direito autoral, NÃO é automática. Você precisa registrar no INPI. Sem registro, qualquer um pode lançar um jogo com o mesmo nome, e se registrar antes de você, o problema passa a ser seu.

A classe que interessa pra games é a 9 (software, jogos eletrônicos) na Classificação de Nice, e dependendo do seu modelo também a 41 (entretenimento). Você registra por classe, então pense em onde o jogo vai viver: só digital? Merchandising físico depois? Cada frente é uma classe.

Os símbolos:

• ™ você usa em marca que ainda não foi registrada (sinaliza intenção)
• ® só pode usar DEPOIS que o INPI concedeu o registro. Usar ® antes da concessão é irregular.

Antes de batizar o jogo, faça a busca de anterioridade na base do INPI (e na do USPTO e WIPO se pretende lançar fora). Já vi gente investir meses de marketing num nome que já era marca registrada de outro. Aí ou troca tudo ou recebe notificação.

Patente de mecânica

A pergunta que sempre aparece: "dá pra patentear minha mecânica de gameplay?" Resposta honesta: quase nunca vale a pena, e no Brasil é especialmente difícil.

Patente exige novidade, atividade inventiva e aplicação industrial. Regra de jogo pura tende a esbarrar nas exclusões da nossa Lei de Propriedade Industrial (Lei 9.279/96), que não considera patenteáveis regras de jogo e métodos abstratos. O que às vezes passa é um método técnico associado, um sistema específico, não "a ideia da mecânica".

O caso clássico que todo mundo cita é o sistema Nemesis da Warner (registrado nos EUA), que prendeu por anos algo perto de "inimigos que lembram do jogador". Repare em duas coisas: foi nos EUA, não aqui, e custou rios de dinheiro em advogado. Patente é caro, demora anos e tem prazo de validade. Pra 99% dos indies, o esforço vai melhor investido em lançar e construir marca. Se você acha que tem mesmo algo inédito e técnico, fale com um advogado de patentes antes de divulgar qualquer detalhe, porque divulgação pública pode matar a novidade.

Como registrar, na prática

Direito autoral / software

No INPI, o registro de programa de computador pede uma identificação da obra e um trecho do código-fonte (você não precisa depositar o projeto inteiro; o INPI aceita um extrato, normalmente em formato criptografado por hash justamente pra você não expor tudo). Guarde também seu histórico de versionamento.

E aqui vai a dica que vale mais que qualquer registro caro: seu Git já é prova de autoria. Commits datados, com seu nome, mostrando a obra evoluindo ao longo do tempo. Um repositório privado com histórico íntegro é uma das evidências mais fortes que existem de quem criou o quê e quando. Use isso. É de graça e você já faz.

Marca

O fluxo no INPI, em ordem:

1. Busca de anterioridade (confirmar que o nome está livre na sua classe)
2. Definir as classes de Nice corretas
3. Protocolar o pedido e pagar a GRU
4. Acompanhar a publicação e o prazo de oposição de terceiros
5. Responder exigências, se houver
6. Concessão

Os valores mudam todo ano, então não confie em número de blog: consulte a tabela de retribuições atual no site do INPI. O que dá pra dizer com segurança é que a taxa oficial costuma ser barata; o que pesa no orçamento é a assessoria de um advogado ou agente de PI, e pra marca que você vai investir anos, geralmente vale pagar por isso.

Pra fora do Brasil, o Sistema de Madri (WIPO) permite pedir registro em vários países num pedido só, e o depósito no Brasil te dá direito de prioridade por 6 meses pra estender lá fora mantendo a data original.

Contratos: o que mata estúdio indie

Mais gente perde a PI por contrato mal feito do que por pirataria. De longe. Você contrata um artista freelancer, ele entrega a arte, e a arte continua sendo dele a menos que o contrato diga o contrário. Isso pega muita gente de surpresa.

Dois documentos que você precisa ter:

NDA (acordo de confidencialidade). Antes de mostrar seu projeto pra parceiro, publisher ou freela, alinhe o que é confidencial. Cláusulas que não podem faltar: definição do que é informação confidencial, o que cada parte pode e não pode fazer com ela, prazo de vigência e o que acontece se vazar.

Contrato com cláusula de cessão de direitos. Esse é o que salva o estúdio. Todo colaborador (artista, músico, programador freela) precisa assinar transferindo pra você os direitos sobre o que criou no projeto. Sem essa cláusula, "work for hire" não é automático no Brasil como muita gente pensa. Os pontos centrais:

• Escopo exato do trabalho
• Cessão dos direitos patrimoniais pro estúdio (e o que acontece com direitos morais, que no Brasil são do autor e não se transferem)
• Pagamento, royalties ou valor fechado
• Prazos e entregas
• Garantia de que o colaborador não usou material de terceiro sem licença

Esse último ponto é sério: se o seu freela usou um asset pirateado ou um sample não licenciado, o processo cai no seu colo, porque o jogo é seu. Contrato bom te protege disso.

Assets de terceiros: licença é tudo

Quase todo jogo usa algo que não foi você que fez: um pacote de sprites da Unity Asset Store, uma fonte, um efeito sonoro do Freesound, uma música Creative Commons. Cada um desses vem com uma licença, e ignorar isso é bomba-relógio. Se você vai vender o jogo, vale aprofundar em como as licenças de assets de terceiros liberam ou proíbem o uso comercial antes de fechar o projeto.

Os tipos que você mais vai encontrar:

• Royalty-free: paga uma vez, usa quanto quiser. NÃO quer dizer "de graça", quer dizer "sem royalty por uso".
• Rights-managed: licença pra um uso específico (uma plataforma, um período). Sair fora do escopo é violação.
• Creative Commons: tem várias. CC0 é domínio público, faz o que quiser. CC BY exige crédito. CC BY-NC proíbe uso comercial, ou seja, NÃO serve pro seu jogo pago. Leia a sigla antes de usar.

O hábito que evita dor de cabeça: mantenha uma planilha (ou um arquivo de texto no repo) listando cada asset de terceiro, de onde veio, qual a licença e o link. Quando chegar a hora de montar os créditos e provar que está tudo licenciado, você agradece. E os assets que exigem atribuição já saem prontos pra entrar na tela de créditos.

Pirataria e DRM: gaste energia onde importa

Vou ser direto: DRM é um jogo que você não ganha. Todo esquema de proteção acaba quebrado, e quanto mais agressivo o DRM, mais ele incomoda quem pagou e empurra a galera pro crack. Sempre invertido.

Então qual a abordagem que funciona na real?

Pra jogo single-player, o consenso de boa parte da indústria indie é não brigar contra a pirataria a ponto de prejudicar o cliente legítimo. Muitos estúdios mantêm uma checagem leve de licença e param por aí. As funções que dependem de servidor (multiplayer, ranking online, conquistas sincronizadas, conteúdo entregue pela rede) já são naturalmente difíceis de piratear, porque exigem uma conta válida do seu lado. É aí que mora a proteção real, não em criptografia exótica no executável.

Sobre "watermark invisível em pixel" e "registro em blockchain de cada asset": esquece. Isso aparece em artigo de PI como se fosse padrão, mas pra estúdio indie é solução cara atrás de problema que você não tem. Sua prova de autoria já está no Git e no registro do INPI. Não complique.

Onde gastar energia de verdade: facilitar a compra legítima. Preço justo, build sem fricção, disponível onde seu público está. A maioria das pessoas paga quando comprar é mais fácil que piratear.

Quando alguém clona seu jogo

Vai acontecer, principalmente se o jogo for bem. A pergunta certa não é "como impeço", é "o que eu consigo realmente defender".

Lembra a separação lá do começo: ideia e mecânica quase não têm proteção. Então um clone que copia o loop de gameplay mas usa arte e código próprios é frustrante, mas juridicamente difícil de derrubar. Agora, um clone que copiou sua arte, sua trilha, seu código ou o nome do seu jogo, esse você tem como atacar, porque aí entra direito autoral e marca.

O caminho prático quando você acha um clone:

1. Junte evidência antes de qualquer coisa: screenshots, vídeo lado a lado, datas, URL. Print tudo, porque o anúncio some quando o sujeito percebe.
2. Identifique o que foi copiado de fato (arte? nome? código?) e não o que "parece parecido".
3. Para arte/código copiado em loja digital (Steam, App Store, Google Play, itch.io), a via mais rápida costuma ser a notificação de remoção via DMCA direto pra plataforma. Você não precisa de processo pra isso, as lojas têm canal próprio.
4. Para uso indevido do seu nome de marca, a notificação extrajudicial e, se preciso, ação no INPI ou na Justiça.

Pra casos sérios, vale ter um advogado de PI antes de mandar notificação, porque DMCA falso ou acusação sem base pode voltar contra você.

O essencial, sem enrolação

Se você é indie e tem orçamento curto, priorize nessa ordem:

1. Versione tudo no Git. Sua prova de autoria mais barata e mais forte já está aí.
2. Registre a marca (nome e logo) na classe certa antes de investir pesado em divulgação. É o ativo que clone mais ataca e o mais fácil de defender.
3. Contrato de cessão com todo colaborador. Sem isso, a arte e a música do seu jogo podem não ser suas.
4. Controle as licenças dos assets de terceiros num arquivo simples no repo.
5. Esqueça DRM pesado e patente de mecânica. Custo alto, retorno baixo pro seu estágio.

Proteção de PI não é sobre montar uma fortaleza. É sobre não deixar porta escancarada nos pontos que importam. Faça o básico bem feito e você já está à frente da maioria.