Hi Madhan, I think this is the problem: https://github.com/apache/incubator-atlas/blob/master/addons/hive-bridge/src/main/java/org/apache/atlas/hive/hook/HiveHook.java#L55
This is referring to JSONObject from org.json package. Thanks Hemanth On Sat, Nov 26, 2016 at 1:01 PM, Madhan Neethiraj <mad...@apache.org> wrote: > Hemanth, David, > > > > Atlas uses JOSN libraries from org.json4s, while the licensing issue seems to > be about the code/libraries from ‘https://github.com/stleary/JSON-java’. Are > both referring to the same? > > Thanks, > Madhan > > On 11/25/16, 2:00 AM, "David Radley" <david_rad...@uk.ibm.com> wrote: > > Hi , > It does seem like we should move away from using this json library. Of the > options, I suggest we use Jackson, > all the best, David. > > > > From: Hemanth Yamijala <yhema...@gmail.com> > To: dev@atlas.incubator.apache.org > Date: 25/11/2016 09:13 > Subject: Fwd: JSON License and Apache Projects > > > > Atlas-dev, > > Is this something to worry about? I see references to > o.json.JSONObject in HiveHook. And we seem to be pulling it in via > Hive dependencies. > > Thanks > hemanth > > > ---------- Forwarded message ---------- > From: Ted Dunning <ted.dunn...@gmail.com> > Date: Thu, Nov 24, 2016 at 6:40 AM > Subject: Fwd: JSON License and Apache Projects > To: "gene...@incubator.apache.org" <gene...@incubator.apache.org> > > > The VP Legal for Apache has determined that the JSON processing library > from json.org <https://github.com/stleary/JSON-java> is not usable as a > dependency by Apache projects. This is because the license includes a line > that places a field of use condition on downstream users in a way that is > not compatible with Apache's license. > > This decision is, unfortunately, a change from the previous situation. > While the current decision is correct, it would have been nice if we had > had this decision originally. > > As such, some existing projects may be impacted because they assumed that > the json.org dependency was OK to use. > > Incubator projects that are currently using the json.org library have > several courses of action: > > 1) just drop it. Some projects like Storm have demos that use twitter4j > which incorporates the problematic code. These demos aren't core and could > just be dropped for a time. > > 2) help dependencies move away from problem code. I have sent a pull > request to twitter4 <https://github.com/yusuke/twitter4j/pull/254>j, for > example, that eliminates the problem. If they accept the pull, then all > would be good for the projects that use twitter4j (and thus json.org) > > 3) replace the json.org artifact with a compatible one that is open > source. > I have created and published an artifact based on clean-room Android code > <https://github.com/tdunning/open-json> that replicates the most important > parts of the json.org code. This code is compatible, but lacks some > coverage. It also could lead to jar hell if used unjudiciously because it > uses the org.json package. Shading and exclusion in a pom might help. Or > not. Go with caution here. > > 4) switch to safer alternatives such as Jackson. This requires code > changes, but is probably a good thing to do. This option is the one that > is > best in the long-term but is also the most expensive. > > > ---------- Forwarded message ---------- > From: Jim Jagielski <j...@apache.org> > Date: Wed, Nov 23, 2016 at 6:10 AM > Subject: JSON License and Apache Projects > To: ASF Board <bo...@apache.org> > > > (forwarded from legal-discuss@) > > As some of you may know, recently the JSON License has been > moved to Category X (https://www.apache.org/legal/resolved#category-x). > > I understand that this has impacted some projects, especially > those in the midst of doing a release. I also understand that > up until now, really, there has been no real "outcry" over our > usage of it, especially from end-users and other consumers of > our projects which use it. > > As compelling as that is, the fact is that the JSON license > itself is not OSI approved and is therefore not, by definition, > an "Open Source license" and, as such, cannot be considered as > one which is acceptable as related to categories. > > Therefore, w/ my VP Legal hat on, I am making the following > statements: > > o No new project, sub-project or codebase, which has not > used JSON licensed jars (or similar), are allowed to use > them. In other words, if you haven't been using them, you > aren't allowed to start. It is Cat-X. > > o If you have been using it, and have done so in a *release*, > AND there has been NO pushback from your community/eco-system, > you have a temporary exclusion from the Cat-X classification thru > April 30, 2017. At that point in time, ANY and ALL usage > of these JSON licensed artifacts are DISALLOWED. You must > either find a suitably licensed replacement, or do without. > There will be NO exceptions. > > o Any situation not covered by the above is an implicit > DISALLOWAL of usage. > > Also please note that in the 2nd situation (where a temporary > exclusion has been granted), you MUST ensure that NOTICE explicitly > notifies the end-user that a JSON licensed artifact exists. They > may not be aware of it up to now, and that MUST be addressed. > > If there are any questions, please ask on the legal-discuss@a.o > list. > > -- > Jim Jagielski > VP Legal Affairs > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > >
