airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bolke de Bruin <bdbr...@gmail.com>
Subject Re: Resolving the GPL Licensing issues with Unidecode
Date Fri, 04 Aug 2017 18:54:23 GMT
We don't "statically" link indeed GPL code and don't distribute it either. I wonder why blue-yonder
came to their conclusion (it is already in 1.7 as well). 

Bolke 

Sent from my iPhone

> On 4 Aug 2017, at 20:13, Arthur Wiedmer <arthur.wiedmer@gmail.com> wrote:
> 
> Good to know.
> 
> We do not ship it as part of the release, it would be downloaded at install
> time. I misunderstood the ASF restriction as concerning parts which are
> deemed essential to the functioning of the tool.
> 
> In this case python-nvd3 is used for some of the charting in Airflow, so as
> long as someone is not using the webserver, they are not required to run
> the code.
> 
> Best,
> Arthur
> 
>> On Aug 3, 2017 20:02, "Alexander Shorin" <kxepal@apache.org> wrote:
>> 
>> Do you release Airflow with all the dependencies included in release
>> tarball? In other words, do you *distribute* GPL-licensed work? If you
>> don't, you have no blockers on this.
>> 
>> ASF restriction applies to distirbution only. What people downloads
>> them self via package manager to satisfy build / runtime dependencies
>> doesn't count.
>> 
>> Reference:
>> https://www.apache.org/licenses/GPL-compatibility.html
>>> The Apache Software Foundation does not allow its own projects to
>> distribute software under licenses more restrictive than the Apache
>> License, and the Free Software Foundation does not distribute software
>> under the Apache License.
>> 
>> And because of this,I don't see any issues for Till to upgrade to
>> 1.8+, unless they prepare own Airflow release which includes all the
>> deps to distribute it across own company network.
>> 
>> --
>> ,,,^..^,,,
>> 
>> On Fri, Aug 4, 2017 at 3:23 AM, Arthur Wiedmer <arthur.wiedmer@gmail.com>
>> wrote:
>>> I would qualify that as a blocker.
>>> 
>>> Best,
>>> Arthur
>>> 
>>> On Aug 3, 2017 16:36, "Maxime Beauchemin" <maximebeauchemin@gmail.com>
>>> wrote:
>>> 
>>>> Hey, how does this affect the current release(s) taking place?
>>>> 
>>>> Max
>>>> 
>>>> On Thu, Aug 3, 2017 at 8:57 AM, Bolke de Bruin <bdbruin@gmail.com>
>> wrote:
>>>> 
>>>>> Oh that is a nice catch. Obviously option 3 is the easiest to get this
>>>>> resolved so it might be worth a try. This could be done by stating
>> that
>>>> the
>>>>> Apache Foundation and its lawyers disagree with the assessment the
>> author
>>>>> makes. I even think, but ianal, that python-slugify is not compliant
>> (you
>>>>> would need a LGPL version of unidecode for that).
>>>>> 
>>>>> Another option is to convince the author of unidecode to release
>> under a
>>>>> dual license as was the case with the original Perl module (perl
>> artistic
>>>>> and gpl). This might be difficult though: https://github.com/avian2/
>>>>> unidecode/issues/9
>>>>> 
>>>>> Probably the best option is 1. We should move to a webpack/yarn/npm
>> setup
>>>>> anyway. However this might be a bigger effort than you are up to.
>>>>> 
>>>>> Bolke
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On 3 Aug 2017, at 13:48, Heistermann, Till <
>>>>> Till.Heistermann@blue-yonder.com> wrote:
>>>>>> 
>>>>>> Hey all,
>>>>>> 
>>>>>> At Blue Yonder, we would love to upgrade to Airflow 1.8+,
>>>>>> but licensing issues with the dependencies currently prevent us from
>>>>> doing so.
>>>>>> (see https://issues.apache.org/jira/browse/AIRFLOW-1430 )
>>>>>> 
>>>>>> To sum it up, airflow 1.8+ pulls in the GPL-Licensed dependency
>>>>> `Unidecode`
>>>>>> via `python-slugify` and `python-nvd3`.
>>>>>> 
>>>>>> We would like to help resolving this.
>>>>>> 
>>>>>> We see three possible options here:
>>>>>> 
>>>>>> 1) Replace `python-nvd3` in airflow
>>>>>> 
>>>>>> 2) Replace the slugify implementation used in `python-nvd3`
>>>>>> 
>>>>>> 3) Replace the Unicode tables used in `python-slugify` with a
>>>>> licence-compatible version (e.g. https://github.com/kmike/text-
>> unidecode
>>>> ).
>>>>>> The main developer of `python-slugify` did not seem to be open to
>> this
>>>>> in back in 2014 though, but it might be worth a new try (see
>>>>> https://github.com/un33k/python-slugify/issues/7)
>>>>>> 
>>>>>> What is your opinion about this?
>>>>>> Which approach would be the most feasible?
>>>>>> Are you aware of libraries that could act as drop-in replacements?
>>>>>> 
>>>>>> Cheers, Till
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 

Mime
View raw message