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 <[email protected]> > 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 > > > > >
