streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joey Frazee <joey.fra...@icloud.com>
Subject Re: [DISCUSS] JSON.org license is now category-x
Date Mon, 14 Nov 2016 19:44:49 GMT
I don't think dependency:tree transitively follows all the way through, so we actually don't
see the violators.

> On Nov 14, 2016, at 12:00 PM, Suneel Marthi <suneel.marthi@gmail.com> wrote:
> 
> mvn dependency:tree (or something like that)
> 
> it gives all libs along with their dependent libs
> 
>> On Mon, Nov 14, 2016 at 6:41 PM, sblackmon <sblackmon@apache.org> wrote:
>> 
>> Thanks for bringing this up Joey.
>> 
>> Looking into this it’s already on Twitter4J’s radar and there’s an open
>> pull-request.
>> 
>> https://github.com/yusuke/twitter4j/pull/215
>> 
>> Provided they resolve and release again in the near future, the only
>> action we’ll need to take is to upgrade.
>> 
>> Any ideas on ways to scan all of our direct dependencies for usage of
>> org.json:json?
>> On November 14, 2016 at 6:04:53 PM, Joey Frazee (joey.frazee@icloud.com)
>> wrote:
>> 
>> The ASF recently reclassified the JSON license for org.json as category-x
>> because of its "shall be used for Good, not Evil" clause [1].
>> 
>> There does not appear to be any direct usage of it in Streams but there
>> are a number of dependencies in Streams that do depend on org.json, most
>> notably Twitter4j, and it does appear in the poms.
>> 
>> Looking forward to the next release it probably makes sense to verify
>> where it's being pulled in and find an alternative. There seem to be 3
>> approaches people are taking:
>> 
>> - Pull relevant code into the project and replace the JSON.org code with a
>> compatible alternative
>> 
>> - Cease distributing offending modules as part of the Apache release
>> 
>> - Replace dependencies with alternatives that do not depend on org.json.
>> 
>> To my knowledge releases aren't currently getting -1 because of this, but
>> it's probably coming and prudent to address it anyway.
>> 
>> I think in the case of Twitter4j at least, we can likely pull the code
>> into the project, replace the org.json dep and begin working towards our
>> own implementation.
>> 
>> -joey
>> 
>> 1. http://www.apache.org/legal/resolved#json
>> 

Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message