[openstack-dev] [tc][kolla] Ansible module with GPLv3
Michał Jastrzębski
inc007 at gmail.com
Sat Nov 5 14:47:34 UTC 2016
Hey Fungi!
So unfortunately I don't see any viable way to write this plugin from
scratch. Plugin we'd need to write would have to mimic (without
derivative:)) this one
https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/strategy/linear.py
<- I don't think it's possible to reinvent this without jeopardizing
Kolla's stability. On the other hand if we inherit this class, it
might actually be pretty straightforward. I don't see any way of
avoiding writing this plugin without making it GPL v3.
On the bright note, rest of the project will keep using it in a
GPL-safe way, so it might be only GPL-licensed part of it. So real
question would be how to distribute it. I see 3 options
1. Make it part of Kolla-ansible, single file licensed as GPL
2. Make it separate project and Kolla will just install it like it
installs anything else
3. Work with Ansible community to merge it to Ansible itself
It's my understanding that shade, which had similar issues, followed 2
-> 3 path - started as a separate project and got merged into Ansible
eventually. That would be safe bet I think.
Regards,
Michal
On 5 November 2016 at 09:08, Jeremy Stanley <fungi at yuggoth.org> wrote:
> On 2016-11-04 16:38:45 -0700 (-0700), Clint Byrum wrote:
> [...]
>> Modules are not plugins.
> [...]
>> 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:
> [...]
>
> On further reading I mostly concur. Unfamiliarity with Ansible led
> me to believe they used the terms plug-in and module
> interchangeably, and I missed that the "strategy" qualifier was key
> to Michał's original problem statement. Strategy plugins do seem to
> generally import lots of GPLv3 licensed Python modules from Ansible
> and call into them, which under conventional wisdom makes the result
> a derivative work of Ansible that therefore needs to be distributed
> under a license compatible with GPLv3 (Apache2 would qualify
> according to the FSF).
>
> So presumably as long as the software in question is written from
> scratch without directly reusing code from existing software under
> other licenses, it could be distributed under Apache2 (which when
> combined with Ansible proper leads to a GPLv3 work as the latter
> provides a superset of the conditions for the former). Depending on
> who you listen to, this may also mean being careful to only
> reference Ansible's API documentation and not look at the underlying
> code or at other similar plug-ins, so as to avoid inadvertently
> copying some implementation details.
>
> Basically I also concur with Steve's evaluation, and hopefully so
> will the legal-discuss ML. In that case, it boils down to whether
> the strategy plug-in in question can be written from scratch or for
> expediency/convenience must be forked from another. If from scratch
> then it doesn't sound like there's any issue including it in the
> openstack/kolla repo under one of the OpenStack approved licenses as
> long as the Kolla team agrees.
>
> If a fork of, say, another GPLv3 plug-in then there may be legal
> reasons for it to belong in a separate repo without ICLA
> enforcement... though that's something I'd want to hear from lawyers
> since our contributors agree to the ICLA once as a blanket action,
> not on a per-repo basis, and there's plenty of software
> (particularly among unofficial projects) in our Gerrit for which the
> ICLA is not even remotely applicable. If there's no legal
> requirement to put it in a separate repo and it can be treated as an
> aggregation, then it would just be up to the Kolla team to decide
> whether they also find it acceptable or require some logical
> separation there for other reasons.
> --
> Jeremy Stanley
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list