incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bolke de Bruin <>
Subject [REVOKE][VOTE] Release Airflow 1.10.0
Date Sat, 28 Jul 2018 10:54:02 GMT

Revoking the vote to address (mostly) license issues.


> Begin forwarded message:
> From: Bolke de Bruin <>
> Subject: Re: [VOTE] Release Airflow 1.10.0
> Date: 28 July 2018 at 12:52:28 CEST
> To:
> 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 <> 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:
>> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message