www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: A grace period for getting rid of JSON license jars
Date Sat, 19 Nov 2016 00:02:35 GMT
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 <ted.dunning@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 <alanfgates@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 <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