Michal,
IANAL but I can give you a little history on my interactions with the BOD and TC as Kolla PTL with regards to the licensing mess that Ansible’s GPLv3 introduces into OpenStack.
For plugins _TO ANSIBLE_ for Kolla, we can license the code as ASL2.0 (which should be done) if its new code (i.e. it is not a derived work). The TC ruled during the ocata goals
for 3.5 review that plugins to third party projects are not required to be implemented in python 3.5 nor are plugins for third party projects considered part of the “delivery” for OpenStack hence all rules are moot with regards to licensing concerns (As long
as the ASL2.0 license is followed). I can find a reference if you require one. I was very strong on pushing back on the ocata python 3.5 goals because of this very reason, which led to the TC ruling during voting). I *speculate* (definitely not
an attorneyJ the rationale for this is that pretty much everything implemented in Linux is tainted by a GPLv2 or GPLv3 license because of
a transitive dependency on kernel.org, glibc, kernel headers, gcc, libpython, and pretty much the whole operating system on which OpenStack runs.
If you license a plugin as ASL 2.0, and it is then imported into Ansible (which is GPL v3), the GPLv3 license taints the ASL license, however, that doesn’t matter for Kolla’s case since
we are not bound by transitive dependencies that have not been instantiated. We should probably document this somewhere so someone doesn’t run afoul of the FSF if creating derived works of Kolla with your proposed plugin (btw, whats the plugin?) when they
do instantiate the plugin and create a transitive ASL2.0 plugin that is tainted by a GPLv3 licensed work (Ansible).
If you want to use someone else’s implementation of a GPLv3 Ansible module and include it as part of the Kolla deliverable, that won’t fly as the GPLv3 taints the entire work and is not
permitted under the OSI approved licenses list by the OpenStack foundation (unless the GPLv3 includes an ASL2.0 exception, of which there are a few transitive dependencies that use this model). If you want to use someone else’s implementation, you will have
to implement your own that behaves in the same way. It is unclear if this implementation should be cleanroom, but if your struggling with that question, just ask Lei Zhang (jeffrey4l in irc) to implement the plugin as he hasn’t seen whatever GPLv3 plugin
you intend to include in the repository.
To further eliminate your concerns, our kolla-ansible tool uses a piped open call to treat Ansible as a network service. Treating GPLv3 code in this way does not create a transitive dependency
between the consumer of the network service and the consumer. Consider for example if google GPLv3’ed all their code – every time you accessed google’s web services, you would be in violation of the GPLv3 unless google shipped you their codebase as well as
a mechanism to rebuild it from scratch. Logic wins this one and fortunately the GPLv3 backed off on the transitive dependency network service model (or nobody in their right mind would license anything with GPLv3 – questionable why anyone would anyway, but
that ship has sailed).
This is why we can’t do an “import ansible” in our codebase, and instead if we want to track progress (via a GUI for example – is that the plugin your thinking of?) the tracking must be
done directly in Ansible as a separate network service (in this case popen is a network interface call which creates a networked runtime of Ansible – which keeps operators out of the requirement to ship their code to cloud consumers when using Kolla.
This is the standard legal recommendation coming out of every org I’m aware of including the FSF.
Hope that helps.
As you are now the Kolla PTL, you need to keep a keen watch for dependency management and ensure no transitive GPLv3 dependencies are instantiated during the runtime of our standard tools
which are not protected by the network service popen protection afforded by the GPLv3 license (i.e. things in the runtime that are outside of Ansible plugins).
Regards
-steve