github/site-policy: GitHub's own policies released under CC0 for you to fork
Collaborative development on GitHub's site policies, procedures, and guidelines
At a glance
- What is it?
- The Terms of Service, Privacy Statement and a set of conduct and compliance policies that govern github.com, published as Markdown under a public domain dedication, with a review process that explains how each change got in.
- Who is it for?
- This repository is valuable less as legal text than as a worked example of how a large platform publishes and revises its policies in public. If you want a starting point for your own Terms of Service or Acceptable Use Policy, the CC0 dedication means you can take any file in `Policies/` and adapt it without restriction, and the commit history gives you the reasoning behind the wording.
- Can I use it commercially?
- Yes. CC0-1.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 28, 2026, and from our analysis. They are not legal advice.
Editorial analysis
An official repository that is not the official policy
The first line of the README is a warning worth reading before anything else: this is the official repository of GitHub's open sourced policies, and it may not reflect the exact policies live on GitHub, because the documentation site is updated separately from the Help site. That gap is the single most important fact for anyone considering relying on it.
What the repository actually contains is small. The tracked files are:
Policies/
CODE_OF_CONDUCT.md
CONTRIBUTING.md
LICENSE.md
README.mdThe policies live in the `Policies/` directory, which is not enumerated in the tracked file list, so the exact inventory is whatever is inside it. The release history gives a partial picture: the 2018-08-13 release documented four additions, namely the GitHub Anti-Bribery Statement, the GitHub Gifts and Entertainment Policy, the GitHub Event Code of Conduct and the GitHub Event Terms, each with a link to its file and a pointer to the live versions on the Help site.
Earlier releases name the documents you would expect at the centre of the set. The October 2017 release covered the Terms of Service, Corporate Terms of Service, Marketplace Terms of Service, Privacy Statement and Open Source Applications Terms and Conditions. The topics on the repository are `law`, `policy`, `privacy-policy` and `terms-of-service`, which is an accurate summary of the whole thing.
CC0 with an explicit trademark carve-out
The licence is CC0-1.0, and the README is unusually direct about what that means in practice. If any of the policies are useful to you, even in part, you are welcome to use them without restriction. There is no attribution requirement and no share-alike obligation.
What the licence does not do is grant trademark rights, and the README says so in the licence section itself. For a document set that names GitHub throughout, that carve-out is the practical limit on reuse: you can take the structure and the clauses, but you cannot present the result in a way that implies GitHub endorsement, and you would need to strip or replace the trademarks regardless of what CC0 permits.
The README also asks for three things, framed as optional and in the spirit of transparency rather than as licence conditions. Share adapted policies under CC0-1.0 or other open terms, make adaptations transparent by publishing a public repository showing the changes, and let GitHub know how you used them, through a help-wanted link in the contribution guidelines. None of that is binding, and the phrasing is careful to say you are under no legal obligation. It is a request that the project can point at when someone asks whether the openness has been used well.
The review process is the interesting engineering artefact
Policy drafting has a version control problem that most teams solve badly, and this repository solves it explicitly. Policies are open for discussion and feedback throughout the year, and the README commits that someone from GitHub's legal department will see your feedback, while being honest that they might not respond immediately.
The timing rules are the specific part. When GitHub opens a pull request changing a policy, in most cases it stays open for 24 hours before the change takes effect, and comments on the pull requests are welcome in the ordinary open source way. For material changes to the Privacy Statement or the Terms of Service, including the Acceptable Use Policies, GitHub posts the updates 30 days before they take effect.
The README is candid about why the general 30-day period was dropped: feedback tends to arrive soon after changes are posted, so applying 30 days to most documents was unnecessarily delaying ships. That is a piece of process reasoning you would struggle to find in most corporate policy pages, and it is the kind of detail that makes the repository worth reading even if you never fork it.
There is one documented bug in the process. The README notes that links will not resolve in the rendering of the policies in this repository, which is a fair warning for anyone reading the documents there rather than on the Help site. GitHub also reserves the right to alter policies outside the schedule when necessary, for example when a new product ships.
What the repository refuses to do
The README sets out three things it asks you not to post in issues, and together they describe the boundary of the project precisely.
The first is legal complaints and technical support requests, on the grounds that issues are not answered promptly and that Support is the right route for anything needing a real answer. The second is hypotheticals, and the reasoning is the sharpest line in the document: GitHub cannot give legal advice, which means it often cannot say whether a hypothetical situation would violate its policies, and cannot say what you should or should not do. It can tell you how it interprets its policies, and that is the limit. The third is giving other users legal advice, to avoid confusion.
The disclaimer at the end of the README expands the same limit into formal language. The information is for informational purposes only, is not intended as legal advice, is not a solicitation, and use of it does not create an attorney-client relationship with GitHub. GitHub is not a law firm. Then the practical sentence that matters most to an adopter: these policies may not suit your organization's needs, and you should consult a lawyer if you want to adopt them.
The responsibility framing is handled lightly, in the tone of a README rather than a policy: follow the Code of Conduct and help maintain a respectful environment.
The release history as a record of regulatory moments
There are three releases, and they are tagged with dates rather than version numbers, which is itself a signal that this repository versions policy documents rather than software.
The 2018-05-25 release, titled as the policies effective as of that date, is the one that matters most historically. Its note explains the cadence, that about every six months the terms and policies are reviewed to see whether they are as clear as they can be, and that this round focused on aligning them with the General Data Protection Regulation in Europe, with changes to the Privacy Statement and Terms of Service. It also announces GDPR compliance and states the commitment to the same level of privacy protection regardless of residency, location or citizenship, and notes other changes clarifying account control and developer obligations when integrations are created for others.
The 2017-10-11 release is a good example of the incremental work that never appears in a changelog summary. It lists changes to five documents, then specifics: removal of redundant language in the API section, consolidation of termination and limitation of liability language into their respective sections, and added notice about potential opt-in features in the section on private repositories. It closes with the merge date of the associated pull request.
That granularity is the argument for the repository existing. A published policy tells you what the rules are. A repository with commits, pull requests and issues tells you how the rules were argued, which the README explicitly says is the reason for publishing rather than just releasing the text.
Editorial conclusion
This repository is valuable less as legal text than as a worked example of how a large platform publishes and revises its policies in public. If you want a starting point for your own Terms of Service or Acceptable Use Policy, the CC0 dedication means you can take any file in `Policies/` and adapt it without restriction, and the commit history gives you the reasoning behind the wording. Read the disclaimer before you do, because GitHub states plainly that the text may not suit your organization and that GitHub is not a law firm. Fork the repository, drop in your own entity details, and take the change-review process as the part worth copying.
Frequently asked questions
Can I reuse GitHub's policies in my own project?
Yes. The policies are offered under CC0-1.0, which the README describes as allowing use without restriction, even in part. Two caveats come with it: CC0 grants no trademark permissions, and you need to check the content applies to what you are using it for.
Is this repository the same as the policies live on GitHub?
Not always. The README says outright that this is the official repository of open sourced policies but may not reflect the exact policies live on GitHub, because the documentation site is updated separately from the Help site. The README also notes that links will not resolve when the policies are rendered inside the repository.
How does GitHub decide when a policy change takes effect?
Most pull requests are left open for 24 hours before changes take effect, with comments welcome. Material changes to the Privacy Statement or Terms of Service, including the Acceptable Use Policies, are posted 30 days ahead. The README explains that the general 30-day window was dropped because feedback arrives soon after posting and was delaying releases.
Can I ask whether my situation violates GitHub's policies?
Not through this repository. The README asks people not to post legal complaints, technical support requests or hypotheticals, and explains that GitHub cannot give legal advice, including on hypothetical situations. It can describe how it interprets its policies, and it points support questions to GitHub Support instead.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/github-site-policy)