Please see the e-mail below about JSON License which is also archived at: https://www.mail-archive.com/[email protected]/msg57452.html
The side-effect for Wink is that we need to find a replacement for our dependency on json.org dependencies and come up with a release. Anyone volunteering to help on this ? ---------- Forwarded message ---------- From: Ted Dunning <[email protected]> Date: Wed, Nov 23, 2016 at 5:10 PM Subject: Fwd: JSON License and Apache Projects To: "[email protected]" <[email protected]> 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. -- Luciano Resende http://twitter.com/lresende1975 http://lresende.blogspot.com/
