Software crackeado no GitHub: por que o DMCA trava

Um desenvolvedor independente passou um mês pedindo ao GitHub que tirasse do ar cópias crackeadas do software dele. Elas continuam lá. O relato apareceu no Hacker News e virou aquele tipo de thread que todo mundo que vende software lê com um nó no estômago. Software crackeado no GitHub não é novidade. A novidade é perceber que o caminho "oficial" para resolver pode demorar mais do que o seu lançamento.

Eu não tenho os bastidores do caso. Não sei o que foi escrito na notificação nem o que o GitHub respondeu em cada etapa. Mas conheço bem o processo, e ele explica muito sobre por que isso acontece. Explica também o que você, que escreve JavaScript e talvez venda alguma coisa, pode fazer antes de chegar nesse ponto.

O que aconteceu com o software crackeado no GitHub

O resumo é simples. Alguém pegou um software pago, removeu a verificação de licença e publicou o resultado em repositórios públicos. O autor mandou o pedido de remoção. Um mês depois, as cópias seguiam acessíveis.

Pela thread dá para ver duas reações. Uma parte dos comentários cai em cima do GitHub: "a Microsoft tem dinheiro para contratar gente, por que um mês?". A outra parte cai em cima do processo: "a notificação precisa estar exatamente no formato, senão volta para o fim da fila".

As duas têm um pouco de razão. E é aí que o assunto fica interessante.

Como funciona um pedido DMCA no GitHub

O GitHub segue o DMCA, a lei americana de direitos autorais. Quem hospeda conteúdo ganha proteção legal se remover material infrator quando recebe uma notificação válida. O ponto é esse "válida".

Uma notificação precisa ter, em linhas gerais:

• identificação da obra protegida (o seu software, com link para onde ele é vendido ou distribuído)
• a URL exata de cada arquivo ou repositório infrator
• seus dados de contato
• uma declaração de boa-fé e outra de que as informações são verdadeiras, sob pena de perjúrio
• assinatura

Parece burocracia boba, mas cada item tem motivo. Sem eles, qualquer um derruba o repositório de qualquer um com um e-mail. Isso já aconteceu muitas vezes, inclusive com projetos legítimos.

O GitHub ainda publica todas as notificações num repositório público, o github/dmca. Vale abrir. Você vê milhares de pedidos, muitos de empresas grandes, muitos mal formulados.

Tem um detalhe que pega muita gente: os forks. Se o repositório crackeado foi forkado 200 vezes, a notificação precisa deixar claro que a rede inteira de forks infringe, ou listar cada um. Senão o GitHub remove o original e os 200 forks continuam lá. Você manda o pedido, comemora, e descobre que o problema só mudou de endereço.

E existe a contranotificação. Quem publicou pode contestar. Nesse caso, o material volta ao ar em 10 a 14 dias úteis, a não ser que você entre com uma ação judicial. Para um dev solo, processar alguém anônimo em outro país é uma piada de mau gosto.

O DMCA protege a plataforma primeiro. Você vem depois.

Por que isso importa para quem escreve JavaScript

O tema aqui é JavaScript por um motivo bem prático. JS é a linguagem mais fácil de crackear que existe. Você entrega o código-fonte para o usuário. Minificado, talvez ofuscado, mas entrega.

Extensão de navegador, app Electron, plugin de editor, componente pago de UI, template de dashboard. Tudo isso roda na máquina de quem comprou, e qualquer pessoa com o DevTools aberto consegue ler.

Olha o padrão que eu mais vejo em produto pequeno:

// checagem de licença 100% no cliente
const res = await fetch('https://api.meuapp.com/license/' + key)
const { valid } = await res.json()

if (!valid) {
  showPaywall()
  return
}

unlockProFeatures()

Para crackear isso, ninguém precisa ser hacker. Basta trocar if (!valid) por if (false) e pronto. Ou interceptar a resposta e devolver { "valid": true }. Leva uns cinco minutos, e quatro deles são para achar o arquivo certo no bundle.

Ofuscação atrasa, mas não impede. Ferramentas de deobfuscação recuperam boa parte da estrutura, e quem cracka software faz isso por hobby. Você está apostando tempo de trabalho contra o tempo livre de alguém que se diverte com isso. Spoiler: você perde.

O que muda no seu código: mova o valor para o servidor

A única proteção que funciona de verdade é não entregar no cliente a coisa que vale dinheiro. Se a feature pro roda no navegador, ela pode ser copiada. Se ela depende de algo que só o seu servidor faz, a cópia crackeada fica capenga.

Na prática, isso significa trocar "o cliente pergunta se pode" por "o servidor só responde se pode":

// Bun + Hono, por exemplo
app.post('/api/export-pdf', async (c) => {
  const user = await getUser(c)
  if (!user?.plan || user.plan === 'free') {
    return c.json({ error: 'upgrade required' }, 402)
  }

  const pdf = await renderPdf(await c.req.json())
  return c.body(pdf, 200, { 'Content-Type': 'application/pdf' })
})

Aqui não tem if no front para remover. A geração do PDF acontece no servidor. Quem crackear o front vai ter um botão bonito que devolve 402.

Nem todo produto permite isso. Um template de dashboard é só código e não tem servidor nenhum. Um app offline precisa funcionar sem rede. Nesses casos, algumas coisas ajudam a reduzir o estrago:

• Licença assinada, não "válida ou não". O servidor assina um token (JWT com chave privada, Ed25519) com e-mail, plano e validade. O app valida a assinatura com a chave pública. Isso não impede o crack, mas impede o gerador de chaves falsas.
• Marca d'água por cliente. Embuta um identificador do comprador no build que ele baixa. Quando a cópia vazar, você sabe de onde veio e tem prova concreta para o pedido de remoção.
• Atualizações como valor. Cópia crackeada congela na versão que vazou. Se você lança melhoria todo mês, o pirata fica para trás sozinho.

Vale a pena brigar com a pirataria?

Aqui vai minha opinião, e ela é meio impopular. Para a maioria dos devs independentes, caçar cópia crackeada é um péssimo uso de tempo.

Quem baixa a versão crackeada de um plugin de 30 dólares, em geral, nunca ia pagar 30 dólares. Não é venda perdida, é um usuário que nunca seria cliente. Cada hora gasta preenchendo notificação e respondendo e-mail do suporte do GitHub é uma hora sem melhorar o produto para quem paga.

Mas isso tem limite. Tem diferença entre alguém crackear e usar em casa e alguém publicar a cópia num repositório que aparece no Google antes da sua página de vendas. O segundo caso machuca de verdade. Ele tira tráfego, confunde o usuário e às vezes vem com malware embutido, o que vira problema de reputação para você. Aí faz sentido agir, e agir bem:

1. Monte a notificação completa de primeira, com cada URL e a menção explícita aos forks.
2. Guarde provas: commits originais com data, página de vendas, a marca d'água se tiver.
3. Denuncie também no Google, pelo formulário de remoção de direitos autorais. Às vezes tirar da busca resolve mais rápido do que tirar do GitHub.
4. Se o repositório distribui malware junto, denuncie como abuso. Esse canal costuma andar mais rápido do que o de direito autoral.

O que eu tiro desse caso

O GitHub merece a crítica pela demora. Um mês é muito para um caso que parece óbvio, e a plataforma tem recursos para fazer melhor. Mas confiar que o GitHub vai proteger o seu modelo de negócio é colocar a fechadura na porta do vizinho.

Se você vende algo feito em JavaScript, parta do princípio de que vai ser copiado. Coloque o que vale dinheiro onde o usuário não alcança e faça a versão paga melhorar mais rápido do que qualquer pirata consegue acompanhar. É o que eu tento aplicar nos projetos que eu mantenho: se o código está no navegador, ele já é público.

Um dev passou um mês pedindo ao GitHub para derrubar cópias crackeadas do software dele. Elas continuam no ar.

O DMCA protege a plataforma primeiro. Você vem depois: notificação no formato exato, cada fork listado, e ainda pode vir uma contranotificação.

Quem vende algo em JavaScript precisa encarar uma verdade: se o código roda no navegador, ele já é público. Trocar um if (!valid) leva cinco minutos.

A proteção que funciona é tirar do cliente o que vale dinheiro e deixar isso no servidor. O resto ajuda: licença assinada, marca d'água por comprador e atualização constante.

Escrevi no blog como montar um pedido de remoção que funciona e quando vale a pena brigar com a pirataria. Se você vende software, vale a leitura.

#JavaScript #GitHub #DesenvolvimentoDeSoftware #IndieHacker #Seguranca