The Apache ManifoldCF project got an official Legal ruling on the json license and accepted it many years ago.
Thanks, Karl On Thu, Nov 24, 2016 at 7:11 AM, Guillaume Laforge <glafo...@gmail.com> wrote: > 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> >
