incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Ewen <se...@apache.org>
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 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 <blackdrag@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.dunning@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 <jim@apache.org>
>>> Date: Wed, Nov 23, 2016 at 6:10 AM
>>> Subject: JSON License and Apache Projects
>>> To: ASF Board <board@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

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