Developer Says Cracked Software Stayed on GitHub for a Month

By Lazar Milicevic · Published October 12, 2026 · 9 min read

A developer posted on Hacker News that he reported copies of his paid software to GitHub on 4 September 2026 and got a reply about a month later. If you sell software as a solo founder, the takeaway isn't "GitHub is slow." It's that nobody is looking for copies of your product except you, and nobody keeps your evidence except you. Here's exactly how I'd build a monitoring and evidence workflow that doesn't require a legal department.

What We Actually Know (and What We Don't)

The source is a Tell HN thread titled "GitHub refuses to remove cracked copies of my software after a month." The author says he reported the copies on 4 September 2026 and heard back roughly a month later. GitHub's reply said it could not confirm a violation of 17 U.S. Code § 1201, the anti-circumvention provision. It did not mention an ordinary copyright claim under § 512.

Several things are not established, and I'm not going to pretend otherwise:

• We haven't seen the original submission, so we can't say which type of notice was filed. Some HN commenters think it was the wrong type. That's opinion, not fact.
• The author says people ask AI models to take the JavaScript from his website, strip the ads, and publish the result on GitHub as a "new product." It's unclear whether every repository is a true cracked copy or an LLM-written re-implementation. Those are legally different situations.
• One HN commenter claims GitHub manually reviews every § 1201 notice, and another says ordinary § 512 notices usually clear in days. Both are anecdotal. I found no official GitHub processing-time figure.
• Whether GitHub is "breaking the law and forfeiting safe harbor" is a commenter's legal opinion. It depends on whether a valid § 512(c)(3) notice was actually submitted.

It's also not an isolated pattern. Another vendor wrote on 24 September 2026 that GitHub had not removed malicious imitation software after three weeks. Two data points isn't a statistic, but it's enough to plan for slow removal.

The practical conclusion: build your process assuming the platform will not do your detective work and may not move fast.

Finding Copies Is Legally Your Problem

The DMCA doesn't require a service provider to monitor its service for infringement. According to a Congressional Research Service report, the safe harbor structure puts the burden of detection on the rightsholder. GitHub is not scanning for your paid tool.

Forks make this worse. GitHub's takedown guide says it does not automatically disable forks when it disables a parent repository. You have to identify each allegedly infringing fork in the notice. So your monitoring has to track forks, not just the first repo you stumble on.

Start with three identifiers you can rely on:

1. Your product name
2. A distinctive filename or package name
3. One unique phrase that only appears in your paid distribution (a comment string, an error message, an internal function name)

Here's a first-pass manual search you can run today using the GitHub CLI:

# Code search for a unique phrase from your paid build
gh search code "your-unique-internal-string" --limit 50

# Repo search by product name
gh search repos "YourProductName" --limit 50 --json fullName,url,updatedAt,isFork

# Look for distinctive filenames
gh search code "filename:yourproduct.min.js" --limit 50

Don't automate yet. Run these by hand for a week and note which queries return real matches versus noise. A search that returns 200 unrelated hits is worse than no search, because you'll stop reading the results. Automate only the queries that earned their place.

When you do automate, keep it boring: a cron job on a small server, one query per line, results written to a file, a diff against yesterday's file, and a notification only when something new appears.

#!/usr/bin/env bash
# monitor.sh - run daily via cron
set -euo pipefail
DIR="$HOME/piracy-watch"
mkdir -p "$DIR"
TODAY="$DIR/$(date +%F).txt"
PREV="$DIR/latest.txt"

{
  gh search code "your-unique-internal-string" --limit 100 --json repository,path \
    --jq '.[] | "\(.repository.nameWithOwner)\t\(.path)"'
  gh search repos "YourProductName" --limit 100 --json fullName \
    --jq '.[].fullName'
} | sort -u > "$TODAY"

if [ -f "$PREV" ]; then
  NEW=$(comm -13 "$PREV" "$TODAY")
  [ -n "$NEW" ] && echo "$NEW" | mail -s "New possible matches" you@example.com
fi
cp "$TODAY" "$PREV"

That's maybe 20 minutes of setup. It won't catch everything, but it turns "I heard about it on Twitter" into a repeatable check.

Build a Case Record Before You Need One

The failure mode I'd worry about most isn't a slow platform. It's discovering a copy, losing the link, and reconstructing your evidence weeks later. The fix is a single case record per incident, created the moment you find a match.

A case file needs:

• Repository URL and the specific files or release that match
• Date and time you found it
• Screenshots of the repo, the file, and the commit history
• A Wayback Machine capture of the page (the Save Page Now feature creates a permanent link for any URL)
• Your ownership documentation and the relevant license or terms
• Report date, reference number if provided, and follow-up status

A simple YAML file per case is enough:

case_id: 2026-10-001
found: 2026-10-12T14:20:00Z
repo_url: github.com
matching_paths:
  - dist/yourproduct.min.js
is_fork: false
forks_checked: pending
archive_url: ""        # paste Save Page Now link
screenshots:
  - evidence/2026-10-001/repo-root.png
  - evidence/2026-10-001/file-view.png
ownership_docs:
  - docs/license-terms-v3.pdf
classification: unreviewed   # unreviewed | authorized | shared-lib | unauthorized-copy | reimplementation
reviewer: ""
reported_on: ""
report_reference: ""
status: open
notes: ""

One caution on the archive step. In my own view, a Wayback capture is not something to build a legal strategy on. Treat the archive link as one more timestamped record that costs you nothing, not as a guarantee. If a dispute gets serious, talk to a lawyer about what evidence they actually want.

The Human Review Gate

A matching repository is not automatically piracy. A shared library, an authorized fork, a reseller with a license, and a cracked release all look similar in a search result and need completely different responses. This is the step I would never automate away.

The reviewer asks three questions:

1. Is this actually my material? Compare the files, not just the name.
2. Is the distribution unauthorized? Check licenses, partners, and customers who may have a right to host it.
3. What exactly am I asking the host to remove? A whole repository, or specific files?

That last question matters for the notice itself. GitHub's guide says a takedown notice must include, at a minimum, the URL of the allegedly infringing material. If less than a whole repository infringes, you need to name the specific files or line numbers. Vague notices are how you end up waiting.

There's a second fork in the road worth understanding before you file. GitHub treats anti-circumvention claims separately from ordinary copyright notices. A § 1201 claim must describe the technical measures in place and how the accused project circumvents them. If your case is "someone copied my code or content," that's a copyright claim. If your case is "someone defeated my license check or paywall," that's an anti-circumvention claim with different requirements. GitHub's reply in the HN thread cited § 1201, which suggests that's the lane the report landed in. I can't tell you whether that was the right call for that developer, and neither can the commenters guessing from the outside.

Also note that GitHub's DMCA process only accepts notices for works protected by copyright. Trademark complaints go through a separate trademark policy.

Where does AI fit? Let it do the tedious parts: flag candidate matches, diff files against your release, and draft the case summary. Don't let it accuse a repository owner or file a complaint on its own. False positives carry real costs, including accusing a paying customer or a legitimate fork.

Filing the Notice Properly

Once a human has signed off, file through the host's actual process. For GitHub, that's the web form, or as an alternative you can email copyright@github.com with a plain-text version of the letter in the email body.

For an ordinary copyright notice, 17 U.S.C. § 512(c)(3)(A) requires six elements, per the statute text:

1. A signature
2. Identification of the copyrighted work
3. Identification and location of the infringing material
4. Your contact details
5. A good-faith-belief statement
6. A statement of accuracy and authority, made under penalty of perjury

That last element is why a human has to sign off. You are attesting under penalty of perjury. Don't let a template generator do that for you.

Three things to know about what happens next:

• Timing on GitHub's side. According to GitHub's DMCA policy, if a notice alleges that an entire repository infringes, GitHub disables it expeditiously. Otherwise it gives the repository owner approximately one business day to change or delete the content. That's the documented policy; actual elapsed time in any given case may differ, as the HN thread shows.
• Notices are public. GitHub publishes complete and actionable notices, with personal information redacted, in the public github/dmca repository. Expect your notice to be visible.
• Counter-notices. After a compliant counter-notice, the provider must restore the material after at least 10 and at most 14 business days, unless you tell them you've filed a court action, per the U.S. Copyright Office. GitHub's own docs say "10-14 days" without the word "business"; the statute governs, so plan on business days.

If the infringer is anonymous and you need to identify them, § 512(h) lets a copyright owner ask a U.S. district court clerk to issue a subpoena to a service provider. The request needs a copy of the notice, a proposed subpoena, and a sworn declaration, per the statute. That's a point where you should be talking to an attorney.

This is not legal advice. I build operational systems; I'm not your lawyer. Use this as a process skeleton, and check the official sources above before filing anything.

Put It Next to Your Uptime Alerts

My position: a takedown form is not a protection strategy. It's one step in an incident workflow. If your product makes money, distribution monitoring belongs beside uptime alerts and failed-payment alerts.

For context on scale, TorrentFreak reports that GitHub processed 2,661 DMCA takedown notices in 2025, affecting 47,228 repositories, and received 645 anti-circumvention claims, up about 41% from 2024. Those are secondary-source figures I haven't checked against GitHub's own transparency text, so treat them as directional. The direction is clear enough: the volume is high, and anti-circumvention claims in particular are getting more attention, which is a reason to get the notice type right the first time.

The minimum viable version of this system:

• A scheduled search for 3 identifiers (daily or weekly, depending on how often you ship)
• A diff-based alert so you only see new matches
• One YAML case file per incident, with archive link and screenshots
• A named person who makes the final call on every report
• A tracker for report date, reference number, and follow-up
• A recurring check on forks of anything you've reported

None of that stops copying. What it does is make sure that when you file, you file once, with complete evidence, against the right targets, and you can see exactly how long you've been waiting.

Where bizflowai.io Fits

This is the approach I'd recommend for a small software business, and it's built from ordinary parts: scheduled checks that surface candidates, structured records that capture evidence at the moment of discovery, a human approval step before anything gets sent externally, and a tracker that keeps follow-ups from silently dying. If you want to see how I think about practical automation for solopreneurs and small teams, start at bizflowai.io.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.