You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@atlas.apache.org by Hemanth Yamijala <yh...@gmail.com> on 2016/11/25 09:13:41 UTC
Fwd: JSON License and Apache Projects
Atlas-dev,
Is this something to worry about? I see references to
o.json.JSONObject in HiveHook. And we seem to be pulling it in via
Hive dependencies.
Thanks
hemanth
---------- Forwarded message ----------
From: Ted Dunning <te...@gmail.com>
Date: Thu, Nov 24, 2016 at 6:40 AM
Subject: Fwd: JSON License and Apache Projects
To: "general@incubator.apache.org" <ge...@incubator.apache.org>
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 <ji...@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
Re: Fwd: JSON License and Apache Projects
Posted by David Radley <da...@uk.ibm.com>.
Hi ,
It does seem like we should move away from using this json library. Of the
options, I suggest we use Jackson,
all the best, David.
From: Hemanth Yamijala <yh...@gmail.com>
To: dev@atlas.incubator.apache.org
Date: 25/11/2016 09:13
Subject: Fwd: JSON License and Apache Projects
Atlas-dev,
Is this something to worry about? I see references to
o.json.JSONObject in HiveHook. And we seem to be pulling it in via
Hive dependencies.
Thanks
hemanth
---------- Forwarded message ----------
From: Ted Dunning <te...@gmail.com>
Date: Thu, Nov 24, 2016 at 6:40 AM
Subject: Fwd: JSON License and Apache Projects
To: "general@incubator.apache.org" <ge...@incubator.apache.org>
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 <ji...@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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU