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.mar...@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 <sblack...@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.fra...@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 >>
