ARIA dependencies License issues

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

Hi,

I went over all of ARIA's dependencies (including recursive dependencies)
and validated them against the Apache allowed licenses
<https://www.apache.org/legal/resolved.html#category-x>.
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.


Thanks,
Ran.

Re: ARIA dependencies License issues

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

Thanks John,
I wasn't familiar with the legal mailing list. I forwarded these questions
there.

I've started another thread about 2 weeks ago ("A few questions about
creating a release") which has a few other questions of similar nature but
somewhat less legal-y - Could you perhaps answer those, or should I forward
them to the legal mailing list as well?

Thanks,
Ran

On Thu, Jun 15, 2017 at 6:24 PM, John D. Ament <jo...@apache.org>
wrote:

> Ran,
>
> I believe the reason you're not getting a response is that this isn't the
> right list to bring it up.  I can provide some insight, but ultimately you
> need to get some legal input (from legal-discuss)
>
> - Code formatting shouldn't be an issue, since its not required for the
> execution of the code.
> - Paramiko would be an issue.  I would not include it as a dependency.
>
> John
>
> On Wed, Jun 14, 2017 at 11:17 AM Ran Ziv <ra...@gigaspaces.com> wrote:
>
> > Bumping this again, still waiting for answers on these issues.
> >
> > On Sun, Jun 4, 2017 at 3:02 PM, Ran Ziv <ra...@gigaspaces.com> wrote:
> >
> > > Hi,
> > >
> > > I went over all of ARIA's dependencies (including recursive
> dependencies)
> > > and validated them against the Apache allowed licenses
> > > <https://www.apache.org/legal/resolved.html#category-x>.
> > > 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.
> > >
> > >
> > > Thanks,
> > > Ran.
> > >
> > >
> >
>

Re: ARIA dependencies License issues

["John D. Ament" <jo...@apache.org>]

Ran,

I believe the reason you're not getting a response is that this isn't the
right list to bring it up.  I can provide some insight, but ultimately you
need to get some legal input (from legal-discuss)

- Code formatting shouldn't be an issue, since its not required for the
execution of the code.
- Paramiko would be an issue.  I would not include it as a dependency.

John

On Wed, Jun 14, 2017 at 11:17 AM Ran Ziv <ra...@gigaspaces.com> wrote:

> Bumping this again, still waiting for answers on these issues.
>
> On Sun, Jun 4, 2017 at 3:02 PM, Ran Ziv <ra...@gigaspaces.com> wrote:
>
> > Hi,
> >
> > I went over all of ARIA's dependencies (including recursive dependencies)
> > and validated them against the Apache allowed licenses
> > <https://www.apache.org/legal/resolved.html#category-x>.
> > 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.
> >
> >
> > Thanks,
> > Ran.
> >
> >
>

Re: ARIA dependencies License issues

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

Bumping this again, still waiting for answers on these issues.

On Sun, Jun 4, 2017 at 3:02 PM, Ran Ziv <ra...@gigaspaces.com> wrote:

> Hi,
>
> I went over all of ARIA's dependencies (including recursive dependencies)
> and validated them against the Apache allowed licenses
> <https://www.apache.org/legal/resolved.html#category-x>.
> 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.
>
>
> Thanks,
> Ran.
>
>