Re: A grace period for getting rid of JSON license jars
From: | Andrew Wang <andrew.wang-AT-cloudera.com> | |
To: | legal-discuss-AT-apache.org | |
Subject: | Re: A grace period for getting rid of JSON license jars | |
Date: | Fri, 18 Nov 2016 16:02:35 -0800 | |
Message-ID: | <CAGB5D2ZyxH4hBhhu+3nNafXuGjdkJASFWd=79-F9qyzFHdV2Ug@mail.gmail.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 <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 >> >> >