FYI, Revoking the vote to address (mostly) license issues.
Cheers Bolke > Begin forwarded message: > > From: Bolke de Bruin <bdbr...@gmail.com> > Subject: Re: [VOTE] Release Airflow 1.10.0 > Date: 28 July 2018 at 12:52:28 CEST > To: gene...@incubator.apache.org > > Hi Justin, > > Thanks for the feedback. The holiday period seems to make gathering +1s a bit > slow. We are going to address the issues you and Sebb mentioned and put it up > for a revote at the PMC, which should be relatively quick as they don't > consider functional changes. For the potential GPL issue I am going to see if > we can set NON_GPL by default from the setup while I will also re-open the > legal issue to see if there is a more operations friendly way. > > Cheers > Bolke > >> On 24 Jul 2018, at 23:23, Justin Mclean <jus...@classsoftware.com> wrote: >> >> HI, >> >>> On the GPL dependency you mentioned. We are not distributing GPL sources, >>> not in source or in binary form. This has never been the case. >> >> Which is fine. There are two issues with GPL (Category X software): >> - you can’t distribute them [1] >> - Can you rely on them [2] >> >> It’s [2] that seem to be the issues here. Optional dependancies on Category >> X are allowed but I’m really not sure in this case that it is truly optional. >> >>> As to our solution (for now). Python packages are often installed site-wide >>> and can be part of the dependencies of other packages. While we maybe could >>> enforce the installation of the non-GPL API it would/could 1) interfere >>> with other packages on the same system that do not set this environment >>> variable explicitly. 2) If any the other packages upgrades without setting >>> this variable it would pull in the GPL API. So we decided that it would be >>> better to educate the user and make it part of the install instructions. >>> >>> We can reconsider, but we cannot solve #1 and #2. Which, in my opinion, >>> would make it more opaque to the users. >> >> IMO at the very least user should be informed that this is the case and >> loudly and possibly with a prompt as part of the build and install process >> so that they understand that what they are using may not be under the terms >> of the ALv2 as claimed on the cover. >> >>> Given the current situation is at least improvement over the old situation >>> can you reconsider your -1 for this release and preferably agree with our >>> approach (or maybe have an improvement over it)? >> >> I would suggest you reopen the legal JIRA and describe the current situation >> (like above) and see if an answer can be found. >> >> Other IPMC member (and you mentors) can vote on this release and if it gets >> 3 +1’s and more plus ones than -1s then it’s a release. Remember a -1 vote >> on a release is not a veto. >> >> Thanks, >> Justin >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >
