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