[jira] [Updated] (TC-50) Mitigate json.org dependency

["Ryan Durfey (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TC-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ryan Durfey updated TC-50:
--------------------------
    Labels: dependancy json.org  (was: )

> Mitigate json.org dependency
> ----------------------------
>
>                 Key: TC-50
>                 URL: https://issues.apache.org/jira/browse/TC-50
>             Project: Traffic Control
>          Issue Type: Improvement
>          Components: Traffic Router
>    Affects Versions: 1.9.0
>            Reporter: Mark Torluemke
>              Labels: dependancy, json.org
>
> Per this email:
> {noformat}
> From: Ted Dunning <te...@gmail.com>
> Reply-To: "general@incubator.apache.org" <ge...@incubator.apache.org>
> Date: Wednesday, November 23, 2016 at 6:10 PM
> To: "general@incubator.apache.org" <ge...@incubator.apache.org>
> Subject: Fwd: JSON License and Apache Projects
> 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.
> ---------- Forwarded message ----------
> From: Jim Jagielski <ji...@apache.org>
> Date: Wed, Nov 23, 2016 at 6:10 AM
> Subject: JSON License and Apache Projects
> To: ASF Board <bo...@apache.org>
> (forwarded from legal-discuss@)
> As some of you may know, recently the JSON License has been
> moved to Category X (https://www.apache.org/legal/resolved#category-x).
> I understand that this has impacted some projects, especially
> those in the midst of doing a release. I also understand that
> up until now, really, there has been no real "outcry" over our
> usage of it, especially from end-users and other consumers of
> our projects which use it.
> As compelling as that is, the fact is that the JSON license
> itself is not OSI approved and is therefore not, by definition,
> an "Open Source license" and, as such, cannot be considered as
> one which is acceptable as related to categories.
> Therefore, w/ my VP Legal hat on, I am making the following
> statements:
> o No new project, sub-project or codebase, which has not
>    used JSON licensed jars (or similar), are allowed to use
>    them. In other words, if you haven't been using them, you
>    aren't allowed to start. It is Cat-X.
> o If you have been using it, and have done so in a *release*,
>    AND there has been NO pushback from your community/eco-system,
>    you have a temporary exclusion from the Cat-X classification thru
>    April 30, 2017. At that point in time, ANY and ALL usage
>    of these JSON licensed artifacts are DISALLOWED. You must
>    either find a suitably licensed replacement, or do without.
>    There will be NO exceptions.
> o Any situation not covered by the above is an implicit
>    DISALLOWAL of usage.
> Also please note that in the 2nd situation (where a temporary
> exclusion has been granted), you MUST ensure that NOTICE explicitly
> notifies the end-user that a JSON licensed artifact exists. They
> may not be aware of it up to now, and that MUST be addressed.
> If there are any questions, please ask on the legal-discuss@a.o
> list.
> --
> Jim Jagielski
> VP Legal Affairs
> {noformat}
> I see it in the pom.xml: https://raw.githubusercontent.com/apache/incubator-trafficcontrol/93bb2b9bcf572ee32fd21891ab3bbd891211d55f/traffic_router/core/pom.xml



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)