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 <romb...@apache.org>: > > 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 >
