v2 ships with no LICENSE file, and four manifests declare plain MIT

Blank issues are disabled, so I filled the bug form's fields by hand — this is a packaging problem rather than a session bug, so the runtime fields are marked not applicable.

Which version line? v2 — current (@modelcontextprotocol/inspector@latest)
Which client? All / shared core
Inspector version: 2.7.0
Node version: v24.13.0
Operating system: Windows 11
Transport: Not applicable / never connected
MCP server under inspection: Not applicable — this is about the repository and the published package, not a connection.

Steps to reproduce

# 1. no LICENSE file on the default branch
curl -sI https://raw.githubusercontent.com/modelcontextprotocol/inspector/main/LICENSE | head -1
# HTTP/2 404

# 2. GitHub detects no license for the repository
gh api repos/modelcontextprotocol/inspector --jq '.license'
# null

# 3. the published package declares MIT
npm view @modelcontextprotocol/inspector@2.7.0 license
# MIT

# 4. ...and ships no license text
npm pack @modelcontextprotocol/inspector@2.7.0 >/dev/null && tar -tzf modelcontextprotocol-inspector-2.7.0.tgz | grep -i license
# (no output)

# 5. v1 has both
gh api 'repos/modelcontextprotocol/inspector/contents/LICENSE?ref=v1/main' --jq '.name'
# LICENSE
gh api 'repos/modelcontextprotocol/inspector/contents/package.json?ref=v1/main' --jq '.content' | base64 -d | grep '"license"'
#   "license": "SEE LICENSE IN LICENSE",

Expected behavior

main carries a LICENSE file, and the license field of every published manifest agrees with it — the state v1/main is in today, which is what #1017 and #1036 established.

Actual behavior

main has no LICENSE file, and four manifests declare plain MIT:

Manifest	license	published?
package.json	"MIT"	yes, as @modelcontextprotocol/inspector
clients/cli/package.json	"MIT"	private: true
clients/tui/package.json	"MIT"	private: true
clients/launcher/package.json	"MIT"	private: true
clients/web/package.json	absent	private: true

README.md (the "License" section) also says MIT.

The reason this looks like a regression rather than a preference: the LICENSE on v1/main opens with the project's transition notice — that new contributions are licensed under Apache-2.0, and that MIT applies only to contributions whose authors have not granted relicensing consent. v2 is a complete rewrite, so its code is new contributions. A bare "license": "MIT" on main, with no license text anywhere in the repository or in the tarball, states something different from that notice.

Concretely, this affects three groups:

• License checkers — the failure reported in #1093 (a tool choking on the license field) is back in a stronger form: the field parses, but there is no license text to check it against, and GitHub's own detector returns nothing.
• Redistributors — the npm tarball carries an SPDX identifier and no license text. That was #1036, closed and fixed on v1.
• Contributors — the CLA question ("what am I licensing my contribution under?") has no answer in the repository today.

Why I am opening this against v2

#1093 was closed with:

If this still happens in v2, we'd genuinely like to know. […] Please open a fresh issue against v2 with steps to reproduce

It does still happen, and worse than in v1: v1 at least had the file.

Related, all closed: #1017 (update the license for the Linux Foundation transition), #1036 (missing LICENSE in the npm package), #1093 (license field breaks checker tools).

Already prototyped a fix?

No — and I do not think an outside diff is the right shape here anyway, since which text applies to v2 is a maintainer and legal call, not a code change. What the fix has to cover, going by what v1 already does:

1. a LICENSE at the repository root on main;
2. the license field in the four manifests set to whatever that file says (v1 uses SEE LICENSE IN LICENSE);
3. the README's License section matching;
4. the file actually landing in the tarball — worth checking against .npmignore, since that is what #1036 turned on.

For what it is worth, modelcontextprotocol/typescript-sdk — the repository #1017 pointed at as the reference — carries the same transition text.

I found this while running a repository conformance checker of my own across a set of MCP repositories; the license rule fired here, and everything above is what I verified by hand afterwards.

Before you submit

• I searched existing issues and this is not a duplicate (the three related ones are closed; no open issue mentions the license).
• This is not a security vulnerability report.

Start by comparing v1/main's LICENSE and package.json with the root package.json, clients/cli/package.json, clients/tui/package.json, clients/launcher/package.json, README.md, and .npmignore. Confirm the applicable license text with maintainers before changing it, then verify the root file, manifest values, README section, and npm tarball agree by rerunning the issue's GitHub and npm checks.