Answers · code licenses
Which license should I choose for my open-source MCP server?
Last updated
TL;DR: Pick one on purpose, and add it before anyone uses the code: with no license file, default copyright applies and nobody may legally copy, change or redistribute your server, even though the repo is public. For most MCP servers the choice is MIT or Apache-2.0. Both let anyone use the server in commercial and closed products as long as they keep your notice; Apache-2.0 adds an express patent grant and is what the MCP project itself is moving to for new code. If you want people who run a modified copy of your server as a hosted service to share their changes, AGPL-3.0 is the license built for that, at the cost of many companies avoiding it. Check your dependencies first: a GPL or AGPL dependency limits what you can choose.
What should I check, step by step?
1. List your server's dependencies and their licenses before choosing; anything you bundle constrains your outbound license (npm sbom, pip-licenses, or Rightshold's check.mjs).
- Decide what you want: maximum adoption (MIT or Apache-2.0), patent protection for users and contributors (Apache-2.0), or changes to hosted copies coming back to you (AGPL-3.0).
- Add the full license text as LICENSE (or LICENSE.md / LICENSE.txt) at the repo root, with your name or organization and the year. GitHub detects it with Licensee and shows it on the repo page.
- Set the same SPDX id in your package metadata: "license": "Apache-2.0" in package.json, or license = "MIT" in pyproject.toml.
- Keep the license file in what you publish to npm, PyPI or a container registry, not only on GitHub.
- If you take outside contributions, say in CONTRIBUTING.md that contributions are under the project's license, so you never have to ask everyone later (the MCP project is doing exactly that to move from MIT to Apache-2.0).
- Write down why you chose it. Changing licenses later means getting agreement from every contributor whose code you keep, or rewriting their code.
Why a public repo with no license isn't open source
GitHub's licensing docs say that without a license, default copyright law applies: you keep all rights and no one may reproduce, distribute or create derivative works from your code.
- GitHub's Terms of Service let other GitHub users view and fork a public repo on GitHub. That is not permission to run your server in their product or ship a copy.
- For an MCP server this matters early: people install it with npx or uvx, and company users often check the license before approving it. No license usually means no approval.
MIT vs Apache-2.0 vs AGPL-3.0 for an MCP server
MIT: shortest, only asks users to keep the copyright and license notice. Fine for small servers and wrappers; it has no express patent grant.
- Apache-2.0: also permissive, and adds an express patent license from every contributor. If someone sues claiming the work infringes their patent, the patent licenses they received under Apache-2.0 end. Users must keep notices, the NOTICE file if you have one, and mark files they changed.
- AGPL-3.0: section 13 says if someone modifies your server and users interact with it over a network, those users must be offered the source of that version. That fits remote (HTTP) MCP servers that you don't want closed forks of. Many companies have policies against AGPL dependencies, so expect less adoption.
- GPL-3.0 does little for a server that people run remotely, because its source duty is triggered by distributing copies, not by running the software for others. For a local stdio server that people install and run, copies are distributed, so GPL does apply to them.
What the MCP project itself does
The LICENSE in the modelcontextprotocol/modelcontextprotocol repo says the project is moving from MIT to Apache-2.0: new code and specification contributions are Apache-2.0, documentation is CC-BY-4.0, and older contributions stay MIT until their authors agree to relicense.
- You don't have to match the SDK's license. MIT and Apache-2.0 SDKs can be used in a server under either license, or under a copyleft license, as long as you keep their notices.
What can go wrong?
You bundle a GPL or AGPL dependency in an MIT server you ship. The combined copy you distribute has to follow the copyleft license; MIT on your own files doesn't change that.
- The license is only in the README. GitHub may not detect it, and registries may show the package as unlicensed.
- You pick a 'non-commercial' or custom license and call it open source. Licenses that restrict commercial use are not open source by the OSI definition, and companies may not be allowed to use them.
- You copy a LICENSE file from another project and leave their name in it.
What do the license checks say?
Yes means the license grants the use, on the duties listed. Duties such as source_disclosure, share_alike and network_source_offer are the ones that conflict with keeping a product closed-source.
| Use | Answer | Why |
|---|---|---|
| Someone modifies your MIT server and ships it in a paid closed-source product (MIT) | Yes | Every use you described is granted by MIT, and nothing you described is prohibited. Duties: attribution, license_notice. |
| The same under Apache-2.0 (Apache-2.0) | Yes | Every use you described is granted by Apache 2.0, and nothing you described is prohibited. Duties: attribution, license_notice, state_changes. |
| The same under AGPL-3.0 (AGPL-3.0-only) | Yes | Every use you described is granted by AGPL 3.0, and nothing you described is prohibited. Duties: attribution, license_notice, state_changes, share_alike, source_disclosure, network_source_offer. |
How do I ask Rightshold about this (free, no key)?
Add the MCP server https://www.rightshold.com/mcp to Claude, Cursor, ChatGPT, Grok or VS Code, then ask: “My MCP server depends on packages under MIT, Apache-2.0 and ISC. Can I license it under Apache-2.0, and what do I have to keep?”
{
"tool": "license_compatibility",
"arguments": {
"licenses": [
"MIT",
"Apache-2.0",
"ISC"
],
"intended_use": {
"redistribution": true,
"commercial_use": true
}
}
}- Free, no key. Returns whether the licenses can be combined, the reason for each pair, the combined duties, and an outbound license hint: for an all-permissive set it says the choice is yours; with a GPL or AGPL dependency it names that license as the one that governs the combined work.
- Find your dependencies' licenses first, free: curl -fsSL https://www.rightshold.com/check.mjs | node - lists every npm dependency with its license.
- check_license with a GitHub, npm or PyPI page as source_url reads the license a single dependency declares.
Rightshold checks the licenses you give it and the license a GitHub, npm or PyPI page declares. It doesn't choose a license for you, read your code, or know your goals, and it isn't legal advice.
What are the sources?
- GitHub Docs: Licensing a repository (no license = default copyright)
- Choose a License: Licenses compared
- Apache License 2.0 (section 3, patent license)
- GNU Affero General Public License v3.0 (section 13, remote network interaction)
- Model Context Protocol: LICENSE (MIT to Apache-2.0 transition)
- npm Docs: package.json license field (SPDX ids)
- SPDX License List
- Open Source Initiative: The Open Source Definition
Related
- Can I use MIT, GPL or AGPL code in a closed-source SaaS?
- MIT vs Apache 2.0
- How to check every npm dependency's license before shipping
- How to pin MCP server versions and review changes before upgrading
Not legal advice. JSON · Markdown · All answers
Get a free API key in one call
No card and no email needed. 100 free credits; the license and policy checks stay free without a key.
curl -s -X POST https://www.rightshold.com/v1/accounts/signup -H "Content-Type: application/json" -d '{"accept_terms":true}'
export RIGHTSHOLD_API_KEY=rs_... # the api_key from the reply (shown once)
curl -s https://www.rightshold.com/v1/licenses/check -H "Authorization: Bearer $RIGHTSHOLD_API_KEY" \
-H "Content-Type: application/json" -d '{"license":"MIT","intended_use":{"commercial_use":true}}'