You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Alan Gates <al...@gmail.com> on 2016/11/16 13:22:58 UTC
A grace period for getting rid of JSON license jars
The recent moving of the JSON license to category X means that a number of projects cannot do any releases until this is fixed. I know this includes Hadoop, Hive, and Spark, and probably a number of others since hadoop-common (which many project use) depends on jars from json.org. The Hive team in particular is trying to get a maintenance release out which is blocked by this.
I talked with Jim Jagielski briefly today and he suggested that perhaps we could have a grandfather clause on this so that projects that already are using it could continue to, at least for a period of time, so that they can continue to produce releases rather than needing to spend unplanned time switching out this library[1].
To be specific I propose we give projects already using this license 6 months to clean this up in which they can continue to release with dependencies on the JSON license.
Alan.
1. The amount of time to fix this will not be trivial. Based on a little bit of digging I’ve done the alternatives are not 100% identical in their behavior which will mean projects will need to thoroughly test the replacements and change their code to deal with the differences.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Alex Harui <ah...@adobe.com>.
From the peanut gallery: did you guys rule out "next release after Dec 31, 2016"? Or is it the same? I'm just wondering if there are projects that don't release very often that are going be under pressure. What happens if you don't hit June 1?
-Alex
From: Henri Yandell <ba...@apache.org>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Wednesday, November 16, 2016 at 8:35 AM
To: ASF Legal Discuss <le...@apache.org>>
Subject: Re: A grace period for getting rid of JSON license jars
+1, makes sense.
Rounding up, that would be a 'Move off of the Java JSON parser by June 1st 2017'.
On Wed, Nov 16, 2016 at 5:22 AM, Alan Gates <al...@gmail.com>> wrote:
The recent moving of the JSON license to category X means that a number of projects cannot do any releases until this is fixed. I know this includes Hadoop, Hive, and Spark, and probably a number of others since hadoop-common (which many project use) depends on jars from json.org<http://json.org>. The Hive team in particular is trying to get a maintenance release out which is blocked by this.
I talked with Jim Jagielski briefly today and he suggested that perhaps we could have a grandfather clause on this so that projects that already are using it could continue to, at least for a period of time, so that they can continue to produce releases rather than needing to spend unplanned time switching out this library[1].
To be specific I propose we give projects already using this license 6 months to clean this up in which they can continue to release with dependencies on the JSON license.
Alan.
1. The amount of time to fix this will not be trivial. Based on a little bit of digging I’ve done the alternatives are not 100% identical in their behavior which will mean projects will need to thoroughly test the replacements and change their code to deal with the differences.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<ma...@apache.org>
For additional commands, e-mail: legal-discuss-help@apache.org<ma...@apache.org>
Re: A grace period for getting rid of JSON license jars
Posted by Henri Yandell <ba...@apache.org>.
+1, makes sense.
Rounding up, that would be a 'Move off of the Java JSON parser by June 1st
2017'.
On Wed, Nov 16, 2016 at 5:22 AM, Alan Gates <al...@gmail.com> wrote:
> The recent moving of the JSON license to category X means that a number of
> projects cannot do any releases until this is fixed. I know this includes
> Hadoop, Hive, and Spark, and probably a number of others since
> hadoop-common (which many project use) depends on jars from json.org.
> The Hive team in particular is trying to get a maintenance release out
> which is blocked by this.
>
> I talked with Jim Jagielski briefly today and he suggested that perhaps we
> could have a grandfather clause on this so that projects that already are
> using it could continue to, at least for a period of time, so that they can
> continue to produce releases rather than needing to spend unplanned time
> switching out this library[1].
>
> To be specific I propose we give projects already using this license 6
> months to clean this up in which they can continue to release with
> dependencies on the JSON license.
>
> Alan.
>
> 1. The amount of time to fix this will not be trivial. Based on a little
> bit of digging I’ve done the alternatives are not 100% identical in their
> behavior which will mean projects will need to thoroughly test the
> replacements and change their code to deal with the differences.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: A grace period for getting rid of JSON license jars
Posted by Andrew Wang <an...@cloudera.com>.
On Fri, Nov 18, 2016 at 4:09 PM, sebb <se...@gmail.com> wrote:
> On 19 November 2016 at 00:02, Andrew Wang <an...@cloudera.com>
> wrote:
> > In Hadoop, we have the issue of third party libraries that have a bundled
> > version of json.org. We can't simply swap it out.
>
> If those libraries are bundled with Hadoop, but are optional, then one
> solution may be to stop bundling those libraries.
>
> You're welcome to chime in on the JIRA:
https://issues.apache.org/jira/browse/HADOOP-13050
This is a dependency on the AWS SDK. It's not optional, and upgrading it to
a version that doesn't have json.org has compatibility implications.
An overall point is that sunsetting json.org can have compatibility
implications for Apache projects. This affects user expectations and
project guarantees around end-of-life for a release line.
I'll add that typical EOLs for enterprise software is measured in multiple
years. If I had my druthers, we'd grandfather in existing release lines
where bumping json.org would affect compatibility and thus EOL
expectations. Failing that, giving us at least until June would be
significant.
> >
> > On Fri, Nov 18, 2016 at 3:41 PM, Ted Dunning <te...@gmail.com>
> wrote:
> >>
> >>
> >> Uhh...
> >>
> >> I was hoping that we have a MUCH sooner deadline than June 1st if we are
> >> saying "next release after". The June date is more appropriate if the
> >> language is "must have clean release before".
> >>
> >> In any case, I now have put an artifact on maven central that should
> allow
> >> most of these projects to simply change a maven pom by replacing the
> >> dependency. The artifact isn't in the mvncentral search engine yet, but
> it
> >> is in central.
> >>
> >> This is the dependency you should need:
> >>
> >> <dependency>
> >> <groupId>com.tdunning</groupId>
> >> <artifactId>json</artifactId>
> >> <version>1.0</version>
> >> </dependency>
> >>
> >>
> >>
> >>
> >> On Fri, Nov 18, 2016 at 2:33 PM, Alan Gates <al...@gmail.com>
> wrote:
> >>>
> >>> I am new to the legal discuss list, so I’m not sure how we declare
> >>> consensus here. I agree with Ted’s clarification that this applies to
> the
> >>> next release after the June 1 2017 deadline. Thus my reformulated
> proposal
> >>> would look like:
> >>> “Projects already using the JSON license are allowed to continue making
> >>> releases without modification until June 1 2017. Any releases made
> after
> >>> that date must not have dependencies on code released under the JSON
> >>> license.”
> >>>
> >>> Alan.
> >>>
> >>> > On Nov 18, 2016, at 20:30, Joe Witt <jo...@gmail.com> wrote:
> >>> >
> >>> > Hello,
> >>> >
> >>> > Has a decision been reached by any chance? We're looking to kick off
> >>> > the next Apache NiFi release and while we've done the work to
> >>> > eliminate the use of this library it required us to reduce user
> >>> > convenience in one case that we'd love to undo and expect the grace
> >>> > period will resolve.
> >>> >
> >>> > Thanks
> >>> > Joe
> >>> >
> >>> > On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning <te...@gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> I like this too, but would rather have the "next release after
> >>> >> xxx/yyy" form
> >>> >> of deadline.
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <ji...@jagunet.com>
> >>> >> wrote:
> >>> >>>
> >>> >>> The more I think about it, the more this makes sense. Basically
> >>> >>> we refuse the use of it for any new projects/efforts, but those
> >>> >>> projects which are currently using it, with no issues, should
> >>> >>> be allowed to continue using them, grandfathered, at least for
> >>> >>> a time being.
> >>> >>>
> >>> >>> Let me mull this over some more and make an official determination/
> >>> >>> ruling. :)
> >>> >>>
> >>> >>>> On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com>
> >>> >>>> wrote:
> >>> >>>>
> >>> >>>> The recent moving of the JSON license to category X means that a
> >>> >>>> number
> >>> >>>> of projects cannot do any releases until this is fixed. I know
> this
> >>> >>>> includes Hadoop, Hive, and Spark, and probably a number of others
> >>> >>>> since
> >>> >>>> hadoop-common (which many project use) depends on jars from
> >>> >>>> json.org. The
> >>> >>>> Hive team in particular is trying to get a maintenance release out
> >>> >>>> which is
> >>> >>>> blocked by this.
> >>> >>>>
> >>> >>>> I talked with Jim Jagielski briefly today and he suggested that
> >>> >>>> perhaps
> >>> >>>> we could have a grandfather clause on this so that projects that
> >>> >>>> already are
> >>> >>>> using it could continue to, at least for a period of time, so that
> >>> >>>> they can
> >>> >>>> continue to produce releases rather than needing to spend
> unplanned
> >>> >>>> time
> >>> >>>> switching out this library[1].
> >>> >>>>
> >>> >>>> To be specific I propose we give projects already using this
> license
> >>> >>>> 6
> >>> >>>> months to clean this up in which they can continue to release with
> >>> >>>> dependencies on the JSON license.
> >>> >>>>
> >>> >>>> Alan.
> >>> >>>>
> >>> >>>> 1. The amount of time to fix this will not be trivial. Based on a
> >>> >>>> little bit of digging I’ve done the alternatives are not 100%
> >>> >>>> identical in
> >>> >>>> their behavior which will mean projects will need to thoroughly
> test
> >>> >>>> the
> >>> >>>> replacements and change their code to deal with the differences.
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> ------------------------------------------------------------
> ---------
> >>> >>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >>> >>>> For additional commands, e-mail: legal-discuss-help@apache.org
> >>> >>>>
> >>> >>>
> >>> >>>
> >>> >>> ------------------------------------------------------------
> ---------
> >>> >>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >>> >>> For additional commands, e-mail: legal-discuss-help@apache.org
> >>> >>>
> >>> >>
> >>> >
> >>> > ------------------------------------------------------------
> ---------
> >>> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >>> > For additional commands, e-mail: legal-discuss-help@apache.org
> >>> >
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >>> For additional commands, e-mail: legal-discuss-help@apache.org
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: A grace period for getting rid of JSON license jars
Posted by sebb <se...@gmail.com>.
On 19 November 2016 at 00:02, Andrew Wang <an...@cloudera.com> wrote:
> In Hadoop, we have the issue of third party libraries that have a bundled
> version of json.org. We can't simply swap it out.
If those libraries are bundled with Hadoop, but are optional, then one
solution may be to stop bundling those libraries.
>
> On Fri, Nov 18, 2016 at 3:41 PM, Ted Dunning <te...@gmail.com> wrote:
>>
>>
>> Uhh...
>>
>> I was hoping that we have a MUCH sooner deadline than June 1st if we are
>> saying "next release after". The June date is more appropriate if the
>> language is "must have clean release before".
>>
>> In any case, I now have put an artifact on maven central that should allow
>> most of these projects to simply change a maven pom by replacing the
>> dependency. The artifact isn't in the mvncentral search engine yet, but it
>> is in central.
>>
>> This is the dependency you should need:
>>
>> <dependency>
>> <groupId>com.tdunning</groupId>
>> <artifactId>json</artifactId>
>> <version>1.0</version>
>> </dependency>
>>
>>
>>
>>
>> On Fri, Nov 18, 2016 at 2:33 PM, Alan Gates <al...@gmail.com> wrote:
>>>
>>> I am new to the legal discuss list, so I’m not sure how we declare
>>> consensus here. I agree with Ted’s clarification that this applies to the
>>> next release after the June 1 2017 deadline. Thus my reformulated proposal
>>> would look like:
>>> “Projects already using the JSON license are allowed to continue making
>>> releases without modification until June 1 2017. Any releases made after
>>> that date must not have dependencies on code released under the JSON
>>> license.”
>>>
>>> Alan.
>>>
>>> > On Nov 18, 2016, at 20:30, Joe Witt <jo...@gmail.com> wrote:
>>> >
>>> > Hello,
>>> >
>>> > Has a decision been reached by any chance? We're looking to kick off
>>> > the next Apache NiFi release and while we've done the work to
>>> > eliminate the use of this library it required us to reduce user
>>> > convenience in one case that we'd love to undo and expect the grace
>>> > period will resolve.
>>> >
>>> > Thanks
>>> > Joe
>>> >
>>> > On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning <te...@gmail.com>
>>> > wrote:
>>> >>
>>> >> I like this too, but would rather have the "next release after
>>> >> xxx/yyy" form
>>> >> of deadline.
>>> >>
>>> >>
>>> >>
>>> >> On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <ji...@jagunet.com>
>>> >> wrote:
>>> >>>
>>> >>> The more I think about it, the more this makes sense. Basically
>>> >>> we refuse the use of it for any new projects/efforts, but those
>>> >>> projects which are currently using it, with no issues, should
>>> >>> be allowed to continue using them, grandfathered, at least for
>>> >>> a time being.
>>> >>>
>>> >>> Let me mull this over some more and make an official determination/
>>> >>> ruling. :)
>>> >>>
>>> >>>> On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com>
>>> >>>> wrote:
>>> >>>>
>>> >>>> The recent moving of the JSON license to category X means that a
>>> >>>> number
>>> >>>> of projects cannot do any releases until this is fixed. I know this
>>> >>>> includes Hadoop, Hive, and Spark, and probably a number of others
>>> >>>> since
>>> >>>> hadoop-common (which many project use) depends on jars from
>>> >>>> json.org. The
>>> >>>> Hive team in particular is trying to get a maintenance release out
>>> >>>> which is
>>> >>>> blocked by this.
>>> >>>>
>>> >>>> I talked with Jim Jagielski briefly today and he suggested that
>>> >>>> perhaps
>>> >>>> we could have a grandfather clause on this so that projects that
>>> >>>> already are
>>> >>>> using it could continue to, at least for a period of time, so that
>>> >>>> they can
>>> >>>> continue to produce releases rather than needing to spend unplanned
>>> >>>> time
>>> >>>> switching out this library[1].
>>> >>>>
>>> >>>> To be specific I propose we give projects already using this license
>>> >>>> 6
>>> >>>> months to clean this up in which they can continue to release with
>>> >>>> dependencies on the JSON license.
>>> >>>>
>>> >>>> Alan.
>>> >>>>
>>> >>>> 1. The amount of time to fix this will not be trivial. Based on a
>>> >>>> little bit of digging I’ve done the alternatives are not 100%
>>> >>>> identical in
>>> >>>> their behavior which will mean projects will need to thoroughly test
>>> >>>> the
>>> >>>> replacements and change their code to deal with the differences.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> ---------------------------------------------------------------------
>>> >>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> >>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>> >>>>
>>> >>>
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> >>> For additional commands, e-mail: legal-discuss-help@apache.org
>>> >>>
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> > For additional commands, e-mail: legal-discuss-help@apache.org
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Andrew Wang <an...@cloudera.com>.
In Hadoop, we have the issue of third party libraries that have a bundled
version of json.org. We can't simply swap it out.
On Fri, Nov 18, 2016 at 3:41 PM, Ted Dunning <te...@gmail.com> wrote:
>
> Uhh...
>
> I was hoping that we have a MUCH sooner deadline than June 1st if we are
> saying "next release after". The June date is more appropriate if the
> language is "must have clean release before".
>
> In any case, I now have put an artifact on maven central that should allow
> most of these projects to simply change a maven pom by replacing the
> dependency. The artifact isn't in the mvncentral search engine yet, but it
> is in central.
>
> This is the dependency you should need:
>
> <dependency>
> <groupId>com.tdunning</groupId>
> <artifactId>json</artifactId>
> <version>1.0</version>
> </dependency>
>
>
>
>
> On Fri, Nov 18, 2016 at 2:33 PM, Alan Gates <al...@gmail.com> wrote:
>
>> I am new to the legal discuss list, so I’m not sure how we declare
>> consensus here. I agree with Ted’s clarification that this applies to the
>> next release after the June 1 2017 deadline. Thus my reformulated proposal
>> would look like:
>> “Projects already using the JSON license are allowed to continue making
>> releases without modification until June 1 2017. Any releases made after
>> that date must not have dependencies on code released under the JSON
>> license.”
>>
>> Alan.
>>
>> > On Nov 18, 2016, at 20:30, Joe Witt <jo...@gmail.com> wrote:
>> >
>> > Hello,
>> >
>> > Has a decision been reached by any chance? We're looking to kick off
>> > the next Apache NiFi release and while we've done the work to
>> > eliminate the use of this library it required us to reduce user
>> > convenience in one case that we'd love to undo and expect the grace
>> > period will resolve.
>> >
>> > Thanks
>> > Joe
>> >
>> > On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning <te...@gmail.com>
>> wrote:
>> >>
>> >> I like this too, but would rather have the "next release after
>> xxx/yyy" form
>> >> of deadline.
>> >>
>> >>
>> >>
>> >> On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <ji...@jagunet.com>
>> wrote:
>> >>>
>> >>> The more I think about it, the more this makes sense. Basically
>> >>> we refuse the use of it for any new projects/efforts, but those
>> >>> projects which are currently using it, with no issues, should
>> >>> be allowed to continue using them, grandfathered, at least for
>> >>> a time being.
>> >>>
>> >>> Let me mull this over some more and make an official determination/
>> >>> ruling. :)
>> >>>
>> >>>> On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com>
>> wrote:
>> >>>>
>> >>>> The recent moving of the JSON license to category X means that a
>> number
>> >>>> of projects cannot do any releases until this is fixed. I know this
>> >>>> includes Hadoop, Hive, and Spark, and probably a number of others
>> since
>> >>>> hadoop-common (which many project use) depends on jars from json.org.
>> The
>> >>>> Hive team in particular is trying to get a maintenance release out
>> which is
>> >>>> blocked by this.
>> >>>>
>> >>>> I talked with Jim Jagielski briefly today and he suggested that
>> perhaps
>> >>>> we could have a grandfather clause on this so that projects that
>> already are
>> >>>> using it could continue to, at least for a period of time, so that
>> they can
>> >>>> continue to produce releases rather than needing to spend unplanned
>> time
>> >>>> switching out this library[1].
>> >>>>
>> >>>> To be specific I propose we give projects already using this license
>> 6
>> >>>> months to clean this up in which they can continue to release with
>> >>>> dependencies on the JSON license.
>> >>>>
>> >>>> Alan.
>> >>>>
>> >>>> 1. The amount of time to fix this will not be trivial. Based on a
>> >>>> little bit of digging I’ve done the alternatives are not 100%
>> identical in
>> >>>> their behavior which will mean projects will need to thoroughly test
>> the
>> >>>> replacements and change their code to deal with the differences.
>> >>>>
>> >>>>
>> >>>>
>> >>>> ------------------------------------------------------------
>> ---------
>> >>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >>>> For additional commands, e-mail: legal-discuss-help@apache.org
>> >>>>
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >>> For additional commands, e-mail: legal-discuss-help@apache.org
>> >>>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> > For additional commands, e-mail: legal-discuss-help@apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
On Sun, Nov 20, 2016 at 3:52 PM, Joe Witt <jo...@gmail.com> wrote:
> especially the twitter4j contribution which is certainly an above and
> beyond gesture.
My thought is that there are no "above and beyond gestures" in opensource.
Some days, you can contribute. Some days you can't.
Re: A grace period for getting rid of JSON license jars
Posted by Joe Witt <jo...@gmail.com>.
Ted
Many thanks to you for taking that on - especially the twitter4j
contribution which is certainly an above and beyond gesture.
Joe
On Nov 20, 2016 6:43 PM, "Ted Dunning" <te...@gmail.com> wrote:
>
> Alan, Joe, Andrew,
>
> I just pushed out version 1.1 of my clone. It has a few improvements based
> on experience changing twitter4j to be acceptable. (thanks for Simon
> Lessard on this).
>
> I have also sent a pull request to the twitter4j folks. I don't understand
> how to run their tests, so my pull request could be considered incomplete.
> It does compile.
>
> The changes in version 1.1 are not functional (changed JSONException to
> unchecked, added constructors to JSONTokener and JSONException).
>
> The new version should land on central shortly.
>
>
>
> On Sat, Nov 19, 2016 at 2:23 AM, Alan Gates <al...@gmail.com> wrote:
>
>> Excellent. Thank you, and thanks for the offer to help.
>>
>> Alan.
>>
>> Sent from my iPhone
>>
>> On Nov 19, 2016, at 11:04, Ted Dunning <te...@gmail.com> wrote:
>>
>>
>> On Sat, Nov 19, 2016 at 2:00 AM, Alan Gates <al...@gmail.com> wrote:
>>
>>> You did not answer the question of whether you're willing to go to dec
>>> 31 or not. As you're the only one disagreeing with the later date, if
>>> you agree to an earlier date I'd call that consensus.
>>>
>>> Can we please agree to a temporary date immediately so projects can
>>> release while we keep arguing? If you don't like my temporary date please
>>> suggest another.
>>>
>>
>> Yes.
>>
>> December 31st sounds like a good date to me. I would also encourage
>> projects that can do a clean release (if they release before then) to do so.
>>
>> I am willing to put in personal time to help make that possible.
>>
>>
>
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
Alan, Joe, Andrew,
I just pushed out version 1.1 of my clone. It has a few improvements based
on experience changing twitter4j to be acceptable. (thanks for Simon
Lessard on this).
I have also sent a pull request to the twitter4j folks. I don't understand
how to run their tests, so my pull request could be considered incomplete.
It does compile.
The changes in version 1.1 are not functional (changed JSONException to
unchecked, added constructors to JSONTokener and JSONException).
The new version should land on central shortly.
On Sat, Nov 19, 2016 at 2:23 AM, Alan Gates <al...@gmail.com> wrote:
> Excellent. Thank you, and thanks for the offer to help.
>
> Alan.
>
> Sent from my iPhone
>
> On Nov 19, 2016, at 11:04, Ted Dunning <te...@gmail.com> wrote:
>
>
> On Sat, Nov 19, 2016 at 2:00 AM, Alan Gates <al...@gmail.com> wrote:
>
>> You did not answer the question of whether you're willing to go to dec 31
>> or not. As you're the only one disagreeing with the later date, if you
>> agree to an earlier date I'd call that consensus.
>>
>> Can we please agree to a temporary date immediately so projects can
>> release while we keep arguing? If you don't like my temporary date please
>> suggest another.
>>
>
> Yes.
>
> December 31st sounds like a good date to me. I would also encourage
> projects that can do a clean release (if they release before then) to do so.
>
> I am willing to put in personal time to help make that possible.
>
>
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
Hen,
This sounds like a good idea.
I think that my email from yesterday outlining some answers deals with your point 2 somewhat. Would you like to take a stab at a draft dealing with the other options and the intro?
Sent from my iPhone
> On Nov 19, 2016, at 11:42, Henri Yandell <ba...@apache.org> wrote:
>
> Perhaps step 1 is a nice write up of the paths a project currently on the json jar should be considering.
>
> After a brief intro of the issue, it could list things like 1) migrate code to Jackson, 2) use com.tdunning (kudos for making that Ted), 3) remove functionality, 4), 5) etc?
>
> Hen
>
>
>> On Sat, Nov 19, 2016 at 2:23 AM, Alan Gates <al...@gmail.com> wrote:
>> Excellent. Thank you, and thanks for the offer to help.
>>
>> Alan.
>>
>> Sent from my iPhone
>>
>>> On Nov 19, 2016, at 11:04, Ted Dunning <te...@gmail.com> wrote:
>>>
>>>
>>>> On Sat, Nov 19, 2016 at 2:00 AM, Alan Gates <al...@gmail.com> wrote:
>>>> You did not answer the question of whether you're willing to go to dec 31 or not. As you're the only one disagreeing with the later date, if you agree to an earlier date I'd call that consensus.
>>>>
>>>> Can we please agree to a temporary date immediately so projects can release while we keep arguing? If you don't like my temporary date please suggest another.
>>>
>>> Yes.
>>>
>>> December 31st sounds like a good date to me. I would also encourage projects that can do a clean release (if they release before then) to do so.
>>>
>>> I am willing to put in personal time to help make that possible.
>
Re: A grace period for getting rid of JSON license jars
Posted by Henri Yandell <ba...@apache.org>.
Perhaps step 1 is a nice write up of the paths a project currently on the
json jar should be considering.
After a brief intro of the issue, it could list things like 1) migrate code
to Jackson, 2) use com.tdunning (kudos for making that Ted), 3) remove
functionality, 4), 5) etc?
Hen
On Sat, Nov 19, 2016 at 2:23 AM, Alan Gates <al...@gmail.com> wrote:
> Excellent. Thank you, and thanks for the offer to help.
>
> Alan.
>
> Sent from my iPhone
>
> On Nov 19, 2016, at 11:04, Ted Dunning <te...@gmail.com> wrote:
>
>
> On Sat, Nov 19, 2016 at 2:00 AM, Alan Gates <al...@gmail.com> wrote:
>
>> You did not answer the question of whether you're willing to go to dec 31
>> or not. As you're the only one disagreeing with the later date, if you
>> agree to an earlier date I'd call that consensus.
>>
>> Can we please agree to a temporary date immediately so projects can
>> release while we keep arguing? If you don't like my temporary date please
>> suggest another.
>>
>
> Yes.
>
> December 31st sounds like a good date to me. I would also encourage
> projects that can do a clean release (if they release before then) to do so.
>
> I am willing to put in personal time to help make that possible.
>
>
Re: A grace period for getting rid of JSON license jars
Posted by Alan Gates <al...@gmail.com>.
Excellent. Thank you, and thanks for the offer to help.
Alan.
Sent from my iPhone
> On Nov 19, 2016, at 11:04, Ted Dunning <te...@gmail.com> wrote:
>
>
>> On Sat, Nov 19, 2016 at 2:00 AM, Alan Gates <al...@gmail.com> wrote:
>> You did not answer the question of whether you're willing to go to dec 31 or not. As you're the only one disagreeing with the later date, if you agree to an earlier date I'd call that consensus.
>>
>> Can we please agree to a temporary date immediately so projects can release while we keep arguing? If you don't like my temporary date please suggest another.
>
> Yes.
>
> December 31st sounds like a good date to me. I would also encourage projects that can do a clean release (if they release before then) to do so.
>
> I am willing to put in personal time to help make that possible.
>
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
On Sat, Nov 19, 2016 at 2:00 AM, Alan Gates <al...@gmail.com> wrote:
> You did not answer the question of whether you're willing to go to dec 31
> or not. As you're the only one disagreeing with the later date, if you
> agree to an earlier date I'd call that consensus.
>
> Can we please agree to a temporary date immediately so projects can
> release while we keep arguing? If you don't like my temporary date please
> suggest another.
>
Yes.
December 31st sounds like a good date to me. I would also encourage
projects that can do a clean release (if they release before then) to do so.
I am willing to put in personal time to help make that possible.
Re: A grace period for getting rid of JSON license jars
Posted by Alan Gates <al...@gmail.com>.
You did not answer the question of whether you're willing to go to dec 31 or not. As you're the only one disagreeing with the later date, if you agree to an earlier date I'd call that consensus.
Can we please agree to a temporary date immediately so projects can release while we keep arguing? If you don't like my temporary date please suggest another.
Alan.
Sent from my iPhone
> On Nov 19, 2016, at 10:03, Ted Dunning <te...@gmail.com> wrote:
>
>
>
>> On Sat, Nov 19, 2016 at 12:38 AM, Alan Gates <al...@gmail.com> wrote:
>> Ted, there's much more to do here than switch out a pom. Every project will have to go through a full test cycle as there are likely to be subtle differences between the libraries. And projects on top of the stack will have to wait for those on the bottom.
>
> I am very aware of that. I want to get those tests started as soon as possible.
>
> Moreover, I will be working to get our own QA teams to test existing versions with the new library as soon as possible. That will be very difficult to schedule, but is really important.
>
> Also, based on some of my first glances, some cases will require waiting for the lower projects, but clearly not all. One example of a problematic dependency is twitter4j where there is source adoption. Other dependencies are cleaner. I am working through a pull request for twitter4j, partly as self education on this matter.
>
>> We've had this license for years. Is 6 more months going to matter?
>
> We are already seeing users reject Apache software because of this issue. So yes, it will matter. The question is how much and how do we trade that off against the pain involved.
>
>>
>> In the interest of letting nifi and hive release will you at least agree to dec 31 as the date and that we get to keep arguing whether to extend that to June 1?
>
> I think that you over-estimate my influence here. This is a decision we will all be making, hopefully by as strong a consensus as possible.
>
> I am happy to agree that simply finding the projects that need changes and communicating with those projects is likely to mean that only some projects will be able to change sooner than that. But that is simply my best guess based on incomplete knowledge of which projects are involved.
>
>
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
On Sat, Nov 19, 2016 at 12:38 AM, Alan Gates <al...@gmail.com> wrote:
> Ted, there's much more to do here than switch out a pom. Every project
> will have to go through a full test cycle as there are likely to be subtle
> differences between the libraries. And projects on top of the stack will
> have to wait for those on the bottom.
>
I am very aware of that. I want to get those tests started as soon as
possible.
Moreover, I will be working to get our own QA teams to test existing
versions with the new library as soon as possible. That will be very
difficult to schedule, but is really important.
Also, based on some of my first glances, some cases will require waiting
for the lower projects, but clearly not all. One example of a problematic
dependency is twitter4j where there is source adoption. Other dependencies
are cleaner. I am working through a pull request for twitter4j, partly as
self education on this matter.
> We've had this license for years. Is 6 more months going to matter?
>
We are already seeing users reject Apache software because of this issue.
So yes, it will matter. The question is how much and how do we trade that
off against the pain involved.
>
> In the interest of letting nifi and hive release will you at least agree
> to dec 31 as the date and that we get to keep arguing whether to extend
> that to June 1?
>
I think that you over-estimate my influence here. This is a decision we
will all be making, hopefully by as strong a consensus as possible.
I am happy to agree that simply finding the projects that need changes and
communicating with those projects is likely to mean that only some projects
will be able to change sooner than that. But that is simply my best guess
based on incomplete knowledge of which projects are involved.
Re: A grace period for getting rid of JSON license jars
Posted by Alan Gates <al...@gmail.com>.
Ted, there's much more to do here than switch out a pom. Every project will have to go through a full test cycle as there are likely to be subtle differences between the libraries. And projects on top of the stack will have to wait for those on the bottom.
We've had this license for years. Is 6 more months going to matter?
In the interest of letting nifi and hive release will you at least agree to dec 31 as the date and that we get to keep arguing whether to extend that to June 1?
Alan.
Sent from my iPhone
> On Nov 19, 2016, at 00:55, sebb <se...@gmail.com> wrote:
>
>> On 18 November 2016 at 23:41, Ted Dunning <te...@gmail.com> wrote:
>>
>> Uhh...
>>
>> I was hoping that we have a MUCH sooner deadline than June 1st if we are
>> saying "next release after". The June date is more appropriate if the
>> language is "must have clean release before".
>>
>> In any case, I now have put an artifact on maven central that should allow
>> most of these projects to simply change a maven pom by replacing the
>> dependency. The artifact isn't in the mvncentral search engine yet, but it
>> is in central.
>>
>> This is the dependency you should need:
>>
>> <dependency>
>> <groupId>com.tdunning</groupId>
>> <artifactId>json</artifactId>
>> <version>1.0</version>
>> </dependency>
>>
>
> Does this use the same Java package names?
>
> This can cause serious problems for larger projects that may be using
> both versions of the library in different areas, and which may not be
> able to change to one or the other.
>
>
>>
>>
>>> On Fri, Nov 18, 2016 at 2:33 PM, Alan Gates <al...@gmail.com> wrote:
>>>
>>> I am new to the legal discuss list, so I’m not sure how we declare
>>> consensus here. I agree with Ted’s clarification that this applies to the
>>> next release after the June 1 2017 deadline. Thus my reformulated proposal
>>> would look like:
>>> “Projects already using the JSON license are allowed to continue making
>>> releases without modification until June 1 2017. Any releases made after
>>> that date must not have dependencies on code released under the JSON
>>> license.”
>>>
>>> Alan.
>>>
>>>> On Nov 18, 2016, at 20:30, Joe Witt <jo...@gmail.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> Has a decision been reached by any chance? We're looking to kick off
>>>> the next Apache NiFi release and while we've done the work to
>>>> eliminate the use of this library it required us to reduce user
>>>> convenience in one case that we'd love to undo and expect the grace
>>>> period will resolve.
>>>>
>>>> Thanks
>>>> Joe
>>>>
>>>> On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning <te...@gmail.com>
>>>> wrote:
>>>>>
>>>>> I like this too, but would rather have the "next release after xxx/yyy"
>>>>> form
>>>>> of deadline.
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <ji...@jagunet.com>
>>>>> wrote:
>>>>>>
>>>>>> The more I think about it, the more this makes sense. Basically
>>>>>> we refuse the use of it for any new projects/efforts, but those
>>>>>> projects which are currently using it, with no issues, should
>>>>>> be allowed to continue using them, grandfathered, at least for
>>>>>> a time being.
>>>>>>
>>>>>> Let me mull this over some more and make an official determination/
>>>>>> ruling. :)
>>>>>>
>>>>>>> On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com> wrote:
>>>>>>>
>>>>>>> The recent moving of the JSON license to category X means that a
>>>>>>> number
>>>>>>> of projects cannot do any releases until this is fixed. I know this
>>>>>>> includes Hadoop, Hive, and Spark, and probably a number of others
>>>>>>> since
>>>>>>> hadoop-common (which many project use) depends on jars from json.org.
>>>>>>> The
>>>>>>> Hive team in particular is trying to get a maintenance release out
>>>>>>> which is
>>>>>>> blocked by this.
>>>>>>>
>>>>>>> I talked with Jim Jagielski briefly today and he suggested that
>>>>>>> perhaps
>>>>>>> we could have a grandfather clause on this so that projects that
>>>>>>> already are
>>>>>>> using it could continue to, at least for a period of time, so that
>>>>>>> they can
>>>>>>> continue to produce releases rather than needing to spend unplanned
>>>>>>> time
>>>>>>> switching out this library[1].
>>>>>>>
>>>>>>> To be specific I propose we give projects already using this license
>>>>>>> 6
>>>>>>> months to clean this up in which they can continue to release with
>>>>>>> dependencies on the JSON license.
>>>>>>>
>>>>>>> Alan.
>>>>>>>
>>>>>>> 1. The amount of time to fix this will not be trivial. Based on a
>>>>>>> little bit of digging I’ve done the alternatives are not 100%
>>>>>>> identical in
>>>>>>> their behavior which will mean projects will need to thoroughly test
>>>>>>> the
>>>>>>> replacements and change their code to deal with the differences.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>>>>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>>>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by sebb <se...@gmail.com>.
On 18 November 2016 at 23:41, Ted Dunning <te...@gmail.com> wrote:
>
> Uhh...
>
> I was hoping that we have a MUCH sooner deadline than June 1st if we are
> saying "next release after". The June date is more appropriate if the
> language is "must have clean release before".
>
> In any case, I now have put an artifact on maven central that should allow
> most of these projects to simply change a maven pom by replacing the
> dependency. The artifact isn't in the mvncentral search engine yet, but it
> is in central.
>
> This is the dependency you should need:
>
> <dependency>
> <groupId>com.tdunning</groupId>
> <artifactId>json</artifactId>
> <version>1.0</version>
> </dependency>
>
Does this use the same Java package names?
This can cause serious problems for larger projects that may be using
both versions of the library in different areas, and which may not be
able to change to one or the other.
>
>
> On Fri, Nov 18, 2016 at 2:33 PM, Alan Gates <al...@gmail.com> wrote:
>>
>> I am new to the legal discuss list, so I’m not sure how we declare
>> consensus here. I agree with Ted’s clarification that this applies to the
>> next release after the June 1 2017 deadline. Thus my reformulated proposal
>> would look like:
>> “Projects already using the JSON license are allowed to continue making
>> releases without modification until June 1 2017. Any releases made after
>> that date must not have dependencies on code released under the JSON
>> license.”
>>
>> Alan.
>>
>> > On Nov 18, 2016, at 20:30, Joe Witt <jo...@gmail.com> wrote:
>> >
>> > Hello,
>> >
>> > Has a decision been reached by any chance? We're looking to kick off
>> > the next Apache NiFi release and while we've done the work to
>> > eliminate the use of this library it required us to reduce user
>> > convenience in one case that we'd love to undo and expect the grace
>> > period will resolve.
>> >
>> > Thanks
>> > Joe
>> >
>> > On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning <te...@gmail.com>
>> > wrote:
>> >>
>> >> I like this too, but would rather have the "next release after xxx/yyy"
>> >> form
>> >> of deadline.
>> >>
>> >>
>> >>
>> >> On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <ji...@jagunet.com>
>> >> wrote:
>> >>>
>> >>> The more I think about it, the more this makes sense. Basically
>> >>> we refuse the use of it for any new projects/efforts, but those
>> >>> projects which are currently using it, with no issues, should
>> >>> be allowed to continue using them, grandfathered, at least for
>> >>> a time being.
>> >>>
>> >>> Let me mull this over some more and make an official determination/
>> >>> ruling. :)
>> >>>
>> >>>> On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com> wrote:
>> >>>>
>> >>>> The recent moving of the JSON license to category X means that a
>> >>>> number
>> >>>> of projects cannot do any releases until this is fixed. I know this
>> >>>> includes Hadoop, Hive, and Spark, and probably a number of others
>> >>>> since
>> >>>> hadoop-common (which many project use) depends on jars from json.org.
>> >>>> The
>> >>>> Hive team in particular is trying to get a maintenance release out
>> >>>> which is
>> >>>> blocked by this.
>> >>>>
>> >>>> I talked with Jim Jagielski briefly today and he suggested that
>> >>>> perhaps
>> >>>> we could have a grandfather clause on this so that projects that
>> >>>> already are
>> >>>> using it could continue to, at least for a period of time, so that
>> >>>> they can
>> >>>> continue to produce releases rather than needing to spend unplanned
>> >>>> time
>> >>>> switching out this library[1].
>> >>>>
>> >>>> To be specific I propose we give projects already using this license
>> >>>> 6
>> >>>> months to clean this up in which they can continue to release with
>> >>>> dependencies on the JSON license.
>> >>>>
>> >>>> Alan.
>> >>>>
>> >>>> 1. The amount of time to fix this will not be trivial. Based on a
>> >>>> little bit of digging I’ve done the alternatives are not 100%
>> >>>> identical in
>> >>>> their behavior which will mean projects will need to thoroughly test
>> >>>> the
>> >>>> replacements and change their code to deal with the differences.
>> >>>>
>> >>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >>>> For additional commands, e-mail: legal-discuss-help@apache.org
>> >>>>
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >>> For additional commands, e-mail: legal-discuss-help@apache.org
>> >>>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> > For additional commands, e-mail: legal-discuss-help@apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
Yes.
On Sun, Nov 20, 2016 at 11:25 PM, Bertrand Delacretaz <
bdelacretaz@apache.org> wrote:
> On Sat, Nov 19, 2016 at 12:41 AM, Ted Dunning <te...@gmail.com>
> wrote:
> > ...This is the dependency you should need:
> > <dependency>
> > <groupId>com.tdunning</groupId>
> > <artifactId>json</artifactId>
> > <version>1.0</version>
> > </dependency>...
>
> Is that https://github.com/tdunning/open-json ?
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: A grace period for getting rid of JSON license jars
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sat, Nov 19, 2016 at 12:41 AM, Ted Dunning <te...@gmail.com> wrote:
> ...This is the dependency you should need:
> <dependency>
> <groupId>com.tdunning</groupId>
> <artifactId>json</artifactId>
> <version>1.0</version>
> </dependency>...
Is that https://github.com/tdunning/open-json ?
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
Uhh...
I was hoping that we have a MUCH sooner deadline than June 1st if we are
saying "next release after". The June date is more appropriate if the
language is "must have clean release before".
In any case, I now have put an artifact on maven central that should allow
most of these projects to simply change a maven pom by replacing the
dependency. The artifact isn't in the mvncentral search engine yet, but it
is in central.
This is the dependency you should need:
<dependency>
<groupId>com.tdunning</groupId>
<artifactId>json</artifactId>
<version>1.0</version>
</dependency>
On Fri, Nov 18, 2016 at 2:33 PM, Alan Gates <al...@gmail.com> wrote:
> I am new to the legal discuss list, so I’m not sure how we declare
> consensus here. I agree with Ted’s clarification that this applies to the
> next release after the June 1 2017 deadline. Thus my reformulated proposal
> would look like:
> “Projects already using the JSON license are allowed to continue making
> releases without modification until June 1 2017. Any releases made after
> that date must not have dependencies on code released under the JSON
> license.”
>
> Alan.
>
> > On Nov 18, 2016, at 20:30, Joe Witt <jo...@gmail.com> wrote:
> >
> > Hello,
> >
> > Has a decision been reached by any chance? We're looking to kick off
> > the next Apache NiFi release and while we've done the work to
> > eliminate the use of this library it required us to reduce user
> > convenience in one case that we'd love to undo and expect the grace
> > period will resolve.
> >
> > Thanks
> > Joe
> >
> > On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning <te...@gmail.com>
> wrote:
> >>
> >> I like this too, but would rather have the "next release after xxx/yyy"
> form
> >> of deadline.
> >>
> >>
> >>
> >> On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <ji...@jagunet.com>
> wrote:
> >>>
> >>> The more I think about it, the more this makes sense. Basically
> >>> we refuse the use of it for any new projects/efforts, but those
> >>> projects which are currently using it, with no issues, should
> >>> be allowed to continue using them, grandfathered, at least for
> >>> a time being.
> >>>
> >>> Let me mull this over some more and make an official determination/
> >>> ruling. :)
> >>>
> >>>> On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com> wrote:
> >>>>
> >>>> The recent moving of the JSON license to category X means that a
> number
> >>>> of projects cannot do any releases until this is fixed. I know this
> >>>> includes Hadoop, Hive, and Spark, and probably a number of others
> since
> >>>> hadoop-common (which many project use) depends on jars from json.org.
> The
> >>>> Hive team in particular is trying to get a maintenance release out
> which is
> >>>> blocked by this.
> >>>>
> >>>> I talked with Jim Jagielski briefly today and he suggested that
> perhaps
> >>>> we could have a grandfather clause on this so that projects that
> already are
> >>>> using it could continue to, at least for a period of time, so that
> they can
> >>>> continue to produce releases rather than needing to spend unplanned
> time
> >>>> switching out this library[1].
> >>>>
> >>>> To be specific I propose we give projects already using this license 6
> >>>> months to clean this up in which they can continue to release with
> >>>> dependencies on the JSON license.
> >>>>
> >>>> Alan.
> >>>>
> >>>> 1. The amount of time to fix this will not be trivial. Based on a
> >>>> little bit of digging I’ve done the alternatives are not 100%
> identical in
> >>>> their behavior which will mean projects will need to thoroughly test
> the
> >>>> replacements and change their code to deal with the differences.
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >>>> For additional commands, e-mail: legal-discuss-help@apache.org
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >>> For additional commands, e-mail: legal-discuss-help@apache.org
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: A grace period for getting rid of JSON license jars
Posted by Alan Gates <al...@gmail.com>.
I am new to the legal discuss list, so I’m not sure how we declare consensus here. I agree with Ted’s clarification that this applies to the next release after the June 1 2017 deadline. Thus my reformulated proposal would look like:
“Projects already using the JSON license are allowed to continue making releases without modification until June 1 2017. Any releases made after that date must not have dependencies on code released under the JSON license.”
Alan.
> On Nov 18, 2016, at 20:30, Joe Witt <jo...@gmail.com> wrote:
>
> Hello,
>
> Has a decision been reached by any chance? We're looking to kick off
> the next Apache NiFi release and while we've done the work to
> eliminate the use of this library it required us to reduce user
> convenience in one case that we'd love to undo and expect the grace
> period will resolve.
>
> Thanks
> Joe
>
> On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning <te...@gmail.com> wrote:
>>
>> I like this too, but would rather have the "next release after xxx/yyy" form
>> of deadline.
>>
>>
>>
>> On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>
>>> The more I think about it, the more this makes sense. Basically
>>> we refuse the use of it for any new projects/efforts, but those
>>> projects which are currently using it, with no issues, should
>>> be allowed to continue using them, grandfathered, at least for
>>> a time being.
>>>
>>> Let me mull this over some more and make an official determination/
>>> ruling. :)
>>>
>>>> On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com> wrote:
>>>>
>>>> The recent moving of the JSON license to category X means that a number
>>>> of projects cannot do any releases until this is fixed. I know this
>>>> includes Hadoop, Hive, and Spark, and probably a number of others since
>>>> hadoop-common (which many project use) depends on jars from json.org. The
>>>> Hive team in particular is trying to get a maintenance release out which is
>>>> blocked by this.
>>>>
>>>> I talked with Jim Jagielski briefly today and he suggested that perhaps
>>>> we could have a grandfather clause on this so that projects that already are
>>>> using it could continue to, at least for a period of time, so that they can
>>>> continue to produce releases rather than needing to spend unplanned time
>>>> switching out this library[1].
>>>>
>>>> To be specific I propose we give projects already using this license 6
>>>> months to clean this up in which they can continue to release with
>>>> dependencies on the JSON license.
>>>>
>>>> Alan.
>>>>
>>>> 1. The amount of time to fix this will not be trivial. Based on a
>>>> little bit of digging I’ve done the alternatives are not 100% identical in
>>>> their behavior which will mean projects will need to thoroughly test the
>>>> replacements and change their code to deal with the differences.
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ted Dunning wrote on Fri, Nov 18, 2016 at 21:29:24 -0800:
> Would we allow releases with gpl dependencies?
Yes, in some circumstances. E.g., if there is an old stable release
line that accidentally uses a GPL'd hard dependency, I could see us
permitting that line to make a few more maintenance releases \u2014 with
appropriate warnings to users.
That's because "don't distribute GPL" is an ASF policy, not a law.
> With dependencies that turned out to be stolen?
That's not the case here, but anyway, a release that embeds code that
ASF has no legal right to (re)distribute, would not be allowed, and if
it accidentally happens then it the artifacts will subsequently be
removed from the mirrors retroactively. That's because ASF can't break
the law.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
I am supportive of allowing for a month or so to convey the bad news. I am not happy with allowing releases for projects that know about the problem.
Would we allow releases with gpl dependencies? With dependencies that turned out to be stolen?
Sent from my iPhone
> On Nov 18, 2016, at 19:37, Joe Witt <jo...@gmail.com> wrote:
>
> Alan, Sean, Henri, Jim, and yourself appear
> supportive of the idea. I'm a +1 as well. Simply prompting for a
> decision.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
I think that theory is weaker than examples here.
I have worked through two examples so far, twitter4j (and thus Apache Nifi)
and Hive.
Twitter4j incorporated the source code. I needed to make a few small
changes for them and sent them a pull request. This was more work than a
pom change but no more than about 2-3 hours. There is no jar hell potential
there because twitter4j changes the package when importing the code.
I haven't made a change to Hive, but I have reviewed all uses of the
org.json code. The new library should satisfy all those uses with just a
pom change. This brings in the possibility of jar hell a la sebb, but
shading should be pretty easy.
So, two data points isn't big data, but the trend so far is that the
conversion is very easy.
The next big data point should be Hadoop which has some difficult spots due
to transitive dependencies on org.json, but my gut is that the conversion
will be easy.
All of these cases ignore QA cycle time.
On Mon, Nov 21, 2016 at 10:30 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> Give me some time to consider all aspects... ApacheCon has
> set me behind a bit :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: A grace period for getting rid of JSON license jars
Posted by Jim Jagielski <ji...@jaguNET.com>.
Give me some time to consider all aspects... ApacheCon has
set me behind a bit :)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Joe Witt <jo...@gmail.com>.
Whether you call it 'source dependency' or 'embedded' code it makes
that thing category-x. Yes, understood and not debating that.
The question is not a technical "how". We all know how to do this.
The question is not a policy "if". It's category-x and that decision
has been made.
The question, I believe, is whether a grace period will be afforded to
continue making Apache releases with pre-existing usage of the now
offending library/code. Alan, Sean, Henri, Jim, and yourself appear
supportive of the idea. I'm a +1 as well. Simply prompting for a
decision.
Thanks
Joe
On Fri, Nov 18, 2016 at 10:15 PM, Ted Dunning <te...@gmail.com> wrote:
>
> On Fri, Nov 18, 2016 at 5:44 PM, Joe Witt <jo...@gmail.com> wrote:
>>
>> Definitely appreciate you taking the initiative on providing an
>> alternative implementation. In the case I'm concerned about we have a
>> library, twitter4j, which uses the json.org code as a source
>> dependency so we'd not be able to exclude their binary dep and replace
>> it.
>
>
> I just looked and twitter4j doesn't really use the json.org code as a
> dependency at all. It embeds that code into its own source code.
>
> That makes twitter4j just as bad as the json.org code.
>
> It shouldn't be too hard to do the source code surgery to remove the
> offending code, however.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
On Fri, Nov 18, 2016 at 5:44 PM, Joe Witt <jo...@gmail.com> wrote:
> Definitely appreciate you taking the initiative on providing an
> alternative implementation. In the case I'm concerned about we have a
> library, twitter4j, which uses the json.org code as a source
> dependency so we'd not be able to exclude their binary dep and replace
> it.
>
I just looked and twitter4j doesn't really use the json.org code as a
dependency at all. It embeds that code into its own source code.
That makes twitter4j just as bad as the json.org code.
It shouldn't be too hard to do the source code surgery to remove the
offending code, however.
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
On Tue, Nov 22, 2016 at 9:06 AM, sebb <se...@gmail.com> wrote:
> Release the new jar under a unique Java package name owned by the
> publisher (i.e. not org.json).
>
Go for it!
> Projects that wish to use it can change POM and imports to use the new jar.
> For dependencies that cannot be changed, create a shaded copy of the
> jar using the org.json package names.
>
Fine idea.
> It seems wrong to deliberately release a competing jar using someone
> else's Java package, even if it is just 'temporary'.
>
That's a hard call and relates back to the Oracle/Google kerfuffle about
re-implementing API's. Ultimately, the package name is as much part of the
API as the class and method names.
Re: A grace period for getting rid of JSON license jars
Posted by sebb <se...@gmail.com>.
I have an alternative solution that I hope avoids most of the issues:
Release the new jar under a unique Java package name owned by the
publisher (i.e. not org.json).
Projects that wish to use it can change POM and imports to use the new jar.
For dependencies that cannot be changed, create a shaded copy of the
jar using the org.json package names.
It seems wrong to deliberately release a competing jar using someone
else's Java package, even if it is just 'temporary'.
On 22 November 2016 at 16:43, Ted Dunning <te...@gmail.com> wrote:
>
>
>
> On Tue, Nov 22, 2016 at 1:48 AM, sebb <se...@gmail.com> wrote:
>>
>>
>> >> I can see how that could work for an individual case, but do we really
>> >> want to release a jar that *requires* the poms to be patched?
>> >
>> >
>> > I think that the patching is at the Apache project level.
>>
>> Yes, but every project that uses the new jar will need to consider
>> patching.
>
>
> The basic alternatives are:
>
> 1) pom level manipulations, possibly including shading but definitely
> including changing the reference to be to a different pom. This can handle
> the cases of direct use of the problem package and transitive use via
> dependencies. As you say, this leaks changes in the org.json component to
> the downstream user of the Apache project (but that can be limited in extent
> and effect using shading).
>
> or
>
> 2) pom AND code manipulations. At the least, this would include changing
> dependencies and imports. And it doesn't actually help with the case of
> dependencies which use the problematic package. In the ideal case, it
> involves changing the way that JSON is handled by moving to something like
> Jackson, but this change must include all dependencies.
>
>
> Note that continuing to use the json.org artifacts as currently licensed is
> NOT an option. That is what is really causing the real sand in the gears.
> Our only choices now are to choose which palliative measures we take in
> removing that dependency. Some such measures can be done quickly and others
> will take longer.
>
>>
>> >>
>> >> Every time a 3rd party project uses an ASF project containing this
>> >> replacement jar they will potentially have to patch their poms.
>> >> That does not seem sensible.
>> >
>> >
>> > I didn't hear that.
>>
>> The solution to my claim of jar hell explained how to fix it in a
>> particular project.
>> I only realised last night that of course it would have to be done by
>> every affected project.
>
>
> The only effect on downstream users will be that they may have to import the
> original json.org jar (if we shade) or they may have access to a more
> restrictive set of capabilities than before (if we don't).
>
>>
>> >> Furthermore, if the jars ever diverge, no amount of pom patching will
>> >> solve the issue.
>> >
>> >
>> > I don't agree with this.
>>
>> Do you mean that jars will never diverge?
>> Or that it does not matter?
>
>
> That it doesn't matter. Apache projects should move away from dependency on
> json.org's artifacts or simulacra of same such as what I have released. If
> they don't move away, that means that they are happy with what they got and
> changes to something that they aren't using shouldn't have much effect.
>
>>
>>
>> The Java classpath only allows a single copy of each class on the same
>> classpath.
>> So if the two jars have different versions of the same class, only one
>> of the classes can be present.
>> So if component A needs the old jar version and component B expects
>> the new jar version, at least one of them will be disappointed.
>
>
> Indeed. Thus shading.
>
>>
>>
>> >>
>> >> Please, let's do this properly.
>> >
>> >
>> > Fine. The right way to do this is to move to Jackson. But that will
>> > take
>> > longer.
>> >
>> > I merely offer an interim solution that can be used safely in some
>> > situations.
>>
>> I contend that it is not safe to do this.
>> At best the solution is unnecessarily fragile.
>
>
> Isn't this choice up to the projects? I don't see why legal-discuss is the
> proper venue for technical decisions.
>
> If you have alternative approaches, that is great. Release something or
> patch a project as a demo. All I have done is propose one alternative. It
> has costs, limitations and defects, as do all approaches.
>
> I should point out that the code I have packaged so far is, ahem, open
> source. Please feel free to provide a patch. Or fork it to provide an
> alternative.
>
>>
>>
>> Interim solutions have a way of becoming permanent, or at least longer
>> lived than you intended and anticipated.
>>
>> > See for instance the twitter4j case. Likewise the Hive case
>> > (possibly with the addition of a little shade).
>>
>> I'm not disputing that the solution should work now.
>> I am saying that it is ill-advised.
>
>
> Not our decision here.
>
> We trust projects to make their own technical decisions.
>
> The only decision that is out of bounds here is to continue use of
> json.org's artifacts.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Sebastien <se...@gmail.com>.
dsl-json seems to be fast, and the license seems to be compatible (BSD
3-Clause).
However, this is a quite new project, which is java-8 oriented AFAICS.
I guess the JSON library we will choose should be java 1.5, 6, 7 & 8
compatible...
On Wed, Nov 23, 2016 at 6:37 PM, Martin Grigorov <mg...@apache.org>
wrote:
> Better use https://github.com/fabienrenaud/java-json-benchmark
> The article by Takipi is both old and the testing approach is inaccurate.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Nov 23, 2016 at 6:25 PM, Tobias Soloschenko <
> tobiassoloschenko@googlemail.com> wrote:
>
> > Hi,
> >
> > we should also consider the performance impact, shouldn't we?
> >
> > http://blog.takipi.com/the-ultimate-json-library-json-simple
> > -vs-gson-vs-jackson-vs-json/
> >
> > kind regards
> >
> > Tobias
> >
> > Am 23.11.16 um 17:26 schrieb Sebastien:
> >
> > I'm +1 for jackson. We already use it in wicket-extensions
> >>
> >> https://github.com/apache/wicket/blob/master/wicket-extensio
> >> ns/src/main/java/org/apache/wicket/extensions/requestlogge
> >> r/JsonRequestLogger.java#L22
> >>
> >> Moreover, I'm personally fine to rely on a 3rd party library for JSON
> >> objects. That way you can use the same library back-end side and get the
> >> JSON objects back (no deserialization issues, which is not true if a
> >> specific JSON lib is front-end side only, like for our JSON internal
> lib)
> >>
> >>
> >> On Wed, Nov 23, 2016 at 5:16 PM, Martijn Dashorst <
> >> martijn.dashorst@gmail.com> wrote:
> >>
> >> Another option would be to use jackson and use the JSON classes in
> >>> Wicket as API wrappers.
> >>>
> >>> Martijn
> >>>
> >>>
> >
>
Re: JSON License and Apache Projects
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi Martin,
sadly there are classes not covered by open-json, but for all others we could make different PRs for 6.x and 7.x and copy them. In this case I would suggest to also let the name of JSONFunction to be like I renamed it.
kind regards
Tobias
> Am 24.11.2016 um 21:46 schrieb Martin Grigorov <mg...@apache.org>:
>
> Hi Tobias,
>
> This PR is OK for 8.x but as Emond said: making such change in 6.x and 7.x
> is a *BIG* API break.
> 1.5.x is not affected because we introduced JSON.org for the Ajax rework in
> Wicket 6.0.0.
> I believe the easier solution for 6.x and 7.x is to copy the classes from
> Open-JSON and replace the current ones.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, Nov 24, 2016 at 7:01 PM, Tobias Soloschenko <
> tobiassoloschenko@googlemail.com> wrote:
>
>> Hi,
>>
>> to provide the most possible backward compatibility I think open-json is
>> great:
>>
>> https://github.com/apache/wicket/pull/193
>> https://github.com/tdunning/open-json/pull/1
>> https://github.com/apache/wicket/pull/193
>>
>> I also think that we should move the classes out and use the external lib.
>>
>> Libraries which are using Apache Wicket JSON only have to organize the
>> imports in most cases. If classes are used which are not ported yet - you
>> can exclude open-json and shift to json.org - or you can implement it
>> yourself.
>>
>> WDYT?
>>
>> kind regards
>>
>> Tobias
>>
>> 2016-11-23 21:26 GMT+01:00 Mark Struberg <st...@yahoo.de.invalid>:
>>
>>> Try Apache Johnzon.
>>> It is really tiny (< 100k) and already used in CXF and TomEE as well for
>>> example.
>>> It's based on the JSON-P specification, so it's even optional if you run
>>> Wicket on a EE7 server.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>> Am 23.11.2016 um 20:24 schrieb Emond Papegaaij <
>>> emond.papegaaij@gmail.com>:
>>>>
>>>> Hi,
>>>>
>>>> Does this mean we can no longer include these files in Wicket 6 and 7?
>>>> If so, that would mean a serious API break, or we need to duplicate
>>>> the entire API in new classes. The classes are part of the public API
>>>> of AbstractDefaultAjaxBehavior and the classes are publicly available.
>>>>
>>>> Looking at the usage of the classes in Wicket, I don't see why we need
>>>> a heavy weight library such as Jackson. Also, Jackson has a history of
>>>> breaking its API even in patch releases. It has proven one of the most
>>>> unreliable libraries in our applications over the past few years.
>>>>
>>>> Wicket only uses the JSON classes in 3 places:
>>>> AbstractDefaultAjaxBehavior, AtmosphereParameters and ModalWindow. I
>>>> think we should either find a lightweight substitute or write
>>>> something ourselves from scratch. As far as I can see, we only use the
>>>> classes to render Maps and arrays to JSON. We do not seem to be using
>>>> them for parsing.
>>>>
>>>> Best regards,
>>>> Emond
>>>>
>>>> On Wed, Nov 23, 2016 at 7:44 PM, Mark Struberg
>>>> <st...@yahoo.de.invalid> wrote:
>>>>> This benchmark is also not really correct.
>>>>> For Johnzon it creates a new JsonProvider for each and every
>>> invocation. This heavily slows down the performance.
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>> Am 23.11.2016 um 18:37 schrieb Martin Grigorov <mgrigorov@apache.org
>>> :
>>>>>>
>>>>>> https://github.com/fabienrenaud/java-json-benchmark
>>>>>
>>>
>>>
>>
Re: JSON License and Apache Projects
Posted by Martin Grigorov <mg...@apache.org>.
Hi Tobias,
This PR is OK for 8.x but as Emond said: making such change in 6.x and 7.x
is a *BIG* API break.
1.5.x is not affected because we introduced JSON.org for the Ajax rework in
Wicket 6.0.0.
I believe the easier solution for 6.x and 7.x is to copy the classes from
Open-JSON and replace the current ones.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Nov 24, 2016 at 7:01 PM, Tobias Soloschenko <
tobiassoloschenko@googlemail.com> wrote:
> Hi,
>
> to provide the most possible backward compatibility I think open-json is
> great:
>
> https://github.com/apache/wicket/pull/193
> https://github.com/tdunning/open-json/pull/1
> https://github.com/apache/wicket/pull/193
>
> I also think that we should move the classes out and use the external lib.
>
> Libraries which are using Apache Wicket JSON only have to organize the
> imports in most cases. If classes are used which are not ported yet - you
> can exclude open-json and shift to json.org - or you can implement it
> yourself.
>
> WDYT?
>
> kind regards
>
> Tobias
>
> 2016-11-23 21:26 GMT+01:00 Mark Struberg <st...@yahoo.de.invalid>:
>
> > Try Apache Johnzon.
> > It is really tiny (< 100k) and already used in CXF and TomEE as well for
> > example.
> > It's based on the JSON-P specification, so it's even optional if you run
> > Wicket on a EE7 server.
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 23.11.2016 um 20:24 schrieb Emond Papegaaij <
> > emond.papegaaij@gmail.com>:
> > >
> > > Hi,
> > >
> > > Does this mean we can no longer include these files in Wicket 6 and 7?
> > > If so, that would mean a serious API break, or we need to duplicate
> > > the entire API in new classes. The classes are part of the public API
> > > of AbstractDefaultAjaxBehavior and the classes are publicly available.
> > >
> > > Looking at the usage of the classes in Wicket, I don't see why we need
> > > a heavy weight library such as Jackson. Also, Jackson has a history of
> > > breaking its API even in patch releases. It has proven one of the most
> > > unreliable libraries in our applications over the past few years.
> > >
> > > Wicket only uses the JSON classes in 3 places:
> > > AbstractDefaultAjaxBehavior, AtmosphereParameters and ModalWindow. I
> > > think we should either find a lightweight substitute or write
> > > something ourselves from scratch. As far as I can see, we only use the
> > > classes to render Maps and arrays to JSON. We do not seem to be using
> > > them for parsing.
> > >
> > > Best regards,
> > > Emond
> > >
> > > On Wed, Nov 23, 2016 at 7:44 PM, Mark Struberg
> > > <st...@yahoo.de.invalid> wrote:
> > >> This benchmark is also not really correct.
> > >> For Johnzon it creates a new JsonProvider for each and every
> > invocation. This heavily slows down the performance.
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>> Am 23.11.2016 um 18:37 schrieb Martin Grigorov <mgrigorov@apache.org
> >:
> > >>>
> > >>> https://github.com/fabienrenaud/java-json-benchmark
> > >>
> >
> >
>
Re: JSON License and Apache Projects
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi,
to provide the most possible backward compatibility I think open-json is
great:
https://github.com/apache/wicket/pull/193
https://github.com/tdunning/open-json/pull/1
https://github.com/apache/wicket/pull/193
I also think that we should move the classes out and use the external lib.
Libraries which are using Apache Wicket JSON only have to organize the
imports in most cases. If classes are used which are not ported yet - you
can exclude open-json and shift to json.org - or you can implement it
yourself.
WDYT?
kind regards
Tobias
2016-11-23 21:26 GMT+01:00 Mark Struberg <st...@yahoo.de.invalid>:
> Try Apache Johnzon.
> It is really tiny (< 100k) and already used in CXF and TomEE as well for
> example.
> It's based on the JSON-P specification, so it's even optional if you run
> Wicket on a EE7 server.
>
> LieGrue,
> strub
>
>
> > Am 23.11.2016 um 20:24 schrieb Emond Papegaaij <
> emond.papegaaij@gmail.com>:
> >
> > Hi,
> >
> > Does this mean we can no longer include these files in Wicket 6 and 7?
> > If so, that would mean a serious API break, or we need to duplicate
> > the entire API in new classes. The classes are part of the public API
> > of AbstractDefaultAjaxBehavior and the classes are publicly available.
> >
> > Looking at the usage of the classes in Wicket, I don't see why we need
> > a heavy weight library such as Jackson. Also, Jackson has a history of
> > breaking its API even in patch releases. It has proven one of the most
> > unreliable libraries in our applications over the past few years.
> >
> > Wicket only uses the JSON classes in 3 places:
> > AbstractDefaultAjaxBehavior, AtmosphereParameters and ModalWindow. I
> > think we should either find a lightweight substitute or write
> > something ourselves from scratch. As far as I can see, we only use the
> > classes to render Maps and arrays to JSON. We do not seem to be using
> > them for parsing.
> >
> > Best regards,
> > Emond
> >
> > On Wed, Nov 23, 2016 at 7:44 PM, Mark Struberg
> > <st...@yahoo.de.invalid> wrote:
> >> This benchmark is also not really correct.
> >> For Johnzon it creates a new JsonProvider for each and every
> invocation. This heavily slows down the performance.
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 23.11.2016 um 18:37 schrieb Martin Grigorov <mg...@apache.org>:
> >>>
> >>> https://github.com/fabienrenaud/java-json-benchmark
> >>
>
>
Re: JSON License and Apache Projects
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Try Apache Johnzon.
It is really tiny (< 100k) and already used in CXF and TomEE as well for example.
It's based on the JSON-P specification, so it's even optional if you run Wicket on a EE7 server.
LieGrue,
strub
> Am 23.11.2016 um 20:24 schrieb Emond Papegaaij <em...@gmail.com>:
>
> Hi,
>
> Does this mean we can no longer include these files in Wicket 6 and 7?
> If so, that would mean a serious API break, or we need to duplicate
> the entire API in new classes. The classes are part of the public API
> of AbstractDefaultAjaxBehavior and the classes are publicly available.
>
> Looking at the usage of the classes in Wicket, I don't see why we need
> a heavy weight library such as Jackson. Also, Jackson has a history of
> breaking its API even in patch releases. It has proven one of the most
> unreliable libraries in our applications over the past few years.
>
> Wicket only uses the JSON classes in 3 places:
> AbstractDefaultAjaxBehavior, AtmosphereParameters and ModalWindow. I
> think we should either find a lightweight substitute or write
> something ourselves from scratch. As far as I can see, we only use the
> classes to render Maps and arrays to JSON. We do not seem to be using
> them for parsing.
>
> Best regards,
> Emond
>
> On Wed, Nov 23, 2016 at 7:44 PM, Mark Struberg
> <st...@yahoo.de.invalid> wrote:
>> This benchmark is also not really correct.
>> For Johnzon it creates a new JsonProvider for each and every invocation. This heavily slows down the performance.
>>
>> LieGrue,
>> strub
>>
>>> Am 23.11.2016 um 18:37 schrieb Martin Grigorov <mg...@apache.org>:
>>>
>>> https://github.com/fabienrenaud/java-json-benchmark
>>
Re: JSON License and Apache Projects
Posted by Emond Papegaaij <em...@gmail.com>.
Hi,
Does this mean we can no longer include these files in Wicket 6 and 7?
If so, that would mean a serious API break, or we need to duplicate
the entire API in new classes. The classes are part of the public API
of AbstractDefaultAjaxBehavior and the classes are publicly available.
Looking at the usage of the classes in Wicket, I don't see why we need
a heavy weight library such as Jackson. Also, Jackson has a history of
breaking its API even in patch releases. It has proven one of the most
unreliable libraries in our applications over the past few years.
Wicket only uses the JSON classes in 3 places:
AbstractDefaultAjaxBehavior, AtmosphereParameters and ModalWindow. I
think we should either find a lightweight substitute or write
something ourselves from scratch. As far as I can see, we only use the
classes to render Maps and arrays to JSON. We do not seem to be using
them for parsing.
Best regards,
Emond
On Wed, Nov 23, 2016 at 7:44 PM, Mark Struberg
<st...@yahoo.de.invalid> wrote:
> This benchmark is also not really correct.
> For Johnzon it creates a new JsonProvider for each and every invocation. This heavily slows down the performance.
>
> LieGrue,
> strub
>
>> Am 23.11.2016 um 18:37 schrieb Martin Grigorov <mg...@apache.org>:
>>
>> https://github.com/fabienrenaud/java-json-benchmark
>
Re: JSON License and Apache Projects
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
This benchmark is also not really correct.
For Johnzon it creates a new JsonProvider for each and every invocation. This heavily slows down the performance.
LieGrue,
strub
> Am 23.11.2016 um 18:37 schrieb Martin Grigorov <mg...@apache.org>:
>
> https://github.com/fabienrenaud/java-json-benchmark
Re: JSON License and Apache Projects
Posted by Martin Grigorov <mg...@apache.org>.
Better use https://github.com/fabienrenaud/java-json-benchmark
The article by Takipi is both old and the testing approach is inaccurate.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Nov 23, 2016 at 6:25 PM, Tobias Soloschenko <
tobiassoloschenko@googlemail.com> wrote:
> Hi,
>
> we should also consider the performance impact, shouldn't we?
>
> http://blog.takipi.com/the-ultimate-json-library-json-simple
> -vs-gson-vs-jackson-vs-json/
>
> kind regards
>
> Tobias
>
> Am 23.11.16 um 17:26 schrieb Sebastien:
>
> I'm +1 for jackson. We already use it in wicket-extensions
>>
>> https://github.com/apache/wicket/blob/master/wicket-extensio
>> ns/src/main/java/org/apache/wicket/extensions/requestlogge
>> r/JsonRequestLogger.java#L22
>>
>> Moreover, I'm personally fine to rely on a 3rd party library for JSON
>> objects. That way you can use the same library back-end side and get the
>> JSON objects back (no deserialization issues, which is not true if a
>> specific JSON lib is front-end side only, like for our JSON internal lib)
>>
>>
>> On Wed, Nov 23, 2016 at 5:16 PM, Martijn Dashorst <
>> martijn.dashorst@gmail.com> wrote:
>>
>> Another option would be to use jackson and use the JSON classes in
>>> Wicket as API wrappers.
>>>
>>> Martijn
>>>
>>>
>
Re: JSON License and Apache Projects
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi,
we should also consider the performance impact, shouldn't we?
http://blog.takipi.com/the-ultimate-json-library-json-simple-vs-gson-vs-jackson-vs-json/
kind regards
Tobias
Am 23.11.16 um 17:26 schrieb Sebastien:
> I'm +1 for jackson. We already use it in wicket-extensions
>
> https://github.com/apache/wicket/blob/master/wicket-extensions/src/main/java/org/apache/wicket/extensions/requestlogger/JsonRequestLogger.java#L22
>
> Moreover, I'm personally fine to rely on a 3rd party library for JSON
> objects. That way you can use the same library back-end side and get the
> JSON objects back (no deserialization issues, which is not true if a
> specific JSON lib is front-end side only, like for our JSON internal lib)
>
>
> On Wed, Nov 23, 2016 at 5:16 PM, Martijn Dashorst <
> martijn.dashorst@gmail.com> wrote:
>
>> Another option would be to use jackson and use the JSON classes in
>> Wicket as API wrappers.
>>
>> Martijn
>>
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
Fwd: JSON License and Apache Projects
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
FYI. Official statement from VP Legal regarding use of json.org <http://json.org/> licensed code.
-Taylor
> Begin forwarded message:
>
> From: Jim Jagielski <ji...@apache.org>
> Subject: JSON License and Apache Projects
> Date: November 23, 2016 at 9:08:30 AM EST
> To: legal-discuss@apache.org
> Reply-To: legal-discuss@apache.org
>
> 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: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
Fwd: JSON License and Apache Projects
Posted by Andy Seaborne <an...@apache.org>.
Jena does not use code with the JSON License so this is just FYI.
jsonld-java uses com.fasterxml.jackson
Some organisations treat the "not be used for evil" clause as not
material; some organisations, Debian and Google, for instance, don't
allow its use.
https://opensource.org/ does not classify it as an Open Source license.
Andy
-------- Forwarded Message --------
Subject: JSON License and Apache Projects
Date: Wed, 23 Nov 2016 09:08:30 -0500
From: Jim Jagielski <ji...@apache.org>
Reply-To: legal-discuss@apache.org
To: legal-discuss@apache.org
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: JSON License and Apache Projects
Posted by Julian Hyde <jh...@apache.org>.
Apache legal have decided that the JSON license is now category X (i.e. we can’t use it). This is a reverse from previous guidance. I don’t believe that we use (directly or indirectly) any JSON-licensed components, but if we do, please speak up and log an issue.
Julian
> Begin forwarded message:
>
> From: Jim Jagielski <ji...@apache.org>
> Date: Wed, Nov 23, 2016 at 10:08 PM
> Subject: JSON License and Apache Projects
> To: legal-discuss@apache.org
>
>
> 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: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
Fwd: JSON License and Apache Projects
Posted by Luke Han <lu...@apache.org>.
Dear community,
We have informed there's JSON license issue which every project has to
resolve it.
Please help to double check if our project directly depends on that
one, and if our dependencies rely on it.
Let's try to upgrade/replace any library to one without such issue in
our coming releases.
More detail, please check below mail from legal.
Thanks.
Luke
---------- Forwarded message ----------
From: Jim Jagielski <ji...@apache.org>
Date: Wed, Nov 23, 2016 at 10:08 PM
Subject: JSON License and Apache Projects
To: legal-discuss@apache.org
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: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Stian Soiland-Reyes <st...@apache.org>.
On 23 November 2016 at 16:21, Sam Ruby <ru...@intertwingly.net> wrote:
>> BTW, has anybody approached json.org to see if they would change their
>> license?
> I've met with Doug personally many times, and discussed this very
> topic. I don't expect him to change his position.
He occasionally grant an extra license like "I give permission to
$company, its customers, partners and minions, to use this software
for evil". Not sure we would want one like that for ASF.. :-))
This youtube link was shared earlier, showing his reasoning:
https://www.youtube.com/watch?v=-hCimLnIsDA
--
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Nov 23, 2016, at 11:21 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Wed, Nov 23, 2016 at 11:11 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>
>> BTW, has anybody approached json.org to see if they would change their
>> license?
>
> I've met with Doug personally many times, and discussed this very
> topic. I don't expect him to change his position.
Heh... same here. I expect he is weary of people asking :)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Ted Dunning <te...@gmail.com>.
Contacting the maintainer might help.
Otherwise, as you say, caveat emptor.
On Wed, Nov 23, 2016 at 11:22 PM, Alex Harui <ah...@adobe.com> wrote:
> I think our project will replace org.json with some Apache project, but
> I'm wondering if there is any obligation to find a way to keep the POM on
> mvnrepository.com from looking like it is ALv2 . Or is it just
> buyer-beware?
>
> -Alex
>
> From: Ted Dunning <te...@gmail.com>
> Reply-To: "legal-discuss@apache.org" <le...@apache.org>
> Date: Wednesday, November 23, 2016 at 11:10 PM
>
> To: "legal-discuss@apache.org" <le...@apache.org>
> Subject: Re: JSON License and Apache Projects
>
>
> I would avoid dealing with this pom. It is a technical inaccurate
> description of a non-open source licensed piece of software.
>
> If you want an open version of the org.json API, see here:
>
> https://github.com/tdunning/open-json
> https://mvnrepository.com/artifact/com.tdunning/json
>
>
>
> On Wed, Nov 23, 2016 at 10:17 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> I don't use GH much, but I don't see a way to contact the owner or open
>> an issue against that repo. Any suggestions on if and how to deal with
>> this pom?
>>
>> -Alex
>>
>> From: Ted Dunning <te...@gmail.com>
>> Reply-To: "legal-discuss@apache.org" <le...@apache.org>
>> Date: Wednesday, November 23, 2016 at 4:01 PM
>> To: "legal-discuss@apache.org" <le...@apache.org>
>> Subject: Re: JSON License and Apache Projects
>>
>>
>> John,
>>
>> The link that Alex provided ( https://mvnrepository.com/ar
>> tifact/org.codeartisans/org.json/20150729 ) is backed up by this source
>> code:
>>
>> https://github.com/eskatos/org.json-java
>>
>> That source code is purely a pom that packages up the original json.org
>> code. It has no source code whatsoever. The README says just this and
>> inspection of the src/ directory shows no additional or modified content.
>>
>> The license clause is simply mis-leading and wrong. It breaks the
>> problematic do-no-evil clause out into a comment instead of recognizing it
>> as part of the license.
>>
>> <licenses>
>> <license>
>> <name>MIT</name>
>> <url>http://opensource.org/licenses/MIT</url>
>> <distribution>repo</distribution>
>> <comments>The software shall be used for good, not
>> evil.</comments>
>> </license>
>> </licenses>
>>
>>
>>
>>
>>
>> On Wed, Nov 23, 2016 at 12:50 PM, John D. Ament <jo...@apache.org>
>> wrote:
>>
>>>
>>>
>>> On Wed, Nov 23, 2016 at 3:34 PM Sam Ruby <ru...@intertwingly.net> wrote:
>>>
>>>> On Wed, Nov 23, 2016 at 2:07 PM, John D. Ament <jo...@apache.org>
>>>> wrote:
>>>> >
>>>> > On Wed, Nov 23, 2016 at 1:16 PM Sam Ruby <ru...@intertwingly.net>
>>>> wrote:
>>>> >>
>>>> >> On Wed, Nov 23, 2016 at 12:21 PM, Justin Mclean
>>>> >> <ju...@classsoftware.com> wrote:
>>>> >> > Hi,
>>>> >> >
>>>> >> >> MIT is OSI certified, compatible with the GPL, and category A.
>>>> >> >>
>>>> >> >> The JSON license is not OSI certified, not compatible with the
>>>> GPL,
>>>> >> >> and (now) category X.
>>>> >> >
>>>> >> > Yep no disagreement from me there.
>>>> >> >
>>>> >> > I should of said it’s based of the text of the MIT license plus
>>>> the “Do
>>>> >> > good not evil bit” which it probably why the pom states MIT.
>>>> >>
>>>> >> All apples are fruit, but not all fruit are apples.
>>>> >>
>>>> >> Religions, Species, and Software Licenses are all examples of
>>>> >> categories where having a "common ancestor" doesn't mean that two
>>>> >> instances of the superclass are compatible.
>>>> >>
>>>> >> The POM is misleading to the point of being unhelpful and incorrect.
>>>> >
>>>> >
>>>> >
>>>> > Just wondering, what POM are you looking at? The true pom has this
>>>> for its
>>>> > license:
>>>> >
>>>> > <licenses>
>>>> > <license>
>>>> > <name>provided without support or warranty</name>
>>>> > <url>http://www.json.org/license.html</url>
>>>> > </license>
>>>> > </licenses>
>>>> >
>>>> > This is the 20090211 version. Similar for the 20080701 version.
>>>> Prior to
>>>> > it had no license declaration.
>>>>
>>>> Here is the link provided earlier in the thread:
>>>>
>>>> https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729
>>>>
>>>> That page indicates that the JAR is made available under the MIT and
>>>> Apache licenses.
>>>>
>>>
>>> Ok, that's what I'm checking on then. The link Alex pointed out is for
>>> a different artifact (binary compatible), different source code.
>>>
>>> Its similar to the google vs oracle copyright an API case.
>>>
>>>
>>>
>>>>
>>>> - Sam Ruby
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>>
>>>>
>>
>
Re: JSON License and Apache Projects
Posted by Alex Harui <ah...@adobe.com>.
I think our project will replace org.json with some Apache project, but I'm wondering if there is any obligation to find a way to keep the POM on mvnrepository.com from looking like it is ALv2 . Or is it just buyer-beware?
-Alex
From: Ted Dunning <te...@gmail.com>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Wednesday, November 23, 2016 at 11:10 PM
To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Subject: Re: JSON License and Apache Projects
I would avoid dealing with this pom. It is a technical inaccurate description of a non-open source licensed piece of software.
If you want an open version of the org.json API, see here:
https://github.com/tdunning/open-json
https://mvnrepository.com/artifact/com.tdunning/json
On Wed, Nov 23, 2016 at 10:17 PM, Alex Harui <ah...@adobe.com>> wrote:
I don't use GH much, but I don't see a way to contact the owner or open an issue against that repo. Any suggestions on if and how to deal with this pom?
-Alex
From: Ted Dunning <te...@gmail.com>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Wednesday, November 23, 2016 at 4:01 PM
To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Subject: Re: JSON License and Apache Projects
John,
The link that Alex provided ( https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729 ) is backed up by this source code:
https://github.com/eskatos/org.json-java
That source code is purely a pom that packages up the original json.org<http://json.org> code. It has no source code whatsoever. The README says just this and inspection of the src/ directory shows no additional or modified content.
The license clause is simply mis-leading and wrong. It breaks the problematic do-no-evil clause out into a comment instead of recognizing it as part of the license.
<licenses>
<license>
<name>MIT</name>
<url>http://opensource.org/licenses/MIT</url>
<distribution>repo</distribution>
<comments>The software shall be used for good, not evil.</comments>
</license>
</licenses>
On Wed, Nov 23, 2016 at 12:50 PM, John D. Ament <jo...@apache.org>> wrote:
On Wed, Nov 23, 2016 at 3:34 PM Sam Ruby <ru...@intertwingly.net>> wrote:
On Wed, Nov 23, 2016 at 2:07 PM, John D. Ament <jo...@apache.org>> wrote:
>
> On Wed, Nov 23, 2016 at 1:16 PM Sam Ruby <ru...@intertwingly.net>> wrote:
>>
>> On Wed, Nov 23, 2016 at 12:21 PM, Justin Mclean
>> <ju...@classsoftware.com>> wrote:
>> > Hi,
>> >
>> >> MIT is OSI certified, compatible with the GPL, and category A.
>> >>
>> >> The JSON license is not OSI certified, not compatible with the GPL,
>> >> and (now) category X.
>> >
>> > Yep no disagreement from me there.
>> >
>> > I should of said it’s based of the text of the MIT license plus the “Do
>> > good not evil bit” which it probably why the pom states MIT.
>>
>> All apples are fruit, but not all fruit are apples.
>>
>> Religions, Species, and Software Licenses are all examples of
>> categories where having a "common ancestor" doesn't mean that two
>> instances of the superclass are compatible.
>>
>> The POM is misleading to the point of being unhelpful and incorrect.
>
>
>
> Just wondering, what POM are you looking at? The true pom has this for its
> license:
>
> <licenses>
> <license>
> <name>provided without support or warranty</name>
> <url>http://www.json.org/license.html</url>
> </license>
> </licenses>
>
> This is the 20090211 version. Similar for the 20080701 version. Prior to
> it had no license declaration.
Here is the link provided earlier in the thread:
https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729
That page indicates that the JAR is made available under the MIT and
Apache licenses.
Ok, that's what I'm checking on then. The link Alex pointed out is for a different artifact (binary compatible), different source code.
Its similar to the google vs oracle copyright an API case.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<ma...@apache.org>
For additional commands, e-mail: legal-discuss-help@apache.org<ma...@apache.org>
Re: JSON License and Apache Projects
Posted by Ted Dunning <te...@gmail.com>.
I would avoid dealing with this pom. It is a technical inaccurate
description of a non-open source licensed piece of software.
If you want an open version of the org.json API, see here:
https://github.com/tdunning/open-json
https://mvnrepository.com/artifact/com.tdunning/json
On Wed, Nov 23, 2016 at 10:17 PM, Alex Harui <ah...@adobe.com> wrote:
> I don't use GH much, but I don't see a way to contact the owner or open an
> issue against that repo. Any suggestions on if and how to deal with this
> pom?
>
> -Alex
>
> From: Ted Dunning <te...@gmail.com>
> Reply-To: "legal-discuss@apache.org" <le...@apache.org>
> Date: Wednesday, November 23, 2016 at 4:01 PM
> To: "legal-discuss@apache.org" <le...@apache.org>
> Subject: Re: JSON License and Apache Projects
>
>
> John,
>
> The link that Alex provided ( https://mvnrepository.com/
> artifact/org.codeartisans/org.json/20150729 ) is backed up by this source
> code:
>
> https://github.com/eskatos/org.json-java
>
> That source code is purely a pom that packages up the original json.org
> code. It has no source code whatsoever. The README says just this and
> inspection of the src/ directory shows no additional or modified content.
>
> The license clause is simply mis-leading and wrong. It breaks the
> problematic do-no-evil clause out into a comment instead of recognizing it
> as part of the license.
>
> <licenses>
> <license>
> <name>MIT</name>
> <url>http://opensource.org/licenses/MIT</url>
> <distribution>repo</distribution>
> <comments>The software shall be used for good, not
> evil.</comments>
> </license>
> </licenses>
>
>
>
>
>
> On Wed, Nov 23, 2016 at 12:50 PM, John D. Ament <jo...@apache.org>
> wrote:
>
>>
>>
>> On Wed, Nov 23, 2016 at 3:34 PM Sam Ruby <ru...@intertwingly.net> wrote:
>>
>>> On Wed, Nov 23, 2016 at 2:07 PM, John D. Ament <jo...@apache.org>
>>> wrote:
>>> >
>>> > On Wed, Nov 23, 2016 at 1:16 PM Sam Ruby <ru...@intertwingly.net>
>>> wrote:
>>> >>
>>> >> On Wed, Nov 23, 2016 at 12:21 PM, Justin Mclean
>>> >> <ju...@classsoftware.com> wrote:
>>> >> > Hi,
>>> >> >
>>> >> >> MIT is OSI certified, compatible with the GPL, and category A.
>>> >> >>
>>> >> >> The JSON license is not OSI certified, not compatible with the GPL,
>>> >> >> and (now) category X.
>>> >> >
>>> >> > Yep no disagreement from me there.
>>> >> >
>>> >> > I should of said it’s based of the text of the MIT license plus the
>>> “Do
>>> >> > good not evil bit” which it probably why the pom states MIT.
>>> >>
>>> >> All apples are fruit, but not all fruit are apples.
>>> >>
>>> >> Religions, Species, and Software Licenses are all examples of
>>> >> categories where having a "common ancestor" doesn't mean that two
>>> >> instances of the superclass are compatible.
>>> >>
>>> >> The POM is misleading to the point of being unhelpful and incorrect.
>>> >
>>> >
>>> >
>>> > Just wondering, what POM are you looking at? The true pom has this for
>>> its
>>> > license:
>>> >
>>> > <licenses>
>>> > <license>
>>> > <name>provided without support or warranty</name>
>>> > <url>http://www.json.org/license.html</url>
>>> > </license>
>>> > </licenses>
>>> >
>>> > This is the 20090211 version. Similar for the 20080701 version.
>>> Prior to
>>> > it had no license declaration.
>>>
>>> Here is the link provided earlier in the thread:
>>>
>>> https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729
>>>
>>> That page indicates that the JAR is made available under the MIT and
>>> Apache licenses.
>>>
>>
>> Ok, that's what I'm checking on then. The link Alex pointed out is for a
>> different artifact (binary compatible), different source code.
>>
>> Its similar to the google vs oracle copyright an API case.
>>
>>
>>
>>>
>>> - Sam Ruby
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>>
>
Re: JSON License and Apache Projects
Posted by Alex Harui <ah...@adobe.com>.
I already got a response that the fix has been published and is propagating. I will try to remember to verify.
From: Alex Harui <ah...@adobe.com>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Thursday, November 24, 2016 at 7:24 AM
To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Subject: Re: JSON License and Apache Projects
I will contact him.
From: "John D. Ament" <jo...@apache.org>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Thursday, November 24, 2016 at 5:28 AM
To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Subject: Re: JSON License and Apache Projects
The guy who published it is a committer/PMC member on Zest. Though I do agree, its generally not a valid release.
John
On Thu, Nov 24, 2016 at 1:18 AM Alex Harui <ah...@adobe.com>> wrote:
I don't use GH much, but I don't see a way to contact the owner or open an issue against that repo. Any suggestions on if and how to deal with this pom?
-Alex
From: Ted Dunning <te...@gmail.com>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Wednesday, November 23, 2016 at 4:01 PM
To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Subject: Re: JSON License and Apache Projects
John,
The link that Alex provided ( https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729 ) is backed up by this source code:
https://github.com/eskatos/org.json-java
That source code is purely a pom that packages up the original json.org<http://json.org> code. It has no source code whatsoever. The README says just this and inspection of the src/ directory shows no additional or modified content.
The license clause is simply mis-leading and wrong. It breaks the problematic do-no-evil clause out into a comment instead of recognizing it as part of the license.
<licenses>
<license>
<name>MIT</name>
<url>http://opensource.org/licenses/MIT</url>
<distribution>repo</distribution>
<comments>The software shall be used for good, not evil.</comments>
</license>
</licenses>
On Wed, Nov 23, 2016 at 12:50 PM, John D. Ament <jo...@apache.org>> wrote:
On Wed, Nov 23, 2016 at 3:34 PM Sam Ruby <ru...@intertwingly.net>> wrote:
On Wed, Nov 23, 2016 at 2:07 PM, John D. Ament <jo...@apache.org>> wrote:
>
> On Wed, Nov 23, 2016 at 1:16 PM Sam Ruby <ru...@intertwingly.net>> wrote:
>>
>> On Wed, Nov 23, 2016 at 12:21 PM, Justin Mclean
>> <ju...@classsoftware.com>> wrote:
>> > Hi,
>> >
>> >> MIT is OSI certified, compatible with the GPL, and category A.
>> >>
>> >> The JSON license is not OSI certified, not compatible with the GPL,
>> >> and (now) category X.
>> >
>> > Yep no disagreement from me there.
>> >
>> > I should of said it’s based of the text of the MIT license plus the “Do
>> > good not evil bit” which it probably why the pom states MIT.
>>
>> All apples are fruit, but not all fruit are apples.
>>
>> Religions, Species, and Software Licenses are all examples of
>> categories where having a "common ancestor" doesn't mean that two
>> instances of the superclass are compatible.
>>
>> The POM is misleading to the point of being unhelpful and incorrect.
>
>
>
> Just wondering, what POM are you looking at? The true pom has this for its
> license:
>
> <licenses>
> <license>
> <name>provided without support or warranty</name>
> <url>http://www.json.org/license.html</url>
> </license>
> </licenses>
>
> This is the 20090211 version. Similar for the 20080701 version. Prior to
> it had no license declaration.
Here is the link provided earlier in the thread:
https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729
That page indicates that the JAR is made available under the MIT and
Apache licenses.
Ok, that's what I'm checking on then. The link Alex pointed out is for a different artifact (binary compatible), different source code.
Its similar to the google vs oracle copyright an API case.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<ma...@apache.org>
For additional commands, e-mail: legal-discuss-help@apache.org<ma...@apache.org>
Re: JSON License and Apache Projects
Posted by Alex Harui <ah...@adobe.com>.
I will contact him.
From: "John D. Ament" <jo...@apache.org>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Thursday, November 24, 2016 at 5:28 AM
To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Subject: Re: JSON License and Apache Projects
The guy who published it is a committer/PMC member on Zest. Though I do agree, its generally not a valid release.
John
On Thu, Nov 24, 2016 at 1:18 AM Alex Harui <ah...@adobe.com>> wrote:
I don't use GH much, but I don't see a way to contact the owner or open an issue against that repo. Any suggestions on if and how to deal with this pom?
-Alex
From: Ted Dunning <te...@gmail.com>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Wednesday, November 23, 2016 at 4:01 PM
To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Subject: Re: JSON License and Apache Projects
John,
The link that Alex provided ( https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729 ) is backed up by this source code:
https://github.com/eskatos/org.json-java
That source code is purely a pom that packages up the original json.org<http://json.org> code. It has no source code whatsoever. The README says just this and inspection of the src/ directory shows no additional or modified content.
The license clause is simply mis-leading and wrong. It breaks the problematic do-no-evil clause out into a comment instead of recognizing it as part of the license.
<licenses>
<license>
<name>MIT</name>
<url>http://opensource.org/licenses/MIT</url>
<distribution>repo</distribution>
<comments>The software shall be used for good, not evil.</comments>
</license>
</licenses>
On Wed, Nov 23, 2016 at 12:50 PM, John D. Ament <jo...@apache.org>> wrote:
On Wed, Nov 23, 2016 at 3:34 PM Sam Ruby <ru...@intertwingly.net>> wrote:
On Wed, Nov 23, 2016 at 2:07 PM, John D. Ament <jo...@apache.org>> wrote:
>
> On Wed, Nov 23, 2016 at 1:16 PM Sam Ruby <ru...@intertwingly.net>> wrote:
>>
>> On Wed, Nov 23, 2016 at 12:21 PM, Justin Mclean
>> <ju...@classsoftware.com>> wrote:
>> > Hi,
>> >
>> >> MIT is OSI certified, compatible with the GPL, and category A.
>> >>
>> >> The JSON license is not OSI certified, not compatible with the GPL,
>> >> and (now) category X.
>> >
>> > Yep no disagreement from me there.
>> >
>> > I should of said it’s based of the text of the MIT license plus the “Do
>> > good not evil bit” which it probably why the pom states MIT.
>>
>> All apples are fruit, but not all fruit are apples.
>>
>> Religions, Species, and Software Licenses are all examples of
>> categories where having a "common ancestor" doesn't mean that two
>> instances of the superclass are compatible.
>>
>> The POM is misleading to the point of being unhelpful and incorrect.
>
>
>
> Just wondering, what POM are you looking at? The true pom has this for its
> license:
>
> <licenses>
> <license>
> <name>provided without support or warranty</name>
> <url>http://www.json.org/license.html</url>
> </license>
> </licenses>
>
> This is the 20090211 version. Similar for the 20080701 version. Prior to
> it had no license declaration.
Here is the link provided earlier in the thread:
https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729
That page indicates that the JAR is made available under the MIT and
Apache licenses.
Ok, that's what I'm checking on then. The link Alex pointed out is for a different artifact (binary compatible), different source code.
Its similar to the google vs oracle copyright an API case.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<ma...@apache.org>
For additional commands, e-mail: legal-discuss-help@apache.org<ma...@apache.org>
Re: JSON License and Apache Projects
Posted by "John D. Ament" <jo...@apache.org>.
The guy who published it is a committer/PMC member on Zest. Though I do
agree, its generally not a valid release.
John
On Thu, Nov 24, 2016 at 1:18 AM Alex Harui <ah...@adobe.com> wrote:
> I don't use GH much, but I don't see a way to contact the owner or open an
> issue against that repo. Any suggestions on if and how to deal with this
> pom?
>
> -Alex
>
> From: Ted Dunning <te...@gmail.com>
> Reply-To: "legal-discuss@apache.org" <le...@apache.org>
> Date: Wednesday, November 23, 2016 at 4:01 PM
> To: "legal-discuss@apache.org" <le...@apache.org>
> Subject: Re: JSON License and Apache Projects
>
>
> John,
>
> The link that Alex provided (
> https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729 )
> is backed up by this source code:
>
> https://github.com/eskatos/org.json-java
>
> That source code is purely a pom that packages up the original json.org
> code. It has no source code whatsoever. The README says just this and
> inspection of the src/ directory shows no additional or modified content.
>
> The license clause is simply mis-leading and wrong. It breaks the
> problematic do-no-evil clause out into a comment instead of recognizing it
> as part of the license.
>
> <licenses>
> <license>
> <name>MIT</name>
> <url>http://opensource.org/licenses/MIT</url>
> <distribution>repo</distribution>
> <comments>The software shall be used for good, not
> evil.</comments>
> </license>
> </licenses>
>
>
>
>
>
> On Wed, Nov 23, 2016 at 12:50 PM, John D. Ament <jo...@apache.org>
> wrote:
>
>
>
> On Wed, Nov 23, 2016 at 3:34 PM Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Wed, Nov 23, 2016 at 2:07 PM, John D. Ament <jo...@apache.org>
> wrote:
> >
> > On Wed, Nov 23, 2016 at 1:16 PM Sam Ruby <ru...@intertwingly.net> wrote:
> >>
> >> On Wed, Nov 23, 2016 at 12:21 PM, Justin Mclean
> >> <ju...@classsoftware.com> wrote:
> >> > Hi,
> >> >
> >> >> MIT is OSI certified, compatible with the GPL, and category A.
> >> >>
> >> >> The JSON license is not OSI certified, not compatible with the GPL,
> >> >> and (now) category X.
> >> >
> >> > Yep no disagreement from me there.
> >> >
> >> > I should of said it’s based of the text of the MIT license plus the
> “Do
> >> > good not evil bit” which it probably why the pom states MIT.
> >>
> >> All apples are fruit, but not all fruit are apples.
> >>
> >> Religions, Species, and Software Licenses are all examples of
> >> categories where having a "common ancestor" doesn't mean that two
> >> instances of the superclass are compatible.
> >>
> >> The POM is misleading to the point of being unhelpful and incorrect.
> >
> >
> >
> > Just wondering, what POM are you looking at? The true pom has this for
> its
> > license:
> >
> > <licenses>
> > <license>
> > <name>provided without support or warranty</name>
> > <url>http://www.json.org/license.html</url>
> > </license>
> > </licenses>
> >
> > This is the 20090211 version. Similar for the 20080701 version. Prior
> to
> > it had no license declaration.
>
> Here is the link provided earlier in the thread:
>
> https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729
>
> That page indicates that the JAR is made available under the MIT and
> Apache licenses.
>
>
> Ok, that's what I'm checking on then. The link Alex pointed out is for a
> different artifact (binary compatible), different source code.
>
> Its similar to the google vs oracle copyright an API case.
>
>
>
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
>
Re: JSON License and Apache Projects
Posted by Alex Harui <ah...@adobe.com>.
I don't use GH much, but I don't see a way to contact the owner or open an issue against that repo. Any suggestions on if and how to deal with this pom?
-Alex
From: Ted Dunning <te...@gmail.com>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Wednesday, November 23, 2016 at 4:01 PM
To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Subject: Re: JSON License and Apache Projects
John,
The link that Alex provided ( https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729 ) is backed up by this source code:
https://github.com/eskatos/org.json-java
That source code is purely a pom that packages up the original json.org<http://json.org> code. It has no source code whatsoever. The README says just this and inspection of the src/ directory shows no additional or modified content.
The license clause is simply mis-leading and wrong. It breaks the problematic do-no-evil clause out into a comment instead of recognizing it as part of the license.
<licenses>
<license>
<name>MIT</name>
<url>http://opensource.org/licenses/MIT</url>
<distribution>repo</distribution>
<comments>The software shall be used for good, not evil.</comments>
</license>
</licenses>
On Wed, Nov 23, 2016 at 12:50 PM, John D. Ament <jo...@apache.org>> wrote:
On Wed, Nov 23, 2016 at 3:34 PM Sam Ruby <ru...@intertwingly.net>> wrote:
On Wed, Nov 23, 2016 at 2:07 PM, John D. Ament <jo...@apache.org>> wrote:
>
> On Wed, Nov 23, 2016 at 1:16 PM Sam Ruby <ru...@intertwingly.net>> wrote:
>>
>> On Wed, Nov 23, 2016 at 12:21 PM, Justin Mclean
>> <ju...@classsoftware.com>> wrote:
>> > Hi,
>> >
>> >> MIT is OSI certified, compatible with the GPL, and category A.
>> >>
>> >> The JSON license is not OSI certified, not compatible with the GPL,
>> >> and (now) category X.
>> >
>> > Yep no disagreement from me there.
>> >
>> > I should of said it’s based of the text of the MIT license plus the “Do
>> > good not evil bit” which it probably why the pom states MIT.
>>
>> All apples are fruit, but not all fruit are apples.
>>
>> Religions, Species, and Software Licenses are all examples of
>> categories where having a "common ancestor" doesn't mean that two
>> instances of the superclass are compatible.
>>
>> The POM is misleading to the point of being unhelpful and incorrect.
>
>
>
> Just wondering, what POM are you looking at? The true pom has this for its
> license:
>
> <licenses>
> <license>
> <name>provided without support or warranty</name>
> <url>http://www.json.org/license.html</url>
> </license>
> </licenses>
>
> This is the 20090211 version. Similar for the 20080701 version. Prior to
> it had no license declaration.
Here is the link provided earlier in the thread:
https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729
That page indicates that the JAR is made available under the MIT and
Apache licenses.
Ok, that's what I'm checking on then. The link Alex pointed out is for a different artifact (binary compatible), different source code.
Its similar to the google vs oracle copyright an API case.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<ma...@apache.org>
For additional commands, e-mail: legal-discuss-help@apache.org<ma...@apache.org>
Re: JSON License and Apache Projects
Posted by Ted Dunning <te...@gmail.com>.
John,
The link that Alex provided (
https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729 ) is
backed up by this source code:
https://github.com/eskatos/org.json-java
That source code is purely a pom that packages up the original json.org
code. It has no source code whatsoever. The README says just this and
inspection of the src/ directory shows no additional or modified content.
The license clause is simply mis-leading and wrong. It breaks the
problematic do-no-evil clause out into a comment instead of recognizing it
as part of the license.
<licenses>
<license>
<name>MIT</name>
<url>http://opensource.org/licenses/MIT</url>
<distribution>repo</distribution>
<comments>The software shall be used for good, not
evil.</comments>
</license>
</licenses>
On Wed, Nov 23, 2016 at 12:50 PM, John D. Ament <jo...@apache.org>
wrote:
>
>
> On Wed, Nov 23, 2016 at 3:34 PM Sam Ruby <ru...@intertwingly.net> wrote:
>
>> On Wed, Nov 23, 2016 at 2:07 PM, John D. Ament <jo...@apache.org>
>> wrote:
>> >
>> > On Wed, Nov 23, 2016 at 1:16 PM Sam Ruby <ru...@intertwingly.net>
>> wrote:
>> >>
>> >> On Wed, Nov 23, 2016 at 12:21 PM, Justin Mclean
>> >> <ju...@classsoftware.com> wrote:
>> >> > Hi,
>> >> >
>> >> >> MIT is OSI certified, compatible with the GPL, and category A.
>> >> >>
>> >> >> The JSON license is not OSI certified, not compatible with the GPL,
>> >> >> and (now) category X.
>> >> >
>> >> > Yep no disagreement from me there.
>> >> >
>> >> > I should of said it’s based of the text of the MIT license plus the
>> “Do
>> >> > good not evil bit” which it probably why the pom states MIT.
>> >>
>> >> All apples are fruit, but not all fruit are apples.
>> >>
>> >> Religions, Species, and Software Licenses are all examples of
>> >> categories where having a "common ancestor" doesn't mean that two
>> >> instances of the superclass are compatible.
>> >>
>> >> The POM is misleading to the point of being unhelpful and incorrect.
>> >
>> >
>> >
>> > Just wondering, what POM are you looking at? The true pom has this for
>> its
>> > license:
>> >
>> > <licenses>
>> > <license>
>> > <name>provided without support or warranty</name>
>> > <url>http://www.json.org/license.html</url>
>> > </license>
>> > </licenses>
>> >
>> > This is the 20090211 version. Similar for the 20080701 version. Prior
>> to
>> > it had no license declaration.
>>
>> Here is the link provided earlier in the thread:
>>
>> https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729
>>
>> That page indicates that the JAR is made available under the MIT and
>> Apache licenses.
>>
>
> Ok, that's what I'm checking on then. The link Alex pointed out is for a
> different artifact (binary compatible), different source code.
>
> Its similar to the google vs oracle copyright an API case.
>
>
>
>>
>> - Sam Ruby
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
Re: JSON License and Apache Projects
Posted by "John D. Ament" <jo...@apache.org>.
On Wed, Nov 23, 2016 at 3:34 PM Sam Ruby <ru...@intertwingly.net> wrote:
> On Wed, Nov 23, 2016 at 2:07 PM, John D. Ament <jo...@apache.org>
> wrote:
> >
> > On Wed, Nov 23, 2016 at 1:16 PM Sam Ruby <ru...@intertwingly.net> wrote:
> >>
> >> On Wed, Nov 23, 2016 at 12:21 PM, Justin Mclean
> >> <ju...@classsoftware.com> wrote:
> >> > Hi,
> >> >
> >> >> MIT is OSI certified, compatible with the GPL, and category A.
> >> >>
> >> >> The JSON license is not OSI certified, not compatible with the GPL,
> >> >> and (now) category X.
> >> >
> >> > Yep no disagreement from me there.
> >> >
> >> > I should of said it’s based of the text of the MIT license plus the
> “Do
> >> > good not evil bit” which it probably why the pom states MIT.
> >>
> >> All apples are fruit, but not all fruit are apples.
> >>
> >> Religions, Species, and Software Licenses are all examples of
> >> categories where having a "common ancestor" doesn't mean that two
> >> instances of the superclass are compatible.
> >>
> >> The POM is misleading to the point of being unhelpful and incorrect.
> >
> >
> >
> > Just wondering, what POM are you looking at? The true pom has this for
> its
> > license:
> >
> > <licenses>
> > <license>
> > <name>provided without support or warranty</name>
> > <url>http://www.json.org/license.html</url>
> > </license>
> > </licenses>
> >
> > This is the 20090211 version. Similar for the 20080701 version. Prior
> to
> > it had no license declaration.
>
> Here is the link provided earlier in the thread:
>
> https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729
>
> That page indicates that the JAR is made available under the MIT and
> Apache licenses.
>
Ok, that's what I'm checking on then. The link Alex pointed out is for a
different artifact (binary compatible), different source code.
Its similar to the google vs oracle copyright an API case.
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: JSON License and Apache Projects
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Nov 23, 2016 at 2:07 PM, John D. Ament <jo...@apache.org> wrote:
>
> On Wed, Nov 23, 2016 at 1:16 PM Sam Ruby <ru...@intertwingly.net> wrote:
>>
>> On Wed, Nov 23, 2016 at 12:21 PM, Justin Mclean
>> <ju...@classsoftware.com> wrote:
>> > Hi,
>> >
>> >> MIT is OSI certified, compatible with the GPL, and category A.
>> >>
>> >> The JSON license is not OSI certified, not compatible with the GPL,
>> >> and (now) category X.
>> >
>> > Yep no disagreement from me there.
>> >
>> > I should of said it’s based of the text of the MIT license plus the “Do
>> > good not evil bit” which it probably why the pom states MIT.
>>
>> All apples are fruit, but not all fruit are apples.
>>
>> Religions, Species, and Software Licenses are all examples of
>> categories where having a "common ancestor" doesn't mean that two
>> instances of the superclass are compatible.
>>
>> The POM is misleading to the point of being unhelpful and incorrect.
>
>
>
> Just wondering, what POM are you looking at? The true pom has this for its
> license:
>
> <licenses>
> <license>
> <name>provided without support or warranty</name>
> <url>http://www.json.org/license.html</url>
> </license>
> </licenses>
>
> This is the 20090211 version. Similar for the 20080701 version. Prior to
> it had no license declaration.
Here is the link provided earlier in the thread:
https://mvnrepository.com/artifact/org.codeartisans/org.json/20150729
That page indicates that the JAR is made available under the MIT and
Apache licenses.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by "John D. Ament" <jo...@apache.org>.
On Wed, Nov 23, 2016 at 1:16 PM Sam Ruby <ru...@intertwingly.net> wrote:
> On Wed, Nov 23, 2016 at 12:21 PM, Justin Mclean
> <ju...@classsoftware.com> wrote:
> > Hi,
> >
> >> MIT is OSI certified, compatible with the GPL, and category A.
> >>
> >> The JSON license is not OSI certified, not compatible with the GPL,
> >> and (now) category X.
> >
> > Yep no disagreement from me there.
> >
> > I should of said it’s based of the text of the MIT license plus the “Do
> good not evil bit” which it probably why the pom states MIT.
>
> All apples are fruit, but not all fruit are apples.
>
> Religions, Species, and Software Licenses are all examples of
> categories where having a "common ancestor" doesn't mean that two
> instances of the superclass are compatible.
>
> The POM is misleading to the point of being unhelpful and incorrect.
>
Just wondering, what POM are you looking at? The true pom has this for its
license:
<licenses>
<license>
<name>provided without support or warranty</name>
<url>http://www.json.org/license.html</url>
</license>
</licenses>
This is the 20090211 version. Similar for the 20080701 version. Prior to
it had no license declaration.
> > Thanks,
> > Justin
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: JSON License and Apache Projects
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Nov 23, 2016 at 12:21 PM, Justin Mclean
<ju...@classsoftware.com> wrote:
> Hi,
>
>> MIT is OSI certified, compatible with the GPL, and category A.
>>
>> The JSON license is not OSI certified, not compatible with the GPL,
>> and (now) category X.
>
> Yep no disagreement from me there.
>
> I should of said it’s based of the text of the MIT license plus the “Do good not evil bit” which it probably why the pom states MIT.
All apples are fruit, but not all fruit are apples.
Religions, Species, and Software Licenses are all examples of
categories where having a "common ancestor" doesn't mean that two
instances of the superclass are compatible.
The POM is misleading to the point of being unhelpful and incorrect.
> Thanks,
> Justin
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> MIT is OSI certified, compatible with the GPL, and category A.
>
> The JSON license is not OSI certified, not compatible with the GPL,
> and (now) category X.
Yep no disagreement from me there.
I should of said it’s based of the text of the MIT license plus the “Do good not evil bit” which it probably why the pom states MIT.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Nov 23, 2016 at 12:01 PM, Justin Mclean
<ju...@classsoftware.com> wrote:
> Hi,
>
>> Are the maven coordinates org.json? Does that mean that this link [1]
>> which implies ALv2 and MIT licensing is incorrect?
>
> It’s modified MIT so MIT is sort of right.
MIT is OSI certified, compatible with the GPL, and category A.
The JSON license is not OSI certified, not compatible with the GPL,
and (now) category X.
> The pom contains:
> <licenses>
> <license>
> <name>MIT</name>
> <url>http://opensource.org/licenses/MIT</url>
> <distribution>repo</distribution>
> <comments>The software shall be used for good, not evil.</comments>
> </license>
> </licenses>
The POM is incorrect.
> But the full license text is here. [1]
>
> Also interesting to note FSF consider it non free [2]
>
> Thanks,
> Justin
>
> 1. http://www.json.org/license.html
> 2. http://directory.fsf.org/wiki/License:JSON
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Are the maven coordinates org.json? Does that mean that this link [1]
> which implies ALv2 and MIT licensing is incorrect?
It’s modified MIT so MIT is sort of right.
The pom contains:
<licenses>
<license>
<name>MIT</name>
<url>http://opensource.org/licenses/MIT</url>
<distribution>repo</distribution>
<comments>The software shall be used for good, not evil.</comments>
</license>
</licenses>
But the full license text is here. [1]
Also interesting to note FSF consider it non free [2]
Thanks,
Justin
1. http://www.json.org/license.html
2. http://directory.fsf.org/wiki/License:JSON
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Alex Harui <ah...@adobe.com>.
On 11/23/16, 8:21 AM, "sa3ruby@gmail.com on behalf of Sam Ruby"
<sa3ruby@gmail.com on behalf of rubys@intertwingly.net> wrote:
>> BTW, has anybody approached json.org to see if they would change their
>> license?
>
>I've met with Doug personally many times, and discussed this very
>topic. I don't expect him to change his position.
Are the maven coordinates org.json? Does that mean that this link [1]
which implies ALv2 and MIT licensing is incorrect?
-Alex
[1] https://mvnrepository.com/artifact/org.codeartisans/org.json
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Nov 23, 2016 at 11:11 AM, Alex Harui <ah...@adobe.com> wrote:
>
> On 11/23/16, 7:26 AM, "Paul Libbrecht" <pa...@hoplahup.net> wrote:
>
>>On 23 Nov 2016, at 16:10, Jim Jagielski <ji...@jaguNET.com> wrote:
>>> Something can't be called Open Source unless it is, well, Open Source
>>> and OSI (and the FSF) are the ones who determine what is and is not.
>>
>>I’ve seen lawyers dispute the OSI right to define that a license is an
>>open-source license.
>>
>>I agree with Sam that we should claim that the foundation has deemed it
>>not open-source and not that OSI has, and maybe assert that the reason
>>was non-verifiability.
>
> I thought the reason was the "no evil" clause. Why can't we say that that
> clause was too open to interpretation to be meet the ASF requirement of
> "brain-dead easy to consume"?
Concurring with OSI's conclusion on this one license is indeed the correct path.
I agree with Paul that no corporation or foundation should abdicate
their role and responsibility for evaluating licenses. That being
said, I do believe that OSI is a source that we should consult with
and weigh heavily.
> BTW, has anybody approached json.org to see if they would change their
> license?
I've met with Doug personally many times, and discussed this very
topic. I don't expect him to change his position.
> -Alex
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Alex Harui <ah...@adobe.com>.
On 11/23/16, 7:26 AM, "Paul Libbrecht" <pa...@hoplahup.net> wrote:
>
>On 23 Nov 2016, at 16:10, Jim Jagielski <ji...@jaguNET.com> wrote:
>> Something can't be called Open Source unless it is, well, Open Source
>> and OSI (and the FSF) are the ones who determine what is and is not.
>
>I’ve seen lawyers dispute the OSI right to define that a license is an
>open-source license.
>
>I agree with Sam that we should claim that the foundation has deemed it
>not open-source and not that OSI has, and maybe assert that the reason
>was non-verifiability.
I thought the reason was the "no evil" clause. Why can't we say that that
clause was too open to interpretation to be meet the ASF requirement of
"brain-dead easy to consume"?
BTW, has anybody approached json.org to see if they would change their
license?
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Nov 23, 2016, at 10:26 AM, Paul Libbrecht <pa...@hoplahup.net> wrote:
>
>
> On 23 Nov 2016, at 16:10, Jim Jagielski <ji...@jaguNET.com> wrote:
>> Something can't be called Open Source unless it is, well, Open Source
>> and OSI (and the FSF) are the ones who determine what is and is not.
>
> I’ve seen lawyers dispute the OSI right to define that a license is an open-source license.
>
> I agree with Sam that we should claim that the foundation has deemed it not open-source and not that OSI has, and maybe assert that the reason was non-verifiability.
>
I stand by what I say. If we want to say we concur w/ OSI, that's fine.
But I refuse to imply that the ASF is a definer of what is,
and is not, Open Source. Period.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Paul Libbrecht <pa...@hoplahup.net>.
On 23 Nov 2016, at 16:10, Jim Jagielski <ji...@jaguNET.com> wrote:
> Something can't be called Open Source unless it is, well, Open Source
> and OSI (and the FSF) are the ones who determine what is and is not.
I’ve seen lawyers dispute the OSI right to define that a license is an open-source license.
I agree with Sam that we should claim that the foundation has deemed it not open-source and not that OSI has, and maybe assert that the reason was non-verifiability.
Paul
Re: JSON License and Apache Projects
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Nov 23, 2016 at 10:10 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> On Nov 23, 2016, at 9:59 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>>
>> On Wed, Nov 23, 2016 at 9:08 AM, Jim Jagielski <ji...@apache.org> wrote:
>>>
>>> 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.
>>
>> Just a small note, the WTFPL is not OSI approved. While I agree with
>> the recategorization of the JSON license; and the fact that we should
>> take into consideration the evaluation of what OSI and others make of
>> licenses; I don't think we should gate any of our decisions on an
>> external entity.
>
> Something can't be called Open Source unless it is, well, Open Source
> and OSI (and the FSF) are the ones who determine what is and is not.
>
> Again, this comes down to the basic tenet that we want consumption and
> usage of ASF projects to be as "brain dead easy" as possible. By having
> a non-OSI license in there, it encourages the legal dept to get
> involved, which disrupts that "easy as possible" meme.
Should the WTFPL be reclassified then?
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Nov 23, 2016, at 9:59 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Wed, Nov 23, 2016 at 9:08 AM, Jim Jagielski <ji...@apache.org> wrote:
>>
>> 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.
>
> Just a small note, the WTFPL is not OSI approved. While I agree with
> the recategorization of the JSON license; and the fact that we should
> take into consideration the evaluation of what OSI and others make of
> licenses; I don't think we should gate any of our decisions on an
> external entity.
>
Something can't be called Open Source unless it is, well, Open Source
and OSI (and the FSF) are the ones who determine what is and is not.
Again, this comes down to the basic tenet that we want consumption and
usage of ASF projects to be as "brain dead easy" as possible. By having
a non-OSI license in there, it encourages the legal dept to get
involved, which disrupts that "easy as possible" meme.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Nov 23, 2016 at 9:08 AM, Jim Jagielski <ji...@apache.org> wrote:
>
> 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.
Just a small note, the WTFPL is not OSI approved. While I agree with
the recategorization of the JSON license; and the fact that we should
take into consideration the evaluation of what OSI and others make of
licenses; I don't think we should gate any of our decisions on an
external entity.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Stian Soiland-Reyes <st...@apache.org>.
Yes, please forward - although this thread has not yet shown up in the
archive at:
https://lists.apache.org/list.html?legal-discuss@apache.org
There's a corresponding private legal list which should NOT be
forwarded from and should be used for confidential cases:
legal-internal@apache.org
On 23 November 2016 at 14:51, Martijn Dashorst
<ma...@gmail.com> wrote:
> Is this a public list, and can I forward this to our dev@ list?
>
> Martijn
>
>
> On Wed, Nov 23, 2016 at 3:08 PM, Jim Jagielski <ji...@apache.org> wrote:
>> 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: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
--
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Jim Jagielski <ji...@jaguNET.com>.
Yes. It is also on board@ so all PMC chairs should now
be aware of this!
> On Nov 23, 2016, at 9:51 AM, Martijn Dashorst <ma...@gmail.com> wrote:
>
> Is this a public list, and can I forward this to our dev@ list?
>
> Martijn
>
>
> On Wed, Nov 23, 2016 at 3:08 PM, Jim Jagielski <ji...@apache.org> wrote:
>> 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: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Martijn Dashorst <ma...@gmail.com>.
Is this a public list, and can I forward this to our dev@ list?
Martijn
On Wed, Nov 23, 2016 at 3:08 PM, Jim Jagielski <ji...@apache.org> wrote:
> 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: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by Sebastien <se...@gmail.com>.
I'm +1 for jackson. We already use it in wicket-extensions
https://github.com/apache/wicket/blob/master/wicket-extensions/src/main/java/org/apache/wicket/extensions/requestlogger/JsonRequestLogger.java#L22
Moreover, I'm personally fine to rely on a 3rd party library for JSON
objects. That way you can use the same library back-end side and get the
JSON objects back (no deserialization issues, which is not true if a
specific JSON lib is front-end side only, like for our JSON internal lib)
On Wed, Nov 23, 2016 at 5:16 PM, Martijn Dashorst <
martijn.dashorst@gmail.com> wrote:
> Another option would be to use jackson and use the JSON classes in
> Wicket as API wrappers.
>
> Martijn
>
Re: JSON License and Apache Projects
Posted by Martijn Dashorst <ma...@gmail.com>.
Another option would be to use jackson and use the JSON classes in
Wicket as API wrappers.
Martijn
On Wed, Nov 23, 2016 at 5:16 PM, Martijn Dashorst
<ma...@gmail.com> wrote:
> Ted Dunning has created this package:
>
> https://github.com/tdunning/open-json
>
> Martijn
>
>
> On Wed, Nov 23, 2016 at 5:13 PM, Martijn Dashorst
> <ma...@gmail.com> wrote:
>> OK,
>>
>> So we need to exorcise the JSON code from our project. This has to be
>> done in all active branches.
>>
>> It also occurred to me that the licensing for these files is
>> incorrectly implemented: the JSON license should also be in /licenses
>> so that the release script will add it to the LICENSE file upon
>> release.
>>
>> Martijn
>>
>>
>> On Wed, Nov 23, 2016 at 4:51 PM, Sebastien <se...@gmail.com> wrote:
>>> Looking at
>>> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/json/README
>>>
>>> The link https://github.com/douglascrockford/JSON-java redirects to
>>> https://github.com/stleary/JSON-java/
>>>
>>> And, https://github.com/stleary/JSON-java/blob/master/LICENSE indicates
>>> that the library is JSON.org licensed.
>>> So, is our copy be affected by the new license terms?
>>>
>>>
>>>
>>> On Wed, Nov 23, 2016 at 4:43 PM, Martin Grigorov <mg...@apache.org>
>>> wrote:
>>>
>>>> We do not depend on it but use a copy of it:
>>>> https://github.com/apache/wicket/tree/master/wicket-
>>>> core/src/main/java/org/apache/wicket/ajax/json
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>> On Wed, Nov 23, 2016 at 4:36 PM, Martijn Dashorst <da...@apache.org>
>>>> wrote:
>>>>
>>>> > FYI: the json.org library for parsing and generating JSON documents
>>>> > is now category X, which means it is prohibited from being included
>>>> > in Apache releases.
>>>> >
>>>> > As far as I know we are not exposed, but we should be diligent and
>>>> > make note of this and replace if we do have a (transitive)
>>>> > dependency.
>>>> >
>>>> > The issue is the "don't use this for evil" clause, that makes it hard to
>>>> > get past legal departments without any issue. The license is also not
>>>> > approved by the OSI, and therefore moved to the category X.
>>>> >
>>>> > Martijn
>>>> >
>>>> >
>>>> >
>>>> > ---------- Forwarded message ----------
>>>> > From: Jim Jagielski <ji...@apache.org>
>>>> > Date: Wed, Nov 23, 2016 at 3:08 PM
>>>> > Subject: JSON License and Apache Projects
>>>> > To: legal-discuss@apache.org
>>>> >
>>>> >
>>>> > 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: legal-discuss-unsubscribe@apache.org
>>>> > For additional commands, e-mail: legal-discuss-help@apache.org
>>>> >
>>>>
>>
>>
>>
>> --
>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: JSON License and Apache Projects
Posted by Martijn Dashorst <ma...@gmail.com>.
Ted Dunning has created this package:
https://github.com/tdunning/open-json
Martijn
On Wed, Nov 23, 2016 at 5:13 PM, Martijn Dashorst
<ma...@gmail.com> wrote:
> OK,
>
> So we need to exorcise the JSON code from our project. This has to be
> done in all active branches.
>
> It also occurred to me that the licensing for these files is
> incorrectly implemented: the JSON license should also be in /licenses
> so that the release script will add it to the LICENSE file upon
> release.
>
> Martijn
>
>
> On Wed, Nov 23, 2016 at 4:51 PM, Sebastien <se...@gmail.com> wrote:
>> Looking at
>> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/json/README
>>
>> The link https://github.com/douglascrockford/JSON-java redirects to
>> https://github.com/stleary/JSON-java/
>>
>> And, https://github.com/stleary/JSON-java/blob/master/LICENSE indicates
>> that the library is JSON.org licensed.
>> So, is our copy be affected by the new license terms?
>>
>>
>>
>> On Wed, Nov 23, 2016 at 4:43 PM, Martin Grigorov <mg...@apache.org>
>> wrote:
>>
>>> We do not depend on it but use a copy of it:
>>> https://github.com/apache/wicket/tree/master/wicket-
>>> core/src/main/java/org/apache/wicket/ajax/json
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Wed, Nov 23, 2016 at 4:36 PM, Martijn Dashorst <da...@apache.org>
>>> wrote:
>>>
>>> > FYI: the json.org library for parsing and generating JSON documents
>>> > is now category X, which means it is prohibited from being included
>>> > in Apache releases.
>>> >
>>> > As far as I know we are not exposed, but we should be diligent and
>>> > make note of this and replace if we do have a (transitive)
>>> > dependency.
>>> >
>>> > The issue is the "don't use this for evil" clause, that makes it hard to
>>> > get past legal departments without any issue. The license is also not
>>> > approved by the OSI, and therefore moved to the category X.
>>> >
>>> > Martijn
>>> >
>>> >
>>> >
>>> > ---------- Forwarded message ----------
>>> > From: Jim Jagielski <ji...@apache.org>
>>> > Date: Wed, Nov 23, 2016 at 3:08 PM
>>> > Subject: JSON License and Apache Projects
>>> > To: legal-discuss@apache.org
>>> >
>>> >
>>> > 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: legal-discuss-unsubscribe@apache.org
>>> > For additional commands, e-mail: legal-discuss-help@apache.org
>>> >
>>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: JSON License and Apache Projects
Posted by Martijn Dashorst <ma...@gmail.com>.
OK,
So we need to exorcise the JSON code from our project. This has to be
done in all active branches.
It also occurred to me that the licensing for these files is
incorrectly implemented: the JSON license should also be in /licenses
so that the release script will add it to the LICENSE file upon
release.
Martijn
On Wed, Nov 23, 2016 at 4:51 PM, Sebastien <se...@gmail.com> wrote:
> Looking at
> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/json/README
>
> The link https://github.com/douglascrockford/JSON-java redirects to
> https://github.com/stleary/JSON-java/
>
> And, https://github.com/stleary/JSON-java/blob/master/LICENSE indicates
> that the library is JSON.org licensed.
> So, is our copy be affected by the new license terms?
>
>
>
> On Wed, Nov 23, 2016 at 4:43 PM, Martin Grigorov <mg...@apache.org>
> wrote:
>
>> We do not depend on it but use a copy of it:
>> https://github.com/apache/wicket/tree/master/wicket-
>> core/src/main/java/org/apache/wicket/ajax/json
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Wed, Nov 23, 2016 at 4:36 PM, Martijn Dashorst <da...@apache.org>
>> wrote:
>>
>> > FYI: the json.org library for parsing and generating JSON documents
>> > is now category X, which means it is prohibited from being included
>> > in Apache releases.
>> >
>> > As far as I know we are not exposed, but we should be diligent and
>> > make note of this and replace if we do have a (transitive)
>> > dependency.
>> >
>> > The issue is the "don't use this for evil" clause, that makes it hard to
>> > get past legal departments without any issue. The license is also not
>> > approved by the OSI, and therefore moved to the category X.
>> >
>> > Martijn
>> >
>> >
>> >
>> > ---------- Forwarded message ----------
>> > From: Jim Jagielski <ji...@apache.org>
>> > Date: Wed, Nov 23, 2016 at 3:08 PM
>> > Subject: JSON License and Apache Projects
>> > To: legal-discuss@apache.org
>> >
>> >
>> > 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: legal-discuss-unsubscribe@apache.org
>> > For additional commands, e-mail: legal-discuss-help@apache.org
>> >
>>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: JSON License and Apache Projects
Posted by Sebastien <se...@gmail.com>.
Looking at
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/json/README
The link https://github.com/douglascrockford/JSON-java redirects to
https://github.com/stleary/JSON-java/
And, https://github.com/stleary/JSON-java/blob/master/LICENSE indicates
that the library is JSON.org licensed.
So, is our copy be affected by the new license terms?
On Wed, Nov 23, 2016 at 4:43 PM, Martin Grigorov <mg...@apache.org>
wrote:
> We do not depend on it but use a copy of it:
> https://github.com/apache/wicket/tree/master/wicket-
> core/src/main/java/org/apache/wicket/ajax/json
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Nov 23, 2016 at 4:36 PM, Martijn Dashorst <da...@apache.org>
> wrote:
>
> > FYI: the json.org library for parsing and generating JSON documents
> > is now category X, which means it is prohibited from being included
> > in Apache releases.
> >
> > As far as I know we are not exposed, but we should be diligent and
> > make note of this and replace if we do have a (transitive)
> > dependency.
> >
> > The issue is the "don't use this for evil" clause, that makes it hard to
> > get past legal departments without any issue. The license is also not
> > approved by the OSI, and therefore moved to the category X.
> >
> > Martijn
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Jim Jagielski <ji...@apache.org>
> > Date: Wed, Nov 23, 2016 at 3:08 PM
> > Subject: JSON License and Apache Projects
> > To: legal-discuss@apache.org
> >
> >
> > 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: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
Re: JSON License and Apache Projects
Posted by Sebastien <se...@gmail.com>.
Looking at
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/json/README
The link https://github.com/douglascrockford/JSON-java redirects to
https://github.com/stleary/JSON-java/
And, https://github.com/stleary/JSON-java/blob/master/LICENSE indicates
that the library is JSON.org licensed.
So, is our copy be affected by the new license terms?
On Wed, Nov 23, 2016 at 4:43 PM, Martin Grigorov <mg...@apache.org>
wrote:
> We do not depend on it but use a copy of it:
> https://github.com/apache/wicket/tree/master/wicket-
> core/src/main/java/org/apache/wicket/ajax/json
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Nov 23, 2016 at 4:36 PM, Martijn Dashorst <da...@apache.org>
> wrote:
>
> > FYI: the json.org library for parsing and generating JSON documents
> > is now category X, which means it is prohibited from being included
> > in Apache releases.
> >
> > As far as I know we are not exposed, but we should be diligent and
> > make note of this and replace if we do have a (transitive)
> > dependency.
> >
> > The issue is the "don't use this for evil" clause, that makes it hard to
> > get past legal departments without any issue. The license is also not
> > approved by the OSI, and therefore moved to the category X.
> >
> > Martijn
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Jim Jagielski <ji...@apache.org>
> > Date: Wed, Nov 23, 2016 at 3:08 PM
> > Subject: JSON License and Apache Projects
> > To: legal-discuss@apache.org
> >
> >
> > 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: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
Re: JSON License and Apache Projects
Posted by Martin Grigorov <mg...@apache.org>.
We do not depend on it but use a copy of it:
https://github.com/apache/wicket/tree/master/wicket-core/src/main/java/org/apache/wicket/ajax/json
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Nov 23, 2016 at 4:36 PM, Martijn Dashorst <da...@apache.org>
wrote:
> FYI: the json.org library for parsing and generating JSON documents
> is now category X, which means it is prohibited from being included
> in Apache releases.
>
> As far as I know we are not exposed, but we should be diligent and
> make note of this and replace if we do have a (transitive)
> dependency.
>
> The issue is the "don't use this for evil" clause, that makes it hard to
> get past legal departments without any issue. The license is also not
> approved by the OSI, and therefore moved to the category X.
>
> Martijn
>
>
>
> ---------- Forwarded message ----------
> From: Jim Jagielski <ji...@apache.org>
> Date: Wed, Nov 23, 2016 at 3:08 PM
> Subject: JSON License and Apache Projects
> To: legal-discuss@apache.org
>
>
> 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: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
Re: JSON License and Apache Projects
Posted by Maxim Solodovnik <so...@gmail.com>.
In case it is about this: org.json:json:jar:20090211 libarary
I'm afraid wicketstuff is affected
Could you please confirm it is about this library?
On Wed, Nov 23, 2016 at 10:36 PM, Martijn Dashorst <da...@apache.org>
wrote:
> FYI: the json.org library for parsing and generating JSON documents
> is now category X, which means it is prohibited from being included
> in Apache releases.
>
> As far as I know we are not exposed, but we should be diligent and
> make note of this and replace if we do have a (transitive)
> dependency.
>
> The issue is the "don't use this for evil" clause, that makes it hard to
> get past legal departments without any issue. The license is also not
> approved by the OSI, and therefore moved to the category X.
>
> Martijn
>
>
>
> ---------- Forwarded message ----------
> From: Jim Jagielski <ji...@apache.org>
> Date: Wed, Nov 23, 2016 at 3:08 PM
> Subject: JSON License and Apache Projects
> To: legal-discuss@apache.org
>
>
> 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: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
--
WBR
Maxim aka solomax
Re: JSON License and Apache Projects
Posted by Martin Grigorov <mg...@apache.org>.
We do not depend on it but use a copy of it:
https://github.com/apache/wicket/tree/master/wicket-core/src/main/java/org/apache/wicket/ajax/json
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Nov 23, 2016 at 4:36 PM, Martijn Dashorst <da...@apache.org>
wrote:
> FYI: the json.org library for parsing and generating JSON documents
> is now category X, which means it is prohibited from being included
> in Apache releases.
>
> As far as I know we are not exposed, but we should be diligent and
> make note of this and replace if we do have a (transitive)
> dependency.
>
> The issue is the "don't use this for evil" clause, that makes it hard to
> get past legal departments without any issue. The license is also not
> approved by the OSI, and therefore moved to the category X.
>
> Martijn
>
>
>
> ---------- Forwarded message ----------
> From: Jim Jagielski <ji...@apache.org>
> Date: Wed, Nov 23, 2016 at 3:08 PM
> Subject: JSON License and Apache Projects
> To: legal-discuss@apache.org
>
>
> 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: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
Re: JSON License and Apache Projects
Posted by Maxim Solodovnik <so...@gmail.com>.
In case it is about this: org.json:json:jar:20090211 libarary
I'm afraid wicketstuff is affected
Could you please confirm it is about this library?
On Wed, Nov 23, 2016 at 10:36 PM, Martijn Dashorst <da...@apache.org>
wrote:
> FYI: the json.org library for parsing and generating JSON documents
> is now category X, which means it is prohibited from being included
> in Apache releases.
>
> As far as I know we are not exposed, but we should be diligent and
> make note of this and replace if we do have a (transitive)
> dependency.
>
> The issue is the "don't use this for evil" clause, that makes it hard to
> get past legal departments without any issue. The license is also not
> approved by the OSI, and therefore moved to the category X.
>
> Martijn
>
>
>
> ---------- Forwarded message ----------
> From: Jim Jagielski <ji...@apache.org>
> Date: Wed, Nov 23, 2016 at 3:08 PM
> Subject: JSON License and Apache Projects
> To: legal-discuss@apache.org
>
>
> 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: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
--
WBR
Maxim aka solomax
Fwd: JSON License and Apache Projects
Posted by Martijn Dashorst <da...@apache.org>.
FYI: the json.org library for parsing and generating JSON documents
is now category X, which means it is prohibited from being included
in Apache releases.
As far as I know we are not exposed, but we should be diligent and
make note of this and replace if we do have a (transitive)
dependency.
The issue is the "don't use this for evil" clause, that makes it hard to
get past legal departments without any issue. The license is also not
approved by the OSI, and therefore moved to the category X.
Martijn
---------- Forwarded message ----------
From: Jim Jagielski <ji...@apache.org>
Date: Wed, Nov 23, 2016 at 3:08 PM
Subject: JSON License and Apache Projects
To: legal-discuss@apache.org
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: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
(cc board@ so PMC chairs are included)
Thanks Jim for providing decisive, actionable guidance on the issue. Affected PMCs now have unambiguous paths forward for addressing the issue.
If Jim has no objections, I'd encourage PMC Chairs to forward this to their respective dev@ lists, whether affected or not. It's a good reminder of both the importance and difficulties of OSS licensing. It would also serve as a reminder of why the legal*@ lists exist and encourage more individuals to follow those discussions.
-Taylor
> On Nov 23, 2016, at 9:08 AM, Jim Jagielski <ji...@apache.org> wrote:
>
> 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: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Fwd: JSON License and Apache Projects
Posted by Stian Soiland-Reyes <st...@apache.org>.
We need to check we are not using org.json as the JSON.org license has
been verified as NOT open source.
See below from Legal VP - tl;dr: "The Software shall be used for Good,
not Evil." is an ambiguous restriction of use!
It seems org.json is used in taverna-mobile -- possibly through the
Apache-licensed clean-room implementation of org.json (part of Android
SDK I believe), but that needs to be verified:
./incubator-taverna-mobile/app/src/main/java/org/apache/taverna/mobile/utils/WorkflowDB.java:import
org.json.JSONArray;
./incubator-taverna-mobile/app/src/main/java/org/apache/taverna/mobile/utils/WorkflowDB.java:import
org.json.JSONException;
./incubator-taverna-mobile/app/src/main/java/org/apache/taverna/mobile/utils/WorkflowDB.java:import
org.json.JSONObject;
(..)
./incubator-taverna-common-activities/taverna-interaction-activity/src/main/resources/json2.js
is also from json.org - but it has a permissive Public Domain license
(which has other issues) but otherwise is OK.
(as mentioned in LICENSE for incubator-taverna-common-activities)
(If you found the JSON license funny - see here:
---------- Forwarded message ----------
From: Jim Jagielski <ji...@apache.org>
Date: 23 November 2016 at 14:08
Subject: JSON License and Apache Projects
To: legal-discuss@apache.org
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: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
--
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718
Re: JSON License and Apache Projects
Posted by Jim Jagielski <ji...@jaguNET.com>.
Since 'OpenSSL+RSA license' is not in any way part of
this discussion, I have no idea what you are referring
to.
If you have a specific question, then please ask.
> On Nov 27, 2016, at 12:05 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> [Note private/public x-post]
>
> On Wed, Nov 23, 2016 at 8:08 AM, Jim Jagielski <ji...@apache.org> wrote:
>
> Therefore, w/ my VP Legal hat on, I am making the following
> statements:
>
> 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.
>
> So as we are to understand it, OpenSSL+RSA license with all of its
> wrinkles and warts, is similarly disallowed on an expedited timeframe,
> including removal of mod_ssl from httpd?
>
> Just want to ensure that I'm understanding how 'legal-hat' is applying
> policy equitably and fairly throughout the foundation's activities. I'm
> certain httpd project and others will also comply.
>
> Cheers,
>
> Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: JSON License and Apache Projects
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
[Note private/public x-post]
On Wed, Nov 23, 2016 at 8:08 AM, Jim Jagielski <ji...@apache.org> wrote:
>
> Therefore, w/ my VP Legal hat on, I am making the following
> statements:
>
> 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.
>
So as we are to understand it, OpenSSL+RSA license with all of its
wrinkles and warts, is similarly disallowed on an expedited timeframe,
including removal of mod_ssl from httpd?
Just want to ensure that I'm understanding how 'legal-hat' is applying
policy equitably and fairly throughout the foundation's activities. I'm
certain httpd project and others will also comply.
Cheers,
Bill
JSON License and Apache Projects
Posted by Jim Jagielski <ji...@apache.org>.
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: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
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 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
Fwd: JSON License and Apache Projects
Posted by Ted Dunning <te...@gmail.com>.
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: A grace period for getting rid of JSON license jars
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
IMHO this discussion Hans (understandably) veered a bit off course to a technical discussion that's arguably a bit off topic.
While one of the main projects I work on is very, very minimally affected by this, it is nonetheless affected. And there are large projects that are very seriously affected.
I humbly ask that we take technical discussions to a more appropriate dev list.
The main questions I think a lot of PMCs are wondering about are:
Will there be a grace period? If so, what's the deadline?
I also think there needs to be some sort of action notifying PMCs of the issue. There's no guarantee that everyone who needs to be aware of this is subscribed to this list.
-Taylor
> On Nov 22, 2016, at 6:16 PM, Ted Dunning <te...@gmail.com> wrote:
>
>
>> On Tue, Nov 22, 2016 at 11:15 AM, Jochen Wiedmann <jo...@gmail.com> wrote:
>> > On Tue, Nov 22, 2016 at 1:48 AM, sebb <se...@gmail.com> wrote:
>> >>
>> >>
>> >> >> I can see how that could work for an individual case, but do we really
>> >> >> want to release a jar that *requires* the poms to be patched?
>> >> >
>> >> >
>> >> > I think that the patching is at the Apache project level.
>> >>
>> >> Yes, but every project that uses the new jar will need to consider
>> >> patching.
>>
>> Be that as it may. We say "Don't use json.org." And we (maybe, rather,
>> Ted) suggest an alternative, which may have some problems attached to
>> it. But, that is (IMO) way better than just the "Don't" part.
>
> And further, if sebb wants to add another approach with different caveats, that's great. Better than what we have.
>
> That said, I have already had private email saying that providing SOME alternative has made at least one person decide to back off from flaming the board over this. So carrot and stick seems to be helping.
>
>
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
On Tue, Nov 22, 2016 at 11:15 AM, Jochen Wiedmann <jochen.wiedmann@gmail.com
> wrote:
> > On Tue, Nov 22, 2016 at 1:48 AM, sebb <se...@gmail.com> wrote:
> >>
> >>
> >> >> I can see how that could work for an individual case, but do we
> really
> >> >> want to release a jar that *requires* the poms to be patched?
> >> >
> >> >
> >> > I think that the patching is at the Apache project level.
> >>
> >> Yes, but every project that uses the new jar will need to consider
> >> patching.
>
> Be that as it may. We say "Don't use json.org." And we (maybe, rather,
> Ted) suggest an alternative, which may have some problems attached to
> it. But, that is (IMO) way better than just the "Don't" part.
And further, if sebb wants to add another approach with different caveats,
that's great. Better than what we have.
That said, I have already had private email saying that providing SOME
alternative has made at least one person decide to back off from flaming
the board over this. So carrot and stick seems to be helping.
Re: A grace period for getting rid of JSON license jars
Posted by Jochen Wiedmann <jo...@gmail.com>.
> On Tue, Nov 22, 2016 at 1:48 AM, sebb <se...@gmail.com> wrote:
>>
>>
>> >> I can see how that could work for an individual case, but do we really
>> >> want to release a jar that *requires* the poms to be patched?
>> >
>> >
>> > I think that the patching is at the Apache project level.
>>
>> Yes, but every project that uses the new jar will need to consider
>> patching.
Be that as it may. We say "Don't use json.org." And we (maybe, rather,
Ted) suggest an alternative, which may have some problems attached to
it. But, that is (IMO) way better than just the "Don't" part.
Jochen
--
The next time you hear: "Don't reinvent the wheel!"
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
On Tue, Nov 22, 2016 at 1:48 AM, sebb <se...@gmail.com> wrote:
>
> >> I can see how that could work for an individual case, but do we really
> >> want to release a jar that *requires* the poms to be patched?
> >
> >
> > I think that the patching is at the Apache project level.
>
> Yes, but every project that uses the new jar will need to consider
> patching.
>
The basic alternatives are:
1) pom level manipulations, possibly including shading but definitely
including changing the reference to be to a different pom. This can handle
the cases of direct use of the problem package and transitive use via
dependencies. As you say, this leaks changes in the org.json component to
the downstream user of the Apache project (but that can be limited in
extent and effect using shading).
or
2) pom AND code manipulations. At the least, this would include changing
dependencies and imports. And it doesn't actually help with the case of
dependencies which use the problematic package. In the ideal case, it
involves changing the way that JSON is handled by moving to something like
Jackson, but this change must include all dependencies.
Note that continuing to use the json.org artifacts as currently licensed is
NOT an option. That is what is really causing the real sand in the gears.
Our only choices now are to choose which palliative measures we take in
removing that dependency. Some such measures can be done quickly and
others will take longer.
> >>
> >> Every time a 3rd party project uses an ASF project containing this
> >> replacement jar they will potentially have to patch their poms.
> >> That does not seem sensible.
> >
> >
> > I didn't hear that.
>
> The solution to my claim of jar hell explained how to fix it in a
> particular project.
> I only realised last night that of course it would have to be done by
> every affected project.
>
The only effect on downstream users will be that they may have to import
the original json.org jar (if we shade) or they may have access to a more
restrictive set of capabilities than before (if we don't).
> >> Furthermore, if the jars ever diverge, no amount of pom patching will
> >> solve the issue.
> >
> >
> > I don't agree with this.
>
> Do you mean that jars will never diverge?
> Or that it does not matter?
>
That it doesn't matter. Apache projects should move away from dependency on
json.org's artifacts or simulacra of same such as what I have released. If
they don't move away, that means that they are happy with what they got and
changes to something that they aren't using shouldn't have much effect.
>
> The Java classpath only allows a single copy of each class on the same
> classpath.
> So if the two jars have different versions of the same class, only one
> of the classes can be present.
> So if component A needs the old jar version and component B expects
> the new jar version, at least one of them will be disappointed.
>
Indeed. Thus shading.
>
> >>
> >> Please, let's do this properly.
> >
> >
> > Fine. The right way to do this is to move to Jackson. But that will take
> > longer.
> >
> > I merely offer an interim solution that can be used safely in some
> > situations.
>
> I contend that it is not safe to do this.
> At best the solution is unnecessarily fragile.
>
Isn't this choice up to the projects? I don't see why legal-discuss is the
proper venue for technical decisions.
If you have alternative approaches, that is great. Release something or
patch a project as a demo. All I have done is propose one alternative. It
has costs, limitations and defects, as do all approaches.
I should point out that the code I have packaged so far is, ahem, open
source. Please feel free to provide a patch. Or fork it to provide an
alternative.
>
> Interim solutions have a way of becoming permanent, or at least longer
> lived than you intended and anticipated.
>
> > See for instance the twitter4j case. Likewise the Hive case
> > (possibly with the addition of a little shade).
>
> I'm not disputing that the solution should work now.
> I am saying that it is ill-advised.
>
Not our decision here.
We trust projects to make their own technical decisions.
The only decision that is out of bounds here is to continue use of json.org's
artifacts.
Re: A grace period for getting rid of JSON license jars
Posted by sebb <se...@gmail.com>.
On 22 November 2016 at 09:07, Ted Dunning <te...@gmail.com> wrote:
>
>
> On Tue, Nov 22, 2016 at 12:52 AM, sebb <se...@gmail.com> wrote:
>>
>> There has been a suggestion that jar hell can be avoided by patching the
>> poms.
>> I can see how that could work for an individual case, but do we really
>> want to release a jar that *requires* the poms to be patched?
>
>
> I think that the patching is at the Apache project level.
Yes, but every project that uses the new jar will need to consider patching.
>>
>> Every time a 3rd party project uses an ASF project containing this
>> replacement jar they will potentially have to patch their poms.
>> That does not seem sensible.
>
>
> I didn't hear that.
The solution to my claim of jar hell explained how to fix it in a
particular project.
I only realised last night that of course it would have to be done by
every affected project.
> You are right that doesn't seem super sensible.
>
>>
>> Furthermore, if the jars ever diverge, no amount of pom patching will
>> solve the issue.
>
>
> I don't agree with this.
Do you mean that jars will never diverge?
Or that it does not matter?
The Java classpath only allows a single copy of each class on the same
classpath.
So if the two jars have different versions of the same class, only one
of the classes can be present.
So if component A needs the old jar version and component B expects
the new jar version, at least one of them will be disappointed.
>>
>> Please, let's do this properly.
>
>
> Fine. The right way to do this is to move to Jackson. But that will take
> longer.
>
> I merely offer an interim solution that can be used safely in some
> situations.
I contend that it is not safe to do this.
At best the solution is unnecessarily fragile.
Interim solutions have a way of becoming permanent, or at least longer
lived than you intended and anticipated.
> See for instance the twitter4j case. Likewise the Hive case
> (possibly with the addition of a little shade).
I'm not disputing that the solution should work now.
I am saying that it is ill-advised.
>
>
>> On 21 November 2016 at 21:12, Ted Dunning <te...@gmail.com> wrote:
>> >
>> > On Mon, Nov 21, 2016 at 11:01 AM, sebb <se...@gmail.com> wrote:
>> >>
>> >> > This preference is equivalent to "unable or unwilling to make proper
>> >> > Apache
>> >> > releases".
>> >>
>> >> I did not mean ASF projects.
>> >> I was thinking about 3rd party code that is used by ASF code.
>> >
>> >
>> > So far, we don't have any examples of this. The only source code
>> > dependency
>> > in a dependency case so far is twitter4j and it was easily dealt with
>> > and
>> > the community is receptive.
>> >
>> > Projects which depend on the org.json version of the code in a
>> > non-optional
>> > way where those projects will not change to fix the problem will become
>> > unusable by ASF code. The ASF projects that use these dependencies will
>> > become unreleasable unless they make some sort of change.
>> >
>> > That would suck. No doubt. No argument about that.
>> >
>> > But that situation is still theoretical. We have no examples of this.
>> >
>> > Let's work the problem as it exists right now.
>> >
>> >
>> >>
>> >>
>> >> > The JSON license is unacceptable. It puts ill-defined constraints on
>> >> > the
>> >> > downstream users. It isn't open source. It can't be a dependency for
>> >> > a
>> >> > proper Apache release.
>> >> >
>> >> > The library I have created is one way around the problem, but it is
>> >> > definitely not a long-term solution.
>> >>
>> >> The problem is, once it has been released, it's going to be difficult
>> >> to un-release it...
>> >
>> >
>> > I don't plan to un-release it. But I do plan to help projects move away
>> > from
>> > depending on my library. The best departure direction is probably
>> > jackson.
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
On Tue, Nov 22, 2016 at 12:52 AM, sebb <se...@gmail.com> wrote:
> There has been a suggestion that jar hell can be avoided by patching the
> poms.
> I can see how that could work for an individual case, but do we really
> want to release a jar that *requires* the poms to be patched?
>
I think that the patching is at the Apache project level.
> Every time a 3rd party project uses an ASF project containing this
> replacement jar they will potentially have to patch their poms.
> That does not seem sensible.
>
I didn't hear that.
You are right that doesn't seem super sensible.
> Furthermore, if the jars ever diverge, no amount of pom patching will
> solve the issue.
>
I don't agree with this.
> Please, let's do this properly.
>
Fine. The right way to do this is to move to Jackson. But that will take
longer.
I merely offer an interim solution that can be used safely in some
situations. See for instance the twitter4j case. Likewise the Hive case
(possibly with the addition of a little shade).
On 21 November 2016 at 21:12, Ted Dunning <te...@gmail.com> wrote:
> >
> > On Mon, Nov 21, 2016 at 11:01 AM, sebb <se...@gmail.com> wrote:
> >>
> >> > This preference is equivalent to "unable or unwilling to make proper
> >> > Apache
> >> > releases".
> >>
> >> I did not mean ASF projects.
> >> I was thinking about 3rd party code that is used by ASF code.
> >
> >
> > So far, we don't have any examples of this. The only source code
> dependency
> > in a dependency case so far is twitter4j and it was easily dealt with and
> > the community is receptive.
> >
> > Projects which depend on the org.json version of the code in a
> non-optional
> > way where those projects will not change to fix the problem will become
> > unusable by ASF code. The ASF projects that use these dependencies will
> > become unreleasable unless they make some sort of change.
> >
> > That would suck. No doubt. No argument about that.
> >
> > But that situation is still theoretical. We have no examples of this.
> >
> > Let's work the problem as it exists right now.
> >
> >
> >>
> >>
> >> > The JSON license is unacceptable. It puts ill-defined constraints on
> the
> >> > downstream users. It isn't open source. It can't be a dependency for a
> >> > proper Apache release.
> >> >
> >> > The library I have created is one way around the problem, but it is
> >> > definitely not a long-term solution.
> >>
> >> The problem is, once it has been released, it's going to be difficult
> >> to un-release it...
> >
> >
> > I don't plan to un-release it. But I do plan to help projects move away
> from
> > depending on my library. The best departure direction is probably
> jackson.
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: A grace period for getting rid of JSON license jars
Posted by sebb <se...@gmail.com>.
There has been a suggestion that jar hell can be avoided by patching the poms.
I can see how that could work for an individual case, but do we really
want to release a jar that *requires* the poms to be patched?
Every time a 3rd party project uses an ASF project containing this
replacement jar they will potentially have to patch their poms.
That does not seem sensible.
Furthermore, if the jars ever diverge, no amount of pom patching will
solve the issue.
Please, let's do this properly.
On 21 November 2016 at 21:12, Ted Dunning <te...@gmail.com> wrote:
>
> On Mon, Nov 21, 2016 at 11:01 AM, sebb <se...@gmail.com> wrote:
>>
>> > This preference is equivalent to "unable or unwilling to make proper
>> > Apache
>> > releases".
>>
>> I did not mean ASF projects.
>> I was thinking about 3rd party code that is used by ASF code.
>
>
> So far, we don't have any examples of this. The only source code dependency
> in a dependency case so far is twitter4j and it was easily dealt with and
> the community is receptive.
>
> Projects which depend on the org.json version of the code in a non-optional
> way where those projects will not change to fix the problem will become
> unusable by ASF code. The ASF projects that use these dependencies will
> become unreleasable unless they make some sort of change.
>
> That would suck. No doubt. No argument about that.
>
> But that situation is still theoretical. We have no examples of this.
>
> Let's work the problem as it exists right now.
>
>
>>
>>
>> > The JSON license is unacceptable. It puts ill-defined constraints on the
>> > downstream users. It isn't open source. It can't be a dependency for a
>> > proper Apache release.
>> >
>> > The library I have created is one way around the problem, but it is
>> > definitely not a long-term solution.
>>
>> The problem is, once it has been released, it's going to be difficult
>> to un-release it...
>
>
> I don't plan to un-release it. But I do plan to help projects move away from
> depending on my library. The best departure direction is probably jackson.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
On Mon, Nov 21, 2016 at 11:01 AM, sebb <se...@gmail.com> wrote:
> > This preference is equivalent to "unable or unwilling to make proper
> Apache
> > releases".
>
> I did not mean ASF projects.
> I was thinking about 3rd party code that is used by ASF code.
>
So far, we don't have any examples of this. The only source code dependency
in a dependency case so far is twitter4j and it was easily dealt with and
the community is receptive.
Projects which depend on the org.json version of the code in a non-optional
way where those projects will not change to fix the problem will become
unusable by ASF code. The ASF projects that use these dependencies will
become unreleasable unless they make some sort of change.
That would suck. No doubt. No argument about that.
But that situation is still theoretical. We have no examples of this.
Let's work the problem as it exists right now.
>
> > The JSON license is unacceptable. It puts ill-defined constraints on the
> > downstream users. It isn't open source. It can't be a dependency for a
> > proper Apache release.
> >
> > The library I have created is one way around the problem, but it is
> > definitely not a long-term solution.
>
> The problem is, once it has been released, it's going to be difficult
> to un-release it...
I don't plan to un-release it. But I do plan to help projects move away
from depending on my library. The best departure direction is probably
jackson.
Re: A grace period for getting rid of JSON license jars
Posted by sebb <se...@gmail.com>.
On 21 November 2016 at 17:23, Ted Dunning <te...@gmail.com> wrote:
>
> On Mon, Nov 21, 2016 at 3:38 AM, sebb <se...@gmail.com> wrote:
>>
>> > But in any case it will only work if the publicly usable API is
>> > identical in
>> > the two jars.
>> > Or rather, if the new jar contains all the publicly usable objects
>> > (methods,
>> > fields,classes etc) from the original jar.
>> >
>> > That's kind of the point of the new jar
>>
>> In which case it's incomplete; there's no JSONML class in the new jar
>> for example.
>> I've not checked the fields that may have been used.
>
>
> You are correct that the current jar is incomplete. It is an expedient to
> allow projects to continue releasing while they do something more correct.
>
>>
>>
>> >
>> > And the new jar will have to continue to track changes to the old jar.
>> >
>> > I disagree, in the long term the projects can either switch to Jackson
>> > or
>> > some other licence-compliant library, or we can hope that json.org fixes
>> > their licence.
>>
>> There will always be projects that are unable or unwilling to switch.
>
>
> This preference is equivalent to "unable or unwilling to make proper Apache
> releases".
I did not mean ASF projects.
I was thinking about 3rd party code that is used by ASF code.
> The JSON license is unacceptable. It puts ill-defined constraints on the
> downstream users. It isn't open source. It can't be a dependency for a
> proper Apache release.
>
> The library I have created is one way around the problem, but it is
> definitely not a long-term solution.
The problem is, once it has been released, it's going to be difficult
to un-release it...
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
On Mon, Nov 21, 2016 at 3:38 AM, sebb <se...@gmail.com> wrote:
> > But in any case it will only work if the publicly usable API is
> identical in
> > the two jars.
> > Or rather, if the new jar contains all the publicly usable objects
> (methods,
> > fields,classes etc) from the original jar.
> >
> > That's kind of the point of the new jar
>
> In which case it's incomplete; there's no JSONML class in the new jar
> for example.
> I've not checked the fields that may have been used.
>
You are correct that the current jar is incomplete. It is an expedient to
allow projects to continue releasing while they do something more correct.
>
> >
> > And the new jar will have to continue to track changes to the old jar.
> >
> > I disagree, in the long term the projects can either switch to Jackson or
> > some other licence-compliant library, or we can hope that json.org fixes
> > their licence.
>
> There will always be projects that are unable or unwilling to switch.
This preference is equivalent to "unable or unwilling to make proper Apache
releases".
The JSON license is unacceptable. It puts ill-defined constraints on the
downstream users. It isn't open source. It can't be a dependency for a
proper Apache release.
The library I have created is one way around the problem, but it is
definitely not a long-term solution.
Re: A grace period for getting rid of JSON license jars
Posted by sebb <se...@gmail.com>.
There's another aspect to this: the org.json package domain is owned
by a 3rd party.
On 21 November 2016 at 11:38, sebb <se...@gmail.com> wrote:
> On 21 November 2016 at 11:16, Simon Lessard <si...@gmail.com> wrote:
>> Not sure what you mean by that.
>>
>> Maven gives precedence to locally defined dependencies if you have
>>
>> <dependencides>
>> <dependency>
>> <groupId>foo.bar</groupId>
>> <artifactId>project-depending-on-z</artifactId>
>> </dependency>
>> <dependency>
>> <groupId>x.y</groupId>
>> <artifactId>z</artifactId>
>> <scope>provided</scope>
>> </dependency>
>> </dependencides>
>>
>> Then z.jar will be excluded from the runtime dependencies (and packaging
>> through Shade or other)
>
> The problem is that the application will likely continue to work most
> of the time.
> Debugging failures can be quite difficult (you see similar issues with
> web app classloader problems all the time)
>
> If you know you have to do this you can probably take the time to fix
> the Maven classpath.
> But this will be an ongoing maintenance issue.
>
>>
>> But in any case it will only work if the publicly usable API is identical in
>> the two jars.
>> Or rather, if the new jar contains all the publicly usable objects (methods,
>> fields,classes etc) from the original jar.
>>
>> That's kind of the point of the new jar
>
> In which case it's incomplete; there's no JSONML class in the new jar
> for example.
> I've not checked the fields that may have been used.
>
>>
>> And the new jar will have to continue to track changes to the old jar.
>>
>> I disagree, in the long term the projects can either switch to Jackson or
>> some other licence-compliant library, or we can hope that json.org fixes
>> their licence.
>
> There will always be projects that are unable or unwilling to switch.
>
>>
>> Regards,
>>
>> On Mon, Nov 21, 2016 at 12:02 PM, sebb <se...@gmail.com> wrote:
>>>
>>> On 21 November 2016 at 10:52, Simon Lessard <si...@gmail.com>
>>> wrote:
>>> > Hi Sebb,
>>> >
>>> > It should not be a major problem, you simply have to exclude the
>>> > json.org
>>> > libray in the POM. There's two ways to do that:
>>> > 1. The clean way: for each dependency using json.org, add the <exclude>
>>> > tag
>>> > (require to use mvn dependency:tree until there's no trace of it left)
>>>
>>> That is quite a lot of effort for a large project.
>>>
>>> > 2. The not so clean way: Define json.org as a project dependency in the
>>> > provided scope in the POM. You'll still have both library at compile
>>> > time,
>>> > but only one at packaging.runtime
>>>
>>> Not sure what you mean by that.
>>>
>>> But in any case it will only work if the publicly usable API is
>>> identical in the two jars.
>>> Or rather, if the new jar contains all the publicly usable objects
>>> (methods, fields,classes etc) from the original jar.
>>> And the new jar will have to continue to track changes to the old jar.
>>>
>>> >
>>> > Regards,
>>> >
>>> > On Mon, Nov 21, 2016 at 11:45 AM, sebb <se...@gmail.com> wrote:
>>> >>
>>> >> On 19 November 2016 at 03:08, Ted Dunning <te...@gmail.com>
>>> >> wrote:
>>> >> >
>>> >> > So ... there are a few questions popping up in different forms that
>>> >> > bear
>>> >> > on
>>> >> > the same issues. Here are some paraphrases and my answers:
>>> >> >
>>> >> > 1) Does the replacement library use the org.json package?
>>> >> >
>>> >> > Yes. It does. This may be a problem. If it turns out that way, I will
>>> >> > spin
>>> >> > another version that uses a different package root.
>>> >>
>>> >> Yes, it is a potential major problem.
>>> >>
>>> >> Think of it this way:
>>> >> would it be OK to set up an application with both your library and the
>>> >> original library on the classpath?
>>> >>
>>> >> If you tell Maven that your jar and the original jar have different
>>> >> (gid,aid) coords, then Maven has no way of knowing that these contain
>>> >> the same packages.
>>> >> So Maven will add them both to the classpath if they are both
>>> >> referenced.
>>> >>
>>> >> > On the other hand, it looks to me so far that re-using the org.json
>>> >> > package
>>> >> > actually makes proper surgery easier.
>>> >>
>>> >> Yes, but the cost is potential jar hell.
>>> >>
>>> >> > 2) I have a dependency on a third party that has a dependency on
>>> >> > org.json
>>> >> > stuff.
>>> >> >
>>> >> > First and most inflammatory answer: that makes the third party
>>> >> > dependency
>>> >> > category X.
>>> >> >
>>> >> > Second and much less inflammatory answer: because the package name is
>>> >> > the
>>> >> > same, you are likely to be able to satisfy the transitive dependency
>>> >> > with my
>>> >> > packaging of the Android library. It may require slightly more
>>> >> > footwork
>>> >> > than
>>> >> > just swapping out the pom clause as I suggested earlier.
>>> >> >
>>> >> > 3) I have a dependency that includes the org.json source code.
>>> >> >
>>> >> > First and most inflammatory answer: that makes the third party
>>> >> > dependency
>>> >> > category X.
>>> >> >
>>> >> > Second and much less inflammatory answer: you might be able to
>>> >> > convince
>>> >> > your
>>> >> > dependency to use the code I extracted instead. If not, that is a
>>> >> > really
>>> >> > difficult spot.
>>> >> >
>>> >> > 4) I have a dependency that includes the org.json jar file.
>>> >> >
>>> >> > First and most inflammatory answer: that makes the third party
>>> >> > dependency
>>> >> > category X.
>>> >> >
>>> >> > Second and much less inflammatory answer: This should be solvable by
>>> >> > simply
>>> >> > swapping jars. Explicitly packaging jars that are in maven central is
>>> >> > kind
>>> >> > of perverse, however, and really ought to be discouraged.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Fri, Nov 18, 2016 at 5:44 PM, Joe Witt <jo...@gmail.com> wrote:
>>> >> >>
>>> >> >> Ted,
>>> >> >>
>>> >> >> Agreed and understood that json.org's library is now considered
>>> >> >> category-x.
>>> >> >>
>>> >> >> In this case the discussion centers around the grace period to
>>> >> >> continue apache releases while resolving pre-existing valid usage of
>>> >> >> the library.
>>> >> >>
>>> >> >> Definitely appreciate you taking the initiative on providing an
>>> >> >> alternative implementation. In the case I'm concerned about we have
>>> >> >> a
>>> >> >> library, twitter4j, which uses the json.org code as a source
>>> >> >> dependency so we'd not be able to exclude their binary dep and
>>> >> >> replace
>>> >> >> it.
>>> >> >>
>>> >> >> As I mentioned previously we've already taken the steps necessary to
>>> >> >> remove any usage of json.org dependencies from our codebase and
>>> >> >> we're
>>> >> >> prepared to release. The problem is that the solution meant
>>> >> >> removing
>>> >> >> an often used feature from the build and it will create user
>>> >> >> confusion
>>> >> >> and is inconsistent with our stated backward compatibility guidance
>>> >> >> for the community.
>>> >> >>
>>> >> >> We did reach out to the dependency community, twitter4j, and they
>>> >> >> responded right away and seem willing to work with us to resolve so
>>> >> >> it
>>> >> >> is just a matter of time. The grace period would allow us to avoid
>>> >> >> impact to our users while we continue to responsibly address the
>>> >> >> matter.
>>> >> >>
>>> >> >> There does seem to be consensus on this thread that some form of
>>> >> >> grace
>>> >> >> period is reasonable so just looking to see if that has reached the
>>> >> >> point of a decision.
>>> >> >>
>>> >> >> Thanks
>>> >> >> Joe
>>> >> >>
>>> >> >> On Fri, Nov 18, 2016 at 6:42 PM, Ted Dunning <te...@gmail.com>
>>> >> >> wrote:
>>> >> >> >
>>> >> >> > Joe,
>>> >> >> >
>>> >> >> > I think that the consensus is that JSON is category X.
>>> >> >> >
>>> >> >> > Consider using the library I just built. Should result in little
>>> >> >> > or
>>> >> >> > no
>>> >> >> > user
>>> >> >> > visible change.
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > On Fri, Nov 18, 2016 at 11:30 AM, Joe Witt <jo...@gmail.com>
>>> >> >> > wrote:
>>> >> >> >>
>>> >> >> >> Hello,
>>> >> >> >>
>>> >> >> >> Has a decision been reached by any chance? We're looking to kick
>>> >> >> >> off
>>> >> >> >> the next Apache NiFi release and while we've done the work to
>>> >> >> >> eliminate the use of this library it required us to reduce user
>>> >> >> >> convenience in one case that we'd love to undo and expect the
>>> >> >> >> grace
>>> >> >> >> period will resolve.
>>> >> >> >>
>>> >> >> >> Thanks
>>> >> >> >> Joe
>>> >> >> >>
>>> >> >> >> On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning
>>> >> >> >> <te...@gmail.com>
>>> >> >> >> wrote:
>>> >> >> >> >
>>> >> >> >> > I like this too, but would rather have the "next release after
>>> >> >> >> > xxx/yyy"
>>> >> >> >> > form
>>> >> >> >> > of deadline.
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski
>>> >> >> >> > <ji...@jagunet.com>
>>> >> >> >> > wrote:
>>> >> >> >> >>
>>> >> >> >> >> The more I think about it, the more this makes sense.
>>> >> >> >> >> Basically
>>> >> >> >> >> we refuse the use of it for any new projects/efforts, but
>>> >> >> >> >> those
>>> >> >> >> >> projects which are currently using it, with no issues, should
>>> >> >> >> >> be allowed to continue using them, grandfathered, at least for
>>> >> >> >> >> a time being.
>>> >> >> >> >>
>>> >> >> >> >> Let me mull this over some more and make an official
>>> >> >> >> >> determination/
>>> >> >> >> >> ruling. :)
>>> >> >> >> >>
>>> >> >> >> >> > On Nov 16, 2016, at 2:22 PM, Alan Gates
>>> >> >> >> >> > <al...@gmail.com>
>>> >> >> >> >> > wrote:
>>> >> >> >> >> >
>>> >> >> >> >> > The recent moving of the JSON license to category X means
>>> >> >> >> >> > that
>>> >> >> >> >> > a
>>> >> >> >> >> > number
>>> >> >> >> >> > of projects cannot do any releases until this is fixed. I
>>> >> >> >> >> > know
>>> >> >> >> >> > this
>>> >> >> >> >> > includes Hadoop, Hive, and Spark, and probably a number of
>>> >> >> >> >> > others
>>> >> >> >> >> > since
>>> >> >> >> >> > hadoop-common (which many project use) depends on jars from
>>> >> >> >> >> > json.org.
>>> >> >> >> >> > The
>>> >> >> >> >> > Hive team in particular is trying to get a maintenance
>>> >> >> >> >> > release
>>> >> >> >> >> > out
>>> >> >> >> >> > which is
>>> >> >> >> >> > blocked by this.
>>> >> >> >> >> >
>>> >> >> >> >> > I talked with Jim Jagielski briefly today and he suggested
>>> >> >> >> >> > that
>>> >> >> >> >> > perhaps
>>> >> >> >> >> > we could have a grandfather clause on this so that projects
>>> >> >> >> >> > that
>>> >> >> >> >> > already are
>>> >> >> >> >> > using it could continue to, at least for a period of time,
>>> >> >> >> >> > so
>>> >> >> >> >> > that
>>> >> >> >> >> > they can
>>> >> >> >> >> > continue to produce releases rather than needing to spend
>>> >> >> >> >> > unplanned
>>> >> >> >> >> > time
>>> >> >> >> >> > switching out this library[1].
>>> >> >> >> >> >
>>> >> >> >> >> > To be specific I propose we give projects already using this
>>> >> >> >> >> > license
>>> >> >> >> >> > 6
>>> >> >> >> >> > months to clean this up in which they can continue to
>>> >> >> >> >> > release
>>> >> >> >> >> > with
>>> >> >> >> >> > dependencies on the JSON license.
>>> >> >> >> >> >
>>> >> >> >> >> > Alan.
>>> >> >> >> >> >
>>> >> >> >> >> > 1. The amount of time to fix this will not be trivial.
>>> >> >> >> >> > Based
>>> >> >> >> >> > on a
>>> >> >> >> >> > little bit of digging I’ve done the alternatives are not
>>> >> >> >> >> > 100%
>>> >> >> >> >> > identical in
>>> >> >> >> >> > their behavior which will mean projects will need to
>>> >> >> >> >> > thoroughly
>>> >> >> >> >> > test
>>> >> >> >> >> > the
>>> >> >> >> >> > replacements and change their code to deal with the
>>> >> >> >> >> > differences.
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> > ---------------------------------------------------------------------
>>> >> >> >> >> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> >> >> >> >> > For additional commands, e-mail:
>>> >> >> >> >> > legal-discuss-help@apache.org
>>> >> >> >> >> >
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >> ---------------------------------------------------------------------
>>> >> >> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> >> >> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
>>> >> >> >> >>
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> ---------------------------------------------------------------------
>>> >> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> >> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
>>> >> >> >>
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >> ---------------------------------------------------------------------
>>> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
>>> >> >>
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> >> For additional commands, e-mail: legal-discuss-help@apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Simon Lessard, Software Architect
>>> > CMA IT
>>> > ( +33(0) 6 79 37 39 85 (France)
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>
>>
>>
>> --
>> Simon Lessard, Software Architect
>> CMA IT
>> ( +33(0) 6 79 37 39 85 (France)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by sebb <se...@gmail.com>.
On 21 November 2016 at 11:16, Simon Lessard <si...@gmail.com> wrote:
> Not sure what you mean by that.
>
> Maven gives precedence to locally defined dependencies if you have
>
> <dependencides>
> <dependency>
> <groupId>foo.bar</groupId>
> <artifactId>project-depending-on-z</artifactId>
> </dependency>
> <dependency>
> <groupId>x.y</groupId>
> <artifactId>z</artifactId>
> <scope>provided</scope>
> </dependency>
> </dependencides>
>
> Then z.jar will be excluded from the runtime dependencies (and packaging
> through Shade or other)
The problem is that the application will likely continue to work most
of the time.
Debugging failures can be quite difficult (you see similar issues with
web app classloader problems all the time)
If you know you have to do this you can probably take the time to fix
the Maven classpath.
But this will be an ongoing maintenance issue.
>
> But in any case it will only work if the publicly usable API is identical in
> the two jars.
> Or rather, if the new jar contains all the publicly usable objects (methods,
> fields,classes etc) from the original jar.
>
> That's kind of the point of the new jar
In which case it's incomplete; there's no JSONML class in the new jar
for example.
I've not checked the fields that may have been used.
>
> And the new jar will have to continue to track changes to the old jar.
>
> I disagree, in the long term the projects can either switch to Jackson or
> some other licence-compliant library, or we can hope that json.org fixes
> their licence.
There will always be projects that are unable or unwilling to switch.
>
> Regards,
>
> On Mon, Nov 21, 2016 at 12:02 PM, sebb <se...@gmail.com> wrote:
>>
>> On 21 November 2016 at 10:52, Simon Lessard <si...@gmail.com>
>> wrote:
>> > Hi Sebb,
>> >
>> > It should not be a major problem, you simply have to exclude the
>> > json.org
>> > libray in the POM. There's two ways to do that:
>> > 1. The clean way: for each dependency using json.org, add the <exclude>
>> > tag
>> > (require to use mvn dependency:tree until there's no trace of it left)
>>
>> That is quite a lot of effort for a large project.
>>
>> > 2. The not so clean way: Define json.org as a project dependency in the
>> > provided scope in the POM. You'll still have both library at compile
>> > time,
>> > but only one at packaging.runtime
>>
>> Not sure what you mean by that.
>>
>> But in any case it will only work if the publicly usable API is
>> identical in the two jars.
>> Or rather, if the new jar contains all the publicly usable objects
>> (methods, fields,classes etc) from the original jar.
>> And the new jar will have to continue to track changes to the old jar.
>>
>> >
>> > Regards,
>> >
>> > On Mon, Nov 21, 2016 at 11:45 AM, sebb <se...@gmail.com> wrote:
>> >>
>> >> On 19 November 2016 at 03:08, Ted Dunning <te...@gmail.com>
>> >> wrote:
>> >> >
>> >> > So ... there are a few questions popping up in different forms that
>> >> > bear
>> >> > on
>> >> > the same issues. Here are some paraphrases and my answers:
>> >> >
>> >> > 1) Does the replacement library use the org.json package?
>> >> >
>> >> > Yes. It does. This may be a problem. If it turns out that way, I will
>> >> > spin
>> >> > another version that uses a different package root.
>> >>
>> >> Yes, it is a potential major problem.
>> >>
>> >> Think of it this way:
>> >> would it be OK to set up an application with both your library and the
>> >> original library on the classpath?
>> >>
>> >> If you tell Maven that your jar and the original jar have different
>> >> (gid,aid) coords, then Maven has no way of knowing that these contain
>> >> the same packages.
>> >> So Maven will add them both to the classpath if they are both
>> >> referenced.
>> >>
>> >> > On the other hand, it looks to me so far that re-using the org.json
>> >> > package
>> >> > actually makes proper surgery easier.
>> >>
>> >> Yes, but the cost is potential jar hell.
>> >>
>> >> > 2) I have a dependency on a third party that has a dependency on
>> >> > org.json
>> >> > stuff.
>> >> >
>> >> > First and most inflammatory answer: that makes the third party
>> >> > dependency
>> >> > category X.
>> >> >
>> >> > Second and much less inflammatory answer: because the package name is
>> >> > the
>> >> > same, you are likely to be able to satisfy the transitive dependency
>> >> > with my
>> >> > packaging of the Android library. It may require slightly more
>> >> > footwork
>> >> > than
>> >> > just swapping out the pom clause as I suggested earlier.
>> >> >
>> >> > 3) I have a dependency that includes the org.json source code.
>> >> >
>> >> > First and most inflammatory answer: that makes the third party
>> >> > dependency
>> >> > category X.
>> >> >
>> >> > Second and much less inflammatory answer: you might be able to
>> >> > convince
>> >> > your
>> >> > dependency to use the code I extracted instead. If not, that is a
>> >> > really
>> >> > difficult spot.
>> >> >
>> >> > 4) I have a dependency that includes the org.json jar file.
>> >> >
>> >> > First and most inflammatory answer: that makes the third party
>> >> > dependency
>> >> > category X.
>> >> >
>> >> > Second and much less inflammatory answer: This should be solvable by
>> >> > simply
>> >> > swapping jars. Explicitly packaging jars that are in maven central is
>> >> > kind
>> >> > of perverse, however, and really ought to be discouraged.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Fri, Nov 18, 2016 at 5:44 PM, Joe Witt <jo...@gmail.com> wrote:
>> >> >>
>> >> >> Ted,
>> >> >>
>> >> >> Agreed and understood that json.org's library is now considered
>> >> >> category-x.
>> >> >>
>> >> >> In this case the discussion centers around the grace period to
>> >> >> continue apache releases while resolving pre-existing valid usage of
>> >> >> the library.
>> >> >>
>> >> >> Definitely appreciate you taking the initiative on providing an
>> >> >> alternative implementation. In the case I'm concerned about we have
>> >> >> a
>> >> >> library, twitter4j, which uses the json.org code as a source
>> >> >> dependency so we'd not be able to exclude their binary dep and
>> >> >> replace
>> >> >> it.
>> >> >>
>> >> >> As I mentioned previously we've already taken the steps necessary to
>> >> >> remove any usage of json.org dependencies from our codebase and
>> >> >> we're
>> >> >> prepared to release. The problem is that the solution meant
>> >> >> removing
>> >> >> an often used feature from the build and it will create user
>> >> >> confusion
>> >> >> and is inconsistent with our stated backward compatibility guidance
>> >> >> for the community.
>> >> >>
>> >> >> We did reach out to the dependency community, twitter4j, and they
>> >> >> responded right away and seem willing to work with us to resolve so
>> >> >> it
>> >> >> is just a matter of time. The grace period would allow us to avoid
>> >> >> impact to our users while we continue to responsibly address the
>> >> >> matter.
>> >> >>
>> >> >> There does seem to be consensus on this thread that some form of
>> >> >> grace
>> >> >> period is reasonable so just looking to see if that has reached the
>> >> >> point of a decision.
>> >> >>
>> >> >> Thanks
>> >> >> Joe
>> >> >>
>> >> >> On Fri, Nov 18, 2016 at 6:42 PM, Ted Dunning <te...@gmail.com>
>> >> >> wrote:
>> >> >> >
>> >> >> > Joe,
>> >> >> >
>> >> >> > I think that the consensus is that JSON is category X.
>> >> >> >
>> >> >> > Consider using the library I just built. Should result in little
>> >> >> > or
>> >> >> > no
>> >> >> > user
>> >> >> > visible change.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Nov 18, 2016 at 11:30 AM, Joe Witt <jo...@gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Hello,
>> >> >> >>
>> >> >> >> Has a decision been reached by any chance? We're looking to kick
>> >> >> >> off
>> >> >> >> the next Apache NiFi release and while we've done the work to
>> >> >> >> eliminate the use of this library it required us to reduce user
>> >> >> >> convenience in one case that we'd love to undo and expect the
>> >> >> >> grace
>> >> >> >> period will resolve.
>> >> >> >>
>> >> >> >> Thanks
>> >> >> >> Joe
>> >> >> >>
>> >> >> >> On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning
>> >> >> >> <te...@gmail.com>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> > I like this too, but would rather have the "next release after
>> >> >> >> > xxx/yyy"
>> >> >> >> > form
>> >> >> >> > of deadline.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski
>> >> >> >> > <ji...@jagunet.com>
>> >> >> >> > wrote:
>> >> >> >> >>
>> >> >> >> >> The more I think about it, the more this makes sense.
>> >> >> >> >> Basically
>> >> >> >> >> we refuse the use of it for any new projects/efforts, but
>> >> >> >> >> those
>> >> >> >> >> projects which are currently using it, with no issues, should
>> >> >> >> >> be allowed to continue using them, grandfathered, at least for
>> >> >> >> >> a time being.
>> >> >> >> >>
>> >> >> >> >> Let me mull this over some more and make an official
>> >> >> >> >> determination/
>> >> >> >> >> ruling. :)
>> >> >> >> >>
>> >> >> >> >> > On Nov 16, 2016, at 2:22 PM, Alan Gates
>> >> >> >> >> > <al...@gmail.com>
>> >> >> >> >> > wrote:
>> >> >> >> >> >
>> >> >> >> >> > The recent moving of the JSON license to category X means
>> >> >> >> >> > that
>> >> >> >> >> > a
>> >> >> >> >> > number
>> >> >> >> >> > of projects cannot do any releases until this is fixed. I
>> >> >> >> >> > know
>> >> >> >> >> > this
>> >> >> >> >> > includes Hadoop, Hive, and Spark, and probably a number of
>> >> >> >> >> > others
>> >> >> >> >> > since
>> >> >> >> >> > hadoop-common (which many project use) depends on jars from
>> >> >> >> >> > json.org.
>> >> >> >> >> > The
>> >> >> >> >> > Hive team in particular is trying to get a maintenance
>> >> >> >> >> > release
>> >> >> >> >> > out
>> >> >> >> >> > which is
>> >> >> >> >> > blocked by this.
>> >> >> >> >> >
>> >> >> >> >> > I talked with Jim Jagielski briefly today and he suggested
>> >> >> >> >> > that
>> >> >> >> >> > perhaps
>> >> >> >> >> > we could have a grandfather clause on this so that projects
>> >> >> >> >> > that
>> >> >> >> >> > already are
>> >> >> >> >> > using it could continue to, at least for a period of time,
>> >> >> >> >> > so
>> >> >> >> >> > that
>> >> >> >> >> > they can
>> >> >> >> >> > continue to produce releases rather than needing to spend
>> >> >> >> >> > unplanned
>> >> >> >> >> > time
>> >> >> >> >> > switching out this library[1].
>> >> >> >> >> >
>> >> >> >> >> > To be specific I propose we give projects already using this
>> >> >> >> >> > license
>> >> >> >> >> > 6
>> >> >> >> >> > months to clean this up in which they can continue to
>> >> >> >> >> > release
>> >> >> >> >> > with
>> >> >> >> >> > dependencies on the JSON license.
>> >> >> >> >> >
>> >> >> >> >> > Alan.
>> >> >> >> >> >
>> >> >> >> >> > 1. The amount of time to fix this will not be trivial.
>> >> >> >> >> > Based
>> >> >> >> >> > on a
>> >> >> >> >> > little bit of digging I’ve done the alternatives are not
>> >> >> >> >> > 100%
>> >> >> >> >> > identical in
>> >> >> >> >> > their behavior which will mean projects will need to
>> >> >> >> >> > thoroughly
>> >> >> >> >> > test
>> >> >> >> >> > the
>> >> >> >> >> > replacements and change their code to deal with the
>> >> >> >> >> > differences.
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > ---------------------------------------------------------------------
>> >> >> >> >> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> >> >> >> > For additional commands, e-mail:
>> >> >> >> >> > legal-discuss-help@apache.org
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> >> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> For additional commands, e-mail: legal-discuss-help@apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Simon Lessard, Software Architect
>> > CMA IT
>> > ( +33(0) 6 79 37 39 85 (France)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
>
>
> --
> Simon Lessard, Software Architect
> CMA IT
> ( +33(0) 6 79 37 39 85 (France)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Simon Lessard <si...@gmail.com>.
*Not sure what you mean by that.*
Maven gives precedence to locally defined dependencies if you have
<dependencides>
<dependency>
<groupId>foo.bar</groupId>
<artifactId>project-depending-on-z</artifactId>
</dependency>
<dependency>
<groupId>x.y</groupId>
<artifactId>z</artifactId>
<scope>provided</scope>
</dependency>
</dependencides>
Then z.jar will be excluded from the runtime dependencies (and packaging
through Shade or other)
*But in any case it will only work if the publicly usable API is identical
in the two jars.Or rather, if the new jar contains all the publicly usable
objects (methods, fields,classes etc) from the original jar.*
That's kind of the point of the new jar
*And the new jar will have to continue to track changes to the old jar.*
I disagree, in the long term the projects can either switch to Jackson or
some other licence-compliant library, or we can hope that json.org fixes
their licence.
Regards,
On Mon, Nov 21, 2016 at 12:02 PM, sebb <se...@gmail.com> wrote:
> On 21 November 2016 at 10:52, Simon Lessard <si...@gmail.com>
> wrote:
> > Hi Sebb,
> >
> > It should not be a major problem, you simply have to exclude the
> json.org
> > libray in the POM. There's two ways to do that:
> > 1. The clean way: for each dependency using json.org, add the <exclude>
> tag
> > (require to use mvn dependency:tree until there's no trace of it left)
>
> That is quite a lot of effort for a large project.
>
> > 2. The not so clean way: Define json.org as a project dependency in the
> > provided scope in the POM. You'll still have both library at compile
> time,
> > but only one at packaging.runtime
>
> Not sure what you mean by that.
>
> But in any case it will only work if the publicly usable API is
> identical in the two jars.
> Or rather, if the new jar contains all the publicly usable objects
> (methods, fields,classes etc) from the original jar.
> And the new jar will have to continue to track changes to the old jar.
>
> >
> > Regards,
> >
> > On Mon, Nov 21, 2016 at 11:45 AM, sebb <se...@gmail.com> wrote:
> >>
> >> On 19 November 2016 at 03:08, Ted Dunning <te...@gmail.com>
> wrote:
> >> >
> >> > So ... there are a few questions popping up in different forms that
> bear
> >> > on
> >> > the same issues. Here are some paraphrases and my answers:
> >> >
> >> > 1) Does the replacement library use the org.json package?
> >> >
> >> > Yes. It does. This may be a problem. If it turns out that way, I will
> >> > spin
> >> > another version that uses a different package root.
> >>
> >> Yes, it is a potential major problem.
> >>
> >> Think of it this way:
> >> would it be OK to set up an application with both your library and the
> >> original library on the classpath?
> >>
> >> If you tell Maven that your jar and the original jar have different
> >> (gid,aid) coords, then Maven has no way of knowing that these contain
> >> the same packages.
> >> So Maven will add them both to the classpath if they are both
> referenced.
> >>
> >> > On the other hand, it looks to me so far that re-using the org.json
> >> > package
> >> > actually makes proper surgery easier.
> >>
> >> Yes, but the cost is potential jar hell.
> >>
> >> > 2) I have a dependency on a third party that has a dependency on
> >> > org.json
> >> > stuff.
> >> >
> >> > First and most inflammatory answer: that makes the third party
> >> > dependency
> >> > category X.
> >> >
> >> > Second and much less inflammatory answer: because the package name is
> >> > the
> >> > same, you are likely to be able to satisfy the transitive dependency
> >> > with my
> >> > packaging of the Android library. It may require slightly more
> footwork
> >> > than
> >> > just swapping out the pom clause as I suggested earlier.
> >> >
> >> > 3) I have a dependency that includes the org.json source code.
> >> >
> >> > First and most inflammatory answer: that makes the third party
> >> > dependency
> >> > category X.
> >> >
> >> > Second and much less inflammatory answer: you might be able to
> convince
> >> > your
> >> > dependency to use the code I extracted instead. If not, that is a
> really
> >> > difficult spot.
> >> >
> >> > 4) I have a dependency that includes the org.json jar file.
> >> >
> >> > First and most inflammatory answer: that makes the third party
> >> > dependency
> >> > category X.
> >> >
> >> > Second and much less inflammatory answer: This should be solvable by
> >> > simply
> >> > swapping jars. Explicitly packaging jars that are in maven central is
> >> > kind
> >> > of perverse, however, and really ought to be discouraged.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Fri, Nov 18, 2016 at 5:44 PM, Joe Witt <jo...@gmail.com> wrote:
> >> >>
> >> >> Ted,
> >> >>
> >> >> Agreed and understood that json.org's library is now considered
> >> >> category-x.
> >> >>
> >> >> In this case the discussion centers around the grace period to
> >> >> continue apache releases while resolving pre-existing valid usage of
> >> >> the library.
> >> >>
> >> >> Definitely appreciate you taking the initiative on providing an
> >> >> alternative implementation. In the case I'm concerned about we have
> a
> >> >> library, twitter4j, which uses the json.org code as a source
> >> >> dependency so we'd not be able to exclude their binary dep and
> replace
> >> >> it.
> >> >>
> >> >> As I mentioned previously we've already taken the steps necessary to
> >> >> remove any usage of json.org dependencies from our codebase and
> we're
> >> >> prepared to release. The problem is that the solution meant removing
> >> >> an often used feature from the build and it will create user
> confusion
> >> >> and is inconsistent with our stated backward compatibility guidance
> >> >> for the community.
> >> >>
> >> >> We did reach out to the dependency community, twitter4j, and they
> >> >> responded right away and seem willing to work with us to resolve so
> it
> >> >> is just a matter of time. The grace period would allow us to avoid
> >> >> impact to our users while we continue to responsibly address the
> >> >> matter.
> >> >>
> >> >> There does seem to be consensus on this thread that some form of
> grace
> >> >> period is reasonable so just looking to see if that has reached the
> >> >> point of a decision.
> >> >>
> >> >> Thanks
> >> >> Joe
> >> >>
> >> >> On Fri, Nov 18, 2016 at 6:42 PM, Ted Dunning <te...@gmail.com>
> >> >> wrote:
> >> >> >
> >> >> > Joe,
> >> >> >
> >> >> > I think that the consensus is that JSON is category X.
> >> >> >
> >> >> > Consider using the library I just built. Should result in little or
> >> >> > no
> >> >> > user
> >> >> > visible change.
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Fri, Nov 18, 2016 at 11:30 AM, Joe Witt <jo...@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Hello,
> >> >> >>
> >> >> >> Has a decision been reached by any chance? We're looking to kick
> >> >> >> off
> >> >> >> the next Apache NiFi release and while we've done the work to
> >> >> >> eliminate the use of this library it required us to reduce user
> >> >> >> convenience in one case that we'd love to undo and expect the
> grace
> >> >> >> period will resolve.
> >> >> >>
> >> >> >> Thanks
> >> >> >> Joe
> >> >> >>
> >> >> >> On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning <
> ted.dunning@gmail.com>
> >> >> >> wrote:
> >> >> >> >
> >> >> >> > I like this too, but would rather have the "next release after
> >> >> >> > xxx/yyy"
> >> >> >> > form
> >> >> >> > of deadline.
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <
> jim@jagunet.com>
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> The more I think about it, the more this makes sense. Basically
> >> >> >> >> we refuse the use of it for any new projects/efforts, but those
> >> >> >> >> projects which are currently using it, with no issues, should
> >> >> >> >> be allowed to continue using them, grandfathered, at least for
> >> >> >> >> a time being.
> >> >> >> >>
> >> >> >> >> Let me mull this over some more and make an official
> >> >> >> >> determination/
> >> >> >> >> ruling. :)
> >> >> >> >>
> >> >> >> >> > On Nov 16, 2016, at 2:22 PM, Alan Gates <
> alanfgates@gmail.com>
> >> >> >> >> > wrote:
> >> >> >> >> >
> >> >> >> >> > The recent moving of the JSON license to category X means
> that
> >> >> >> >> > a
> >> >> >> >> > number
> >> >> >> >> > of projects cannot do any releases until this is fixed. I
> know
> >> >> >> >> > this
> >> >> >> >> > includes Hadoop, Hive, and Spark, and probably a number of
> >> >> >> >> > others
> >> >> >> >> > since
> >> >> >> >> > hadoop-common (which many project use) depends on jars from
> >> >> >> >> > json.org.
> >> >> >> >> > The
> >> >> >> >> > Hive team in particular is trying to get a maintenance
> release
> >> >> >> >> > out
> >> >> >> >> > which is
> >> >> >> >> > blocked by this.
> >> >> >> >> >
> >> >> >> >> > I talked with Jim Jagielski briefly today and he suggested
> that
> >> >> >> >> > perhaps
> >> >> >> >> > we could have a grandfather clause on this so that projects
> >> >> >> >> > that
> >> >> >> >> > already are
> >> >> >> >> > using it could continue to, at least for a period of time, so
> >> >> >> >> > that
> >> >> >> >> > they can
> >> >> >> >> > continue to produce releases rather than needing to spend
> >> >> >> >> > unplanned
> >> >> >> >> > time
> >> >> >> >> > switching out this library[1].
> >> >> >> >> >
> >> >> >> >> > To be specific I propose we give projects already using this
> >> >> >> >> > license
> >> >> >> >> > 6
> >> >> >> >> > months to clean this up in which they can continue to release
> >> >> >> >> > with
> >> >> >> >> > dependencies on the JSON license.
> >> >> >> >> >
> >> >> >> >> > Alan.
> >> >> >> >> >
> >> >> >> >> > 1. The amount of time to fix this will not be trivial. Based
> >> >> >> >> > on a
> >> >> >> >> > little bit of digging I’ve done the alternatives are not 100%
> >> >> >> >> > identical in
> >> >> >> >> > their behavior which will mean projects will need to
> thoroughly
> >> >> >> >> > test
> >> >> >> >> > the
> >> >> >> >> > replacements and change their code to deal with the
> >> >> >> >> > differences.
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > ------------------------------------------------------------
> ---------
> >> >> >> >> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> >> >> >> > For additional commands, e-mail:
> legal-discuss-help@apache.org
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> ------------------------------------------------------------
> ---------
> >> >> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> >> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> ------------------------------------------------------------
> ---------
> >> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
> >> >> >>
> >> >> >
> >> >>
> >> >> ------------------------------------------------------------
> ---------
> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> For additional commands, e-mail: legal-discuss-help@apache.org
> >>
> >
> >
> >
> > --
> > Simon Lessard, Software Architect
> > CMA IT
> > ( +33(0) 6 79 37 39 85 (France)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
*Simon Lessard*, Software Architect
*CMA* *IT*
*( +33(0) 6 79 37 39 85 (France)*
Re: A grace period for getting rid of JSON license jars
Posted by sebb <se...@gmail.com>.
On 21 November 2016 at 10:52, Simon Lessard <si...@gmail.com> wrote:
> Hi Sebb,
>
> It should not be a major problem, you simply have to exclude the json.org
> libray in the POM. There's two ways to do that:
> 1. The clean way: for each dependency using json.org, add the <exclude> tag
> (require to use mvn dependency:tree until there's no trace of it left)
That is quite a lot of effort for a large project.
> 2. The not so clean way: Define json.org as a project dependency in the
> provided scope in the POM. You'll still have both library at compile time,
> but only one at packaging.runtime
Not sure what you mean by that.
But in any case it will only work if the publicly usable API is
identical in the two jars.
Or rather, if the new jar contains all the publicly usable objects
(methods, fields,classes etc) from the original jar.
And the new jar will have to continue to track changes to the old jar.
>
> Regards,
>
> On Mon, Nov 21, 2016 at 11:45 AM, sebb <se...@gmail.com> wrote:
>>
>> On 19 November 2016 at 03:08, Ted Dunning <te...@gmail.com> wrote:
>> >
>> > So ... there are a few questions popping up in different forms that bear
>> > on
>> > the same issues. Here are some paraphrases and my answers:
>> >
>> > 1) Does the replacement library use the org.json package?
>> >
>> > Yes. It does. This may be a problem. If it turns out that way, I will
>> > spin
>> > another version that uses a different package root.
>>
>> Yes, it is a potential major problem.
>>
>> Think of it this way:
>> would it be OK to set up an application with both your library and the
>> original library on the classpath?
>>
>> If you tell Maven that your jar and the original jar have different
>> (gid,aid) coords, then Maven has no way of knowing that these contain
>> the same packages.
>> So Maven will add them both to the classpath if they are both referenced.
>>
>> > On the other hand, it looks to me so far that re-using the org.json
>> > package
>> > actually makes proper surgery easier.
>>
>> Yes, but the cost is potential jar hell.
>>
>> > 2) I have a dependency on a third party that has a dependency on
>> > org.json
>> > stuff.
>> >
>> > First and most inflammatory answer: that makes the third party
>> > dependency
>> > category X.
>> >
>> > Second and much less inflammatory answer: because the package name is
>> > the
>> > same, you are likely to be able to satisfy the transitive dependency
>> > with my
>> > packaging of the Android library. It may require slightly more footwork
>> > than
>> > just swapping out the pom clause as I suggested earlier.
>> >
>> > 3) I have a dependency that includes the org.json source code.
>> >
>> > First and most inflammatory answer: that makes the third party
>> > dependency
>> > category X.
>> >
>> > Second and much less inflammatory answer: you might be able to convince
>> > your
>> > dependency to use the code I extracted instead. If not, that is a really
>> > difficult spot.
>> >
>> > 4) I have a dependency that includes the org.json jar file.
>> >
>> > First and most inflammatory answer: that makes the third party
>> > dependency
>> > category X.
>> >
>> > Second and much less inflammatory answer: This should be solvable by
>> > simply
>> > swapping jars. Explicitly packaging jars that are in maven central is
>> > kind
>> > of perverse, however, and really ought to be discouraged.
>> >
>> >
>> >
>> >
>> >
>> > On Fri, Nov 18, 2016 at 5:44 PM, Joe Witt <jo...@gmail.com> wrote:
>> >>
>> >> Ted,
>> >>
>> >> Agreed and understood that json.org's library is now considered
>> >> category-x.
>> >>
>> >> In this case the discussion centers around the grace period to
>> >> continue apache releases while resolving pre-existing valid usage of
>> >> the library.
>> >>
>> >> Definitely appreciate you taking the initiative on providing an
>> >> alternative implementation. In the case I'm concerned about we have a
>> >> library, twitter4j, which uses the json.org code as a source
>> >> dependency so we'd not be able to exclude their binary dep and replace
>> >> it.
>> >>
>> >> As I mentioned previously we've already taken the steps necessary to
>> >> remove any usage of json.org dependencies from our codebase and we're
>> >> prepared to release. The problem is that the solution meant removing
>> >> an often used feature from the build and it will create user confusion
>> >> and is inconsistent with our stated backward compatibility guidance
>> >> for the community.
>> >>
>> >> We did reach out to the dependency community, twitter4j, and they
>> >> responded right away and seem willing to work with us to resolve so it
>> >> is just a matter of time. The grace period would allow us to avoid
>> >> impact to our users while we continue to responsibly address the
>> >> matter.
>> >>
>> >> There does seem to be consensus on this thread that some form of grace
>> >> period is reasonable so just looking to see if that has reached the
>> >> point of a decision.
>> >>
>> >> Thanks
>> >> Joe
>> >>
>> >> On Fri, Nov 18, 2016 at 6:42 PM, Ted Dunning <te...@gmail.com>
>> >> wrote:
>> >> >
>> >> > Joe,
>> >> >
>> >> > I think that the consensus is that JSON is category X.
>> >> >
>> >> > Consider using the library I just built. Should result in little or
>> >> > no
>> >> > user
>> >> > visible change.
>> >> >
>> >> >
>> >> >
>> >> > On Fri, Nov 18, 2016 at 11:30 AM, Joe Witt <jo...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Hello,
>> >> >>
>> >> >> Has a decision been reached by any chance? We're looking to kick
>> >> >> off
>> >> >> the next Apache NiFi release and while we've done the work to
>> >> >> eliminate the use of this library it required us to reduce user
>> >> >> convenience in one case that we'd love to undo and expect the grace
>> >> >> period will resolve.
>> >> >>
>> >> >> Thanks
>> >> >> Joe
>> >> >>
>> >> >> On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning <te...@gmail.com>
>> >> >> wrote:
>> >> >> >
>> >> >> > I like this too, but would rather have the "next release after
>> >> >> > xxx/yyy"
>> >> >> > form
>> >> >> > of deadline.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <ji...@jagunet.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> The more I think about it, the more this makes sense. Basically
>> >> >> >> we refuse the use of it for any new projects/efforts, but those
>> >> >> >> projects which are currently using it, with no issues, should
>> >> >> >> be allowed to continue using them, grandfathered, at least for
>> >> >> >> a time being.
>> >> >> >>
>> >> >> >> Let me mull this over some more and make an official
>> >> >> >> determination/
>> >> >> >> ruling. :)
>> >> >> >>
>> >> >> >> > On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com>
>> >> >> >> > wrote:
>> >> >> >> >
>> >> >> >> > The recent moving of the JSON license to category X means that
>> >> >> >> > a
>> >> >> >> > number
>> >> >> >> > of projects cannot do any releases until this is fixed. I know
>> >> >> >> > this
>> >> >> >> > includes Hadoop, Hive, and Spark, and probably a number of
>> >> >> >> > others
>> >> >> >> > since
>> >> >> >> > hadoop-common (which many project use) depends on jars from
>> >> >> >> > json.org.
>> >> >> >> > The
>> >> >> >> > Hive team in particular is trying to get a maintenance release
>> >> >> >> > out
>> >> >> >> > which is
>> >> >> >> > blocked by this.
>> >> >> >> >
>> >> >> >> > I talked with Jim Jagielski briefly today and he suggested that
>> >> >> >> > perhaps
>> >> >> >> > we could have a grandfather clause on this so that projects
>> >> >> >> > that
>> >> >> >> > already are
>> >> >> >> > using it could continue to, at least for a period of time, so
>> >> >> >> > that
>> >> >> >> > they can
>> >> >> >> > continue to produce releases rather than needing to spend
>> >> >> >> > unplanned
>> >> >> >> > time
>> >> >> >> > switching out this library[1].
>> >> >> >> >
>> >> >> >> > To be specific I propose we give projects already using this
>> >> >> >> > license
>> >> >> >> > 6
>> >> >> >> > months to clean this up in which they can continue to release
>> >> >> >> > with
>> >> >> >> > dependencies on the JSON license.
>> >> >> >> >
>> >> >> >> > Alan.
>> >> >> >> >
>> >> >> >> > 1. The amount of time to fix this will not be trivial. Based
>> >> >> >> > on a
>> >> >> >> > little bit of digging I’ve done the alternatives are not 100%
>> >> >> >> > identical in
>> >> >> >> > their behavior which will mean projects will need to thoroughly
>> >> >> >> > test
>> >> >> >> > the
>> >> >> >> > replacements and change their code to deal with the
>> >> >> >> > differences.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > ---------------------------------------------------------------------
>> >> >> >> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> >> >> > For additional commands, e-mail: legal-discuss-help@apache.org
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> For additional commands, e-mail: legal-discuss-help@apache.org
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
>
>
> --
> Simon Lessard, Software Architect
> CMA IT
> ( +33(0) 6 79 37 39 85 (France)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Simon Lessard <si...@gmail.com>.
Hi Sebb,
It should not be a major problem, you simply have to exclude the json.org
libray in the POM. There's two ways to do that:
1. The clean way: for each dependency using json.org, add the <exclude> tag
(require to use mvn dependency:tree until there's no trace of it left)
2. The not so clean way: Define json.org as a project dependency in the
*provided* scope in the POM. You'll still have both library at compile
time, but only one at packaging.runtime
Regards,
On Mon, Nov 21, 2016 at 11:45 AM, sebb <se...@gmail.com> wrote:
> On 19 November 2016 at 03:08, Ted Dunning <te...@gmail.com> wrote:
> >
> > So ... there are a few questions popping up in different forms that bear
> on
> > the same issues. Here are some paraphrases and my answers:
> >
> > 1) Does the replacement library use the org.json package?
> >
> > Yes. It does. This may be a problem. If it turns out that way, I will
> spin
> > another version that uses a different package root.
>
> Yes, it is a potential major problem.
>
> Think of it this way:
> would it be OK to set up an application with both your library and the
> original library on the classpath?
>
> If you tell Maven that your jar and the original jar have different
> (gid,aid) coords, then Maven has no way of knowing that these contain
> the same packages.
> So Maven will add them both to the classpath if they are both referenced.
>
> > On the other hand, it looks to me so far that re-using the org.json
> package
> > actually makes proper surgery easier.
>
> Yes, but the cost is potential jar hell.
>
> > 2) I have a dependency on a third party that has a dependency on org.json
> > stuff.
> >
> > First and most inflammatory answer: that makes the third party dependency
> > category X.
> >
> > Second and much less inflammatory answer: because the package name is the
> > same, you are likely to be able to satisfy the transitive dependency
> with my
> > packaging of the Android library. It may require slightly more footwork
> than
> > just swapping out the pom clause as I suggested earlier.
> >
> > 3) I have a dependency that includes the org.json source code.
> >
> > First and most inflammatory answer: that makes the third party dependency
> > category X.
> >
> > Second and much less inflammatory answer: you might be able to convince
> your
> > dependency to use the code I extracted instead. If not, that is a really
> > difficult spot.
> >
> > 4) I have a dependency that includes the org.json jar file.
> >
> > First and most inflammatory answer: that makes the third party dependency
> > category X.
> >
> > Second and much less inflammatory answer: This should be solvable by
> simply
> > swapping jars. Explicitly packaging jars that are in maven central is
> kind
> > of perverse, however, and really ought to be discouraged.
> >
> >
> >
> >
> >
> > On Fri, Nov 18, 2016 at 5:44 PM, Joe Witt <jo...@gmail.com> wrote:
> >>
> >> Ted,
> >>
> >> Agreed and understood that json.org's library is now considered
> >> category-x.
> >>
> >> In this case the discussion centers around the grace period to
> >> continue apache releases while resolving pre-existing valid usage of
> >> the library.
> >>
> >> Definitely appreciate you taking the initiative on providing an
> >> alternative implementation. In the case I'm concerned about we have a
> >> library, twitter4j, which uses the json.org code as a source
> >> dependency so we'd not be able to exclude their binary dep and replace
> >> it.
> >>
> >> As I mentioned previously we've already taken the steps necessary to
> >> remove any usage of json.org dependencies from our codebase and we're
> >> prepared to release. The problem is that the solution meant removing
> >> an often used feature from the build and it will create user confusion
> >> and is inconsistent with our stated backward compatibility guidance
> >> for the community.
> >>
> >> We did reach out to the dependency community, twitter4j, and they
> >> responded right away and seem willing to work with us to resolve so it
> >> is just a matter of time. The grace period would allow us to avoid
> >> impact to our users while we continue to responsibly address the
> >> matter.
> >>
> >> There does seem to be consensus on this thread that some form of grace
> >> period is reasonable so just looking to see if that has reached the
> >> point of a decision.
> >>
> >> Thanks
> >> Joe
> >>
> >> On Fri, Nov 18, 2016 at 6:42 PM, Ted Dunning <te...@gmail.com>
> >> wrote:
> >> >
> >> > Joe,
> >> >
> >> > I think that the consensus is that JSON is category X.
> >> >
> >> > Consider using the library I just built. Should result in little or no
> >> > user
> >> > visible change.
> >> >
> >> >
> >> >
> >> > On Fri, Nov 18, 2016 at 11:30 AM, Joe Witt <jo...@gmail.com>
> wrote:
> >> >>
> >> >> Hello,
> >> >>
> >> >> Has a decision been reached by any chance? We're looking to kick off
> >> >> the next Apache NiFi release and while we've done the work to
> >> >> eliminate the use of this library it required us to reduce user
> >> >> convenience in one case that we'd love to undo and expect the grace
> >> >> period will resolve.
> >> >>
> >> >> Thanks
> >> >> Joe
> >> >>
> >> >> On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning <te...@gmail.com>
> >> >> wrote:
> >> >> >
> >> >> > I like this too, but would rather have the "next release after
> >> >> > xxx/yyy"
> >> >> > form
> >> >> > of deadline.
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <ji...@jagunet.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> The more I think about it, the more this makes sense. Basically
> >> >> >> we refuse the use of it for any new projects/efforts, but those
> >> >> >> projects which are currently using it, with no issues, should
> >> >> >> be allowed to continue using them, grandfathered, at least for
> >> >> >> a time being.
> >> >> >>
> >> >> >> Let me mull this over some more and make an official
> determination/
> >> >> >> ruling. :)
> >> >> >>
> >> >> >> > On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com>
> >> >> >> > wrote:
> >> >> >> >
> >> >> >> > The recent moving of the JSON license to category X means that a
> >> >> >> > number
> >> >> >> > of projects cannot do any releases until this is fixed. I know
> >> >> >> > this
> >> >> >> > includes Hadoop, Hive, and Spark, and probably a number of
> others
> >> >> >> > since
> >> >> >> > hadoop-common (which many project use) depends on jars from
> >> >> >> > json.org.
> >> >> >> > The
> >> >> >> > Hive team in particular is trying to get a maintenance release
> out
> >> >> >> > which is
> >> >> >> > blocked by this.
> >> >> >> >
> >> >> >> > I talked with Jim Jagielski briefly today and he suggested that
> >> >> >> > perhaps
> >> >> >> > we could have a grandfather clause on this so that projects that
> >> >> >> > already are
> >> >> >> > using it could continue to, at least for a period of time, so
> that
> >> >> >> > they can
> >> >> >> > continue to produce releases rather than needing to spend
> >> >> >> > unplanned
> >> >> >> > time
> >> >> >> > switching out this library[1].
> >> >> >> >
> >> >> >> > To be specific I propose we give projects already using this
> >> >> >> > license
> >> >> >> > 6
> >> >> >> > months to clean this up in which they can continue to release
> with
> >> >> >> > dependencies on the JSON license.
> >> >> >> >
> >> >> >> > Alan.
> >> >> >> >
> >> >> >> > 1. The amount of time to fix this will not be trivial. Based
> on a
> >> >> >> > little bit of digging I’ve done the alternatives are not 100%
> >> >> >> > identical in
> >> >> >> > their behavior which will mean projects will need to thoroughly
> >> >> >> > test
> >> >> >> > the
> >> >> >> > replacements and change their code to deal with the differences.
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > ------------------------------------------------------------
> ---------
> >> >> >> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> >> >> > For additional commands, e-mail: legal-discuss-help@apache.org
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> ------------------------------------------------------------
> ---------
> >> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
> >> >> >>
> >> >> >
> >> >>
> >> >> ------------------------------------------------------------
> ---------
> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> For additional commands, e-mail: legal-discuss-help@apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
*Simon Lessard*, Software Architect
*CMA* *IT*
*( +33(0) 6 79 37 39 85 (France)*
Re: A grace period for getting rid of JSON license jars
Posted by sebb <se...@gmail.com>.
On 19 November 2016 at 03:08, Ted Dunning <te...@gmail.com> wrote:
>
> So ... there are a few questions popping up in different forms that bear on
> the same issues. Here are some paraphrases and my answers:
>
> 1) Does the replacement library use the org.json package?
>
> Yes. It does. This may be a problem. If it turns out that way, I will spin
> another version that uses a different package root.
Yes, it is a potential major problem.
Think of it this way:
would it be OK to set up an application with both your library and the
original library on the classpath?
If you tell Maven that your jar and the original jar have different
(gid,aid) coords, then Maven has no way of knowing that these contain
the same packages.
So Maven will add them both to the classpath if they are both referenced.
> On the other hand, it looks to me so far that re-using the org.json package
> actually makes proper surgery easier.
Yes, but the cost is potential jar hell.
> 2) I have a dependency on a third party that has a dependency on org.json
> stuff.
>
> First and most inflammatory answer: that makes the third party dependency
> category X.
>
> Second and much less inflammatory answer: because the package name is the
> same, you are likely to be able to satisfy the transitive dependency with my
> packaging of the Android library. It may require slightly more footwork than
> just swapping out the pom clause as I suggested earlier.
>
> 3) I have a dependency that includes the org.json source code.
>
> First and most inflammatory answer: that makes the third party dependency
> category X.
>
> Second and much less inflammatory answer: you might be able to convince your
> dependency to use the code I extracted instead. If not, that is a really
> difficult spot.
>
> 4) I have a dependency that includes the org.json jar file.
>
> First and most inflammatory answer: that makes the third party dependency
> category X.
>
> Second and much less inflammatory answer: This should be solvable by simply
> swapping jars. Explicitly packaging jars that are in maven central is kind
> of perverse, however, and really ought to be discouraged.
>
>
>
>
>
> On Fri, Nov 18, 2016 at 5:44 PM, Joe Witt <jo...@gmail.com> wrote:
>>
>> Ted,
>>
>> Agreed and understood that json.org's library is now considered
>> category-x.
>>
>> In this case the discussion centers around the grace period to
>> continue apache releases while resolving pre-existing valid usage of
>> the library.
>>
>> Definitely appreciate you taking the initiative on providing an
>> alternative implementation. In the case I'm concerned about we have a
>> library, twitter4j, which uses the json.org code as a source
>> dependency so we'd not be able to exclude their binary dep and replace
>> it.
>>
>> As I mentioned previously we've already taken the steps necessary to
>> remove any usage of json.org dependencies from our codebase and we're
>> prepared to release. The problem is that the solution meant removing
>> an often used feature from the build and it will create user confusion
>> and is inconsistent with our stated backward compatibility guidance
>> for the community.
>>
>> We did reach out to the dependency community, twitter4j, and they
>> responded right away and seem willing to work with us to resolve so it
>> is just a matter of time. The grace period would allow us to avoid
>> impact to our users while we continue to responsibly address the
>> matter.
>>
>> There does seem to be consensus on this thread that some form of grace
>> period is reasonable so just looking to see if that has reached the
>> point of a decision.
>>
>> Thanks
>> Joe
>>
>> On Fri, Nov 18, 2016 at 6:42 PM, Ted Dunning <te...@gmail.com>
>> wrote:
>> >
>> > Joe,
>> >
>> > I think that the consensus is that JSON is category X.
>> >
>> > Consider using the library I just built. Should result in little or no
>> > user
>> > visible change.
>> >
>> >
>> >
>> > On Fri, Nov 18, 2016 at 11:30 AM, Joe Witt <jo...@gmail.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> Has a decision been reached by any chance? We're looking to kick off
>> >> the next Apache NiFi release and while we've done the work to
>> >> eliminate the use of this library it required us to reduce user
>> >> convenience in one case that we'd love to undo and expect the grace
>> >> period will resolve.
>> >>
>> >> Thanks
>> >> Joe
>> >>
>> >> On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning <te...@gmail.com>
>> >> wrote:
>> >> >
>> >> > I like this too, but would rather have the "next release after
>> >> > xxx/yyy"
>> >> > form
>> >> > of deadline.
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <ji...@jagunet.com>
>> >> > wrote:
>> >> >>
>> >> >> The more I think about it, the more this makes sense. Basically
>> >> >> we refuse the use of it for any new projects/efforts, but those
>> >> >> projects which are currently using it, with no issues, should
>> >> >> be allowed to continue using them, grandfathered, at least for
>> >> >> a time being.
>> >> >>
>> >> >> Let me mull this over some more and make an official determination/
>> >> >> ruling. :)
>> >> >>
>> >> >> > On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com>
>> >> >> > wrote:
>> >> >> >
>> >> >> > The recent moving of the JSON license to category X means that a
>> >> >> > number
>> >> >> > of projects cannot do any releases until this is fixed. I know
>> >> >> > this
>> >> >> > includes Hadoop, Hive, and Spark, and probably a number of others
>> >> >> > since
>> >> >> > hadoop-common (which many project use) depends on jars from
>> >> >> > json.org.
>> >> >> > The
>> >> >> > Hive team in particular is trying to get a maintenance release out
>> >> >> > which is
>> >> >> > blocked by this.
>> >> >> >
>> >> >> > I talked with Jim Jagielski briefly today and he suggested that
>> >> >> > perhaps
>> >> >> > we could have a grandfather clause on this so that projects that
>> >> >> > already are
>> >> >> > using it could continue to, at least for a period of time, so that
>> >> >> > they can
>> >> >> > continue to produce releases rather than needing to spend
>> >> >> > unplanned
>> >> >> > time
>> >> >> > switching out this library[1].
>> >> >> >
>> >> >> > To be specific I propose we give projects already using this
>> >> >> > license
>> >> >> > 6
>> >> >> > months to clean this up in which they can continue to release with
>> >> >> > dependencies on the JSON license.
>> >> >> >
>> >> >> > Alan.
>> >> >> >
>> >> >> > 1. The amount of time to fix this will not be trivial. Based on a
>> >> >> > little bit of digging I’ve done the alternatives are not 100%
>> >> >> > identical in
>> >> >> > their behavior which will mean projects will need to thoroughly
>> >> >> > test
>> >> >> > the
>> >> >> > replacements and change their code to deal with the differences.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> >> > For additional commands, e-mail: legal-discuss-help@apache.org
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> For additional commands, e-mail: legal-discuss-help@apache.org
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
So ... there are a few questions popping up in different forms that bear on
the same issues. Here are some paraphrases and my answers:
1) Does the replacement library use the org.json package?
Yes. It does. This may be a problem. If it turns out that way, I will spin
another version that uses a different package root.
On the other hand, it looks to me so far that re-using the org.json package
actually makes proper surgery easier.
2) I have a dependency on a third party that has a dependency on org.json
stuff.
First and most inflammatory answer: that makes the third party dependency
category X.
Second and much less inflammatory answer: because the package name is the
same, you are likely to be able to satisfy the transitive dependency with
my packaging of the Android library. It may require slightly more footwork
than just swapping out the pom clause as I suggested earlier.
3) I have a dependency that includes the org.json source code.
First and most inflammatory answer: that makes the third party dependency
category X.
Second and much less inflammatory answer: you might be able to convince
your dependency to use the code I extracted instead. If not, that is a
really difficult spot.
4) I have a dependency that includes the org.json jar file.
First and most inflammatory answer: that makes the third party dependency
category X.
Second and much less inflammatory answer: This should be solvable by simply
swapping jars. Explicitly packaging jars that are in maven central is kind
of perverse, however, and really ought to be discouraged.
On Fri, Nov 18, 2016 at 5:44 PM, Joe Witt <jo...@gmail.com> wrote:
> Ted,
>
> Agreed and understood that json.org's library is now considered
> category-x.
>
> In this case the discussion centers around the grace period to
> continue apache releases while resolving pre-existing valid usage of
> the library.
>
> Definitely appreciate you taking the initiative on providing an
> alternative implementation. In the case I'm concerned about we have a
> library, twitter4j, which uses the json.org code as a source
> dependency so we'd not be able to exclude their binary dep and replace
> it.
>
> As I mentioned previously we've already taken the steps necessary to
> remove any usage of json.org dependencies from our codebase and we're
> prepared to release. The problem is that the solution meant removing
> an often used feature from the build and it will create user confusion
> and is inconsistent with our stated backward compatibility guidance
> for the community.
>
> We did reach out to the dependency community, twitter4j, and they
> responded right away and seem willing to work with us to resolve so it
> is just a matter of time. The grace period would allow us to avoid
> impact to our users while we continue to responsibly address the
> matter.
>
> There does seem to be consensus on this thread that some form of grace
> period is reasonable so just looking to see if that has reached the
> point of a decision.
>
> Thanks
> Joe
>
> On Fri, Nov 18, 2016 at 6:42 PM, Ted Dunning <te...@gmail.com>
> wrote:
> >
> > Joe,
> >
> > I think that the consensus is that JSON is category X.
> >
> > Consider using the library I just built. Should result in little or no
> user
> > visible change.
> >
> >
> >
> > On Fri, Nov 18, 2016 at 11:30 AM, Joe Witt <jo...@gmail.com> wrote:
> >>
> >> Hello,
> >>
> >> Has a decision been reached by any chance? We're looking to kick off
> >> the next Apache NiFi release and while we've done the work to
> >> eliminate the use of this library it required us to reduce user
> >> convenience in one case that we'd love to undo and expect the grace
> >> period will resolve.
> >>
> >> Thanks
> >> Joe
> >>
> >> On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning <te...@gmail.com>
> >> wrote:
> >> >
> >> > I like this too, but would rather have the "next release after
> xxx/yyy"
> >> > form
> >> > of deadline.
> >> >
> >> >
> >> >
> >> > On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <ji...@jagunet.com>
> wrote:
> >> >>
> >> >> The more I think about it, the more this makes sense. Basically
> >> >> we refuse the use of it for any new projects/efforts, but those
> >> >> projects which are currently using it, with no issues, should
> >> >> be allowed to continue using them, grandfathered, at least for
> >> >> a time being.
> >> >>
> >> >> Let me mull this over some more and make an official determination/
> >> >> ruling. :)
> >> >>
> >> >> > On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com>
> wrote:
> >> >> >
> >> >> > The recent moving of the JSON license to category X means that a
> >> >> > number
> >> >> > of projects cannot do any releases until this is fixed. I know
> this
> >> >> > includes Hadoop, Hive, and Spark, and probably a number of others
> >> >> > since
> >> >> > hadoop-common (which many project use) depends on jars from
> json.org.
> >> >> > The
> >> >> > Hive team in particular is trying to get a maintenance release out
> >> >> > which is
> >> >> > blocked by this.
> >> >> >
> >> >> > I talked with Jim Jagielski briefly today and he suggested that
> >> >> > perhaps
> >> >> > we could have a grandfather clause on this so that projects that
> >> >> > already are
> >> >> > using it could continue to, at least for a period of time, so that
> >> >> > they can
> >> >> > continue to produce releases rather than needing to spend unplanned
> >> >> > time
> >> >> > switching out this library[1].
> >> >> >
> >> >> > To be specific I propose we give projects already using this
> license
> >> >> > 6
> >> >> > months to clean this up in which they can continue to release with
> >> >> > dependencies on the JSON license.
> >> >> >
> >> >> > Alan.
> >> >> >
> >> >> > 1. The amount of time to fix this will not be trivial. Based on a
> >> >> > little bit of digging I’ve done the alternatives are not 100%
> >> >> > identical in
> >> >> > their behavior which will mean projects will need to thoroughly
> test
> >> >> > the
> >> >> > replacements and change their code to deal with the differences.
> >> >> >
> >> >> >
> >> >> >
> >> >> > ------------------------------------------------------------
> ---------
> >> >> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> >> > For additional commands, e-mail: legal-discuss-help@apache.org
> >> >> >
> >> >>
> >> >>
> >> >> ------------------------------------------------------------
> ---------
> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> For additional commands, e-mail: legal-discuss-help@apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: A grace period for getting rid of JSON license jars
Posted by Joe Witt <jo...@gmail.com>.
Ted,
Agreed and understood that json.org's library is now considered category-x.
In this case the discussion centers around the grace period to
continue apache releases while resolving pre-existing valid usage of
the library.
Definitely appreciate you taking the initiative on providing an
alternative implementation. In the case I'm concerned about we have a
library, twitter4j, which uses the json.org code as a source
dependency so we'd not be able to exclude their binary dep and replace
it.
As I mentioned previously we've already taken the steps necessary to
remove any usage of json.org dependencies from our codebase and we're
prepared to release. The problem is that the solution meant removing
an often used feature from the build and it will create user confusion
and is inconsistent with our stated backward compatibility guidance
for the community.
We did reach out to the dependency community, twitter4j, and they
responded right away and seem willing to work with us to resolve so it
is just a matter of time. The grace period would allow us to avoid
impact to our users while we continue to responsibly address the
matter.
There does seem to be consensus on this thread that some form of grace
period is reasonable so just looking to see if that has reached the
point of a decision.
Thanks
Joe
On Fri, Nov 18, 2016 at 6:42 PM, Ted Dunning <te...@gmail.com> wrote:
>
> Joe,
>
> I think that the consensus is that JSON is category X.
>
> Consider using the library I just built. Should result in little or no user
> visible change.
>
>
>
> On Fri, Nov 18, 2016 at 11:30 AM, Joe Witt <jo...@gmail.com> wrote:
>>
>> Hello,
>>
>> Has a decision been reached by any chance? We're looking to kick off
>> the next Apache NiFi release and while we've done the work to
>> eliminate the use of this library it required us to reduce user
>> convenience in one case that we'd love to undo and expect the grace
>> period will resolve.
>>
>> Thanks
>> Joe
>>
>> On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning <te...@gmail.com>
>> wrote:
>> >
>> > I like this too, but would rather have the "next release after xxx/yyy"
>> > form
>> > of deadline.
>> >
>> >
>> >
>> > On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> >>
>> >> The more I think about it, the more this makes sense. Basically
>> >> we refuse the use of it for any new projects/efforts, but those
>> >> projects which are currently using it, with no issues, should
>> >> be allowed to continue using them, grandfathered, at least for
>> >> a time being.
>> >>
>> >> Let me mull this over some more and make an official determination/
>> >> ruling. :)
>> >>
>> >> > On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com> wrote:
>> >> >
>> >> > The recent moving of the JSON license to category X means that a
>> >> > number
>> >> > of projects cannot do any releases until this is fixed. I know this
>> >> > includes Hadoop, Hive, and Spark, and probably a number of others
>> >> > since
>> >> > hadoop-common (which many project use) depends on jars from json.org.
>> >> > The
>> >> > Hive team in particular is trying to get a maintenance release out
>> >> > which is
>> >> > blocked by this.
>> >> >
>> >> > I talked with Jim Jagielski briefly today and he suggested that
>> >> > perhaps
>> >> > we could have a grandfather clause on this so that projects that
>> >> > already are
>> >> > using it could continue to, at least for a period of time, so that
>> >> > they can
>> >> > continue to produce releases rather than needing to spend unplanned
>> >> > time
>> >> > switching out this library[1].
>> >> >
>> >> > To be specific I propose we give projects already using this license
>> >> > 6
>> >> > months to clean this up in which they can continue to release with
>> >> > dependencies on the JSON license.
>> >> >
>> >> > Alan.
>> >> >
>> >> > 1. The amount of time to fix this will not be trivial. Based on a
>> >> > little bit of digging I’ve done the alternatives are not 100%
>> >> > identical in
>> >> > their behavior which will mean projects will need to thoroughly test
>> >> > the
>> >> > replacements and change their code to deal with the differences.
>> >> >
>> >> >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> > For additional commands, e-mail: legal-discuss-help@apache.org
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> >> For additional commands, e-mail: legal-discuss-help@apache.org
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
Joe,
I think that the consensus is that JSON is category X.
Consider using the library I just built. Should result in little or no user
visible change.
On Fri, Nov 18, 2016 at 11:30 AM, Joe Witt <jo...@gmail.com> wrote:
> Hello,
>
> Has a decision been reached by any chance? We're looking to kick off
> the next Apache NiFi release and while we've done the work to
> eliminate the use of this library it required us to reduce user
> convenience in one case that we'd love to undo and expect the grace
> period will resolve.
>
> Thanks
> Joe
>
> On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning <te...@gmail.com>
> wrote:
> >
> > I like this too, but would rather have the "next release after xxx/yyy"
> form
> > of deadline.
> >
> >
> >
> > On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> >>
> >> The more I think about it, the more this makes sense. Basically
> >> we refuse the use of it for any new projects/efforts, but those
> >> projects which are currently using it, with no issues, should
> >> be allowed to continue using them, grandfathered, at least for
> >> a time being.
> >>
> >> Let me mull this over some more and make an official determination/
> >> ruling. :)
> >>
> >> > On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com> wrote:
> >> >
> >> > The recent moving of the JSON license to category X means that a
> number
> >> > of projects cannot do any releases until this is fixed. I know this
> >> > includes Hadoop, Hive, and Spark, and probably a number of others
> since
> >> > hadoop-common (which many project use) depends on jars from json.org.
> The
> >> > Hive team in particular is trying to get a maintenance release out
> which is
> >> > blocked by this.
> >> >
> >> > I talked with Jim Jagielski briefly today and he suggested that
> perhaps
> >> > we could have a grandfather clause on this so that projects that
> already are
> >> > using it could continue to, at least for a period of time, so that
> they can
> >> > continue to produce releases rather than needing to spend unplanned
> time
> >> > switching out this library[1].
> >> >
> >> > To be specific I propose we give projects already using this license 6
> >> > months to clean this up in which they can continue to release with
> >> > dependencies on the JSON license.
> >> >
> >> > Alan.
> >> >
> >> > 1. The amount of time to fix this will not be trivial. Based on a
> >> > little bit of digging I’ve done the alternatives are not 100%
> identical in
> >> > their behavior which will mean projects will need to thoroughly test
> the
> >> > replacements and change their code to deal with the differences.
> >> >
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> > For additional commands, e-mail: legal-discuss-help@apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> For additional commands, e-mail: legal-discuss-help@apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: A grace period for getting rid of JSON license jars
Posted by Joe Witt <jo...@gmail.com>.
Hello,
Has a decision been reached by any chance? We're looking to kick off
the next Apache NiFi release and while we've done the work to
eliminate the use of this library it required us to reduce user
convenience in one case that we'd love to undo and expect the grace
period will resolve.
Thanks
Joe
On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning <te...@gmail.com> wrote:
>
> I like this too, but would rather have the "next release after xxx/yyy" form
> of deadline.
>
>
>
> On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>
>> The more I think about it, the more this makes sense. Basically
>> we refuse the use of it for any new projects/efforts, but those
>> projects which are currently using it, with no issues, should
>> be allowed to continue using them, grandfathered, at least for
>> a time being.
>>
>> Let me mull this over some more and make an official determination/
>> ruling. :)
>>
>> > On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com> wrote:
>> >
>> > The recent moving of the JSON license to category X means that a number
>> > of projects cannot do any releases until this is fixed. I know this
>> > includes Hadoop, Hive, and Spark, and probably a number of others since
>> > hadoop-common (which many project use) depends on jars from json.org. The
>> > Hive team in particular is trying to get a maintenance release out which is
>> > blocked by this.
>> >
>> > I talked with Jim Jagielski briefly today and he suggested that perhaps
>> > we could have a grandfather clause on this so that projects that already are
>> > using it could continue to, at least for a period of time, so that they can
>> > continue to produce releases rather than needing to spend unplanned time
>> > switching out this library[1].
>> >
>> > To be specific I propose we give projects already using this license 6
>> > months to clean this up in which they can continue to release with
>> > dependencies on the JSON license.
>> >
>> > Alan.
>> >
>> > 1. The amount of time to fix this will not be trivial. Based on a
>> > little bit of digging I’ve done the alternatives are not 100% identical in
>> > their behavior which will mean projects will need to thoroughly test the
>> > replacements and change their code to deal with the differences.
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> > For additional commands, e-mail: legal-discuss-help@apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Ted Dunning <te...@gmail.com>.
I like this too, but would rather have the "next release after xxx/yyy"
form of deadline.
On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> The more I think about it, the more this makes sense. Basically
> we refuse the use of it for any new projects/efforts, but those
> projects which are currently using it, with no issues, should
> be allowed to continue using them, grandfathered, at least for
> a time being.
>
> Let me mull this over some more and make an official determination/
> ruling. :)
>
> > On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com> wrote:
> >
> > The recent moving of the JSON license to category X means that a number
> of projects cannot do any releases until this is fixed. I know this
> includes Hadoop, Hive, and Spark, and probably a number of others since
> hadoop-common (which many project use) depends on jars from json.org.
> The Hive team in particular is trying to get a maintenance release out
> which is blocked by this.
> >
> > I talked with Jim Jagielski briefly today and he suggested that perhaps
> we could have a grandfather clause on this so that projects that already
> are using it could continue to, at least for a period of time, so that they
> can continue to produce releases rather than needing to spend unplanned
> time switching out this library[1].
> >
> > To be specific I propose we give projects already using this license 6
> months to clean this up in which they can continue to release with
> dependencies on the JSON license.
> >
> > Alan.
> >
> > 1. The amount of time to fix this will not be trivial. Based on a
> little bit of digging I’ve done the alternatives are not 100% identical in
> their behavior which will mean projects will need to thoroughly test the
> replacements and change their code to deal with the differences.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: A grace period for getting rid of JSON license jars
Posted by Jim Jagielski <ji...@jaguNET.com>.
The more I think about it, the more this makes sense. Basically
we refuse the use of it for any new projects/efforts, but those
projects which are currently using it, with no issues, should
be allowed to continue using them, grandfathered, at least for
a time being.
Let me mull this over some more and make an official determination/
ruling. :)
> On Nov 16, 2016, at 2:22 PM, Alan Gates <al...@gmail.com> wrote:
>
> The recent moving of the JSON license to category X means that a number of projects cannot do any releases until this is fixed. I know this includes Hadoop, Hive, and Spark, and probably a number of others since hadoop-common (which many project use) depends on jars from json.org. The Hive team in particular is trying to get a maintenance release out which is blocked by this.
>
> I talked with Jim Jagielski briefly today and he suggested that perhaps we could have a grandfather clause on this so that projects that already are using it could continue to, at least for a period of time, so that they can continue to produce releases rather than needing to spend unplanned time switching out this library[1].
>
> To be specific I propose we give projects already using this license 6 months to clean this up in which they can continue to release with dependencies on the JSON license.
>
> Alan.
>
> 1. The amount of time to fix this will not be trivial. Based on a little bit of digging I’ve done the alternatives are not 100% identical in their behavior which will mean projects will need to thoroughly test the replacements and change their code to deal with the differences.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: A grace period for getting rid of JSON license jars
Posted by Sean Owen <sr...@apache.org>.
(BCC legal-discuss, for a side comment)
FWIW Spark should be un-blocked because it doesn't need the bit of Hive
that uses json.org code, and that's the only usage, so it's just excluded
from the project:
https://github.com/apache/spark/pull/15798
I agree with the sentiment in any event.
On Wed, Nov 16, 2016 at 1:23 PM Alan Gates <al...@gmail.com> wrote:
> The recent moving of the JSON license to category X means that a number of
> projects cannot do any releases until this is fixed. I know this includes
> Hadoop, Hive, and Spark, and probably a number of others since
> hadoop-common (which many project use) depends on jars from json.org.
> The Hive team in particular is trying to get a maintenance release out
> which is blocked by this.
>
> I talked with Jim Jagielski briefly today and he suggested that perhaps we
> could have a grandfather clause on this so that projects that already are
> using it could continue to, at least for a period of time, so that they can
> continue to produce releases rather than needing to spend unplanned time
> switching out this library[1].
>
> To be specific I propose we give projects already using this license 6
> months to clean this up in which they can continue to release with
> dependencies on the JSON license.
>
> Alan.
>
> 1. The amount of time to fix this will not be trivial. Based on a little
> bit of digging I’ve done the alternatives are not 100% identical in their
> behavior which will mean projects will need to thoroughly test the
> replacements and change their code to deal with the differences.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: A grace period for getting rid of JSON license jars
Posted by Stian Soiland-Reyes <st...@apache.org>.
Would it be too much to ask such projects to note clearly the JSON.org
license in its LICENSE, NOTICE or README? It just needs to say it is not
considered open source..?
On 16 Nov 2016 1:23 pm, "Alan Gates" <al...@gmail.com> wrote:
> The recent moving of the JSON license to category X means that a number of
> projects cannot do any releases until this is fixed. I know this includes
> Hadoop, Hive, and Spark, and probably a number of others since
> hadoop-common (which many project use) depends on jars from json.org.
> The Hive team in particular is trying to get a maintenance release out
> which is blocked by this.
>
> I talked with Jim Jagielski briefly today and he suggested that perhaps we
> could have a grandfather clause on this so that projects that already are
> using it could continue to, at least for a period of time, so that they can
> continue to produce releases rather than needing to spend unplanned time
> switching out this library[1].
>
> To be specific I propose we give projects already using this license 6
> months to clean this up in which they can continue to release with
> dependencies on the JSON license.
>
> Alan.
>
> 1. The amount of time to fix this will not be trivial. Based on a little
> bit of digging I’ve done the alternatives are not 100% identical in their
> behavior which will mean projects will need to thoroughly test the
> replacements and change their code to deal with the differences.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>