and of course there is also Apache Johnzon ;-) http://johnzon.apache.org/
On Thu, Nov 24, 2016 at 10:21 AM, Stephan Ewen <se...@apache.org> 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 <blackd...@gmx.org> > 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 <ted.dunn...@gmail.com> >>> 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 <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 >>>> >>>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> -- Hendrik Saly (salyh, hendrikdev22) @hendrikdev22 PGP: 0x22D7F6EC --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
