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 <[email protected]> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]> Date: Friday, November 4, 2016 at 3:50 PM To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]> 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: [email protected]<mailto:[email protected]>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
