You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by William Markito Oliveira <wi...@gmail.com> on 2016/11/25 00:38:50 UTC
Fwd: JSON License and Apache Projects
Interesting thread about json parsing libraries and licensing.
Sent from my iPhone
Begin forwarded message:
> From: Ted Dunning <te...@gmail.com>
> Date: November 24, 2016 at 2:28:47 PM PST
> To: "general@incubator.apache.org" <ge...@incubator.apache.org>
> Subject: Re: JSON License and Apache Projects
> Reply-To: general@incubator.apache.org
>
> Stephan,
>
> What you suggest should work (if you add another dependency to provide the
> needed classes).
>
> You have to be careful, however, because your consumers may expect to get
> the full json.org API.
>
> I would suggest that exclusions like this should only be used while your
> direct dependency still has the dependency on json.org. When they fix it,
> you can drop the exclusion and all will be good.
>
>
>
>> On Thu, Nov 24, 2016 at 2:21 AM, Stephan Ewen <se...@apache.org> wrote:
>>
>> Just to be on the safe side:
>>
>> If project X depends on another project Y that uses json.org (and thus
>> project X has json.org as a transitive dependency) is it sufficient to
>> exclude the transitive json.org dependency in the reference to project Y?
>>
>> Something like that:
>>
>> <dependency>
>> <groupId>org.apache.hive.hcatalog</groupId>
>> <artifactId>hcatalog-core</artifactId>
>> <version>0.12.0</version>
>> <exclusions>
>> <exclusion>
>> <groupId>org.json</groupId>
>> <artifactId>json</artifactId>
>> </exclusion>
>> </exclusions>
>> </dependency>
>>
>> Thanks,
>> Stephan
>>
>>
>> On Thu, Nov 24, 2016 at 10:00 AM, Jochen Theodorou <bl...@gmx.org>
>> wrote:
>>
>>> is that library able to deal with the jdk9 module system?
>>>
>>>
>>>> On 24.11.2016 02:16, James Bognar wrote:
>>>>
>>>> Shameless plug for Apache Juneau that has a cleanroom implementation of
>> a
>>>> JSON serializer and parser in context of a common serialization API that
>>>> includes a variety of serialization languages for POJOs.
>>>>
>>>> On Wed, Nov 23, 2016 at 8:10 PM Ted Dunning <te...@gmail.com>
>>>> wrote:
>>>>
>>>> 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
>>>>>
>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
Re: JSON License and Apache Projects
Posted by Anthony Baker <ab...@pivotal.io>.
Thanks William!
I filed GEODE-2142 for tracking the legal requirement for remove JSON.
Anthony
> On Nov 24, 2016, at 4:38 PM, William Markito Oliveira <wi...@gmail.com> wrote:
>
> Interesting thread about json parsing libraries and licensing.
>
> Sent from my iPhone
>
> Begin forwarded message:
>
>> From: Ted Dunning <te...@gmail.com>
>> Date: November 24, 2016 at 2:28:47 PM PST
>> To: "general@incubator.apache.org" <ge...@incubator.apache.org>
>> Subject: Re: JSON License and Apache Projects
>> Reply-To: general@incubator.apache.org
>>
>> Stephan,
>>
>> What you suggest should work (if you add another dependency to provide the
>> needed classes).
>>
>> You have to be careful, however, because your consumers may expect to get
>> the full json.org API.
>>
>> I would suggest that exclusions like this should only be used while your
>> direct dependency still has the dependency on json.org. When they fix it,
>> you can drop the exclusion and all will be good.
>>
>>
>>
>>> On Thu, Nov 24, 2016 at 2:21 AM, Stephan Ewen <se...@apache.org> wrote:
>>>
>>> Just to be on the safe side:
>>>
>>> If project X depends on another project Y that uses json.org (and thus
>>> project X has json.org as a transitive dependency) is it sufficient to
>>> exclude the transitive json.org dependency in the reference to project Y?
>>>
>>> Something like that:
>>>
>>> <dependency>
>>> <groupId>org.apache.hive.hcatalog</groupId>
>>> <artifactId>hcatalog-core</artifactId>
>>> <version>0.12.0</version>
>>> <exclusions>
>>> <exclusion>
>>> <groupId>org.json</groupId>
>>> <artifactId>json</artifactId>
>>> </exclusion>
>>> </exclusions>
>>> </dependency>
>>>
>>> Thanks,
>>> Stephan
>>>
>>>
>>> On Thu, Nov 24, 2016 at 10:00 AM, Jochen Theodorou <bl...@gmx.org>
>>> wrote:
>>>
>>>> is that library able to deal with the jdk9 module system?
>>>>
>>>>
>>>>> On 24.11.2016 02:16, James Bognar wrote:
>>>>>
>>>>> Shameless plug for Apache Juneau that has a cleanroom implementation of
>>> a
>>>>> JSON serializer and parser in context of a common serialization API that
>>>>> includes a variety of serialization languages for POJOs.
>>>>>
>>>>> On Wed, Nov 23, 2016 at 8:10 PM Ted Dunning <te...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>>
>>>