Abuse and removal policy

The rules are part of the claim conditions; violations can lead to removal. A subdomain must:

• serve content about the claimed open source project — no unrelated content;
• avoid automatic redirects away from the subdomain (redirects must require user interaction);
• not host NSFW/adult content, phishing, malware or illegal content;
• not infringe trademarks or impersonate another project or person;
• keep the record pointed at an approved hosting provider;
• keep the project open source, with a public repository and a LICENSE.

Open an issue in the register repository with the subdomain, what you observed, and any evidence (URLs, screenshots). For sensitive reports — phishing, malware or personal data — keep the public issue short and ask a maintainer to move the details to a private channel.

Content hosted by a provider can also be reported to that provider: GitHub, GitLab, Cloudflare, Vercel and Netlify all have their own abuse processes for hosted content.

• Triage — a maintainer reviews the report, normally within a few days.
• Verification — we check the live content, the claim entry and the project repository, and give the project owner a chance to respond where practical.
• Action — confirmed violations lead to the DNS record being removed (sync-dns --prune), so the subdomain stops resolving. Severe cases (phishing, malware, illegal content) are removed first and explained after.
• Reserved status — names removed for serious abuse may be added to reserved.json so they cannot be claimed again.
• Appeal — reply on the issue; if the problem is fixed, the record can be restored.

• The project is no longer open source (private repository, missing LICENSE, archived).
• The subdomain is abandoned: the target host no longer serves the project.
• The content violates the rules above.
• The claim itself was invalid (false ownership, missing badge after review).

Removals are always limited to records tagged openrepos-register; no other DNS records are touched. Working subdomains of active projects are never recycled or handed to someone else.

Reserved names keep the service and its users safe. The list lives in reserved.json and covers:

• Infrastructure — names the service uses or may need: www, api, status, mail, cdn, DNS and email labels.
• Service and brand — register, docs, openrepos, sourcepage, repos.
• Trust and safety — abuse, security, admin, login, payment and account labels.
• High-risk generic names — labels that invite impersonation or collisions with common services.

Reserved names are not granted by default. If your open source project genuinely needs one, open an issue explaining the use; releases are reviewed case by case and can be revoked if misused.

See the Terms of Service for the claim conditions and the guides for provider setup. To report something, use the register repository.