You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wink.apache.org by Luciano Resende <lu...@gmail.com> on 2016/11/25 18:17:50 UTC
JSON License and Side-Effects to WInk
Please see the e-mail below about JSON License which is also archived at:
https://www.mail-archive.com/general@incubator.apache.org/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 <te...@gmail.com>
Date: Wed, Nov 23, 2016 at 5:10 PM
Subject: Fwd: JSON License and Apache Projects
To: "general@incubator.apache.org" <ge...@incubator.apache.org>
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/
Re: JSON License and Side-Effects to WInk
Posted by Luciano Resende <lu...@gmail.com>.
I was thinking Jackson directly, to be on the safe side.... but open to
other suggestions...
I was looking at the scope of the changes, and it seems that there are
various tests and then json provider in particular json utils.... an easy
way is to see all specific places is to just remove de dependencies from
the pom and see all failures.
Anyway, I will wait for you assessment and feel free to use this thread for
related discussions.
On Fri, Nov 25, 2016 at 10:24 AM Andrii Berezovskyi <an...@kth.se> wrote:
> Hello Luciano,
>
> I might be able to look into this next week(end) but not sure what is the
> scope of the dependence of Wink on json-java?
>
> Do you think we shall start with
> https://mvnrepository.com/artifact/com.tdunning/json/1.1? Or you thought
> of immediately switching to Jackson or like?
>
>
> – Andrew
>
> On 25 Nov 2016, at 19:17, Luciano Resende <luckbr1975@gmail.com<mailto:
> luckbr1975@gmail.com>> wrote:
>
> Please see the e-mail below about JSON License which is also archived at:
> https://www.mail-archive.com/general@incubator.apache.org/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 <te...@gmail.com>
> Date: Wed, Nov 23, 2016 at 5:10 PM
> Subject: Fwd: JSON License and Apache Projects
> To: "general@incubator.apache.org" <ge...@incubator.apache.org>
>
>
> 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/
>
> --
Sent from my Mobile device
Re: JSON License and Side-Effects to WInk
Posted by Andrii Berezovskyi <an...@kth.se>.
Hello Luciano,
I might be able to look into this next week(end) but not sure what is the scope of the dependence of Wink on json-java?
Do you think we shall start with https://mvnrepository.com/artifact/com.tdunning/json/1.1? Or you thought of immediately switching to Jackson or like?
– Andrew
On 25 Nov 2016, at 19:17, Luciano Resende <lu...@gmail.com>> wrote:
Please see the e-mail below about JSON License which is also archived at:
https://www.mail-archive.com/general@incubator.apache.org/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 <te...@gmail.com>
Date: Wed, Nov 23, 2016 at 5:10 PM
Subject: Fwd: JSON License and Apache Projects
To: "general@incubator.apache.org" <ge...@incubator.apache.org>
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/