[openstack-dev] [tc][kolla] Ansible module with GPLv3

Steven Dake (stdake) stdake at cisco.com
Fri Nov 4 23:06:05 UTC 2016


Jeremy

Apologies for top post – lookout broken again.

Since Kolla uses popen to launch Ansible, and the module loads into GPLv3 code, the GPLv3 license ends at the Ansible end of the popen call.  Transitive dependencies are not a thing with network services (popen creates a network service).

If we are talking using someone else’s GPLv3 code, that is completely forbidden and I’d -2 any such review I saw in the queue that behaved in this way.

The correct answer here is simply to develop an ASL2.0 module that works with Ansible.  The GPLv3 does not require us to implement Ansible modules in GPLv3 – we may use whatever license we like (in this case ASL2.0 should be used).  The fact that on instantiation a transitive dependency is created inside the network service (at the second end of the popen call) simply means that code ends up with some kind of GPLv3 license *on instantiation* not on implementation as the plugins themselves can be developed directly in Ansible without interaction with the rest of the Kolla code base.

GPLv3 does not cross network boundaries, or the entire world of computing would be in chaos.

Regards
-steve

From: Jeremy Stanley <fungi at yuggoth.org>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Friday, November 4, 2016 at 3:50 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

On 2016-11-04 22:22:47 +0000 (+0000), Steven Dake (stdake) wrote:
[...]
The first file I examine in any repository is the LICENSE file –
if its GPLv3, I look no further.  I recommend everyone that has
signed the CLA follow the same pattern to keep OpenStack in good
legal health.

As I understand it, the challenge here is that plugins for Ansible
will by definition be derivative works of Ansible and thus inherit
their license choice. No amount of "clean room reimplementation"
will solve that unless you also reimplement Ansible under a
different license while you're at it.

If having the ICLA enforced on a repo with GPL code in it is an
issue, this could in theory be resolved by putting it in a separate
repository with no CLA enforcement. If a plug-in for Ansible being
under the same license as Ansible poses a problem for a repo as a
deliverable of an official OpenStack project team, then perhaps it
could just be distributed in an unofficial repo instead (though this
seems overly proscriptive to me).
--
Jeremy Stanley

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161104/cd7989f0/attachment.html>


More information about the OpenStack-dev mailing list