The MIT license page your project links is a JSON file somebody else can edit

A subdomain is a filename, and the filename is the whole page

The mechanism is short enough to state in one line: the host you want becomes a filename, and that file is the page. The walkthrough describes a `users` directory holding one file per host on mit-license.org, and instructs you to name a new file after the CNAME you want, `rem.json` in the author's own case. The mapping is stated plainly at the top: the link `rem` is the CNAME and `Remy Sharp` is the copyright holder name, and both live in that directory.

So there is no per-project page stored anywhere. A request for `rem.mit-license.org` is answered by reading `users/rem.json` and rendering the MIT text around whatever that file contains. Change the file and every project linking that host gets the new details.

The minimum a file needs is one property, `copyright`. Everything else is decoration on top of the same MIT text, and the visible walkthrough works through each one with an example file. A file whose name is not taken yet does not need to exist in advance, because a request with a free name creates it and the URL is available immediately, which is the self-service path the author recommends as the simplest one:

curl -d'{ "copyright": "Remy Sharp" }' https://rem.mit-license.org

Creating a page needs no account, no key and no confirmation

That last line is the whole signup. There is no registration step, no API key and no confirmation in the text; the stated condition for success is only that the name is free, and the stated failure path is a pull request to the author, who says it will go live soon after. The server is an Express application whose dependencies include `cors`, so a request is expected to arrive from another site's page, and the package is marked private, which means the deployment is a hosted service rather than something you install.

Read together, those facts describe an open write path onto a domain the operator controls. Anyone who can send a POST can leave a JSON file named after a host they choose and have it rendered under mit-license.org, with a copyright holder string of their choosing and a `url` and `email` of their choosing displayed in the notice. Whether a given host resolves is a DNS question, and the text does not describe how a new host gets pointed at the service.

That is not a flaw in the sense of a bug. It is the intended convenience of a service whose whole point is a one line link, and it is also the reason to think twice before treating the resulting page as an authoritative record of who holds copyright in a given project.

The year on the page is always the current year, so it records nothing

MIT text carries a year in its copyright line, and this service does not let you set one. The walkthrough states it as a side note after showing a minimal file: the date will always show the current year.

There is no field for it either. The seven properties listed as available are `copyright`, `url`, `email`, `format`, `gravatar`, `theme` and `license`, and each of the worked examples sets only the property it is explaining. A year cannot be pinned through any of them.

The consequence is that a project created in 2019 and a project created this year render the same line, today, differing only in the copyright holder text. Link that page from a repository and the year in your license notice drifts forward every January without any change on your side, so the page cannot answer the one question a license line is usually asked to answer, which is when the code was licensed. It also means two snapshots of the same link taken years apart differ, and nothing in the rendered page explains why.

Every later correction goes through one maintainer's merge queue

Creation is automated, and then it stops. The text is explicit that if you need to add details you did not include in the original request, you will need to send a pull request on that `user.json` file via GitHub, and the fork route is described the same way: send the pull request and wait for the author to pull, which the author says will happen as quickly as possible.

So the write path is split in two. The first write is anonymous and instant, and every write after it is a human merge decided by one person. A typo in an email address, a holder name spelled wrongly, or a project that has been renamed all need that merge, and nothing in the text gives a service level or a queue to look at.

That matters more than it looks, because the page is usually the only place the notice lives. Projects that link it do not keep a copy of the rendered text, so when the file is wrong the wrongness is what every reader sees, and the fix is a pull request against a repository whose last push is dated 2026-07-06 and which publishes no versioned releases at all.

Four ways to post the same JSON, one of which puts the email in the request line

The API section offers four `curl` forms for the same record. The first posts a JSON string with curl's default content type. The second adds a full record with `url`, `email` and `format`, still posted as a string that the server parses later. The third repeats that exact body with an explicit `Content-Type: application/json` header:

curl -H 'Content-Type: application/json' -d'{ "copyright": "Remy Sharp", "url": "https://remysharp.com", "email": "[email protected]", "format": "txt" }' https://rem.mit-license.org

The fourth moves the same four values out of the body and into the query string, which is the part of a request that web servers, proxies and caches record by default:

curl -X POST "https://rem.mit-license.org/?copyright=Remy%20Sharp&url=http%3A%2F%2Fremysharp.com&email=me%40mysite.com&format=txt"

Two details in those values are easy to miss. The `format` property is what switches the output between rendered HTML and plain text, and only `txt` and `html` are supported. And the URL in the fourth form is percent encoded in full while the copyright name is left with plain spaces, so the two representations of the same record differ in more than encoding.

One advertised field has no example next to it

The field list promises seven properties. Six of them are worked through in the text that follows, each with a small JSON file and a note on what it changes: `copyright` accepts a string, an array of holders that renders as names joined by and, or an array of objects carrying a per holder URL and email; `url` turns the copyright text into a link; `email` appends a mail link with `mailto:` added for you; `format` chooses text over HTML; `gravatar` shows a picture; `theme` selects a stylesheet.

The seventh is `license`, and none of the examples next to it sets that property or explains what it changes. The top-level tree does hold a `licenses/` directory alongside `themes/`, so the field has something in the project it plausibly refers to, but the text never states the relationship, never gives an accepted value, and never says what a page falls back to when the field is absent.

Two other loose ends sit in the same list. The `gravatar` option is stated to require the `email` property and to need a compatibility check against the chosen theme, without saying which themes are compatible, and the warning is attached to the theme discussion rather than to the field. And the theme list itself is the longest part of the walkthrough, naming at least fourteen styles with preview links, where every preview except the default one points at an external code playground rather than at a page on the service.

Two hosting models in the root and no record of what is deployed

The top-level entries describe a service with more than one deployment shape and no visible record of which one runs. A `Procfile` sits next to an `.htaccess`, which is the pairing of a platform that reads a process declaration with the configuration file of a conventional Apache host, and there is no text explaining either, or saying whether both are live. Alongside them sit `server.js`, a `routes/` directory, a `lib/` directory, `utils/`, `assets/`, `robots.txt`, `favicon.ico` and a top-level `test.js`.

The package is marked private and carries a fixed version of 2.0.0, and the repository publishes no releases, so the version number in the manifest is not a record of what is running on the domain. Its scripts show four entry points, `node .` for start, `nodemon .` for development, `node server.js` for serving, and a test command that runs the linter before the tests, which means a lint failure stops the test run before a single test executes. The engine requirement is pinned to a single major line of Node, 24.x.

Stylistically the code is configured for two spaces and no semicolons, and the linter is held at the 1.x line while the application dependencies sit in their current majors, which is the clearest signal in the manifest about which parts of this project still move.

The manifest, the file name and the license field do not agree with each other

Three small disagreements sit in the metadata. The package is named `mit-licence`, with a c, while the repository, the domain and every link in the walkthrough use `mit-license` with an s, so a search by package name and a search by project name land in different places. The repository's own license field is unresolved, recorded as NOASSERTION, while the manifest declares `"license": "MIT"` and a `LICENSE` file is present at the root of the tree.

The two sources of licensing truth therefore do not match, and the sensible reading is that the manifest declaration and the root file are the intended ones and the unresolved field is a detection failure rather than a statement about terms. It is still worth naming, because a page whose entire purpose is publishing a license notice is the last place where the licensing metadata should be ambiguous.

The author entry adds a third data point of the same kind: the manifest gives an address at `leftlogic.com`, while the examples in the walkthrough use addresses at `remysharp.com`. The repository reference in the manifest is written in SSH form rather than the HTTPS form used everywhere else, which is a harmless difference that still means the manifest was not generated from the same source as the text.

Editorial conclusion

This works well as a convenience for a single author who wants one short link in every project, and it is a poor fit the moment a license notice has to be stable evidence. Three things decide it: the copyright year on the page is always the current year, so it does not record when you licensed anything; any correction after creation needs a pull request merged by one maintainer; and the field that names a license is offered in the field list without a worked example next to it. If your project needs a pinned year, a named license and an owner who answers pull requests, copy the license text into the repository instead. If you do link here, put the copyright holder and year in your own README as well, so the notice survives the host going away.

Frequently asked questions

Official sources

1. Issues
2. README
3. remy/mit-license on GitHub