www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ran Ziv <...@gigaspaces.com>
Subject ARIATOSCA dependencies license issues
Date Fri, 16 Jun 2017 17:09:24 GMT

I've read the Apache allowed licenses
<https://www.apache.org/legal/resolved.html#category-x>, and I have a
couple of questions regarding the ARIATOSCA project's dependencies:

1) My first question is regarding the PyLint
<https://github.com/PyCQA/pylint> package (GPL2.0) - This is the tool we
use for validating our Python code format. This is only relevant for
development purposes, and would not be packaged with ARIATOSCA - not even
in the source distribution format.
It is installed from the tests/requirements.txt file, and is used by tox on
CIs or manually by developers.
I'm not sure whether this is a problem from Apache's perspective - i'd
assume it shouldn't be, but if it is we could supposedly simply work with a
different tool for this.

2) My second question is about the Paramiko
<https://github.com/paramiko/paramiko> package (LGPL2.1), which is a
transitive dependency of ARIA (through the Fabric
<https://github.com/fabric/fabric> package) - Paramiko is the native python
implementation for SSH, and is widely used in Python ecosystem - including
in Fabric, which is the library ARIA uses for remote execution.
I believe the main reason we haven't noticed this so far is because in the
past we only checked for non-recursive dependencies - and Fabric is
licensed under BSD-2-clause, which is allowed by Apache.

Since ARIA doesn't use Paramiko directly (but only via Fabric), I'm not
sure if this is a problem either, as Fabric license is ok according to the
licenses rules.
Also, and this might be somewhat naive, but I'm not completely clear about
what constitutes as "included packages" - When we will make a release,
we'll distribute a source and binary packages of ARIA, but no packages
which actually contain any dependencies code - those will be installed
separately (e.g. from PyPI).

If despite the above this still does pose a problem, I'd like to know which
of these viable solutions might be acceptable, if any:

a) we could remove Fabric (and thereby Paramiko) from ARIA's dependencies,
but leave the code using them inside - This way, when a user installs ARIA,
they won't automatically receive any non-ASF-sanctioned dependency code,
and ARIA will work but without any remote execution capabilities - and all
that would be required from the user to add these capabilities is to
manually install the Fabric library.
This way, Fabric is treated like an extension or a plugin, so I'd like to
think this is something acceptable according to Apache's legal constraints.

b) If (a) is not acceptable because ARIA will still have references to
Fabric in the code (despite Fabric not getting installed), then perhaps we
could extract the referencing code as well into a separate package which
lives outside of ASF, and users would have to install this separate package
to be able to use the remote execution capabilities.

Thank you for your help,

View raw message