Licensing risks

[ryw]

I've pulled together a list of questionable licenses that license scanners will pick up for Airflow. Ideally we should look to remove the dependencies from the project.

Project	License	PR
astroid	LGPL-3.0
certifi	MPL-2.0
chardet	LGPL-2.1
JayDeBeApi	LGPL-3.0
ldap3	LGPL-3.0
mysql-connector-python	GPL-3.0
paramiko	LGPL-3.0
pathspec	MPL-2.0
psycopg2-binary	LGPL-3.0
pycountry	LGPL-2.1
PyGithub	LGPL-3.0
pymssql	LGPL-3.0
PySmbClient	GPL-3.0
pytest-rerunfailures	MPL-2.0
text-unidecode	Artistic-2.0
Unidecode	GPL-3.0	#10665
yamllint	GPL-3.0

[potiuk]

Duplicate of #9898

Just to give a bit of context here: As an ASF project we are bound by the https://www.apache.org/legal/resolved.html

We've discussed most (if not all) of those libraries in #9898. I looked through it and do not find any new "watchouts".

IMHO the result of this discussion is that we are "ok". Unless there is other reason (not ASF policies) that we want to get rid of those as risk @ryw?

Maybe we simply want to get rid of those because we want to avoid any risk whatsoever ?

[ryw]

We should seek to eliminate category-x dependencies/references, if possible, as the cleanest resolution.

For those that we cannot get rid of, or don't think we must get rid of (if we think we are OK in how we're using them), we'll document that somewhere for reference (which I volunteer to do).

[potiuk]

Sure - I am perfectly ok with that - and documenting is a good thing.

I just think we are spinning in circles a bit - I thought we reached conclusions and explained all reasons in #9898. So I am surprised a bit that we have the second one, but I might be wrong about "conclusions", so I prefer to ask.

[ryw]

Hi @potiuk i better understand now the technique we're using to provide constraint files that aren't in the source code - which definitely helps with automated scanners, since those files are in orphaned branches (confirmed via Snyk today, at least).

Is the intention to keep this structure going forward through future releases, or is it a 1.10 -> 2.0 thing?

[potiuk]

It's going to stay like that as far as I am concerned. But his is something we are going to discuss on Monday.

I am writing a short proposal for 2.0 release/packaging process today, so that everyone can read it before we have our Monday meetingu on 2.0. I promised I send it before at the last meeting.

[ryw]

Thanks @potiuk - closing this issue, as the latest master doesn't trigger all these license vulnerabilities in Snyk any longer.

[potiuk]

Ah, so Snyke is not that smart eventually :). We still have text-unidecode as transitive (though optional) dependency still.