From einarum at gmail.com  Mon Dec  9 15:54:35 2019
From: einarum at gmail.com (Sergey Sh)
Date: Mon, 9 Dec 2019 17:54:35 +0200
Subject: [legal-discuss] GPLv3 and Apache2 licences for Openstack repos
In-Reply-To: <CAFUYg-8uwXsMki+8CP9RoiH=vJWUh7Qprwpu903E8ErnKtnzjg@mail.gmail.com>
References: <CAFUYg-8uwXsMki+8CP9RoiH=vJWUh7Qprwpu903E8ErnKtnzjg@mail.gmail.com>
Message-ID: <CAFUYg-87WRphutiiOyhXSWwWB0SRynnaEXaFsfc0y4aTE+SaLA@mail.gmail.com>

Hi, all

I wonder if I can get help here or suggestions for licenses question.
We move Ansible modules from upstream Ansible repository to Openstack
namespace. In parallel, we need to develop new modules and modules that
will replace those moved from Ansible. Moved original modules won't change.
The problem is that Ansible and its modules have GPLv3 license and
repositories of Openstack have Apache2.
There are about 150+ people committed to Ansible modules for years, so it's
hardly possible to get approval for relicensing from everyone.
How can we handle this situation without violating licenses and agreements?

As I see it's 3 options

1. Move GPL modules to SIG repo in Openstack, freeze them there, and create
a new Openstack repo with Apache2 license and develop the new modules in
it. Won't it be a problem if new modules will have the same functionality
as GPL ones?

2. Move GPL modules to SIG repo in Openstack, to develop new modules in GPL
there.
3. Move GPL modules to SIG repo in Openstack, to develop new modules in
Apache2 there.

I think because of partial incompatibility of Apache2 <-> GPLv3 licenses
option 3 is barely viable [1]
Option 2 is less preferred because it puts module aside from all Openstack
projects that have Apache2 license.
What are the potential issues of option 1?
I'd appreciate any ideas or opinions about the topic.

Thanks

[1] https://www.apache.org/licenses/GPL-compatibility.html
*Apache 2 software can therefore be included in GPLv3 projects, because the
GPLv3 license accepts our software into GPLv3 works. However, GPLv3
software cannot be included in Apache projects. The licenses are
incompatible in one direction only, and it is a result of ASF's licensing
philosophy and the GPLv3 authors' interpretation of copyright law.*

--
Best regards
Sagi Shnaidman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/legal-discuss/attachments/20191209/ff0c8130/attachment.html>

From mordred at inaugust.com  Mon Dec  9 16:22:39 2019
From: mordred at inaugust.com (Monty Taylor)
Date: Mon, 9 Dec 2019 11:22:39 -0500
Subject: [legal-discuss] GPLv3 and Apache2 licences for Openstack repos
In-Reply-To: <CAFUYg-87WRphutiiOyhXSWwWB0SRynnaEXaFsfc0y4aTE+SaLA@mail.gmail.com>
References: <CAFUYg-8uwXsMki+8CP9RoiH=vJWUh7Qprwpu903E8ErnKtnzjg@mail.gmail.com>
 <CAFUYg-87WRphutiiOyhXSWwWB0SRynnaEXaFsfc0y4aTE+SaLA@mail.gmail.com>
Message-ID: <ABC87B49-64CD-4F54-BCBC-37D2EC430EB1@inaugust.com>



> On Dec 9, 2019, at 10:54 AM, Sergey Sh <einarum at gmail.com> wrote:
> 
> 
> 
> Hi, all
> 
> I wonder if I can get help here or suggestions for licenses question.
> We move Ansible modules from upstream Ansible repository to Openstack namespace.

For slightly more context here - the Ansible upstream is decomposing itself similar to how Kubernetes did, so that communities can manage their own modules in their own repos rather than needing everything to go into the main Ansible repo.

On the OpenStack side, we’ve decided to handle the Ansible modules that interact with OpenStack as part of the ansible-sig:

https://review.opendev.org/#/c/684740/

> In parallel, we need to develop new modules and modules that will replace those moved from Ansible. Moved original modules won't change.
> The problem is that Ansible and its modules have GPLv3 license and repositories of Openstack have Apache2.
> There are about 150+ people committed to Ansible modules for years, so it's hardly possible to get approval for relicensing from everyone.
> How can we handle this situation without violating licenses and agreements?
> 
> As I see it's 3 options
> 
> 1. Move GPL modules to SIG repo in Openstack, freeze them there, and create a new Openstack repo with Apache2 license and develop the new modules in it. Won't it be a problem if new modules will have the same  functionality as GPL ones?

I think this would be confusing for both users and developers, as the current modules are heavily used and I don’t think rewriting them is valuable to anyone.

> 2. Move GPL modules to SIG repo in Openstack, to develop new modules in GPL there.
> 3. Move GPL modules to SIG repo in Openstack, to develop new modules in Apache2 there.
> 
> I think because of partial incompatibility of Apache2 <-> GPLv3 licenses option 3 is barely viable [1]
> Option 2 is less preferred because it puts module aside from all Openstack projects that have Apache2 license.

I think we should just do 2. These repos are being handed to the ansible-sig precisely because of the GPL encumbrance.

The original proposal was to add them as a deliverable to the openstacksdk project, since the existing modules were essentially written and maintained by the SDK team anyway - but that would make them a “deliverable” of the OpenStack project and therefore the GPL nature of them would become an issue.

As deliverables of a SIG, it’s not part of “the software”, but is rather software thet we’re making explicitly to interact with another community, and as a part of that I believe it’s reasonable to simply maintain the GPL license on them since that’s what the existing codebase is, as well as what Ansible itself is. (it’s *highly* unlikely that anyone who cares about these modules is going to have an issue with the GPL, since they are only useful in the context of Ansible, which is GPL)

I don’t think 3 is really an option because there is a decent amount of shared code in the modules, and even though some of it needs a refactor, I think it would be stretching definitions in an extreme manner to not consider even the new modules “derived works”. I also think it would be confusing for people to understand the licensing of the repo in question for not much gain.

> What are the potential issues of option 1?
> I'd appreciate any ideas or opinions about the topic.
> 
> Thanks
> 
> [1] https://www.apache.org/licenses/GPL-compatibility.html
> Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.
> 
> --
> Best regards
> Sagi Shnaidman
> _______________________________________________
> legal-discuss mailing list
> legal-discuss at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss



From fungi at yuggoth.org  Mon Dec  9 17:17:37 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 9 Dec 2019 17:17:37 +0000
Subject: [legal-discuss] GPLv3 and Apache2 licences for Openstack repos
In-Reply-To: <ABC87B49-64CD-4F54-BCBC-37D2EC430EB1@inaugust.com>
References: <CAFUYg-8uwXsMki+8CP9RoiH=vJWUh7Qprwpu903E8ErnKtnzjg@mail.gmail.com>
 <CAFUYg-87WRphutiiOyhXSWwWB0SRynnaEXaFsfc0y4aTE+SaLA@mail.gmail.com>
 <ABC87B49-64CD-4F54-BCBC-37D2EC430EB1@inaugust.com>
Message-ID: <20191209171736.hothjfqwmixzu266@yuggoth.org>

On 2019-12-09 11:22:39 -0500 (-0500), Monty Taylor wrote:
> > On Dec 9, 2019, at 10:54 AM, Sergey Sh <einarum at gmail.com> wrote:
[...]
> > 3. Move GPL modules to SIG repo in Openstack, to develop new
> > modules in Apache2 there.
> > 
> > I think because of partial incompatibility of Apache2 <-> GPLv3
> > licenses option 3 is barely viable
[...]

It depends on how you look at license compatibility. What's usually
expressed is the effective license terms of the work as a whole
(when disparate codebases are combined at runtime). It's not so much
that you're "including" some software in some other software, you're
just combining software with different but compatible licenses, and
the terms under which copyright is licensed for the combined work
tends to be a superset of the license terms for its constituent
parts.

> I don’t think 3 is really an option because there is a decent
> amount of shared code in the modules, and even though some of it
> needs a refactor, I think it would be stretching definitions in an
> extreme manner to not consider even the new modules “derived
> works”. I also think it would be confusing for people to
> understand the licensing of the repo in question for not much
> gain.
[...]

Yes, often when folks do this they talk about "clean room"
development practices where someone familiar with what the new piece
of software needs to do writes a specification and then someone else
who has never seen the original source code writes the replacement
from scratch, to avoid accidentally reusing novel algorithms from
the original which the developer might otherwise have impressed upon
their subconscious memory. That degree of paranoia may be overkill,
but I am not a lawyer and this is not legal advice. ;)
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/legal-discuss/attachments/20191209/910ef0be/attachment.sig>