You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Ted Dunning <te...@gmail.com> on 2016/11/24 01:10:06 UTC
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
Re: Fwd: JSON License and Apache Projects
Posted by Ate Douma <at...@douma.nu>.
On 2016-11-24 16:01, Emilian Bold wrote:
> NetBeans releases use JSON Simple in libs.json_simple which is Apache 2.0.
>
> The repository does have a module, lib.wag (Zembly Web API Gateway
> Libraries), with a dependency on json.org.jar but I don't believe we
> distribute this module...
Note that the ruling is that we cannot even allow just having a dependency
on the json.org library.
>
>
>
> --emi
>
> On Thu, Nov 24, 2016 at 4:12 PM, Ate Douma <at...@douma.nu> wrote:
>
>> FYI
>>
>> I've no clue if this might impact Apache NetBeans but if the json.org
>> library
>> is in use (directly or transitively) somehow in NetBeans, that then will
>> have
>> to be removed and replaced with something else.
>>
>> There is more discussion ongoing on alternatives and solutions on
>> general@incubator.apache.org as well as on legal-discuss@apache.org.
>>
>> Ate
>>
>>
>> -------- Forwarded Message --------
>> Subject: Fwd: JSON License and Apache Projects
>> Date: Wed, 23 Nov 2016 17:10:06 -0800
>> From: Ted Dunning <te...@gmail.com>
>> Reply-To: general@incubator.apache.org
>> 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.
>>
>>
>> ---------- 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
>>
>>
>
Re: Fwd: JSON License and Apache Projects
Posted by Emilian Bold <em...@gmail.com>.
NetBeans releases use JSON Simple in libs.json_simple which is Apache 2.0.
The repository does have a module, lib.wag (Zembly Web API Gateway
Libraries), with a dependency on json.org.jar but I don't believe we
distribute this module...
--emi
On Thu, Nov 24, 2016 at 4:12 PM, Ate Douma <at...@douma.nu> wrote:
> FYI
>
> I've no clue if this might impact Apache NetBeans but if the json.org
> library
> is in use (directly or transitively) somehow in NetBeans, that then will
> have
> to be removed and replaced with something else.
>
> There is more discussion ongoing on alternatives and solutions on
> general@incubator.apache.org as well as on legal-discuss@apache.org.
>
> Ate
>
>
> -------- Forwarded Message --------
> Subject: Fwd: JSON License and Apache Projects
> Date: Wed, 23 Nov 2016 17:10:06 -0800
> From: Ted Dunning <te...@gmail.com>
> Reply-To: general@incubator.apache.org
> 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.
>
>
> ---------- 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
>
>
Fwd: Fwd: JSON License and Apache Projects
Posted by Ate Douma <at...@douma.nu>.
FYI
I've no clue if this might impact Apache NetBeans but if the json.org library
is in use (directly or transitively) somehow in NetBeans, that then will have
to be removed and replaced with something else.
There is more discussion ongoing on alternatives and solutions on
general@incubator.apache.org as well as on legal-discuss@apache.org.
Ate
-------- Forwarded Message --------
Subject: Fwd: JSON License and Apache Projects
Date: Wed, 23 Nov 2016 17:10:06 -0800
From: Ted Dunning <te...@gmail.com>
Reply-To: general@incubator.apache.org
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.
---------- 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
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
>>>>
>>>>
>>>
Fwd: JSON License and Apache Projects
Posted by William Markito Oliveira <wi...@gmail.com>.
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 Vlad Rozov <v....@datatorrent.com>.
There are few other dependencies on JSON libraries in Malhar, but all of
them seem to be under Apache 2.0 license.
As we currently don't whitelist transitive dependencies (I have work in
progress for the core), it will be good to have org.json dependency
check added to the pom similar to what we do to check hadoop transitive
dependency in archetype pom. This will prevent accidental usage of
org.json in the future.
Thank you,
Vlad
On 11/28/16 17:15, amol kekre wrote:
> Chinmay,
> You can do the honor of responding to them so that they know we acted on
> their request.
>
> Thks
> Amol
>
>
> On Mon, Nov 28, 2016 at 1:04 PM, David Yan <da...@datatorrent.com> wrote:
>
>> As far as I know, we don't use anything from json.org directly. We use the
>> json library from jettison:
>> https://mvnrepository.com/artifact/org.codehaus.jettison/jettison.
>> From the dependency tree in apex-core, I don't see anything that says
>> json.org.
>>
>> David
>>
>> On Fri, Nov 25, 2016 at 10:22 AM, Amol Kekre <am...@datatorrent.com> wrote:
>>
>>> Chinmay
>>> +1, Do you want to drive :)
>>>
>>> Thks
>>> Amol
>>>
>>> On Thu, Nov 24, 2016 at 10:02 PM, Chinmay Kolhatkar <ch...@apache.org>
>>> wrote:
>>>
>>>> Yes... That's the mail.. There are couple if related conversations can
>> be
>>>> seen here too:
>>>> https://lists.apache.org/list.html?legal-discuss@apache.org
>>>>
>>>> I suggest we take a look at it and do the needful from our end too.
>>>>
>>>> -Chinmay.
>>>>
>>>>
>>>> On Fri, Nov 25, 2016 at 10:15 AM, Amol Kekre <am...@datatorrent.com>
>>> wrote:
>>>>> Chinmay,
>>>>> Is this the thread you were looking for?
>>>>>
>>>>> Thks
>>>>> Amol
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Ted Dunning <te...@gmail.com>
>>>>> Date: Thu, Nov 24, 2016 at 2:28 PM
>>>>> Subject: Re: JSON License and Apache Projects
>>>>> To: "general@incubator.apache.org" <ge...@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 <
>>> blackdrag@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 <
>>> ted.dunning@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 amol kekre <am...@gmail.com>.
Chinmay,
You can do the honor of responding to them so that they know we acted on
their request.
Thks
Amol
On Mon, Nov 28, 2016 at 1:04 PM, David Yan <da...@datatorrent.com> wrote:
> As far as I know, we don't use anything from json.org directly. We use the
> json library from jettison:
> https://mvnrepository.com/artifact/org.codehaus.jettison/jettison.
> From the dependency tree in apex-core, I don't see anything that says
> json.org.
>
> David
>
> On Fri, Nov 25, 2016 at 10:22 AM, Amol Kekre <am...@datatorrent.com> wrote:
>
> > Chinmay
> > +1, Do you want to drive :)
> >
> > Thks
> > Amol
> >
> > On Thu, Nov 24, 2016 at 10:02 PM, Chinmay Kolhatkar <ch...@apache.org>
> > wrote:
> >
> > > Yes... That's the mail.. There are couple if related conversations can
> be
> > > seen here too:
> > > https://lists.apache.org/list.html?legal-discuss@apache.org
> > >
> > > I suggest we take a look at it and do the needful from our end too.
> > >
> > > -Chinmay.
> > >
> > >
> > > On Fri, Nov 25, 2016 at 10:15 AM, Amol Kekre <am...@datatorrent.com>
> > wrote:
> > >
> > > > Chinmay,
> > > > Is this the thread you were looking for?
> > > >
> > > > Thks
> > > > Amol
> > > >
> > > > ---------- Forwarded message ----------
> > > > From: Ted Dunning <te...@gmail.com>
> > > > Date: Thu, Nov 24, 2016 at 2:28 PM
> > > > Subject: Re: JSON License and Apache Projects
> > > > To: "general@incubator.apache.org" <ge...@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 <
> > blackdrag@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 <
> > ted.dunning@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 David Yan <da...@datatorrent.com>.
As far as I know, we don't use anything from json.org directly. We use the
json library from jettison:
https://mvnrepository.com/artifact/org.codehaus.jettison/jettison.
From the dependency tree in apex-core, I don't see anything that says
json.org.
David
On Fri, Nov 25, 2016 at 10:22 AM, Amol Kekre <am...@datatorrent.com> wrote:
> Chinmay
> +1, Do you want to drive :)
>
> Thks
> Amol
>
> On Thu, Nov 24, 2016 at 10:02 PM, Chinmay Kolhatkar <ch...@apache.org>
> wrote:
>
> > Yes... That's the mail.. There are couple if related conversations can be
> > seen here too:
> > https://lists.apache.org/list.html?legal-discuss@apache.org
> >
> > I suggest we take a look at it and do the needful from our end too.
> >
> > -Chinmay.
> >
> >
> > On Fri, Nov 25, 2016 at 10:15 AM, Amol Kekre <am...@datatorrent.com>
> wrote:
> >
> > > Chinmay,
> > > Is this the thread you were looking for?
> > >
> > > Thks
> > > Amol
> > >
> > > ---------- Forwarded message ----------
> > > From: Ted Dunning <te...@gmail.com>
> > > Date: Thu, Nov 24, 2016 at 2:28 PM
> > > Subject: Re: JSON License and Apache Projects
> > > To: "general@incubator.apache.org" <ge...@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 <
> blackdrag@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 <
> ted.dunning@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 Amol Kekre <am...@datatorrent.com>.
Chinmay
+1, Do you want to drive :)
Thks
Amol
On Thu, Nov 24, 2016 at 10:02 PM, Chinmay Kolhatkar <ch...@apache.org>
wrote:
> Yes... That's the mail.. There are couple if related conversations can be
> seen here too:
> https://lists.apache.org/list.html?legal-discuss@apache.org
>
> I suggest we take a look at it and do the needful from our end too.
>
> -Chinmay.
>
>
> On Fri, Nov 25, 2016 at 10:15 AM, Amol Kekre <am...@datatorrent.com> wrote:
>
> > Chinmay,
> > Is this the thread you were looking for?
> >
> > Thks
> > Amol
> >
> > ---------- Forwarded message ----------
> > From: Ted Dunning <te...@gmail.com>
> > Date: Thu, Nov 24, 2016 at 2:28 PM
> > Subject: Re: JSON License and Apache Projects
> > To: "general@incubator.apache.org" <ge...@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 Chinmay Kolhatkar <ch...@apache.org>.
Yes... That's the mail.. There are couple if related conversations can be
seen here too:
https://lists.apache.org/list.html?legal-discuss@apache.org
I suggest we take a look at it and do the needful from our end too.
-Chinmay.
On Fri, Nov 25, 2016 at 10:15 AM, Amol Kekre <am...@datatorrent.com> wrote:
> Chinmay,
> Is this the thread you were looking for?
>
> Thks
> Amol
>
> ---------- Forwarded message ----------
> From: Ted Dunning <te...@gmail.com>
> Date: Thu, Nov 24, 2016 at 2:28 PM
> Subject: Re: JSON License and Apache Projects
> To: "general@incubator.apache.org" <ge...@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
> > >
> > >
> >
>
Fwd: JSON License and Apache Projects
Posted by Amol Kekre <am...@datatorrent.com>.
Chinmay,
Is this the thread you were looking for?
Thks
Amol
---------- Forwarded message ----------
From: Ted Dunning <te...@gmail.com>
Date: Thu, Nov 24, 2016 at 2:28 PM
Subject: Re: JSON License and Apache Projects
To: "general@incubator.apache.org" <ge...@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 Ted Dunning <te...@gmail.com>.
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 "John D. Ament" <jo...@apache.org>.
Understood. There's a discussion on legal-discuss you may want to join in
on. The current ruling is that you would have until April 30 2017 to
remove the dependency.
John
On Thu, Nov 24, 2016 at 9:19 AM Karl Wright <da...@gmail.com> wrote:
> The Apache ManifoldCF project got an official Legal ruling on the json
> license and accepted it many years ago.
>
> Thanks,
> Karl
>
>
>
> On Thu, Nov 24, 2016 at 7:11 AM, Guillaume Laforge <gl...@gmail.com>
> wrote:
>
> > And Apache Groovy also has some great JSON support as well, with a super
> > fast parser, and serializer as well.
> > So there's choice at Apache regarding JSON :-D
> >
> > On Thu, Nov 24, 2016 at 12:56 PM, Hendrik Dev <he...@gmail.com>
> > wrote:
> >
> > > and of course there is also Apache Johnzon ;-)
> > > http://johnzon.apache.org/
> > >
> > > On Thu, Nov 24, 2016 at 10: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 <
> blackdrag@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 <ted.dunning@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
> > > >>
> > > >>
> > >
> > >
> > >
> > > --
> > > Hendrik Saly (salyh, hendrikdev22)
> > > @hendrikdev22
> > > PGP: 0x22D7F6EC
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Guillaume Laforge
> > Apache Groovy committer & PMC Vice-President
> > Developer Advocate @ Google Cloud Platform
> >
> > Blog: http://glaforge.appspot.com/
> > Social: @glaforge <http://twitter.com/glaforge> / Google+
> > <https://plus.google.com/u/0/114130972232398734985/posts>
> >
>
Re: JSON License and Apache Projects
Posted by Karl Wright <da...@gmail.com>.
The Apache ManifoldCF project got an official Legal ruling on the json
license and accepted it many years ago.
Thanks,
Karl
On Thu, Nov 24, 2016 at 7:11 AM, Guillaume Laforge <gl...@gmail.com>
wrote:
> And Apache Groovy also has some great JSON support as well, with a super
> fast parser, and serializer as well.
> So there's choice at Apache regarding JSON :-D
>
> On Thu, Nov 24, 2016 at 12:56 PM, Hendrik Dev <he...@gmail.com>
> wrote:
>
> > and of course there is also Apache Johnzon ;-)
> > http://johnzon.apache.org/
> >
> > On Thu, Nov 24, 2016 at 10: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
> > >>
> > >>
> >
> >
> >
> > --
> > Hendrik Saly (salyh, hendrikdev22)
> > @hendrikdev22
> > PGP: 0x22D7F6EC
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
Re: JSON License and Apache Projects
Posted by Guillaume Laforge <gl...@gmail.com>.
And Apache Groovy also has some great JSON support as well, with a super
fast parser, and serializer as well.
So there's choice at Apache regarding JSON :-D
On Thu, Nov 24, 2016 at 12:56 PM, Hendrik Dev <he...@gmail.com>
wrote:
> and of course there is also Apache Johnzon ;-)
> http://johnzon.apache.org/
>
> On Thu, Nov 24, 2016 at 10: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
> >>
> >>
>
>
>
> --
> Hendrik Saly (salyh, hendrikdev22)
> @hendrikdev22
> PGP: 0x22D7F6EC
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: JSON License and Apache Projects
Posted by Hendrik Dev <he...@gmail.com>.
and of course there is also Apache Johnzon ;-)
http://johnzon.apache.org/
On Thu, Nov 24, 2016 at 10: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
>>
>>
--
Hendrik Saly (salyh, hendrikdev22)
@hendrikdev22
PGP: 0x22D7F6EC
---------------------------------------------------------------------
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 Stephan Ewen <se...@apache.org>.
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 Jochen Theodorou <bl...@gmx.org>.
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 James Carman <ja...@carmanconsulting.com>.
I had never heard of that project. I am going to have to check that out!
All of my projects use GSON these days, but I'd rather use an ASF project
if possible. Thanks for the plug!
On Wed, Nov 23, 2016 at 8:16 PM James Bognar <ja...@salesforce.com>
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
> >
>
Re: JSON License and Apache Projects
Posted by James Bognar <ja...@salesforce.com>.
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
>
Re: Fwd: JSON License and Apache Projects
Posted by David Radley <da...@uk.ibm.com>.
Hi ,
It does seem like we should move away from using this json library. Of the
options, I suggest we use Jackson,
all the best, David.
From: Hemanth Yamijala <yh...@gmail.com>
To: dev@atlas.incubator.apache.org
Date: 25/11/2016 09:13
Subject: Fwd: JSON License and Apache Projects
Atlas-dev,
Is this something to worry about? I see references to
o.json.JSONObject in HiveHook. And we seem to be pulling it in via
Hive dependencies.
Thanks
hemanth
---------- Forwarded message ----------
From: Ted Dunning <te...@gmail.com>
Date: Thu, Nov 24, 2016 at 6:40 AM
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.
---------- 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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Fwd: JSON License and Apache Projects
Posted by Hemanth Yamijala <yh...@gmail.com>.
Atlas-dev,
Is this something to worry about? I see references to
o.json.JSONObject in HiveHook. And we seem to be pulling it in via
Hive dependencies.
Thanks
hemanth
---------- Forwarded message ----------
From: Ted Dunning <te...@gmail.com>
Date: Thu, Nov 24, 2016 at 6:40 AM
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.
---------- 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