And Apache Groovy also has some great JSON support as well, with a super
fast parser, and serializer as well.
So there's choice at Apache regarding JSON :-D

On Thu, Nov 24, 2016 at 12:56 PM, Hendrik Dev <hendrikde...@gmail.com>
wrote:

> 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
>
>


-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>

Reply via email to