Licensing options for new project (Kolla) entering big tent
Hi folks, Kolla is a project for OpenStack with the mission [1]: " Kolla provides production-ready containers and deployment tools for operating OpenStack clouds that are scalable, fast, reliable, and upgradable using community best practices. " We use a set of libraries only available in Ansible v2.0. Shade [2] ASL2.0 uses these Ansible python libraries [3] licensed under a GPLv3 license. We use Shade in Kolla directly. We had planned to fork these libraries in [3] and cherry-pick only the modules we really need until Ansible 2.0 is available. I asked the TC if this approach would be in violation of the governance repository here: https://github.com/openstack/governance/blob/master/reference/new-projects-r... To which Robert Collins suggested I speak with legal-discuss in this thread [4]. “ As I understand our current license situation, you won't be eligible for big-tent if you depend on GPLv3 code.
From the requirements " * Project must have no library dependencies which effectively restrict how the project may be distributed or deployed "
So I'm also strongly inclined to recommend you speak to the legal list about the implications here. Using a GPLv3 tool via the CLI is very different (by the GPL's design) to using it as a library. -Rob -- Robert Collins <rbtcollins@hp.com<mailto:rbtcollins@hp.com>> Distinguished Technologist HP Converged Cloud “ I’d really like a solution that doesn’t involve rewriting all of the Ansible modules from scratch in a different license, but I guess we can do that if necessary. Can the OpenStack legal team provide some guidance for future TC voting around the thread in [4]? Our deadline for this work is July 31, but we need several weeks to make adjustments to our plans, so if appropriate guidance for the Technical Committee (and our community project) could be offered soon, it would be much appreciated. Regards, -steve [1] https://wiki.openstack.org/wiki/Kolla [2] https://github.com/openstack-infra/shade [3] https://github.com/ansible/ansible-modules-core The thread: [4] http://lists.openstack.org/pipermail/openstack-dev/2015-July/068612.html
On 07/07/2015 07:20 PM, Steven Dake (stdake) wrote:
We use a set of libraries only available in Ansible v2.0. Shade [2] ASL2.0 uses these Ansible python libraries [3] licensed under a GPLv3 license. We use Shade in Kolla directly. We had planned to fork these libraries in [3] and cherry-pick only the modules we really need until Ansible 2.0 is available.
Based on the conversation on IRC, it's the other way around: Ansible core modules for OpenStack use Shade. It's the Ansible code, distributed under GPLv3 that consumes ASLv2 functions offered by Shade. Based on the recent message by Sam Yaple, the issue with Kolla may have been resolved technically and the discussion is more generally about the meaning of new-projects-requirements.
I asked the TC if this approach would be in violation of the governance repository here: https://github.com/openstack/governance/blob/master/reference/new-projects-r... [...] From the requirements " * Project must have no library dependencies which effectively restrict how the project may be distributed or deployed"
I don't think that this requirement line you quote is preventing GPLv3 code in OpenStack because the GNU GPLv3 (and its predecessor v2) doesn't restrict how the code is distributed or deployed. The license provisions kick in when code is modified *and* is distributed with such modifications. The bullet before the one you quoted says: * The proposed project uses an open source license (preferably the Apache v2.0 license, since it is necessary if the project wants to be used in an OpenStack trademark program) This to me means that code can be put under the /openstack/ namespace in any open source approved license. Using Apache SL v2 will make it possible to be legally distributed by the OpenStack Foundation as part of the OpenStack 'core' definition. If the intention of the TC requirements is to prevent strong copyleft licenses in openstack/ namespace maybe the bullets needs to be clarified. It's worth reminding that the GPLv3 allows for additional permissions to be granted downstream (see this historic article http://gplv3.fsf.org/additional-terms-dd2.html for more details, and from the GPLv3 FAQ, like https://www.gnu.org/licenses/gpl-faq.html#GPLModuleLicense), so one could ask to render the GPLv3 code into a Lesser GPLv3 for inclusion in OpenStack. HTH stef PS: IANAL, TINLA
On Wed, Jul 08, 2015 at 12:14:31PM -0700, Stefano Maffulli wrote:
I asked the TC if this approach would be in violation of the governance repository here: https://github.com/openstack/governance/blob/master/reference/new-projects-r... [...] From the requirements " * Project must have no library dependencies which effectively restrict how the project may be distributed or deployed"
I don't think that this requirement line you quote is preventing GPLv3 code in OpenStack because the GNU GPLv3 (and its predecessor v2) doesn't restrict how the code is distributed or deployed. The license provisions kick in when code is modified *and* is distributed with such modifications.
The bullet before the one you quoted says:
* The proposed project uses an open source license (preferably the Apache v2.0 license, since it is necessary if the project wants to be used in an OpenStack trademark program)
This to me means that code can be put under the /openstack/ namespace in any open source approved license. Using Apache SL v2 will make it possible to be legally distributed by the OpenStack Foundation as part of the OpenStack 'core' definition.
If the intention of the TC requirements is to prevent strong copyleft licenses in openstack/ namespace maybe the bullets needs to be clarified.
I agree. If "effectively restrict[s] how the project may be distributed or deployed" was meant to allude to things like GPLv3 that is not obvious. Richard
Just to be clear, the GPLv3 does not require modification for its terms to apply. The terms of the GPLv3 apply upon distribution of the code. The GPLv3 licensed code could not be part of the Technical Committee Approved Release because Section 7.2 of the Restated Bylaws provides that: "The Foundation shall distribute the software in the Technical Committee Approved Release under the Apache License 2.0 unless changed as provided in Section 9.1" so the requirement of the use of the Apache 2.0 license is not limited to code which is eligible for trademark use. Such code, Trademark Designated OpenStack Software, is designated by the Board and is a subset of the Technical Committee Approved Release. I remember a Board discussion about the use of copyleft licenses in dependencies and I think that the Board was generally against it, but I don't think that a decision was reached. I think that a discussion on this issue would be useful and I will discuss with Jonathan. -----Original Message----- From: Richard Fontana [mailto:rfontana@redhat.com] Sent: Wednesday, July 08, 2015 12:38 PM To: Stefano Maffulli Cc: legal-discuss@lists.openstack.org Subject: Re: [legal-discuss] Licensing options for new project (Kolla) entering big tent On Wed, Jul 08, 2015 at 12:14:31PM -0700, Stefano Maffulli wrote:
I asked the TC if this approach would be in violation of the governance repository here: https://github.com/openstack/governance/blob/master/reference/new-pr ojects-requirements.rst [...] From the requirements " * Project must have no library dependencies which effectively restrict how the project may be distributed or deployed"
I don't think that this requirement line you quote is preventing GPLv3 code in OpenStack because the GNU GPLv3 (and its predecessor v2) doesn't restrict how the code is distributed or deployed. The license provisions kick in when code is modified *and* is distributed with such modifications.
The bullet before the one you quoted says:
* The proposed project uses an open source license (preferably the Apache v2.0 license, since it is necessary if the project wants to be used in an OpenStack trademark program)
This to me means that code can be put under the /openstack/ namespace in any open source approved license. Using Apache SL v2 will make it possible to be legally distributed by the OpenStack Foundation as part of the OpenStack 'core' definition.
If the intention of the TC requirements is to prevent strong copyleft licenses in openstack/ namespace maybe the bullets needs to be clarified.
I agree. If "effectively restrict[s] how the project may be distributed or deployed" was meant to allude to things like GPLv3 that is not obvious. Richard _______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss Please consider the environment before printing this email. The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@dlapiper.com. Thank you.
Mark, Thanks that clears it up. I parse that statement a bit differently you have. Its the ³so+² or intent of the clause where I get hung up. The so could be achieved I suspect without the direct requirement of ASL2.0. Technically the technical committee doesn¹t have a TC release anymore either, as far as I understand. But IANAL :) In the Kolla case if we had intended to use #3, we would not be able to apply for big tent by your analysis successfully because we would run into the clause outlined in my original email. Since we are not using method #3, but have rolled our own implementation which is ASL, we are good to go on that clause of the new project rules. Regards -steve On 7/9/15, 9:37 AM, "Radcliffe, Mark" <Mark.Radcliffe@dlapiper.com> wrote:
Just to be clear, the GPLv3 does not require modification for its terms to apply. The terms of the GPLv3 apply upon distribution of the code. The GPLv3 licensed code could not be part of the Technical Committee Approved Release because Section 7.2 of the Restated Bylaws provides that: "The Foundation shall distribute the software in the Technical Committee Approved Release under the Apache License 2.0 unless changed as provided in Section 9.1" so the requirement of the use of the Apache 2.0 license is not limited to code which is eligible for trademark use. Such code, Trademark Designated OpenStack Software, is designated by the Board and is a subset of the Technical Committee Approved Release.
I remember a Board discussion about the use of copyleft licenses in dependencies and I think that the Board was generally against it, but I don't think that a decision was reached. I think that a discussion on this issue would be useful and I will discuss with Jonathan.
-----Original Message----- From: Richard Fontana [mailto:rfontana@redhat.com] Sent: Wednesday, July 08, 2015 12:38 PM To: Stefano Maffulli Cc: legal-discuss@lists.openstack.org Subject: Re: [legal-discuss] Licensing options for new project (Kolla) entering big tent
On Wed, Jul 08, 2015 at 12:14:31PM -0700, Stefano Maffulli wrote:
I asked the TC if this approach would be in violation of the governance repository here: https://github.com/openstack/governance/blob/master/reference/new-pr ojects-requirements.rst [...] From the requirements " * Project must have no library dependencies which effectively restrict how the project may be distributed or deployed"
I don't think that this requirement line you quote is preventing GPLv3 code in OpenStack because the GNU GPLv3 (and its predecessor v2) doesn't restrict how the code is distributed or deployed. The license provisions kick in when code is modified *and* is distributed with such modifications.
The bullet before the one you quoted says:
* The proposed project uses an open source license (preferably the Apache v2.0 license, since it is necessary if the project wants to be used in an OpenStack trademark program)
This to me means that code can be put under the /openstack/ namespace in any open source approved license. Using Apache SL v2 will make it possible to be legally distributed by the OpenStack Foundation as part of the OpenStack 'core' definition.
If the intention of the TC requirements is to prevent strong copyleft licenses in openstack/ namespace maybe the bullets needs to be clarified.
I agree. If "effectively restrict[s] how the project may be distributed or deployed" was meant to allude to things like GPLv3 that is not obvious.
Richard
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss Please consider the environment before printing this email.
The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@dlapiper.com. Thank you.
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
On Thu, Jul 09, 2015 at 07:24:36PM +0000, Steven Dake (stdake) wrote:
Technically the technical committee doesn¹t have a TC release anymore either, as far as I understand. But IANAL :)
I've been wondering about that. What if anything does "Technical Committee Approved Release" mean now? RF
Excerpts from Richard Fontana's message of 2015-07-09 15:43:55 -0400:
On Thu, Jul 09, 2015 at 07:24:36PM +0000, Steven Dake (stdake) wrote:
Technically the technical committee doesn¹t have a TC release anymore either, as far as I understand. But IANAL :)
I've been wondering about that. What if anything does "Technical Committee Approved Release" mean now?
The term is defined in the bylaws as the subset of all OpenStack projects the TC has proposed be included in DefCore's trademark considerations. We have a tag indicating the current list of projects: http://governance.openstack.org/reference/tags/tc-approved-release.html Doug
I am not sure I understand Steven's statement about "so". The intention of the bylaws is clear, the Technical Committee Approved Release (which is defined in Section 4.1(b)) needs to be licensed under ASL2.0. The definitions are below: The “OpenStack Project” shall consist of the released projects to enable cloud computing and the associated library projects, gating projects, and supporting projects managed by the Technical Committee. The Technical Committee shall designate a subset of the OpenStack Project an “OpenStack Technical Committee Approved Release” from time to time. The Board of Directors may determine "Trademark Designated OpenStack Software" from time to time, which will be a subset of the "OpenStack Technical Committee Approved Release" as provided in Section 4.1(b)(ii) and (iii). -----Original Message----- From: Doug Hellmann [mailto:doug@doughellmann.com] Sent: Thursday, July 09, 2015 12:50 PM To: legal-discuss Subject: Re: [legal-discuss] Licensing options for new project (Kolla) entering big tent Excerpts from Richard Fontana's message of 2015-07-09 15:43:55 -0400:
On Thu, Jul 09, 2015 at 07:24:36PM +0000, Steven Dake (stdake) wrote:
Technically the technical committee doesn¹t have a TC release anymore either, as far as I understand. But IANAL :)
I've been wondering about that. What if anything does "Technical Committee Approved Release" mean now?
The term is defined in the bylaws as the subset of all OpenStack projects the TC has proposed be included in DefCore's trademark considerations. We have a tag indicating the current list of projects: http://governance.openstack.org/reference/tags/tc-approved-release.html Doug _______________________________________________ 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 Please consider the environment before printing this email. The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@dlapiper.com. Thank you.
I am not sure I understand your statement. The intention of the bylaws is clear, the Technical Committee Approved Release needs to be licensed under ASL2.0. I am enclosing the latest version of the bylaws. Section 4.1(b) has the definition of Technical Committee Approved Release. -----Original Message----- From: Steven Dake (stdake) [mailto:stdake@cisco.com] Sent: Thursday, July 09, 2015 12:25 PM To: Radcliffe, Mark; Richard Fontana; Stefano Maffulli Cc: legal-discuss@lists.openstack.org; sam@yaple.net Subject: Re: [legal-discuss] Licensing options for new project (Kolla) entering big tent Mark, Thanks that clears it up. I parse that statement a bit differently you have. Its the ³so+² or intent of the clause where I get hung up. The so could be achieved I suspect without the direct requirement of ASL2.0. Technically the technical committee doesn¹t have a TC release anymore either, as far as I understand. But IANAL :) In the Kolla case if we had intended to use #3, we would not be able to apply for big tent by your analysis successfully because we would run into the clause outlined in my original email. Since we are not using method #3, but have rolled our own implementation which is ASL, we are good to go on that clause of the new project rules. Regards -steve On 7/9/15, 9:37 AM, "Radcliffe, Mark" <Mark.Radcliffe@dlapiper.com> wrote:
Just to be clear, the GPLv3 does not require modification for its terms to apply. The terms of the GPLv3 apply upon distribution of the code. The GPLv3 licensed code could not be part of the Technical Committee Approved Release because Section 7.2 of the Restated Bylaws provides that: "The Foundation shall distribute the software in the Technical Committee Approved Release under the Apache License 2.0 unless changed as provided in Section 9.1" so the requirement of the use of the Apache 2.0 license is not limited to code which is eligible for trademark use. Such code, Trademark Designated OpenStack Software, is designated by the Board and is a subset of the Technical Committee Approved Release.
I remember a Board discussion about the use of copyleft licenses in dependencies and I think that the Board was generally against it, but I don't think that a decision was reached. I think that a discussion on this issue would be useful and I will discuss with Jonathan.
-----Original Message----- From: Richard Fontana [mailto:rfontana@redhat.com] Sent: Wednesday, July 08, 2015 12:38 PM To: Stefano Maffulli Cc: legal-discuss@lists.openstack.org Subject: Re: [legal-discuss] Licensing options for new project (Kolla) entering big tent
On Wed, Jul 08, 2015 at 12:14:31PM -0700, Stefano Maffulli wrote:
I asked the TC if this approach would be in violation of the governance repository here: https://github.com/openstack/governance/blob/master/reference/new-p r ojects-requirements.rst [...] From the requirements " * Project must have no library dependencies which effectively restrict how the project may be distributed or deployed"
I don't think that this requirement line you quote is preventing GPLv3 code in OpenStack because the GNU GPLv3 (and its predecessor v2) doesn't restrict how the code is distributed or deployed. The license provisions kick in when code is modified *and* is distributed with such modifications.
The bullet before the one you quoted says:
* The proposed project uses an open source license (preferably the Apache v2.0 license, since it is necessary if the project wants to be used in an OpenStack trademark program)
This to me means that code can be put under the /openstack/ namespace in any open source approved license. Using Apache SL v2 will make it possible to be legally distributed by the OpenStack Foundation as part of the OpenStack 'core' definition.
If the intention of the TC requirements is to prevent strong copyleft licenses in openstack/ namespace maybe the bullets needs to be clarified.
I agree. If "effectively restrict[s] how the project may be distributed or deployed" was meant to allude to things like GPLv3 that is not obvious.
Richard
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss Please consider the environment before printing this email.
The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@dlapiper.com. Thank you.
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
Please consider the environment before printing this email. The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@dlapiper.com. Thank you.
On 09/07/15 15:24, Steven Dake (stdake) wrote:
Mark,
Thanks that clears it up. I parse that statement a bit differently you have. Its the ³so+² or intent of the clause where I get hung up. The so could be achieved I suspect without the direct requirement of ASL2.0. Technically the technical committee doesn¹t have a TC release anymore either, as far as I understand. But IANAL :)
That's incorrect, the by-laws require a TC Approved Release and the TC has defined one. Previously the equivalent was the integrated release; since the by-laws change the TC has adopted a separate tag to clearly define what the TC Approved Release is (currently it's the same subset of projects that were previously in the integrated release).
In the Kolla case if we had intended to use #3, we would not be able to apply for big tent by your analysis successfully because we would run into the clause outlined in my original email.
I don't believe that follows. The by-laws require only that anything in the TC Approved Release be distributed under the ASL. That said, it is completely up to the TC which projects to accept into OpenStack, and it would be well within its rights to reject one that e.g. could never be added to the Approved Release because of an incompatible license.
Since we are not using method #3, but have rolled our own implementation which is ASL, we are good to go on that clause of the new project rules.
Indeed. cheers, Zane.
Regards -steve
On 7/9/15, 9:37 AM, "Radcliffe, Mark" <Mark.Radcliffe@dlapiper.com> wrote:
Just to be clear, the GPLv3 does not require modification for its terms to apply. The terms of the GPLv3 apply upon distribution of the code. The GPLv3 licensed code could not be part of the Technical Committee Approved Release because Section 7.2 of the Restated Bylaws provides that: "The Foundation shall distribute the software in the Technical Committee Approved Release under the Apache License 2.0 unless changed as provided in Section 9.1" so the requirement of the use of the Apache 2.0 license is not limited to code which is eligible for trademark use. Such code, Trademark Designated OpenStack Software, is designated by the Board and is a subset of the Technical Committee Approved Release.
I remember a Board discussion about the use of copyleft licenses in dependencies and I think that the Board was generally against it, but I don't think that a decision was reached. I think that a discussion on this issue would be useful and I will discuss with Jonathan.
-----Original Message----- From: Richard Fontana [mailto:rfontana@redhat.com] Sent: Wednesday, July 08, 2015 12:38 PM To: Stefano Maffulli Cc: legal-discuss@lists.openstack.org Subject: Re: [legal-discuss] Licensing options for new project (Kolla) entering big tent
On Wed, Jul 08, 2015 at 12:14:31PM -0700, Stefano Maffulli wrote:
I asked the TC if this approach would be in violation of the governance repository here: https://github.com/openstack/governance/blob/master/reference/new-pr ojects-requirements.rst [...] From the requirements " * Project must have no library dependencies which effectively restrict how the project may be distributed or deployed"
I don't think that this requirement line you quote is preventing GPLv3 code in OpenStack because the GNU GPLv3 (and its predecessor v2) doesn't restrict how the code is distributed or deployed. The license provisions kick in when code is modified *and* is distributed with such modifications.
The bullet before the one you quoted says:
* The proposed project uses an open source license (preferably the Apache v2.0 license, since it is necessary if the project wants to be used in an OpenStack trademark program)
This to me means that code can be put under the /openstack/ namespace in any open source approved license. Using Apache SL v2 will make it possible to be legally distributed by the OpenStack Foundation as part of the OpenStack 'core' definition.
If the intention of the TC requirements is to prevent strong copyleft licenses in openstack/ namespace maybe the bullets needs to be clarified.
I agree. If "effectively restrict[s] how the project may be distributed or deployed" was meant to allude to things like GPLv3 that is not obvious.
Richard
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss Please consider the environment before printing this email.
The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@dlapiper.com. Thank you.
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
Zane, Comments inline. On 7/9/15, 1:08 PM, "Zane Bitter" <zbitter@redhat.com> wrote:
On 09/07/15 15:24, Steven Dake (stdake) wrote:
Mark,
Thanks that clears it up. I parse that statement a bit differently you have. Its the ³so+² or intent of the clause where I get hung up. The so could be achieved I suspect without the direct requirement of ASL2.0. Technically the technical committee doesn¹t have a TC release anymore either, as far as I understand. But IANAL :)
That's incorrect, the by-laws require a TC Approved Release and the TC has defined one. Previously the equivalent was the integrated release; since the by-laws change the TC has adopted a separate tag to clearly define what the TC Approved Release is (currently it's the same subset of projects that were previously in the integrated release).
Thanks that makes sense - stand corrected :) Thanks for the information - this is all very helpful to me personally although I am sure people are sick of repeating themselves on these points.
In the Kolla case if we had intended to use #3, we would not be able to apply for big tent by your analysis successfully because we would run into the clause outlined in my original email.
I don't believe that follows. The by-laws require only that anything in the TC Approved Release be distributed under the ASL. That said, it is completely up to the TC which projects to accept into OpenStack, and it would be well within its rights to reject one that e.g. could never be added to the Approved Release because of an incompatible license.
Agree
Since we are not using method #3, but have rolled our own implementation which is ASL, we are good to go on that clause of the new project rules.
Indeed.
cheers, Zane.
Regards -steve
On 7/9/15, 9:37 AM, "Radcliffe, Mark" <Mark.Radcliffe@dlapiper.com> wrote:
Just to be clear, the GPLv3 does not require modification for its terms to apply. The terms of the GPLv3 apply upon distribution of the code. The GPLv3 licensed code could not be part of the Technical Committee Approved Release because Section 7.2 of the Restated Bylaws provides that: "The Foundation shall distribute the software in the Technical Committee Approved Release under the Apache License 2.0 unless changed as provided in Section 9.1" so the requirement of the use of the Apache 2.0 license is not limited to code which is eligible for trademark use. Such code, Trademark Designated OpenStack Software, is designated by the Board and is a subset of the Technical Committee Approved Release.
I remember a Board discussion about the use of copyleft licenses in dependencies and I think that the Board was generally against it, but I don't think that a decision was reached. I think that a discussion on this issue would be useful and I will discuss with Jonathan.
-----Original Message----- From: Richard Fontana [mailto:rfontana@redhat.com] Sent: Wednesday, July 08, 2015 12:38 PM To: Stefano Maffulli Cc: legal-discuss@lists.openstack.org Subject: Re: [legal-discuss] Licensing options for new project (Kolla) entering big tent
On Wed, Jul 08, 2015 at 12:14:31PM -0700, Stefano Maffulli wrote:
I asked the TC if this approach would be in violation of the governance repository here: https://github.com/openstack/governance/blob/master/reference/new-pr ojects-requirements.rst [...] From the requirements " * Project must have no library dependencies which effectively restrict how the project may be distributed or deployed"
I don't think that this requirement line you quote is preventing GPLv3 code in OpenStack because the GNU GPLv3 (and its predecessor v2) doesn't restrict how the code is distributed or deployed. The license provisions kick in when code is modified *and* is distributed with such modifications.
The bullet before the one you quoted says:
* The proposed project uses an open source license (preferably the Apache v2.0 license, since it is necessary if the project wants to be used in an OpenStack trademark program)
This to me means that code can be put under the /openstack/ namespace in any open source approved license. Using Apache SL v2 will make it possible to be legally distributed by the OpenStack Foundation as part of the OpenStack 'core' definition.
If the intention of the TC requirements is to prevent strong copyleft licenses in openstack/ namespace maybe the bullets needs to be clarified.
I agree. If "effectively restrict[s] how the project may be distributed or deployed" was meant to allude to things like GPLv3 that is not obvious.
Richard
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss Please consider the environment before printing this email.
The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@dlapiper.com. Thank you.
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
On Thu, Jul 09, 2015 at 04:08:16PM -0400, Zane Bitter wrote:
The by-laws require only that anything in the TC Approved Release be distributed under the ASL. That said, it is completely up to the TC which projects to accept into OpenStack, and it would be well within its rights to reject one that e.g. could never be added to the Approved Release because of an incompatible license.
That might help explain the requirement at https://github.com/openstack/governance/blob/master/reference/new-projects-r... "Project must have no library dependencies which effectively restrict how the project may be distributed or deployed" but it should then be taken to mean "Project must have no library dependencies which effectively prevent the project from being distributed under the Apache License 2.0" (I'll assume that makes sense in a given context). That being so, I am not sure I understand this one "The proposed project uses an open source license (preferably the Apache v2.0 license, since it is necessary if the project wants to be used in an OpenStack trademark program)" Because, given that the OpenStack Foundation uses CLAs that give it the power to license out everything under the Apache License, why does it matter whether the proposed project is initially under an open source license that is not the Apache License? For example, suppose a new official OpenStack project is under the GPL. What's the obstacle to it later being included in the TC Approved Release? All that's necessary is for the Foundation to relicense it under the Apache License. Or is the concern that a (say) GPL-licensed project might have had a pre-OpenStack history including contributions from individuals or entities that are not CLA signatories? Essentially I am asking - how could it be that a project could never be added to the Approved Release because of an incompatible license? Richard
Excerpts from Richard Fontana's message of 2015-07-09 16:34:47 -0400:
On Thu, Jul 09, 2015 at 04:08:16PM -0400, Zane Bitter wrote:
The by-laws require only that anything in the TC Approved Release be distributed under the ASL. That said, it is completely up to the TC which projects to accept into OpenStack, and it would be well within its rights to reject one that e.g. could never be added to the Approved Release because of an incompatible license.
That might help explain the requirement at https://github.com/openstack/governance/blob/master/reference/new-projects-r...
"Project must have no library dependencies which effectively restrict how the project may be distributed or deployed"
but it should then be taken to mean "Project must have no library dependencies which effectively prevent the project from being distributed under the Apache License 2.0" (I'll assume that makes sense in a given context).
That being so, I am not sure I understand this one
"The proposed project uses an open source license (preferably the Apache v2.0 license, since it is necessary if the project wants to be used in an OpenStack trademark program)"
Because, given that the OpenStack Foundation uses CLAs that give it the power to license out everything under the Apache License, why does it matter whether the proposed project is initially under an open source license that is not the Apache License?
For example, suppose a new official OpenStack project is under the GPL. What's the obstacle to it later being included in the TC Approved Release? All that's necessary is for the Foundation to relicense it under the Apache License. Or is the concern that a (say) GPL-licensed project might have had a pre-OpenStack history including contributions from individuals or entities that are not CLA signatories?
Essentially I am asking - how could it be that a project could never be added to the Approved Release because of an incompatible license?
Richard
This may be one of those belt-and-suspenders situations where we didn't want to have to explain to someone that, yes, we could in fact relicense code they thought they put under the GPL because of the CLA. Or maybe we didn't realize we had that power in the first place. Doug
On 2015-07-09 16:34:47 -0400 (-0400), Richard Fontana wrote: [...]
Or is the concern that a (say) GPL-licensed project might have had a pre-OpenStack history including contributions from individuals or entities that are not CLA signatories? [...]
Perhaps a slight variation on this. One work can be a derivative of another copyleft-licensed work and (at least if the copylefted work's authors can't be found or don't all agree to dual-licensing/explicit exceptions) may be bound to the same license or some license whose terms are a superset of the inherited license. We don't want to discourage people within our community from properly leveraging and extending existing free software whose provenance was not within our community. We create enough NIH/reinvented-wheel problems throughout the greater free software landscape as it is, and telling a team that they need to rewrite some base framework from scratch (because their work might be considered a derivative and therefore not Apache licensed) is just that. [DISCLAIMER: I am most definitely not a lawyer!] -- Jeremy Stanley
If we can get all of the code under a CLA we are fine but existing projects (which are not under ASLv2) would need to be carefully vetted. -----Original Message----- From: Jeremy Stanley [mailto:fungi@yuggoth.org] Sent: Thursday, July 09, 2015 2:08 PM To: legal-discuss@lists.openstack.org Subject: Re: [legal-discuss] Licensing options for new project (Kolla) entering big tent On 2015-07-09 16:34:47 -0400 (-0400), Richard Fontana wrote: [...]
Or is the concern that a (say) GPL-licensed project might have had a pre-OpenStack history including contributions from individuals or entities that are not CLA signatories? [...]
Perhaps a slight variation on this. One work can be a derivative of another copyleft-licensed work and (at least if the copylefted work's authors can't be found or don't all agree to dual-licensing/explicit exceptions) may be bound to the same license or some license whose terms are a superset of the inherited license. We don't want to discourage people within our community from properly leveraging and extending existing free software whose provenance was not within our community. We create enough NIH/reinvented-wheel problems throughout the greater free software landscape as it is, and telling a team that they need to rewrite some base framework from scratch (because their work might be considered a derivative and therefore not Apache licensed) is just that. [DISCLAIMER: I am most definitely not a lawyer!] -- Jeremy Stanley _______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss Please consider the environment before printing this email. The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@dlapiper.com. Thank you.
On 09/07/15 16:34, Richard Fontana wrote:
On Thu, Jul 09, 2015 at 04:08:16PM -0400, Zane Bitter wrote:
The by-laws require only that anything in the TC Approved Release be distributed under the ASL. That said, it is completely up to the TC which projects to accept into OpenStack, and it would be well within its rights to reject one that e.g. could never be added to the Approved Release because of an incompatible license.
That might help explain the requirement at https://github.com/openstack/governance/blob/master/reference/new-projects-r...
"Project must have no library dependencies which effectively restrict how the project may be distributed or deployed"
but it should then be taken to mean "Project must have no library dependencies which effectively prevent the project from being distributed under the Apache License 2.0" (I'll assume that makes sense in a given context).
It also says 'or deployed', so e.g. an ASL licensed project with a dependency on a proprietary library would also be excluded. I read it as being an anti-"Open Core" provision. It's also worth noting that the TC's 'requirements' (a) are really just guidelines, and (b) were most certainly not written, or even read, by lawyers :)
That being so, I am not sure I understand this one
"The proposed project uses an open source license (preferably the Apache v2.0 license, since it is necessary if the project wants to be used in an OpenStack trademark program)"
Because, given that the OpenStack Foundation uses CLAs that give it the power to license out everything under the Apache License, why does it matter whether the proposed project is initially under an open source license that is not the Apache License?
For example, suppose a new official OpenStack project is under the GPL. What's the obstacle to it later being included in the TC Approved Release? All that's necessary is for the Foundation to relicense it under the Apache License. Or is the concern that a (say) GPL-licensed project might have had a pre-OpenStack history including contributions from individuals or entities that are not CLA signatories?
If an OpenStack contributor (i.e. someone who had signed the ICLA) had also contributed to another, say GPL-licensed, project and that project was later adopted by OpenStack, would it follow that that person had consented to relicensing their GPL code to the Foundation by virtue of having already signed the ICLA? I don't think it would and, as you say, that's even assuming that all past contributors have signed the ICLA.
Essentially I am asking - how could it be that a project could never be added to the Approved Release because of an incompatible license?
I don't think we're relying on the ICLAs when we adopt pre-existing code as much as we're relying on the license being ASL. Are you perhaps suggesting that the CLA doesn't confer as much benefit as may be assumed because large initial chunks of the code in some projects were not licensed to the Foundation under the CLA but rather under the ASL? cheers, Zane.
On Thu, Jul 09, 2015 at 07:11:39PM -0400, Zane Bitter wrote:
Are you perhaps suggesting that the CLA doesn't confer as much benefit as may be assumed because large initial chunks of the code in some projects were not licensed to the Foundation under the CLA but rather under the ASL?
Well, I don't think I was consciously suggesting that but that's in line with things I've said in the past. :) RF
participants (7)
-
Doug Hellmann
-
Jeremy Stanley
-
Radcliffe, Mark
-
Richard Fontana
-
Stefano Maffulli
-
Steven Dake (stdake)
-
Zane Bitter