apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Yan <da...@datatorrent.com>
Subject Re: JSON License and Apache Projects
Date Mon, 28 Nov 2016 21:04:16 GMT
As far as I know, we don't use anything from json.org directly. We use the
json library from jettison:
https://mvnrepository.com/artifact/org.codehaus.jettison/jettison.
>From the dependency tree in apex-core, I don't see anything that says
json.org.

David

On Fri, Nov 25, 2016 at 10:22 AM, Amol Kekre <amol@datatorrent.com> wrote:

> Chinmay
> +1, Do you want to drive :)
>
> Thks
> Amol
>
> On Thu, Nov 24, 2016 at 10:02 PM, Chinmay Kolhatkar <chinmay@apache.org>
> wrote:
>
> > Yes... That's the mail.. There are couple if related conversations can be
> > seen here too:
> > https://lists.apache.org/list.html?legal-discuss@apache.org
> >
> > I suggest we take a look at it and do the needful from our end too.
> >
> > -Chinmay.
> >
> >
> > On Fri, Nov 25, 2016 at 10:15 AM, Amol Kekre <amol@datatorrent.com>
> wrote:
> >
> > > Chinmay,
> > > Is this the thread you were looking for?
> > >
> > > Thks
> > > Amol
> > >
> > > ---------- Forwarded message ----------
> > > From: Ted Dunning <ted.dunning@gmail.com>
> > > Date: Thu, Nov 24, 2016 at 2:28 PM
> > > Subject: Re: JSON License and Apache Projects
> > > To: "general@incubator.apache.org" <general@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 <sewen@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 <
> 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