www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <joe.w...@gmail.com>
Subject Re: A grace period for getting rid of JSON license jars
Date Sat, 19 Nov 2016 01:44:53 GMT
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 <ted.dunning@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 <joe.witt@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


Mime
View raw message