[tc][kolla] Ansible module with GPLv3
Cross-post from [1] Hello everyone, I'm looking for legal advice about having GPLv3 file in Kolla repository. Our use case doesn't seem to be derivative, so I think that should be possible to pull off - having an single gpl v3 module within Kolla without affecting general Kolla license, but it's highly unorthodox so I would like to have second opinion on that front. Regards, Michal inc0 Jastrzebski [1] http://lists.openstack.org/pipermail/openstack-dev/2016-November/106761.html
On 04/11/16 13:37, Michał Jastrzębski wrote:
Cross-post from [1]
Hello everyone,
I'm looking for legal advice about having GPLv3 file in Kolla repository. Our use case doesn't seem to be derivative, so I think that should be possible to pull off - having an single gpl v3 module within Kolla without affecting general Kolla license, but it's highly unorthodox so I would like to have second opinion on that front.
Sorry, but this is a very clear-cut no. When you signed the CLA you agree to sign over various rights to all contributions you make; rights that you don't have the power to grant if it is, or is a derivative work of, code that was licensed to you as under the GPL. (The same applies to the DCO process, substituting the ASL2 for the CLA.) So nobody can contribute a GPL file under the CLA, and the Foundation is prevented from accepting contributions under any other terms by Article VII of its bylaws. The TC policy is here and echoes much the same thing: http://governance.openstack.org/reference/licensing.html "[Projects] must be licensed under a license supported by the Contributor License Agreement (CLA) which allows redistribution by the OpenStack Foundation under ASLv2 (currently only the MIT and both forms of the BSD license meet this requirement)." cheers, Zane.
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 attorney☺ 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 From: Michał Jastrzębski <inc007@gmail.com> Date: Friday, November 4, 2016 at 10:37 AM To: "legal-discuss@lists.openstack.org" <legal-discuss@lists.openstack.org> Subject: [legal-discuss] [tc][kolla] Ansible module with GPLv3 Cross-post from [1] Hello everyone, I'm looking for legal advice about having GPLv3 file in Kolla repository. Our use case doesn't seem to be derivative, so I think that should be possible to pull off - having an single gpl v3 module within Kolla without affecting general Kolla license, but it's highly unorthodox so I would like to have second opinion on that front. Regards, Michal inc0 Jastrzebski [1] http://lists.openstack.org/pipermail/openstack-dev/2016-November/106761.html _______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org<mailto:legal-discuss@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
On 04/11/16 18:15, Steven Dake (stdake) wrote:
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.
Getting off topic here, but for the record: * The kernel license explicitly disclaims that userspace programs are derivative works: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/COPYING... * glibc is LGPL, so unless you statically link to libc (which ~nobody does) then there isn't an issue: https://sourceware.org/git/?p=glibc.git;a=blob;f=COPYING.LIB * Python is not GPL at all: https://docs.python.org/3/license.html#psf-license-agreement-for-python-rele... cheers, Zane.
Comon Zane you know I make stuff up and I don’t know everything ☺ That’s why we have you for fact checking. ☺ Regards -steve From: Zane Bitter <zbitter@redhat.com> Organization: Red Hat Date: Monday, November 7, 2016 at 7:47 AM To: "legal-discuss@lists.openstack.org" <legal-discuss@lists.openstack.org> Subject: Re: [legal-discuss] [tc][kolla] Ansible module with GPLv3 On 04/11/16 18:15, Steven Dake (stdake) wrote: 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. Getting off topic here, but for the record: * The kernel license explicitly disclaims that userspace programs are derivative works: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/COPYING... * glibc is LGPL, so unless you statically link to libc (which ~nobody does) then there isn't an issue: https://sourceware.org/git/?p=glibc.git;a=blob;f=COPYING.LIB * Python is not GPL at all: https://docs.python.org/3/license.html#psf-license-agreement-for-python-rele... cheers, Zane. _______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org<mailto:legal-discuss@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
participants (3)
-
Michał Jastrzębski
-
Steven Dake (stdake)
-
Zane Bitter