Consider switching to org.json implementation without "don't be evil" license restriction

[philwebb]

Expected behavior

It should be possible to use Jedis without needing to have lawyers accept the "don't be evil" clause of org.json.

Actual behavior

As of commit 858c805 Jedis has a mandatory dependency on org.json:json. This library has an unfortunate "don't be evil" clause added to its MIT license which causes legal problems for some organizations.

See https://wiki.debian.org/qa.debian.org/jsonevil and https://www.apache.org/legal/resolved.html#json for additional background.

Perhaps the library could be optional (similar to #2961) or replaced with com.vaadin.external.google:android-json which is a clean room implementation of the API without any license issues.

Steps to reproduce:

n/a

Redis / Jedis Configuration

n/a

Jedis version:

4.0 and above

Redis version:

n/a

Java version:

n/a

[sazzad16]

@philwebb Thank you for creating this issue including possible alternates.

org.json:json cannot be made optional because the integrated APIs are exposed. It is possible with Gson because it is used only internally.

It can only be replaced. The idea of com.vaadin.external.google:android-json is interesting as we may not have to break our APIs.

[sazzad16]

@philwebb WDYT about breaking Jedis in release 4.4.0 to resolve this issue?

References:

• Replace org.json:json with jackson-databind #3205
• Replace both org.json and gson with jackson-databind #3206

[vpavic]

I just learned that org.json:json recently changed their license to remove the The Software shall be used for Good, not Evil clause. Unfortunately, the replacement is something that appears to be ambiguous. See here for more details:

• #688 update copyright  stleary/JSON-java#688
• License change request stleary/JSON-java#706

[chayim]

In the ideal world, we would not make any changes - because changes like the ones contemplated, mean API changes. API changes like this break users, and I'll err on the side of not doing this.

Prior to choosing a path, it would be great to at least see what the response to [the JSON issue][https://github.com/stleary/JSON-java/issues/706] will be.

[vpavic]

I agree, waiting to see what's the outcome of org.json licensing discussion seems to be like the most reasonable approach.

Until then, users that are affected by org.json's present license can exclude that dependency and pull in com.vaadin.external.google:android-json as a workaround.

[vpavic]

With stleary/JSON-java#706 now closed it appears that org.json:json is sticking with the current public domain license.

Since #3256 this project already depends on org.json:json release publish under the current license.

[github-actions]

This issue is marked stale. It will be closed in 30 days if it is not updated.

[sazzad16]

1. org.json:json have changed their license.
2. Users who are not using RedisJSON commands, can exclude that dependency.
3. org.json:json can safely be replaced (exclude+include) with com.vaadin.external.google:android-json (Make org.json safely replace-able with android-json #3242)

[vpavic]

Users who are not using RedisJSON commands, can exclude that dependency.

If org.json:json is used only for RedisJSON commands, would you consider making it an optional dependency in some future release? My feeling is that majority of Jedis users don't use RedisJSON commands.