[JSON] Replacing json.org

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[JSON] Replacing json.org

Felix Meschberger-3
Hi all

Over at legal-discuss there is a discussion of whether the json.org library with the amended MIT license (remember the „use for good not evil“ clause ?) should be „banned“ by reconsidering the „A“ rating of this license (assuming the clause is just a joke) and turning it into an „X“ rating (don’t use based on Debian’s and other’s considerations:

https://wiki.debian.org/qa.debian.org/jsonevil
https://www.cnet.com/news/dont-be-evil-google-spurns-no-evil-software/

It is not decided yet. But we should probably be prepared.

Plenty of alternatives exist: Jackson, GSon, and IMHO quite interesting javax.json (https://json-processing-spec.java.net/) with a RI from glassfish (https://jsonp.java.net/).

Assuming we would have to change things, I suggest we reimplement the API of our refactoring of the json.org library with javax.json. We could use the RI form glassfish (which is OSGi-ready and includes the API) or implement our own version.

WDYT ?

Regards
Felix
Reply | Threaded
Open this post in threaded view
|

Re: [JSON] Replacing json.org

Robert Munteanu-2
On Fri, 2016-10-28 at 08:08 +0000, Felix Meschberger wrote:

> Hi all
>
> Over at legal-discuss there is a discussion of whether the json.org
> library with the amended MIT license (remember the „use for good not
> evil“ clause ?) should be „banned“ by reconsidering the „A“ rating of
> this license (assuming the clause is just a joke) and turning it into
> an „X“ rating (don’t use based on Debian’s and other’s
> considerations:
>
> https://wiki.debian.org/qa.debian.org/jsonevil
> https://www.cnet.com/news/dont-be-evil-google-spurns-no-evil-software
> /
>
> It is not decided yet. But we should probably be prepared.

We reference org.json in too many bundles bundles, a quick grep
revelead:

- bundles/commons/log-webconsole
- bundles/commons/metrics
- contrib/extensions/slf4j-mdc
- launchpad/builder ( SmokeIT )
- tooling/ide

So the effort would not be too great. I guess each of these can get
blocker issues for the next release, so we don't forget to remove the
dependency when releasing.

More problematic however is the bundles/common/json situation, where we
include the source of some of the json.org classes, which all include
the provision "The Software shall be used for Good, not Evil." . I am
not sure what we need to do about that, if anything.


> Plenty of alternatives exist: Jackson, GSon, and IMHO quite
> interesting javax.json (https://json-processing-spec.java.net/) with
> a RI from glassfish (https://jsonp.java.net/).

For the sake of being complete, there's also

  http://johnzon.apache.org/

which implements JSR-353 ( JSON processing 1.0 ) and also targets JSR-
374 ( JSON processing 1.1, which is due to be released in Q3 2016 ).
"Someone" will have to take a look at the libraries and suggest a
replacement though, there's no point in deploying multiple libraries
for the same thing.


> Assuming we would have to change things, I suggest we reimplement the
> API of our refactoring of the json.org library with javax.json. We
> could use the RI form glassfish (which is OSGi-ready and includes the
> API) or implement our own version.

+1

But I rather hope that the legal situation is cleared up and we don't
need to do anything about it.

Robert

>
> WDYT ?
>
> Regards
> Felix

Reply | Threaded
Open this post in threaded view
|

Re: [JSON] Replacing json.org

Felix Meschberger-3
Hi

Yea, johnzon was also mentioned on the Felix Dev list. Like this.

Regardless of the licensing org.json situation, given that there is javax.json as a standard API, we should maybe consider anyways to replace our uses of the org.json library with javax.json.

As I said, nothing decided yet, but create awareness.

Regards
Felix


> Am 28.10.2016 um 12:57 schrieb Robert Munteanu <[hidden email]>:
>
> On Fri, 2016-10-28 at 08:08 +0000, Felix Meschberger wrote:
>> Hi all
>>
>> Over at legal-discuss there is a discussion of whether the json.org
>> library with the amended MIT license (remember the „use for good not
>> evil“ clause ?) should be „banned“ by reconsidering the „A“ rating of
>> this license (assuming the clause is just a joke) and turning it into
>> an „X“ rating (don’t use based on Debian’s and other’s
>> considerations:
>>
>> https://wiki.debian.org/qa.debian.org/jsonevil
>> https://www.cnet.com/news/dont-be-evil-google-spurns-no-evil-software
>> /
>>
>> It is not decided yet. But we should probably be prepared.
>
> We reference org.json in too many bundles bundles, a quick grep
> revelead:
>
> - bundles/commons/log-webconsole
> - bundles/commons/metrics
> - contrib/extensions/slf4j-mdc
> - launchpad/builder ( SmokeIT )
> - tooling/ide
>
> So the effort would not be too great. I guess each of these can get
> blocker issues for the next release, so we don't forget to remove the
> dependency when releasing.
>
> More problematic however is the bundles/common/json situation, where we
> include the source of some of the json.org classes, which all include
> the provision "The Software shall be used for Good, not Evil." . I am
> not sure what we need to do about that, if anything.
>
>
>> Plenty of alternatives exist: Jackson, GSon, and IMHO quite
>> interesting javax.json (https://json-processing-spec.java.net/) with
>> a RI from glassfish (https://jsonp.java.net/).
>
> For the sake of being complete, there's also
>
>  http://johnzon.apache.org/
>
> which implements JSR-353 ( JSON processing 1.0 ) and also targets JSR-
> 374 ( JSON processing 1.1, which is due to be released in Q3 2016 ).
> "Someone" will have to take a look at the libraries and suggest a
> replacement though, there's no point in deploying multiple libraries
> for the same thing.
>
>
>> Assuming we would have to change things, I suggest we reimplement the
>> API of our refactoring of the json.org library with javax.json. We
>> could use the RI form glassfish (which is OSGi-ready and includes the
>> API) or implement our own version.
>
> +1
>
> But I rather hope that the legal situation is cleared up and we don't
> need to do anything about it.
>
> Robert
>
>>
>> WDYT ?
>>
>> Regards
>> Felix
>

Reply | Threaded
Open this post in threaded view
|

Re: [JSON] Replacing json.org

Roy T. Fielding
On Oct 28, 2016, at 4:20 AM, Felix Meschberger <[hidden email]> wrote:
>
> Hi
>
> Yea, johnzon was also mentioned on the Felix Dev list. Like this.
>
> Regardless of the licensing org.json situation, given that there is javax.json as a standard API, we should maybe consider anyways to replace our uses of the org.json library with javax.json.

No, unless you mean require a min JVM version that has an implementation of that API.

Do not import any Glassfish code into Apache.

....Roy


Reply | Threaded
Open this post in threaded view
|

Re: [JSON] Replacing json.org

Steven Walters
This feels like an "eating your own dog food" scenario, where Sling
could just switch to using its own developed/maintained commons JSON
library...
Or is there something missing from the public conversation as to why
it's being avoided/not mentioned?
Reply | Threaded
Open this post in threaded view
|

Re: [JSON] Replacing json.org

Robert Munteanu-2
On Sat, 2016-10-29 at 20:53 +0900, Steven Walters wrote:
> This feels like an "eating your own dog food" scenario, where Sling
> could just switch to using its own developed/maintained commons JSON
> library...
> Or is there something missing from the public conversation as to why
> it's being avoided/not mentioned?

My personal opinion is that we're not in the JSON parsing 'business',
but FWIW we do have the commons.json bundle which provides some basic
JSON parsing capabilities - object mapping excluded.

If we do decide to move away from the org.json bundle then we should
probably reuse an existing library.

Robert
Reply | Threaded
Open this post in threaded view
|

Re: [JSON] Replacing json.org

Carsten Ziegeler
Robert Munteanu wrote

> On Sat, 2016-10-29 at 20:53 +0900, Steven Walters wrote:
>> This feels like an "eating your own dog food" scenario, where Sling
>> could just switch to using its own developed/maintained commons JSON
>> library...
>> Or is there something missing from the public conversation as to why
>> it's being avoided/not mentioned?
>
> My personal opinion is that we're not in the JSON parsing 'business',
> but FWIW we do have the commons.json bundle which provides some basic
> JSON parsing capabilities - object mapping excluded.
>
> If we do decide to move away from the org.json bundle then we should
> probably reuse an existing library.
>
Neil Bartlett mentioned at the Apache Felix list a clean room
implementation of org.json:
"The Debian page on this issue links to a cleanroom implementation of the
same api, from Android:
https://android.googlesource.com/platform/libcore/+log/master/json"

So we can solve the problem with Sling's commons json through that code.

And I totally agree that we should stop doing our own json library.

Carsten

 

--
Carsten Ziegeler
Adobe Research Switzerland
[hidden email]