Recommend upgrading to the real org.json

[stleary]

org.json now has a public domain license. The latest version is more capable and contains many bug fixes not found in the Android version. Also, you could use similar() for strict comparisons.

[Brummolix]

I agree, for example the original version is vulnerable, see https://nvd.nist.gov/vuln/detail/CVE-2023-5072 The (very old) fork may be vulnerable, too.

[fkriegl]

Context:

currently skyscreamer/JSONassert uses the vaadin implementation of org.json: https://github.com/skyscreamer/JSONassert/blob/7414e901af11c559bc553e5bb8e12b99a57d1c1c/pom.xml#L52-L56

Suggestion:

Use Open Json.

Instead of using org.json aka stleary/JSON-java, I suggest to switch to the Open Json reimplementation, because it has an Apache-2.0 license. Open-Json is based on the original vaadin implementation (which was a reimplementation of stleary/JSON-java).

Background:

Developers are fleeing from stleary/JSON-java because of its non-OSI-license. The JSON license was replaced by a even less specific "Public domain" license in 2022, leaving even more room for interpretation on what this license implies (at least for corporate lawyers... for developers it is likely more than clear).

See also:

The Apache Software Foundation has now also banned this library [...] - https://github.com/stleary/JSON-java/issues/331#issuecomment-303515688

and

[...] they are just looking for something more "formal" to satiate corporate lawyers. I believe a license like this matches what [Douglas Crockford's] intent is [.] - https://github.com/stleary/JSON-java/issues/706#issuecomment-1435351931

The "problem" is that some developers work in a corporate context and thus cannot use software/libraries that are licensed in an ..let's say "informal" way. All that (many) people (likely) want is using this nice little library (props to the maintainer) with less stress regarding an unspecific license.

Since skyscreamer/JSONassert is even used by Spring Framework, this affects thousands of developers and software projects because @spring-projects' spring-framework and spring-boot are widely spread in commercial and non-commercial software products.

[carterpage]

I haven't done a new version in a few years, so this will take some time to get the pom.xml modernized. The org.json update will need to be a new minor version at least since it will change how nulls are handled. I'll probably get a 1.5.2 out first to deal with some immediate problems, and then try to fast follow on 1.6.0.

This is not a commercial effort, so I don't have an ETA. However, I will post updates.

[carterpage]

Any more thoughts on org.json vs openjson?

org.json is backward breaking in terms of null handling and may require a major update. If openjson does not break the tests, then we could probably release with just a minor bump.

Regardless, it's high time to get off the ancient vaadin library.

[carterpage]

Oh, openjson uses different packages. It's perhaps even more backward breaking.

If we were to use org.json, what would be the best version to put in the maven dependency to be as friendly to as many projects as possible? @stleary opinions appreciated.

[stleary]

@carterpage I would recommend the org.json latest release: 20240303.

[fkriegl]

Oh, openjson uses different packages. It's perhaps even more backward breaking.

Is this a problem? How about releasing a new major version with OpenJson? That would not require backward compatibility (and could be picked up in a new spring minor release); and optionally a new minor version with org.json? I know that's twice the work... but I do not see an advantage regarding the license issue when using org.json (which is technically fine). However, the license of org.json is "Public Domain" which is just not formal enough, see my earlier comment regarding that license topic discussion. It would not allow many developers in a corporate context to use the library.

I see two options:

1. The unrealistic one: In a new release of org.json, switch to a more formal license (@stleary), that has the same intent as "public domain" but has some "official definition" and by that satiates corporate lawyers. As already suggested by others org.json could switch to the "Unlicense": https://opensource.org/license/unlicense
   Then, JSONassert could use the version released under this new license.

However, following the closing comment in the issue here I don't think we can expect a change in the license of org.json, as the maintainers do not see a need to change or don't want to acknowledge the problem users are facing with the current license type:

The author Douglas Crockford is well aware of the harm he's doing but numerous request from different projects and parties could not change his mind. - https://wiki.debian.org/qa.debian.org/jsonevil

So maybe JSONassert should just follow the maintainer's advice and do not use org.json:

If Public Domain is not liberal enough for you, I recommend that you do not use it. - https://github.com/stleary/JSON-java/issues/706#issuecomment-1432388496

2. The higher effort option: Use OpenJson or another library with an OSI license type instead and create a new major release.

However, also OpenJson might have drawbacks (how high is the adoption? is there just one maintainer? how often will new (maintenance) release versions be published? etc. ) Maybe also the maintainer of OpenJson (@mfursov) could let us know his thoughts on this.

(Unfortunately) software development is not only about code, but also about legal requirements. Without a different license (in org.json) or using another json library that has an OSI license, I personally don't see a chance to confidently use JSONassert in the future.

[carterpage]

@stleary Briefly, can you please help me understand why 20231013 wouldn't be a safer bet?

• It has the most usages in central (for versions <5 years old)
• It is the oldest commonly used version without any vulnerabilities
• 20240303 has new public methods (JSONAssert isn't using any of those methods, so maybe this is moot.)

I notice json-java is using a much older version of json-path (upgraded from 2.1 to 2.4 in 20240205), so I'm wondering if latest/greatest is ideal for a low level library.