[all][tc][legal] Possible GPL violation in several places
Dear fellow OpenStackers, it has been brought to my attention that having any (Python) imports against a GPL lib (e.g Ansible) *might be* considered linking with all the repercussions of that (copyleft anyone?). Please see the original thread in Launchpad: https://bugs.launchpad.net/kolla-ansible/+bug/1918663 Not only the projects that have "Ansible" in name might be affected, e.g. Ironic also imports Ansible parts. Do note *I am not a lawyer* so I have no idea whether the Python importing is analogous to linking in terms of GPL. I am only forwarding the concerns reported to me in Launchpad. A quick Google search was inconclusive. I have done some analysis in the original Launchpad thread mentioned above. I am copying it here for ease of reference. """ Hmm, the reasoning is interesting. OpenStack Ansible and TripleO would probably also be interested in knowing whether GPL violation is happening or not. I am not in a position to answer this question. I will propagate this matter to the mailing list: http://lists.openstack.org/pipermail/openstack-discuss/ FWIW, TripleO is by Red Hat, just like Ansible, so one would assume they know what they are doing. OTOH, there is always room for a mistake. All in all, end users must use Ansible so they must agree to GPL anyhow, so the license switch would be mostly cosmetic: +/- the OpenStack licensing requirements [1]. That said, Ansible Collections for OpenStack are already licensed under GPL [2]. And a related (and very relevant) project using Ansible - Zuul - includes a note about partial GPL [3]. A quick search [4] reveals a lot of places that could be violating GPL in OpenStack (e.g. in Ironic, base CI jobs) if we followed this linking logic. [1] https://governance.openstack.org/tc/reference/licensing.html [2] https://opendev.org/openstack/ansible-collections-openstack [3] https://opendev.org/zuul/zuul [4] https://codesearch.opendev.org/?q=(from%7Cimport)%5Cs%2B%5Cbansible%5Cb&i=nope&files=&excludeFiles=&repos= """ -yoctozepto
Hi, Thanks for raising this. A note regarding ironic inline. On Sat, Mar 13, 2021 at 10:32 AM Radosław Piliszek < radoslaw.piliszek@gmail.com> wrote:
Dear fellow OpenStackers,
it has been brought to my attention that having any (Python) imports against a GPL lib (e.g Ansible) *might be* considered linking with all the repercussions of that (copyleft anyone?).
Please see the original thread in Launchpad: https://bugs.launchpad.net/kolla-ansible/+bug/1918663
Not only the projects that have "Ansible" in name might be affected, e.g. Ironic also imports Ansible parts.
Only in our ansible modules and only the BSD parts, namely https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/basic... Dmitry
Do note *I am not a lawyer* so I have no idea whether the Python importing is analogous to linking in terms of GPL. I am only forwarding the concerns reported to me in Launchpad. A quick Google search was inconclusive.
I have done some analysis in the original Launchpad thread mentioned above. I am copying it here for ease of reference.
""" Hmm, the reasoning is interesting. OpenStack Ansible and TripleO would probably also be interested in knowing whether GPL violation is happening or not. I am not in a position to answer this question. I will propagate this matter to the mailing list: http://lists.openstack.org/pipermail/openstack-discuss/ FWIW, TripleO is by Red Hat, just like Ansible, so one would assume they know what they are doing. OTOH, there is always room for a mistake. All in all, end users must use Ansible so they must agree to GPL anyhow, so the license switch would be mostly cosmetic: +/- the OpenStack licensing requirements [1]. That said, Ansible Collections for OpenStack are already licensed under GPL [2]. And a related (and very relevant) project using Ansible - Zuul - includes a note about partial GPL [3]. A quick search [4] reveals a lot of places that could be violating GPL in OpenStack (e.g. in Ironic, base CI jobs) if we followed this linking logic.
[1] https://governance.openstack.org/tc/reference/licensing.html [2] https://opendev.org/openstack/ansible-collections-openstack [3] https://opendev.org/zuul/zuul [4] https://codesearch.opendev.org/?q=(from%7Cimport)%5Cs%2B%5Cbansible%5Cb&i=nope&files=&excludeFiles=&repos= """
-yoctozepto
-- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
On 2021-03-13 10:28:37 +0100 (+0100), Radosław Piliszek wrote: [...]
And a related (and very relevant) project using Ansible - Zuul - includes a note about partial GPL [3]. A quick search [4] reveals a lot of places that could be violating GPL in OpenStack (e.g. in Ironic, base CI jobs) if we followed this linking logic. [...]
The reason parts of Zuul are GPL is that they actually include forks of some components of Ansible itself (for example, to be able to thoroughly redirect command outputs to a console stream). Zuul isolates the execution of those parts of its source in order to avoid causing the entire service to be GPL. Are you suggesting that files shipped in Ironic's deliverable repos directly import (in a Python sense) these GPL files? Nothing in the https://opendev.org/zuul/zuul-jobs repository is GPL. I've never seen any credible argument that merely executing a GPL program makes the calling program a derivative work. Also, if the Zuul jobs in project repositories really were GPL, that should still be fine according to our governance: Projects run as part of the OpenStack Infrastructure (in order to produce OpenStack software) may be licensed under any OSI-approved license. This includes tools that are run with or on OpenStack projects only during validation or testing phases of development (e.g., a source code linter). https://governance.openstack.org/tc/reference/licensing.html Anyway, we have a separate mailing list for such topics: http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss Let's please not jump to conclusions when it comes to software licenses. It's not as cut and dried as you might expect. -- Jeremy Stanley
Thanks Dmitry and Jeremy for your quick response. Also thanks Jeremy for replying in Launchpad as well. My answers inline. On Sat, Mar 13, 2021 at 12:07 PM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Not only the projects that have "Ansible" in name might be affected, e.g. Ironic also imports Ansible parts.
Only in our ansible modules and only the BSD parts, namely https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/basic...
Yes, that's something I have missed. The main README suggests everything is GPL in there so I was confused. Perhaps this is what also confused the OP from Launchpad. On Sat, Mar 13, 2021 at 2:07 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2021-03-13 10:28:37 +0100 (+0100), Radosław Piliszek wrote: [...]
And a related (and very relevant) project using Ansible - Zuul - includes a note about partial GPL [3]. A quick search [4] reveals a lot of places that could be violating GPL in OpenStack (e.g. in Ironic, base CI jobs) if we followed this linking logic. [...]
The reason parts of Zuul are GPL is that they actually include forks of some components of Ansible itself (for example, to be able to thoroughly redirect command outputs to a console stream). Zuul isolates the execution of those parts of its source in order to avoid causing the entire service to be GPL.
That's good to know and good that Zuul does it this way. Zuul was given as *the good* example. (if it was not clear from my message)
Are you suggesting that files shipped in Ironic's deliverable repos directly import (in a Python sense) these GPL files? Nothing in the https://opendev.org/zuul/zuul-jobs repository is GPL. I've never seen any credible argument that merely executing a GPL program makes the calling program a derivative work. Also, if the Zuul jobs in project repositories really were GPL, that should still be fine according to our governance:
I'm not suggesting anything. Dmitry gave a good example that parts of Ansible are actually BSD-licensed (even though it's only obvious after inspecting each file) so it has to be analysed file-per-file then. Also, a purist may say that Ansible still "curses" such usage by GPL because, when you import in Python, you are actually executing the __init__s in the context of your software and those are licensed under GPL, especially the root one.
Anyway, we have a separate mailing list for such topics:
http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
I have missed it. Should we post there? It looks pretty abandoned (perhaps for a good reason ;-) ).
Let's please not jump to conclusions when it comes to software licenses. It's not as cut and dried as you might expect.
I know, and thus expect, it to be a complex topic and that's the role of the word "possible" in the very subject. I am seeking advice. Also, for clarity, I am just propagating the original report with my extra findings. I was not aware that there could be any issue whatsoever with the licenses we have. -yoctozepto
On 2021-03-13 18:03:49 +0100 (+0100), Radosław Piliszek wrote: [...]
The main README suggests everything is GPL in there so I was confused. Perhaps this is what also confused the OP from Launchpad. [...]
I suspect (though do not know for sure) that this is why the Ansible maintainers have moved those files all into a separate directory tree. I would not be surprised if they have plans to move them into a separate repository in the future so as to provide even clearer separation. Some of the copyright license situation in there was murky a few years back, so I expect they're still working to improve things in that regard.
a purist may say that Ansible still "curses" such usage by GPL because, when you import in Python, you are actually executing the __init__s in the context of your software and those are licensed under GPL, especially the root one.
The way this is usually done is via a line like: from ansible.module_utils.basic import AnsibleModule I don't believe that actually loads the GPL-licensed ansible/__init__.py file, but I get a bit lost in the nuances of the several different kinds of Python package namespaces. However (and to reiterate, I'm no lawyer, this is not legal advice) what's generally important to look at in these sorts of situations is intent. Law is not like a computer program, and so strict literal interpretations are quite frequently off-base. It's fairly clear the Ansible authors intend for you to be able to import those scripts from ansible.module_utils in more permissively-licensed programs, so by doing that we're not acting counter to their wishes.
I have missed it. Should we post there? It looks pretty abandoned (perhaps for a good reason ;-) ). [...]
It's infrequently-used because such questions arise infrequently (thankfully). If anyone feels we need to start the process of soliciting an actual legal opinion on these matters though, we should re-raise the topic there initially. But before doing that, check the list archives to make sure we haven't already had this discussion in prior years, and also do a bit of research to see whether the Ansible project has already published documentation about the intended license situation for the files you're concerned about. -- Jeremy Stanley
participants (3)
-
Dmitry Tantsur
-
Jeremy Stanley
-
Radosław Piliszek