Open Stack

Clint,

I disagree that modules (which are really plugins) must be licensed under GPLv3.  You may license any module code as you like (i.e. ASL2.0) and include it in a GPLv3 project via Ansible modules because the modules act as plugins.  The ASL2.0 license does taint, however, it does not matter.

We run Ansible via popen, which treats Ansible as a Network Service.  The reality is we don’t care if modules (which are really plugins as they are used in Kolla) taint.  The taint occurs during instation of the module (which PLUGS IN to Ansible during runtime), not as a fact of including the code in the repository.

From previous conversations with the BOD and TC, they don’t see a problem with this since Ansible runs as a network service, isolating the licensing concerns.

A thought experiment (with some turtles).  If Apache was licensed under GPLv3, would your viewing of their web content automatically make that web content and all their web software infrastructure for displaying content GPLv3?  Now dig a little further, and ask, would that make your entire operating system GPLv3?  Now dig a little further, would that make your workstation GPLv3?  Would that make you GPLv3 for viewing the content?  Are we all GPLv3?

That web content is analogous to an Ansible module.  The question I’d like you to answer if you would indulge me is “Where does the GPLv3 license end in this stream?”  Not as an attorney, but purely on technical grounds.  I know what the attorney’s say.

Please review the thread on the legal list for more background.

Regards
-steve

From: Clint Byrum <clint at fewbar.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Friday, November 4, 2016 at 4:38 PM
To: openstack-dev <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

Excerpts from Jeremy Stanley's message of 2016-11-04 23:05:54 +0000:
On 2016-11-04 22:50:10 +0000 (+0000), Jeremy Stanley wrote:
[...]
> 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.
[...]
Further research suggests I'm wrong on this front. I was assuming
Ansible was providing a Python plug-in API here, in which case
coding to that would potentially create a derivative work. Instead
it looks like for at least some things they refer to as plug-ins
they pass around a JSON data structure which upstream Ansible has
said in the past they do not consider to result in plug-ins becoming
derivative works of Ansible. For example:
https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/basic.py

Modules are not plugins.

https://groups.google.com/forum/#!topic/ansible-project/GLwe3vbwTQk

Same here.

https://github.com/ansible/ansible/issues/8864

This only refers to dynamic inventory, which is hardly even a plugin
interface.

Strategy plugins run in ansible itself and must import pieces of Ansible,
and thus must be GPLv3:

https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/strategy

__________________________________________________________________________
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/20161105/76c84e19/attachment.html>