legalmattic: WordPress.com legal documents you are allowed to copy

Legal text published on purpose, since 2014

The repository holds the source of several legal documents on WordPress.com, including the Terms of Service, and the stated ambition is that these documents should embody the vision of the spirit of the web, open and accessible. The subtitle says when that began, publishing WordPress.com legalese since 2014, which places the project well before the current wave of companies publishing their legal pages as public repositories. There is no code here, and the repository records no primary programming language, because the artifact is prose rather than a program. That makes it an unusual kind of open source project: the contribution is a shared vocabulary, the legal phrasing that a service has to write anyway, and the argument that publishing it is better than keeping it behind a link. The project sits under the Automattic organisation, which is also the organisation behind WordPress.com, so the documents are the ones in force for a service people actually use.

What is in the tree, document by document

The top level shows the shape of the set. There is a Terms of Service directory, a DMCA directory and an Offer Letters directory, each of them a folder rather than a single file, which suggests a set of related documents apiece. Alongside them sit four standalone markdown files: Cookie-Policy.md, Legal-Guidelines.md, Privacy-Policy.md, and Privacy-Notice-for-Visitors-to-Our-Users-Sites.md, the last of which is the notice given to people who visit sites belonging to WordPress.com users. LICENSE.txt carries the licence terms, and the .github directory holds the GitHub configuration for the repository. The set is coherent rather than exhaustive, and the split between folders and single files tells you something about how the documents are grouped, with the DMCA and offer letter text treated as a family in each case. The Privacy-Notice-for-Visitors-to-Our-Users-Sites file is the most interesting of the standalone documents, because it covers a party that has no direct relationship with the service, which is a situation many other operators also need to solve.

Reuse is allowed, attribution is requested

The licence is the point of the exercise. The content is licensed under the Creative Commons Attribution-ShareAlike 4.0 International licence, and the project says you are welcome to reuse and adapt the documents for your own projects under that licence, and that you can feel free to re-use and edit the terms to fit your own use. The one condition the project asks for beyond the licence is a link back, so that the source of the licence can be shared and the project can spread further. The share alike half of the licence is the part to watch, because it means an adapted document has to be published under the same terms, which is a condition on redistribution rather than a restriction on use. The other thing the README does is set expectations about the direction of travel, since the aim is that these documents stay open, which is why they are published in a repository at all rather than behind a page that changes without notice.

No pull requests, and where to send problems instead

The contribution policy is closed and the project says so plainly. This repository does not accept external contributions, and if you have spotted a typo or have a concern, you are asked to contact Automattic support. That is a deliberate design choice for a document set that carries legal weight, since accepting outside edits to the text of a Terms of Service would create questions about who stands behind the wording. The practical consequence for a user is that the fork and edit workflow is one way only. You can take the documents, adapt them for your own service, and publish your version, but you cannot hand a correction back and have it merged, and the upstream text will not reflect your changes. The support route is the only feedback channel, which makes the transparency links in the README more important than they would otherwise be, since the Transparency Report and the blog post on why the DMCA documentation was open sourced are where Automattic explains its reasoning.

WordPress.com terms are not a template for your product

The limitation here is not technical but it is the one that matters, and it is easy to gloss over because the licence is so permissive. These documents describe WordPress.com, a specific service operated by a specific company, with the parties, the jurisdiction, the data processing and the product scope that come with it. The licence grants you the right to copy and adapt the text, and it says nothing about whether the text is correct for your business. A different service has different actors, different account structures, different data flows and different obligations, and rewriting those into place is legal work rather than engineering work. Two further gaps deserve naming. The repository publishes no GitHub releases and no changelog, so if a document changes upstream you have to dig through commit history to see what moved. And the documents were written for a general audience, which is a virtue for readability and a limitation for specificity, since a Terms of Service that avoids awkward detail is also a Terms of Service that may not describe your obligations accurately.

The wider legal open source work

The README points at two things beyond the document set itself. The first is a sibling repository, the EU Cookie Law Widget, described as a WordPress plugin that provides a widget to help with EU Cookie Law compliance, which is the same idea applied to a specific piece of interface rather than to a page of text. The second is a pair of links that document Automattic's posture rather than the code, the Automattic Transparency Report and a blog post explaining why the DMCA documentation was open sourced. Taken together, the picture is of a company treating legal and policy text as something meant to be published in the same way it treats its software. On the licence metadata, there is a mismatch to be aware of, since the repository records the licence as a custom one that GitHub cannot classify, while the README states Creative Commons Attribution-ShareAlike 4.0 International, so the LICENSE.txt file is the authoritative text. The last push was on 2026-10-06 and the repository is not archived, so the documents are still being worked on even though no releases are published.

Editorial conclusion

legalmattic fits a team that needs a starting point for the legal pages of a hosted service and wants a document set that is openly licensed, readable and already written in plain language, with the terms of service, cookie policy, privacy policy, DMCA policy and offer letters available as a set. It is the wrong choice if you need a document set for a different business model or jurisdiction, since the text is tied to WordPress.com as a service, and it is a poor fit if your workflow depends on upstream changes, because the repository does not take external contributions. Before you reuse anything, read LICENSE.txt and keep the attribution link the project asks for, and treat every document as a starting point to be checked by whoever handles your legal work rather than as a finished template.

Frequently asked questions

Official sources

1. Automattic/legalmattic on GitHub
2. Issues
3. README