[DISCUSS] JSON.org licensing issue impacting Apache NiFi 1.1 release (and 0.x too)

[Joe Witt <jo...@apache.org>]

Team,

A recent shift in ASF policy toward the JSON.org license [1] as
discussed here [2] means we must eliminate any usage of the JSON.org
for any future releases.

The offending library which we have transitive dependency on in
several places as of this writing is here [3] and the JIRA which
outlines the challenge is here [4].

For the 1.x line I propose to make the following specific changes to
allow us to move forward and I highlight them because they will cause
some downstream user impact which we'll  have to manage but appear
unavoidable at this point.

1) nifi-social-media-nar / GetTwitter processor

This processor utilizes the Twitter4J library which depends on the now
category X code. I plan to remove the nar and ensure we do not
deploy/release the nar by default.  One could optionally build that
component and include it if they wish to do so.  Users would need to
build that component/nar and include it in their build if they want
it.

2) nifi-flume-nar / twitter source

The flume nar bundles the twitter source which also uses twitter4j.  I
plan to simply remove this dependency.

3) nifi-hive-nar / Hive processors

The hive processors depend on hive-common which uses this library.  I
plan to remove nifi-hive-nar and ensure we do not deploy/release the
nar by default.  The code will still be available should someone want
to optionally build and include it themselves.

4) nifi-standard-nar / ValidateJSON processor

This is new in 1.x line.  I plan to revert this commit and reopen this
JIRA for the dependency usage to get resolved.

For processors/components that will not be made available by default
please note that the previous 1.x release provided a feature which
means flows depending on no longer available components will still
come up and will allow the user to alter them.  In the 0.x line the
flow will not come up and the user will need to edit their flow
manually to remove the offending dependency or provide it on the
classpath.

The release notes/highlights will be updated to very clearly reflect
this situation and provide guidance to users wishing to leverage these
resources.

A similar path will need to be followed for the 0.x line for any
future releases and I will create JIRAs to address them.  For those
interested in this topic please take a moment to review the state of
the situation and if you see more optimal tradeoffs we can make to
limit downstream consumption impact please do advise.

Thanks
Joe

[1] http://www.json.org/license.html
[2] https://lists.apache.org/thread.html/9627a9278d263378a2045d4bffccb6e83b9f01bb783c6dd6fa325faf@%3Clegal-discuss.apache.org%3E
[3] https://github.com/stleary/JSON-java
[4] https://issues.apache.org/jira/browse/NIFI-2991