ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ran Ziv <>
Subject ARIA dependencies License issues
Date Sun, 04 Jun 2017 12:02:24 GMT

I went over all of ARIA's dependencies (including recursive dependencies)
and validated them against the Apache allowed licenses
We've done this before and found no issues, but this time two libraries
came up as a possible problem. I have a few theories about how this might
have happened, but what's more important is to understand what we can do
about it.

John, Suneel - I was hoping you might be able to answer some of the legal
questions / suggestions I've made below. If not, please advise where I
might be able to get answers for those.

The first package is PyLint (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 ARIA - 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 if 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.

The more serious issue is with the Paramiko package (LGPL2.1) - 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 in the execution-plugin.
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), this might
be considered ok.
Otherwise, we have few other options:

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

Assuming this is not enough to claim that these packages are "not included"
with ARIA, 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.

If this too 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.

Finally, if none of my suggestions above pans out, I'd suggest we
temporarily remove the remote execution capabilities, aim for an ARIA
release with local capabilities only, and try to figure a workaround for
the remote execution at a later date.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message