On Dec 9, 2019, at 10:54 AM, Sergey Sh <einarum@gmail.com> wrote:
Hi, all
I wonder if I can get help here or suggestions for licenses question. We move Ansible modules from upstream Ansible repository to Openstack namespace.
For slightly more context here - the Ansible upstream is decomposing itself similar to how Kubernetes did, so that communities can manage their own modules in their own repos rather than needing everything to go into the main Ansible repo. On the OpenStack side, we’ve decided to handle the Ansible modules that interact with OpenStack as part of the ansible-sig: https://review.opendev.org/#/c/684740/
In parallel, we need to develop new modules and modules that will replace those moved from Ansible. Moved original modules won't change. The problem is that Ansible and its modules have GPLv3 license and repositories of Openstack have Apache2. There are about 150+ people committed to Ansible modules for years, so it's hardly possible to get approval for relicensing from everyone. How can we handle this situation without violating licenses and agreements?
As I see it's 3 options
1. Move GPL modules to SIG repo in Openstack, freeze them there, and create a new Openstack repo with Apache2 license and develop the new modules in it. Won't it be a problem if new modules will have the same functionality as GPL ones?
I think this would be confusing for both users and developers, as the current modules are heavily used and I don’t think rewriting them is valuable to anyone.
2. Move GPL modules to SIG repo in Openstack, to develop new modules in GPL there. 3. Move GPL modules to SIG repo in Openstack, to develop new modules in Apache2 there.
I think because of partial incompatibility of Apache2 <-> GPLv3 licenses option 3 is barely viable [1] Option 2 is less preferred because it puts module aside from all Openstack projects that have Apache2 license.
I think we should just do 2. These repos are being handed to the ansible-sig precisely because of the GPL encumbrance. The original proposal was to add them as a deliverable to the openstacksdk project, since the existing modules were essentially written and maintained by the SDK team anyway - but that would make them a “deliverable” of the OpenStack project and therefore the GPL nature of them would become an issue. As deliverables of a SIG, it’s not part of “the software”, but is rather software thet we’re making explicitly to interact with another community, and as a part of that I believe it’s reasonable to simply maintain the GPL license on them since that’s what the existing codebase is, as well as what Ansible itself is. (it’s *highly* unlikely that anyone who cares about these modules is going to have an issue with the GPL, since they are only useful in the context of Ansible, which is GPL) I don’t think 3 is really an option because there is a decent amount of shared code in the modules, and even though some of it needs a refactor, I think it would be stretching definitions in an extreme manner to not consider even the new modules “derived works”. I also think it would be confusing for people to understand the licensing of the repo in question for not much gain.
What are the potential issues of option 1? I'd appreciate any ideas or opinions about the topic.
Thanks
[1] https://www.apache.org/licenses/GPL-compatibility.html Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.
-- Best regards Sagi Shnaidman _______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss