Developer Says Cracked Software Stayed on GitHub for a Month
Finding Pirated Copies of Your Software Is Your Job, Not GitHub's
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.
How to disable Copilot code review in GitHub?
Copilot reviews a pull request only when someone asks, unless automatic review is switched on, so the first step is to find out which switch asked. GitHub documents four sources: your own "Automatic Copilot code review" setting, a repository ruleset, an organization or enterprise ruleset with the rule "Automatically request Copilot code review", and a person or a bot requesting Copilot as a reviewer. Turn off the one that applies. The automatic ones are independent: "These configurations are not hierarchical; neither inherits from or overrides the other." To stop people who bring their own Copilot license from requesting reviews in your repository, a repository admin or organization owner enables "Only allow Copilot code review to be triggered by authorized users". An organization owner can turn off the Copilot code review option for members who get Copilot from the organization, and an enterprise can block it in all its repositories.
Every step below is from GitHub's own documentation as I read it on 9 October 2026, and GitHub did not see this text before publication.
Where the review comes from and who can turn it off
| Where the review comes from | Who can turn it off | Where | What it does not stop |
| --- | --- | --- | --- |
| Your own automatic setting | you | profile picture > Copilot settings > Code review: turn off "Automatic Copilot code review" | rulesets and other people's requests |
| A repository ruleset | repository admins, or a custom role with "edit repository rules" | Settings > Rulesets: clear "Automatically request Copilot code review", set the ruleset to Disabled, or delete it | the author's own setting |
| An organization ruleset | organization owners and users with "Manage organization ref update rules and rulesets" | organization Settings > Repository > Rulesets | the same |
| An enterprise ruleset | enterprise owners | the enterprise-level branch ruleset | the same |
| A Copilot license from outside your organization or enterprise | repository admins, or organization owners for all repositories | Settings > Copilot > Code review: enable "Only allow Copilot code review to be triggered by authorized users" | ruleset reviews |
| Copilot from your organization | organization owners | organization Settings > Copilot > Policies: the Copilot code review option | an enterprise policy; a second organization that enables it |
| Members without a license | enterprise administrators or organization owners | keep "Allow members without a Copilot license to use Copilot code review in GitHub.com" disabled, its default | members with a license |
| Every user in an enterprise's repositories | enterprise owners and AI managers | AI controls > Agents > Copilot code review: "Block Copilot code review in all enterprise repositories" | nothing named; it covers personal plans too |
| One pull request | anyone who can request reviews | the Reviewers sidebar, or gh pr edit | not said for a review already running or posted |
How to tell which switch asked
If no setting of yours asked, look at the author: their own automatic review covers their pull requests "in any repository where Copilot code review is available to you". An author on Copilot Free has no such setting, because the Free plan "does not include Copilot code review".
Then the rulesets. Anyone with read access can view the active ones, and the shortcut is "adding the /rules slug to the repository's URL". Or, from a terminal:
gh ruleset check main
Last, the requester. GitHub's general rule for review requests is that "you need write access to the repository", and that page does not say whether it covers Copilot. Requests also come through the REST API as "copilot-pull-request-reviewer[bot]", and through GraphQL since 2 October 2026, so a workflow or a bot can ask. By default, AI credits go to the pull request author when a repository requests the review automatically and to the requester for a manual one; the organization pays "when a bot requests the review", and the organization or enterprise pays for people without a Copilot license or on Copilot Free. For members with a paid Copilot license, an enterprise or organization owner "can instead choose to bill the organization".
What each switch leaves running
Your own setting exists on the Copilot Pro, Copilot Pro+ and Copilot Max plans and with a Copilot Business or Copilot Enterprise license, not for managed user accounts. Turning it off does not touch rulesets: "Your user settings cannot disable push or draft reviews that a ruleset has enabled." Your review effort stays as set. A repository's automatic review lives in its ruleset, under "Branch rules", not in Settings > Copilot > Code review.
A license is external when it is "not provided by the organization or enterprise that owns the repository", and by default people can use one to request a review. With the authorized-users setting on, "Copilot is not offered as a reviewer to people who are not authorized, and API review requests from those people do not start a review." In a personal repository only the owner or a direct collaborator can then request one. Automatic reviews from personal settings of people who are not authorized stop. "Automatic reviews configured by repository or organization rulesets still run." Set at the organization, it cannot be turned off per repository. GitHub documented it on 7 October 2026.
The organization option governs reviews "on GitHub.com or in GitHub Mobile" for members who get Copilot from that organization: "Generally, policies only apply to users on your Copilot plan." An enterprise choice wins: "you cannot override that setting at the organization level." For a person with Copilot from several organizations in one enterprise the policy is "Least restrictive": "if any of the organizations has enabled a feature, this feature is enabled for the user everywhere."
The enterprise block reaches further, "including for users who get access to Copilot from a personal plan or another enterprise." Turning the enterprise's Copilot code review policy off instead covers its licensed users and also removes pull request summaries: the policy "allows your licensed users to request reviews from Copilot and use Copilot to generate pull request summaries."
For one pull request:
gh pr edit 123 --remove-reviewer "@copilot"
The @copilot value is "not supported on GitHub Enterprise Server", where Copilot is not available. The pages I read do not say what removing the request does to a review already running or posted, and a review "usually takes less than 30 seconds". Resolving a Copilot comment does not keep it away: "Copilot may repeat the same comments again, even if they have been dismissed".
Before 22 October 2026, for enterprises
GitHub's default availability page says the "Default policy for new features" policy "will start applying to new and existing GA features from October 22, 2026." The covered features include the Copilot code review policy on the Agents page. The default policy itself starts enabled, and "unconfigured features will be enabled on October 22". It covers enterprises with Copilot Business or Copilot Enterprise, and organizations that were left to decide and have not configured the feature. To keep Copilot code review off, set its policy explicitly before 22 October 2026 or disable the default policy. The date will change availability, not automatic review, which will still need a ruleset or a person's own setting.
If you want review only on request
| Tool | By default | Request-only switch | How to ask |
| --- | --- | --- | --- |
| GitHub Copilot | "By default, Copilot only reviews a pull request if you assign it to the pull request." | leave automatic review off everywhere | Reviewers sidebar, or gh pr edit 123 --add-reviewer "@copilot" |
| CodeRabbit | "CodeRabbit reviews every eligible PR automatically" | enabled: false under reviews.auto_review | @coderabbitai review (incremental) or @coderabbitai full review, "Regardless of any auto-review configuration" |
| Cursor Bugbot | "Runs automatic reviews on every PR update" | personal setting "only when mentioned"; per repository, manualTriggerOnly in the Bugbot Admin API | cursor review or bugbot run |
| Greptile | config default "autoReview": ["open"], which starts a review "unasked" when a pull request is opened | "autoReview": [] | @greptileai |
| Qodo | "Automatic is the default." | Code review trigger set to Manual only | /agentic_review |
| Sigma (Mnemoverse, the author's company) | closed beta on GitHub for invited accounts; documented modes Automatic, On request and Off, invited accounts start with On request | On request: "Explicit requests only. A push alone does not start this reviewer."; Off: "No new review or recheck work." | /sigma review; documented: invited accounts need GitHub-confirmed admin, maintain or write access |
Sources, read on 9 October 2026. GitHub Docs: Configuring code review by GitHub Copilot, About GitHub Copilot code review, Using GitHub Copilot code review, organization policies, policy conflicts, enterprise and organization policies, enterprise code review policy, blocking agentic features, default availability, repository rulesets, organization rulesets, enterprise rulesets, requesting a review, plans. GitHub CLI manual: gh pr edit, gh ruleset check. GitHub changelog, 2 October 2026. The docs change of 7 October 2026. CodeRabbit automatic review controls, Cursor Bugbot docs, Greptile trigger configuration, Greptile config reference, Qodo, trigger a code review. Sigma: its public home page and documentation.
2 reactions · 1 comment
Mentions
なるほどわからん github.com/github/docs/blob/main/content/copilot/…
Developer Says Cracked Software Stayed on GitHub for a Month Finding Pirated Copies of Your Software Is Your Job, Not GitHub's 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.
How to disable Copilot code review in GitHub? Copilot reviews a pull request only when someone asks, unless automatic review is switched on, so the first step is to find out which switch asked. GitHub documents four sources: your own "Automatic Copilot code review" setting, a repository ruleset, an organization or enterprise ruleset with the rule "Automatically request Copilot code review", and a person or a bot requesting Copilot as a reviewer. Turn off the one that applies. The automatic ones are independent: "These configurations are not hierarchical; neither inherits from or overrides the other." To stop people who bring their own Copilot license from requesting reviews in your repository, a repository admin or organization owner enables "Only allow Copilot code review to be triggered by authorized users". An organization owner can turn off the Copilot code review option for members who get Copilot from the organization, and an enterprise can block it in all its repositories. Every step below is from GitHub's own documentation as I read it on 9 October 2026, and GitHub did not see this text before publication. Where the review comes from and who can turn it off | Where the review comes from | Who can turn it off | Where | What it does not stop | | --- | --- | --- | --- | | Your own automatic setting | you | profile picture > Copilot settings > Code review: turn off "Automatic Copilot code review" | rulesets and other people's requests | | A repository ruleset | repository admins, or a custom role with "edit repository rules" | Settings > Rulesets: clear "Automatically request Copilot code review", set the ruleset to Disabled, or delete it | the author's own setting | | An organization ruleset | organization owners and users with "Manage organization ref update rules and rulesets" | organization Settings > Repository > Rulesets | the same | | An enterprise ruleset | enterprise owners | the enterprise-level branch ruleset | the same | | A Copilot license from outside your organization or enterprise | repository admins, or organization owners for all repositories | Settings > Copilot > Code review: enable "Only allow Copilot code review to be triggered by authorized users" | ruleset reviews | | Copilot from your organization | organization owners | organization Settings > Copilot > Policies: the Copilot code review option | an enterprise policy; a second organization that enables it | | Members without a license | enterprise administrators or organization owners | keep "Allow members without a Copilot license to use Copilot code review in GitHub.com" disabled, its default | members with a license | | Every user in an enterprise's repositories | enterprise owners and AI managers | AI controls > Agents > Copilot code review: "Block Copilot code review in all enterprise repositories" | nothing named; it covers personal plans too | | One pull request | anyone who can request reviews | the Reviewers sidebar, or gh pr edit | not said for a review already running or posted | How to tell which switch asked If no setting of yours asked, look at the author: their own automatic review covers their pull requests "in any repository where Copilot code review is available to you". An author on Copilot Free has no such setting, because the Free plan "does not include Copilot code review". Then the rulesets. Anyone with read access can view the active ones, and the shortcut is "adding the /rules slug to the repository's URL". Or, from a terminal: gh ruleset check main Last, the requester. GitHub's general rule for review requests is that "you need write access to the repository", and that page does not say whether it covers Copilot. Requests also come through the REST API as "copilot-pull-request-reviewer[bot]", and through GraphQL since 2 October 2026, so a workflow or a bot can ask. By default, AI credits go to the pull request author when a repository requests the review automatically and to the requester for a manual one; the organization pays "when a bot requests the review", and the organization or enterprise pays for people without a Copilot license or on Copilot Free. For members with a paid Copilot license, an enterprise or organization owner "can instead choose to bill the organization". What each switch leaves running Your own setting exists on the Copilot Pro, Copilot Pro+ and Copilot Max plans and with a Copilot Business or Copilot Enterprise license, not for managed user accounts. Turning it off does not touch rulesets: "Your user settings cannot disable push or draft reviews that a ruleset has enabled." Your review effort stays as set. A repository's automatic review lives in its ruleset, under "Branch rules", not in Settings > Copilot > Code review. A license is external when it is "not provided by the organization or enterprise that owns the repository", and by default people can use one to request a review. With the authorized-users setting on, "Copilot is not offered as a reviewer to people who are not authorized, and API review requests from those people do not start a review." In a personal repository only the owner or a direct collaborator can then request one. Automatic reviews from personal settings of people who are not authorized stop. "Automatic reviews configured by repository or organization rulesets still run." Set at the organization, it cannot be turned off per repository. GitHub documented it on 7 October 2026. The organization option governs reviews "on GitHub.com or in GitHub Mobile" for members who get Copilot from that organization: "Generally, policies only apply to users on your Copilot plan." An enterprise choice wins: "you cannot override that setting at the organization level." For a person with Copilot from several organizations in one enterprise the policy is "Least restrictive": "if any of the organizations has enabled a feature, this feature is enabled for the user everywhere." The enterprise block reaches further, "including for users who get access to Copilot from a personal plan or another enterprise." Turning the enterprise's Copilot code review policy off instead covers its licensed users and also removes pull request summaries: the policy "allows your licensed users to request reviews from Copilot and use Copilot to generate pull request summaries." For one pull request: gh pr edit 123 --remove-reviewer "@copilot" The @copilot value is "not supported on GitHub Enterprise Server", where Copilot is not available. The pages I read do not say what removing the request does to a review already running or posted, and a review "usually takes less than 30 seconds". Resolving a Copilot comment does not keep it away: "Copilot may repeat the same comments again, even if they have been dismissed". Before 22 October 2026, for enterprises GitHub's default availability page says the "Default policy for new features" policy "will start applying to new and existing GA features from October 22, 2026." The covered features include the Copilot code review policy on the Agents page. The default policy itself starts enabled, and "unconfigured features will be enabled on October 22". It covers enterprises with Copilot Business or Copilot Enterprise, and organizations that were left to decide and have not configured the feature. To keep Copilot code review off, set its policy explicitly before 22 October 2026 or disable the default policy. The date will change availability, not automatic review, which will still need a ruleset or a person's own setting. If you want review only on request | Tool | By default | Request-only switch | How to ask | | --- | --- | --- | --- | | GitHub Copilot | "By default, Copilot only reviews a pull request if you assign it to the pull request." | leave automatic review off everywhere | Reviewers sidebar, or gh pr edit 123 --add-reviewer "@copilot" | | CodeRabbit | "CodeRabbit reviews every eligible PR automatically" | enabled: false under reviews.auto_review | @coderabbitai review (incremental) or @coderabbitai full review, "Regardless of any auto-review configuration" | | Cursor Bugbot | "Runs automatic reviews on every PR update" | personal setting "only when mentioned"; per repository, manualTriggerOnly in the Bugbot Admin API | cursor review or bugbot run | | Greptile | config default "autoReview": ["open"], which starts a review "unasked" when a pull request is opened | "autoReview": [] | @greptileai | | Qodo | "Automatic is the default." | Code review trigger set to Manual only | /agentic_review | | Sigma (Mnemoverse, the author's company) | closed beta on GitHub for invited accounts; documented modes Automatic, On request and Off, invited accounts start with On request | On request: "Explicit requests only. A push alone does not start this reviewer."; Off: "No new review or recheck work." | /sigma review; documented: invited accounts need GitHub-confirmed admin, maintain or write access | Sources, read on 9 October 2026. GitHub Docs: Configuring code review by GitHub Copilot, About GitHub Copilot code review, Using GitHub Copilot code review, organization policies, policy conflicts, enterprise and organization policies, enterprise code review policy, blocking agentic features, default availability, repository rulesets, organization rulesets, enterprise rulesets, requesting a review, plans. GitHub CLI manual: gh pr edit, gh ruleset check. GitHub changelog, 2 October 2026. The docs change of 7 October 2026. CodeRabbit automatic review controls, Cursor Bugbot docs, Greptile trigger configuration, Greptile config reference, Qodo, trigger a code review. Sigma: its public home page and documentation.