The JSON License is MIT plus one sentence: the Software shall be used for Good, not Evil. That use restriction is why policies reject it.
On this page
What it does
The JSON License is Douglas Crockford's MIT text with one sentence added: the Software shall be used for Good, not Evil. Everything else reads like MIT. You may use, copy, modify, publish, distribute, sublicense, and sell the code, as long as the copyright notice and the full permission notice, including that sentence, travel with it. The added sentence is a field-of-use restriction: it limits what you are allowed to use the software for. That is what puts it outside the Open Source Definition, which does not allow a license to restrict fields of endeavour.
Details
The clause sounds like a joke and behaves like a procurement blocker. The Free Software Foundation treats the license as non-free, Debian treats it as failing its guidelines, and Fedora rejects it. The Apache Software Foundation put it on its prohibited list, which forced real code changes in Apache projects. So a buyer with a license policy may refuse the component even though the grant underneath is MIT-shaped. There is also no way to show the use condition is met, because Good and Evil are undefined and no objective test exists.
Pros
- Naming the situation (no license, dual license, exception, custom text) is better than forcing a nearby SPDX id.
- Once the files are read, the rest of the review looks like any other component.
Cons
- Auto-fetch and SPDX matching will not finish this for you. A person has to read what shipped.
- Wrong SPDX on a dual-license or LicenseRef package is a common attestation error.
What it allows and requires
Choose a category to see the full grant in one scannable list. Permissions show what the license allows, limits show what it withholds, and obligations show the conditions your release process must satisfy.
Permissions
Commercial use
You may ship the code inside a paid product. The license does not restrict commercial use.
Modify
You may change the code, including keeping those changes private, unless a later obligation says otherwise.
Distribute
You may give copies to others. Distribution is what usually turns notice and source duties into real work.
Sublicense
You may include the code under your own product terms, so long as you still meet this license's conditions.
Private use
Use inside your company, including internal forks, does not by itself trigger distribution duties.
Limits
Hold liable
The authors disclaim warranty. Recipients cannot hold them liable for damages arising from the software, except where law forbids that disclaimer.
Use trademark
The license is not a trademark license. Names, logos and product marks stay with their owners unless a separate grant says otherwise.
Patent grant
The text does not grant patents. If buyers want an express patent grant, Apache-2.0 is the usual alternative.
Field of use
The sentence "the Software shall be used for Good, not Evil" is a field-of-use restriction. That is why Debian, Fedora and the Apache Software Foundation reject this license.
Obligations
Include copyright
Keep the copyright line with every copy or substantial portion you distribute.
Include license
Keep the license text with every copy or substantial portion you distribute. A web page is not a substitute for notices inside a shipped artifact.
What JSON requires when you ship
JSON is a situation more than a standard grant. Read what is actually on the component, then record that, rather than hoping a nearby SPDX id covers it. The steps below are how to keep the record tied to the text you actually have.
You are meeting the notice condition when the copyright line and the full permission notice, including the Good-not-Evil sentence, travel with every copy you distribute.
You are as close as this license allows on the use clause when the person who owns license policy has looked at it and written down a decision, because nothing here can be checked objectively.
You have removed the question entirely when you replace the dependency. In Java, org.json has Apache-2.0 alternatives such as Jackson and Gson, at the cost of rewriting the call sites.
You are ready for a customer review when your component record names the license as JSON rather than as MIT, so the buyer's own policy can be applied to it.
The duties named in JSON
There is no standard grant to scan. Record the identifier and the text that is actually on the component, then treat nearby SPDX ids as other pages, not as substitutes.
Include copyright
Keep the copyright line with every copy or substantial portion you distribute.
Include license
Keep the license text with every copy or substantial portion you distribute. A web page is not a substitute for notices inside a shipped artifact.
Things to be aware of
- The license is read as MIT because the first 95 percent of the text is MIT. The added sentence is the only part that matters to a policy review.
- An SBOM records the component as MIT-like and it passes an allow-list that would have rejected it. Record the identifier as JSON and let the buyer decide.
- The replacement is postponed until a customer objects. The swap to an Apache-2.0 parser is a rewrite of the call sites, and it is cheaper before a deal is on the table.
What the JSON License does not do
Search results often flatten JSON License into a slogan. These are the usual misreads. JSON is a grant with conditions, not a permission to skip the paperwork below.
- The JSON License is not Open Source. The "used for Good, not Evil" sentence is a field-of-use restriction.
- It does not behave like MIT just because the rest of the text looks familiar.
How JSON differs from nearby licenses
These licenses are often confused with JSON, but their release duties differ. Each row summarizes what the license requires when you ship. Open the linked page for the full checklist.
- JSON
- The JSON License is MIT plus one sentence: the Software shall be used for Good, not Evil. That use restriction is why policies reject it.
- MIT
- MIT lets you ship the code inside a closed, paid product. The one condition is that the copyright line and license text travel with every copy.
- source-available
- You can read the code. That is not the same as permission to use it any way you like. Source available is not open source.
- proprietary
- Not open source. The agreement you signed sets the terms, so the text you attach and the limits you record are the whole record.
Common questions about JSON License
Answers to common questions about what JSON License requires, when its duties apply, and what evidence belongs with a release.
What is the JSON License?
The JSON License is Douglas Crockford's MIT text with one sentence added: the Software shall be used for Good, not Evil. Everything else reads like MIT. You may use, copy, modify, publish, distribute, sublicense, and sell the code, as long as the copyright notice and the full permission notice, including that sentence, travel with it. The added sentence is a field-of-use restriction: it limits what you are allowed to use the software for. That is what puts it outside the Open Source Definition, which does not allow a license to restrict fields of endeavour.
What does JSON require when you ship a product?
You are meeting the notice condition when the copyright line and the full permission notice, including the Good-not-Evil sentence, travel with every copy you distribute. You are as close as this license allows on the use clause when the person who owns license policy has looked at it and written down a decision, because nothing here can be checked objectively. You have removed the question entirely when you replace the dependency. In Java, org.json has Apache-2.0 alternatives such as Jackson and Gson, at the cost of rewriting the call sites. You are ready for a customer review when your component record names the license as JSON rather than as MIT, so the buyer's own policy can be applied to it.
Why does JSON sit under special cases?
JSON is a situation rather than a standard public grant: no license, a choice between licenses, an exception, a custom identifier, or a text that fits none of the families above. Each one is decided by reading what is actually there.
How is JSON different from MIT License?
JSON asks this: The JSON License is MIT plus one sentence: the Software shall be used for Good, not Evil. That use restriction is why policies reject it. MIT License asks this: MIT lets you ship the code inside a closed, paid product. The one condition is that the copyright line and license text travel with every copy. Open the MIT License page for what that license requires when you ship. Do not treat the SPDX ids as interchangeable because the short names look similar.
Where do I record JSON for a buyer?
SourceTrust fetches the published artifact, extracts the license files, and compares that text against the declared SPDX id, so the extra sentence is in front of you instead of buried inside a jar. No external obligation exists for a field-of-use restriction, so nothing lands on the project checklist and publishing is not held for it. The license catalog still records this license as permissive, so the component page groups it that way. The decision here is a policy one and it stays yours.
Where do I record JSON for a buyer?
SourceTrust fetches the published artifact, extracts the license files, and compares that text against the declared SPDX id, so the extra sentence is in front of you instead of buried inside a jar. No external obligation exists for a field-of-use restriction, so nothing lands on the project checklist and publishing is not held for it.
The license catalog still records this license as permissive, so the component page groups it that way. The decision here is a policy one and it stays yours.
Read /docs/inventory-compliance to find every project that carries it.
See also
The hub is the pillar for this cluster. Sibling licenses are the other spokes. Product FAQ links explain how SourceTrust records the duty, not the license text itself.
Practical guidance for procurement review, not legal advice. Confirm high-stakes use with counsel.