[
https://issues.apache.org/jira/browse/NIFI-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15651857#comment-15651857
]
Joseph Witt commented on NIFI-2991:
-----------------------------------
Email I sent to dev list today modified to reflect matt burgess analysis of
hive.
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. Matt
Burgess found that we can simply exclude this dependency and our uses of hive
still work just fine. He will issue a PR for this. The PR should exclude the
dependency and clean up the dependency reference if present for the
LICENSE/NOTICE as appropriate.
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
> JSON.org license is now CatX
> ----------------------------
>
> Key: NIFI-2991
> URL: https://issues.apache.org/jira/browse/NIFI-2991
> Project: Apache NiFi
> Issue Type: Bug
> Reporter: Sean Busbey
> Assignee: Joseph Witt
> Priority: Blocker
> Fix For: 1.1.0
>
>
> per [update resolved legal|http://www.apache.org/legal/resolved.html#json]:
> {quote}
> CAN APACHE PRODUCTS INCLUDE WORKS LICENSED UNDER THE JSON LICENSE?
> No. As of 2016-11-03 this has been moved to the 'Category X' license list.
> Prior to this, use of the JSON Java library was allowed. See Debian's page
> for a list of alternatives.
> {quote}
> I don't know how many of our versions include stuff under this license, it's
> definitely currently in master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
