Improving JSONCrack License for Clarity and Legal Robustness

[paimagham]

Feature

Acknowledgement of Effort

First, I want to thank the JSONCrack team for providing a clear and permissive license that allows for non-commercial use of the software. It’s clear that the license reflects an intention to enable teaching, academic research, and personal experimentation while protecting the software from unauthorized commercial use.

Why the License Needs Improvement

While the current license serves its purpose, I believe it could benefit from improvements in clarity, structure, and legal robustness:

Clarity: Some sections can be more explicit, especially regarding definitions of terms like “commercial use” and “non-commercial use.”
Readability: Structuring the license with section headings (e.g., Purpose, Permitted Use, Restrictions) would make it easier for users to navigate and understand.
Legal Robustness: Adding common legal clauses, such as a more detailed Disclaimer of Warranties and Limitation of Liability, can protect the software and maintainers from unforeseen legal issues.
Summary of Proposed Changes

Alternative solutions or implementations

I have prepared a draft of an improved license, which includes the following updates:

Section Headings: Introduced clear sections (Purpose, Permitted Use, Commercial Use, etc.) for better readability.
Clarified Definitions: Provided explicit examples of non-commercial and commercial use, and internal use.
Enhanced Legal Clauses: Added a detailed Disclaimer of Warranties and Limitation of Liability to ensure legal protection for the maintainers and contributors.
Improved Terminology: Simplified complex sentences and used consistent language throughout the license.

Other context

No response

[oleole39]

Hello,
I agree that the project would gain from clarifying the license. But to my mind it would gain even more from using a standardized license rather than crafting its own, in particular as - unless I missed something - there is nothing too specific in the current JSON Crack license.

Looks like https://creativecommons.org/licenses/by-nc/4.0/ could do the job.
Or maybe even better, dual-license it with AGPL 3.0 + Commercial license.
More info there: https://opensource.stackexchange.com/questions/9805/can-i-license-my-project-with-an-open-source-license-but-disallow-commercial-use

[AykutSarac]

Thanks for sharing your thoughts and suggestions. These are the goals of the LICENSE:

• It shouldn't be used for commercial purposes without commercial license.
• For non-commercial purposes appropriate attributes should be given, same license and stated changes.
• Fine to use internally within a organization/locally and modifications.

I'd love to hear your thoughts, additions and LICENSE suggestions.

[oleole39]

• It shouldn't be used for commercial purposes without commercial license.
• For non-commercial purposes appropriate attributes should be given, same license and stated changes.
• Fine to use internally within a organization/locally and modifications.

Note that I am not a lawyer and that I have limited practical experience with Open Source licensing, but I find CC BY-NC 4.0 (cf. link above) covering exactly those needs.
However make sure to read the second answer of the StackExchange topic already linked above (that one) which could have been written for you - it lists caveats for such license (to which could be added for what it matters that CC BY-NC 4.0 is approved as an open source license by the Free Software Foundation but not by Open Source Initiative, as opposed to AGPL 3.0/Dual licensing accepted as such by both organizations) and explains why dual licensing with AGPL 3.0 could be a better idea.
Though AGPL 3.0 may discourage commercial use for companies building non-AGPL 3.0 products (i.e. most commercial companies, which are not likely to be willing to offer downloading their product for free), I guess it would nevertheless not prevent commercial use from commercial companies integrating your code in a AGPL-3.0-licensed product, or service companies (like someone providing support or hosting plan for your software).

It seems it leaves a trade-off for you to find between how widespread you want the free version to be versus how strictly protected from commercial use it should be, but I believe that any of these licenses will be better than using current JSON Crack license which is not granting more security to you as the original author/main contributor of the software (the text leaving probably much to interpretation and not benefiting from the legal care given to more established licenses as well as from their experience in terms of legal precedents) and makes your project less interesting/usable for non-commercial projects due to the legal uncertainties of custom licenses.

[AykutSarac]

Updated the license. MIT with Commons Clause Restrictions, mainly prevents the use for commercial projects and redistribution. Looking forward to feedbacks.

[oleole39]

I didn't know about the Commons Clause Restrictions - is the related section you added a kind of standard or something you crafted ?
It seems different from what I could find about Commons Clause:
https://commonsclause.com/
https://mitcc.org/

In case that would matter to you, as described in the first link of this post and in the ones below, the Commons Clause mentioned here above is apparently not considered as an open source license (as defined by Open Source Initiative or FSF), even when used jointly with a copyleft license (as opposed to the dual licensing presented earlier).
https://sfconservancy.org/blog/2018/aug/22/commons-clause/
https://www.fsf.org/blogs/licensing/protecting-free-software-against-confusing-additional-restrictions

Personally I find confusing - not to say contradictory - the fact that it claims allowing

to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, and distribute the Software as part of an application, website, or product

But then

1. No Redistribution – You may not sell, sublicense, or otherwise redistribute the components of this Software as part of any product, tool, or service that competes with JSON Crack or provides similar functionality without explicit permission.
2. No Competing Products – You may not use the Software to create a tool, service, or platform that directly competes with JSON Crack or utilizes its components without explicit permission.

My case is that I packaged JSON Crack with some customizations for a self-host platform (you may understand it as a sort of Docker alternative without virtualization to minimize server's hardware requirements) which is distributed free of charge.
The packaging code I wrote is licensed AGPL3.0, and the end user able to perform a sort of 1-click install of JSON Crack on his/her server using that package can find a mention of upstream license (i.e. up to now your custom "JSON Crack license"), a brief summary ("free for non-commercial use"), and a link to upstream repo (i.e. no appropriation of your code). From the 2 first points of you Commons Clause Restrictions' section, I don't understand whether I am still allowed to upgrade that package with newer versions of JSON Crack, at least without your explicit permission.

• is that sublicensing?
• is that a form of redistribution ?
• is self hosting a slightly customized version of JSON Crack distributed under the name JSON Crack and provide free access to it considered to compete with official JSON Crack instance ? What actually means "JSON Crack" here - the software or also the service from official instance?

[AykutSarac]

• Is that sublicensing?
  No. It’s based on MIT but adds restrictions.

• Is that a form of redistribution?
  Yes, but since it won't be a public-service it falls under allowed use.

• Self hosting is completely fine.

My goal is to separate JSON Crack's visualization component into a separate repo/library so it can have its own license with less restrictions, but I have no time to do this at the moment. The library will have more freedom over the website. I don't want to see people rebranding jsoncrack.com and publishing it as a service with no contribution.

I agree that there's a solid confusion. I see there's no good balance between the open-source and the limitations. I like Sentry’s License because it restricts competing products while still allowing redistribution in some cases, and transitions to Apache 2.0 after 2 years. This might be a good fit for JSON Crack to protect its commercial potential while staying community-friendly.

[oleole39]

My goal is to separate JSON Crack's visualization component into a separate repo/library so it can have its own license with less restrictions, but I have no time to do this at the moment. The library will have more freedom over the website.

Understood, still if I get well what you mean by visualization component, it would be a different (although complementary) project than the /editor page of JSON Crack website.

I don't want to see people rebranding jsoncrack.com and publishing it as a service with no contribution.

• Is that a form of redistribution?
  Yes, but since it won't be a public-service it falls under allowed use.
• Self hosting is completely fine.

Here there's a limitation I had not understood before if that's what you mean - that once self-hosted, it could not be offered for free to public. Maybe you would consider offering access to it to a restricted community as not "public" (i.e. internal use), but whether rebranded/customized or not, I now understand it could not be self-hosted while allowing access without particular restrictions (i.e. potentially accessible to the whole world).

I like Sentry’s License because it restricts competing products while still allowing redistribution in some cases, and transitions to Apache 2.0 after 2 years. This might be a good fit for JSON Crack to protect its commercial potential while staying community-friendly.

Basically I find the wording of the license currently in the repo ambiguous, typically for the previous point I wasn't able to understand straightforwardly.
The "standard" Commons Clause (https://mitcc.org) or the FSL License (https://fsl.software - the one used by Sentry) both seem much more straightforward to me, although they protect only against commercial use, not against the case of my previous paragraph here above.

Over Commons Clause, I believe FSL license somehow could reassure a licensee paying a commercial license to you that your software is less likely to be abandoned than a proprietary software as anyone can still fork a 2y-old branch as a new start point, including to make a commercial product out of it.
Then of course 2 years can be a lot (if you made many significant upgrades from which any 2-y downgrade would be commercially painful), but also not much at the same time since you could find that there would still be a legal door for "illegitimate" competition if you come to a point where you make little to no commits to the software in a 2y-period.
Note that FSL License can be used together with either MIT or Apache as per your preference, but due to the restriction it includes, that won't make it to be considered as "Open Source" as per OSI's or FSF's definitions.