GPL dependencies

We need to avoid GPL.

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.

Snyk is reporting the following dependencies in our requirements.txt for python 3.6, 3.7, 3.8 are GPL v3:

• jaydebeapi v1.2.3
• mysql-connector-python v8.0.18
• pysmbclient v0.1.5
• unidecode v1.1.1
• yamllint v1.23.0

I see some previous discussion + mitigation for unidecode but not all of these.

[ryw]

Thanks @potiuk - i’ll submit a documentation PR around this.

[potiuk]

Sure we should review those. I don’t think there is anything to raise in those projects … if they are using GPL licence, that’s their choice.

And it’s not all black@white use/no use. But luckily we are perfectly covered and ASF tells us exactly what to do. The restriction of GPL which belongs to so called “category X” is very precisely described here: https://www.apache.org/legal/resolved.html#category-x. And it’s quite clear that this is perfectly OK to have requirements (in form of dependencies) as long as a) we do not redistribute the code or binary and b) this is an optional feature of our software. More details follow:

1. We cannot distribute the dependency in either form (source or binary). But we can use it (otherwise we would not be able to use Linux as it’s Kernel is GPL). Specific comment in Apache licensing policy is “For example, using a GPL’ed tool during the build is OK, however including GPL’ed source code is not.”

2. THEY MAY BE RELIED UPON WHEN THEY SUPPORT AN OPTIONAL FEATURE¶ Optional means that the component is not required for standard use of the product or for the product to achieve a desirable level of quality. The question to ask yourself in this situation is: “Will the majority of users want to use my product without adding the optional components?”

In light of the above:

1. Yamllint is fine - we are using it as a build tool but we do not redistribute it nor it is needed for Airflow to run (at all)

2. mysql-connector-python v8.0.18 - that’s an interesting one. We have also mysqlclient (also GPL) to connect for MySQL operator. But we do not rely on either to connect to our MetaData store even if MySQL is used as the backend. This entirely depends on the configuration of SQL Alchemy connection string. There are many engines you can use for MySQL and there is for example https://github.com/PyMySQL/PyMySQL which is MIT licence.

3. Pysmbclient is clearly optional.

4. unidecode. We have an explanation in the Changelog that this is an optional feature. It is a transitive (and optional) dependency of nvd3 (which we used to have vendored in and modified to not load it). So nvd3/slugify now will only use unidecode if it is installed in the system and it is not necessary for it to run.

### SLUGIFY_USES_TEXT_UNIDECODE or AIRFLOW_GPL_UNIDECODE no longer required

It is no longer required to set one of the environment variables to avoid
a GPL dependency. Airflow will now always use text-unidecode if unidecode
was not installed before.

1. Jaydbapi is used by the JDBC hook. Also optional.

I think we are good.