There are few other dependencies on JSON libraries in Malhar, but all of
them seem to be under Apache 2.0 license.
As we currently don't whitelist transitive dependencies (I have work in
progress for the core), it will be good to have org.json dependency
check added to the pom similar to what we do to check hadoop transitive
dependency in archetype pom. This will prevent accidental usage of
org.json in the future.
Thank you,
Vlad
On 11/28/16 17:15, amol kekre wrote:
Chinmay,
You can do the honor of responding to them so that they know we acted on
their request.
Thks
Amol
On Mon, Nov 28, 2016 at 1:04 PM, David Yan <[email protected]> wrote:
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 <[email protected]> wrote:
Chinmay
+1, Do you want to drive :)
Thks
Amol
On Thu, Nov 24, 2016 at 10:02 PM, Chinmay Kolhatkar <[email protected]>
wrote:
Yes... That's the mail.. There are couple if related conversations can
be
seen here too:
https://lists.apache.org/[email protected]
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 <[email protected]>
wrote:
Chinmay,
Is this the thread you were looking for?
Thks
Amol
---------- Forwarded message ----------
From: Ted Dunning <[email protected]>
Date: Thu, Nov 24, 2016 at 2:28 PM
Subject: Re: JSON License and Apache Projects
To: "[email protected]" <[email protected]>
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 <[email protected]>
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 <
[email protected]>
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 <
[email protected]>
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 <[email protected]>
Date: Wed, Nov 23, 2016 at 6:10 AM
Subject: JSON License and Apache Projects
To: ASF Board <[email protected]>
(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 [email protected]
list.
--
Jim Jagielski
VP Legal Affairs
------------------------------------------------------------
---------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected].
org
