Cracked software on GitHub: why DMCA takedowns stall

An indie developer spent a month asking GitHub to take down cracked copies of their software. They're still there. The story showed up on Hacker News and turned into the kind of thread everyone who sells software reads with a knot in their stomach. Cracked software on GitHub is nothing new. What's new is realizing the "official" path to fix it can take longer than your launch.

I don't know the behind-the-scenes details of this case. I don't know what the notice said or how GitHub replied at each step. But I know the process well, and it explains a lot about why this happens. It also explains what you can do before you get to that point, if you write JavaScript and maybe sell something.

What happened with the cracked software on GitHub

The short version is simple. Someone took a paid piece of software, stripped out the license check and published the result in public repositories. The author sent a takedown request. A month later, the copies were still available.

The thread shows two kinds of reactions. Some comments go after GitHub: "Microsoft has money to hire people, why a month?". Others go after the process: "the notice has to be in exactly the right format, or it goes back to the end of the line".

Both have a point. And that's where things get interesting.

How a DMCA takedown works on GitHub

GitHub follows the DMCA, the US copyright law. Anyone who hosts content gets legal protection if they remove infringing material after receiving a valid notice. The key word is "valid".

Broadly speaking, a notice needs:

• identification of the protected work (your software, with a link to where it's sold or distributed)
• the exact URL of each infringing file or repository
• your contact details
• a good-faith statement and another saying the information is accurate, under penalty of perjury
• a signature

It looks like silly paperwork, but every item has a reason. Without them, anyone could take down anyone's repository with a single email. That has happened many times, including to legitimate projects.

GitHub also publishes every notice in a public repository, github/dmca. It's worth a look. You'll see thousands of requests, many from big companies, many poorly written.

There's a detail that trips up a lot of people: forks. If the cracked repository was forked 200 times, the notice has to make clear that the entire fork network is infringing, or list each fork. Otherwise GitHub removes the original and the 200 forks stay up. You send the request, celebrate, and then find out the problem just moved to a new address.

Then there's the counter-notice. Whoever published the copy can dispute it. In that case, the material goes back up in 10 to 14 business days unless you file a lawsuit. For a solo dev, suing an anonymous person in another country is a bad joke.

The DMCA protects the platform first. You come second.

Why this matters if you write JavaScript

JavaScript is the focus here for a very practical reason. JS is the easiest language to crack. You hand the source code to the user. Minified, maybe obfuscated, but you hand it over.

Browser extensions, Electron apps, editor plugins, paid UI components, dashboard templates. All of it runs on the buyer's machine, and anyone with DevTools open can read it.

Here's the pattern I see most in small products:

// license check 100% on the client
const res = await fetch('https://api.myapp.com/license/' + key)
const { valid } = await res.json()

if (!valid) {
  showPaywall()
  return
}

unlockProFeatures()

Cracking this doesn't take a hacker. Just change if (!valid) to if (false) and you're done. Or intercept the response and return { "valid": true }. It takes about five minutes, and four of them go to finding the right file in the bundle.

Obfuscation slows people down, but it doesn't stop them. Deobfuscation tools recover most of the structure, and people who crack software do it as a hobby. You're betting your work hours against the free time of someone who enjoys this. Spoiler: you lose.

What changes in your code: move the value to the server

The only protection that really works is not shipping the thing that makes money to the client. If the pro feature runs in the browser, it can be copied. If it depends on something only your server does, the cracked copy ends up crippled.

In practice, this means switching from "the client asks if it can" to "the server only answers if it can":

// Bun + Hono, for example
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' })
})

There's no if in the front end to remove here. The PDF is generated on the server. Whoever cracks the front end gets a nice-looking button that returns 402.

Not every product allows this. A dashboard template is just code with no server at all. An offline app has to work without a network. In those cases, a few things help limit the damage:

• A signed license, not "valid or not". The server signs a token (JWT with a private key, Ed25519) containing email, plan and expiration. The app checks the signature with the public key. This doesn't stop the crack, but it does stop fake key generators.
• Per-customer watermarks. Embed a buyer identifier in the build they download. When the copy leaks, you know where it came from and you have concrete proof for the takedown request.
• Updates as value. A cracked copy is frozen at the version that leaked. If you ship improvements every month, the pirate falls behind on their own.

Is it worth fighting piracy?

Here's my opinion, and it's a bit unpopular. For most indie devs, hunting down cracked copies is a terrible use of time.

Someone who downloads the cracked version of a 30-dollar plugin usually was never going to pay 30 dollars. It's not a lost sale. It's a user who would never have been a customer. Every hour spent filling out notices and answering emails from GitHub support is an hour not spent improving the product for people who pay.

But there's a limit. Someone cracking it and using it at home is different from someone publishing the copy in a repository that shows up on Google before your sales page. The second case really hurts. It takes traffic, confuses users and sometimes comes bundled with malware, which turns into a reputation problem for you. That's when it makes sense to act, and to act well:

1. Put together a complete notice on the first try, with every URL and an explicit mention of the forks.
2. Keep evidence: original commits with dates, your sales page, the watermark if you have one.
3. Report it to Google too, through the copyright removal form. Sometimes getting it out of search works faster than getting it off GitHub.
4. If the repository also distributes malware, report it as abuse. That channel usually moves faster than the copyright one.

What I take from this case

GitHub deserves the criticism for the delay. A month is a lot for a case that looks obvious, and the platform has the resources to do better. But trusting GitHub to protect your business model is like putting the lock on your neighbor's door.

If you sell something built in JavaScript, assume it will be copied. Put what makes money where users can't reach it, and make the paid version improve faster than any pirate can keep up with. That's what I try to apply in the projects I maintain: if the code is in the browser, it's already public.

A dev spent a month asking GitHub to take down cracked copies of their software. They're still up.

The DMCA protects the platform first. You come second: a notice in the exact format, every fork listed, and there might still be a counter-notice.

If you sell anything built in JavaScript, face this truth: if the code runs in the browser, it's already public. Swapping an if (!valid) takes five minutes.

The protection that works is moving whatever makes money off the client and keeping it on the server. The rest helps: signed licenses, per-buyer watermarks and constant updates.

I wrote on the blog about how to put together a takedown request that works, and when it's worth fighting piracy. If you sell software, give it a read.

#JavaScript #GitHub #SoftwareDevelopment #IndieHacker #Security