Chinmay, You can do the honor of responding to them so that they know we acted on their request.
Thks Amol On Mon, Nov 28, 2016 at 1:04 PM, David Yan <[email protected]> wrote: > As far as I know, we don't use anything from json.org directly. We use the > json library from jettison: > https://mvnrepository.com/artifact/org.codehaus.jettison/jettison. > From the dependency tree in apex-core, I don't see anything that says > json.org. > > David > > On Fri, Nov 25, 2016 at 10:22 AM, Amol Kekre <[email protected]> wrote: > > > Chinmay > > +1, Do you want to drive :) > > > > Thks > > Amol > > > > On Thu, Nov 24, 2016 at 10:02 PM, Chinmay Kolhatkar <[email protected]> > > wrote: > > > > > Yes... That's the mail.. There are couple if related conversations can > be > > > seen here too: > > > https://lists.apache.org/[email protected] > > > > > > I suggest we take a look at it and do the needful from our end too. > > > > > > -Chinmay. > > > > > > > > > On Fri, Nov 25, 2016 at 10:15 AM, Amol Kekre <[email protected]> > > wrote: > > > > > > > Chinmay, > > > > Is this the thread you were looking for? > > > > > > > > Thks > > > > Amol > > > > > > > > ---------- Forwarded message ---------- > > > > From: Ted Dunning <[email protected]> > > > > Date: Thu, Nov 24, 2016 at 2:28 PM > > > > Subject: Re: JSON License and Apache Projects > > > > To: "[email protected]" <[email protected]> > > > > > > > > > > > > Stephan, > > > > > > > > What you suggest should work (if you add another dependency to > provide > > > the > > > > needed classes). > > > > > > > > You have to be careful, however, because your consumers may expect to > > get > > > > the full json.org API. > > > > > > > > I would suggest that exclusions like this should only be used while > > your > > > > direct dependency still has the dependency on json.org. When they > fix > > > it, > > > > you can drop the exclusion and all will be good. > > > > > > > > > > > > > > > > On Thu, Nov 24, 2016 at 2:21 AM, Stephan Ewen <[email protected]> > > wrote: > > > > > > > > > Just to be on the safe side: > > > > > > > > > > If project X depends on another project Y that uses json.org (and > > thus > > > > > project X has json.org as a transitive dependency) is it > sufficient > > to > > > > > exclude the transitive json.org dependency in the reference to > > project > > > > Y? > > > > > > > > > > Something like that: > > > > > > > > > > <dependency> > > > > > <groupId>org.apache.hive.hcatalog</groupId> > > > > > <artifactId>hcatalog-core</artifactId> > > > > > <version>0.12.0</version> > > > > > <exclusions> > > > > > <exclusion> > > > > > <groupId>org.json</groupId> > > > > > <artifactId>json</artifactId> > > > > > </exclusion> > > > > > </exclusions> > > > > > </dependency> > > > > > > > > > > Thanks, > > > > > Stephan > > > > > > > > > > > > > > > On Thu, Nov 24, 2016 at 10:00 AM, Jochen Theodorou < > > [email protected]> > > > > > wrote: > > > > > > > > > > > is that library able to deal with the jdk9 module system? > > > > > > > > > > > > > > > > > > On 24.11.2016 02:16, James Bognar wrote: > > > > > > > > > > > >> Shameless plug for Apache Juneau that has a cleanroom > > implementation > > > > of > > > > > a > > > > > >> JSON serializer and parser in context of a common serialization > > API > > > > that > > > > > >> includes a variety of serialization languages for POJOs. > > > > > >> > > > > > >> On Wed, Nov 23, 2016 at 8:10 PM Ted Dunning < > > [email protected]> > > > > > >> wrote: > > > > > >> > > > > > >> 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 <[email protected]> > > > > > >>> Date: Wed, Nov 23, 2016 at 6:10 AM > > > > > >>> Subject: JSON License and Apache Projects > > > > > >>> To: ASF Board <[email protected]> > > > > > >>> > > > > > >>> > > > > > >>> (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 [email protected] > > > > > >>> list. > > > > > >>> > > > > > >>> -- > > > > > >>> Jim Jagielski > > > > > >>> VP Legal Affairs > > > > > >>> > > > > > >>> > > > > > >> > > > > > > ------------------------------------------------------------ > > > --------- > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected]. > org > > > > > > > > > > > > > > > > > > > > > > > > > > >
