Thanks William! I filed GEODE-2142 for tracking the legal requirement for remove JSON.
Anthony > On Nov 24, 2016, at 4:38 PM, William Markito Oliveira > <william.mark...@gmail.com> wrote: > > Interesting thread about json parsing libraries and licensing. > > Sent from my iPhone > > Begin forwarded message: > >> From: Ted Dunning <ted.dunn...@gmail.com> >> Date: November 24, 2016 at 2:28:47 PM PST >> To: "gene...@incubator.apache.org" <gene...@incubator.apache.org> >> Subject: Re: JSON License and Apache Projects >> Reply-To: gene...@incubator.apache.org >> >> 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 <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 >>>> >>>> >>>
