Consider dual licensing under Perl Artistic

[bolkedebruin]

Hi,

I am one of the maintainers of Apache Airflow. Indirectly we make use of unidecode through a dependency (python-nvd3 -> python-slugify -> unidecode). The Apache Software Foundation considers the GPLv2 incompatible with the APL2.

We didn't find out about the issue until now due to the fact that nvd3 and python-slugify maintain compatible licensed. Python-slugify is MIT licensed which might be incompatible with GPLv2 (I am not a lawyer).

We could ask python-slugify to use an alternative library or implement our own. Both are obviously a hassle as we need to convince package maintainers to switch. Also there is not technical reason to do so for us.

As the original Perl package was also available under the Perl Artistic License, would you consider dual licensing your derivative? That would allows us to continue to use the very useful libraries and just make us very happy :-).

Thanks for your consideration in advance! Bolke

[avian2]

Hi

I'm glad you find unidecode useful. Unfortunately, I do not want to release the Python port under a permissive license. However:

unidecode is available under the terms of GPL 2 or any later version. According to the FSF, Apache License 2.0 is compatible with GPL 3.

Similarly, according to the FSF, the usual MIT license is compatible with GPL. I tend to trust FSF in these matters.

If it turns out that you can't use unidecode after all, there exists a similar library that is available under the Artistic License: https://github.com/kmike/text-unidecode

[bolkedebruin]

Hi @avian2

Thanks for your response. Unfortunately, the compatibility is one way: “Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.”. We indirectly link due our dependency on python-nvd3.

This probably also goes for the MIT licensed python-slugify. So given your answer I will take it up with its maintainers to see if they are willing to change the dependency to text-unidecode if we can’t convince you otherwise.

Cheers Bolke

[bolkedebruin]

@avian2 quick question, which might resolve all: do you consider python-slugify using unidecode as a python module a derivative work from unidecode?

[avian2]

No, I don't consider python-slugify as a derivative work from unidecode. I agree with what @un33k said in https://github.com/un33k/python-slugify/issues/7.

FSF's interpretation of GPL is that using interpreted libraries (like Python modules) triggers the derivative clause. However Unidecode basically provides a single function, and obviously libraries other than unidecode already exist that can provide other implementations of that function. It's hard to argue that simply using this interface makes any code "based on unidecode".

[bolkedebruin]

Thanks. That probably solves the issue.