ARIATOSCA dependencies license issues

[Ran Ziv <ra...@gigaspaces.com>]

Hi,

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,
Ran.

Re: ARIATOSCA dependencies license issues

[Daniel Shahaf <d....@daniel.shahaf.name>]

Ran Ziv wrote on Tue, 20 Jun 2017 12:25 +0300:
> this would mean that users installing ARIATOSCA would not receive fabric as
> is, but installing, say, "apache-ariatosca[ssh]" would install fabric as
> well.

That'd be fine.

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

Re: ARIATOSCA dependencies license issues

[Ran Ziv <ra...@gigaspaces.com>]

Thank you Daniel.

Glad to hear PyLint isn't a problem.

Regarding Fabric, it does not have pluggable SSH backends - it is tightly
coupled with Paramiko.
The SSH functionality is important yet the product is in fact viable
without this functionality, so I think we'll indeed go for option a
(opt-in).
Does this "opt-in" mean the user will have to manually install fabric where
we only suggest doing so via README, or is it ok to use the Python
"extra_require" mechanism for this (see Apache Airflow's setup.py
<https://github.com/apache/incubator-airflow/blob/master/setup.py#L250>) -
this would mean that users installing ARIATOSCA would not receive fabric as
is, but installing, say, "apache-ariatosca[ssh]" would install fabric as
well.

Thanks for your help,
Ran



On Sun, Jun 18, 2017 at 8:06 PM, Daniel Shahaf <d....@daniel.shahaf.name>
wrote:

> Ran Ziv wrote on Fri, 16 Jun 2017 20:09 +0300:
> > 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.
>
> It's not a problem: your release contains neither PyLint nor a derived
> work of PyLint.  Compare how C projects are allowed to use Valgrind.
>
> > 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.
>
> Does fabric have pluggable ssh backends?  If a user can use fabric with
> some category-A ssh package instead of paramiko, then the dependency on
> fabric should be acceptable.
>
> Failing that, do you consider the ssh functionality optional?  I.e., is
> the product viable without ssh functionality?  If so, making the
> paramiko dependency opt-in (similar to your (a) option) will suffice.
> See <https://www.apache.org/legal/resolved#optional>.
>
> HTH,
>
> Daniel
>

Re: ARIATOSCA dependencies license issues

[Daniel Shahaf <d....@daniel.shahaf.name>]

Ran Ziv wrote on Fri, 16 Jun 2017 20:09 +0300:
> 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.

It's not a problem: your release contains neither PyLint nor a derived
work of PyLint.  Compare how C projects are allowed to use Valgrind.

> 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.

Does fabric have pluggable ssh backends?  If a user can use fabric with
some category-A ssh package instead of paramiko, then the dependency on
fabric should be acceptable.

Failing that, do you consider the ssh functionality optional?  I.e., is
the product viable without ssh functionality?  If so, making the
paramiko dependency opt-in (similar to your (a) option) will suffice.
See <https://www.apache.org/legal/resolved#optional>.

HTH,

Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org