incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Ewen <>
Subject Re: JSON License and Apache Projects
Date Thu, 24 Nov 2016 10:21:50 GMT
Just to be on the safe side:

If project X depends on another project Y that uses (and thus
project X has as a transitive dependency) is it sufficient to
exclude the transitive dependency in the reference to project Y?

Something like that:



On Thu, Nov 24, 2016 at 10:00 AM, Jochen Theodorou <>

> 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 <>
>> wrote:
>> The VP Legal for Apache has determined that the JSON processing library
>>> from <> 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 dependency was OK to use.
>>> Incubator projects that are currently using the 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 <>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
>>> 3) replace the artifact with a compatible one that is open
>>> source.
>>> I have created and published an artifact based on clean-room Android code
>>> <> that replicates the most
>>> important
>>> parts of the 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 <>
>>> Date: Wed, Nov 23, 2016 at 6:10 AM
>>> Subject: JSON License and Apache Projects
>>> To: ASF Board <>
>>> (forwarded from legal-discuss@)
>>> As some of you may know, recently the JSON License has been
>>> moved to 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message