Hello, Following a suggestion from Jeremy Stanley (below), I'm contacting this list. If I understand Jeremy correctly, checking code in to StackForge does not transfer any IP, or grant any rights, other than those granted in the license declaration that we make in our code (in this case, the Apache 2.0 license). Is that correct? Many thanks, Joe Marshall. -----Original Message----- From: Emma Gordon Sent: 06 May 2015 13:06 To: Joe Marshall Subject: FW: [openstack-dev] [Fuel][Plugin] Contributor license agreement for fuel plugin code? -----Original Message----- From: Jeremy Stanley [mailto:fungi@yuggoth.org] Sent: 06 May 2015 12:58 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Fuel][Plugin] Contributor license agreement for fuel plugin code? On 2015-05-06 11:02:42 +0000 (+0000), Emma Gordon (projectcalico.org) wrote:
If fuel plugin code is checked into a stackforge repository (as
suggested in the fuel plugin wiki
https://wiki.openstack.org/wiki/Fuel/Plugins#Repo), who owns that
code?
I am not a lawyer, but my understanding is that the individual copyright holders mentioned in comments at the tops of various files, listed in an AUTHORS file (if included) and indicated within the repository's Git commit history retain rights over their contributions in a project relying on the Apache License (or those rights may belong to their individual respective employers in a work-for-hire situation as well).
Is there a contributor license agreement to sign? (For example,
contributors to OpenStack would sign this
If Fuel is planning to apply for inclusion in OpenStack, then it may make sense to get all current and former contributors to its source repositories to agree to the OpenStack Individual Contributor License Agreement. Note that it does _not_ change the ownership of the software (copyrights), it's intended to simply reinforce the OpenStack Foundation's ability to continue to redistribute the software under the Apache License by affirming that the terms of the license are applied correctly and intentionally. More detailed questions are probably best posed to the legal-discuss@lists.openstack.org<mailto:legal-discuss@lists.openstack.org> mailing list, or to your own private legal representation. -- Jeremy Stanley
On 05/06/2015 07:52 AM, Joe Marshall (projectcalico.org) wrote:
Hello,
Following a suggestion from Jeremy Stanley (below), I'm contacting this list. If I understand Jeremy correctly, checking code in to StackForge does not transfer any IP, or grant any rights, other than those granted in the license declaration that we make in our code (in this case, the Apache 2.0 license). Is that correct?
I am also not a lawyer, but I agree with Jeremy's assessment. There is nothing about checking code in to stackforge that transfers ownership.
Many thanks,
Joe Marshall.
-----Original Message-----
From: Emma Gordon
Sent: 06 May 2015 13:06
To: Joe Marshall
Subject: FW: [openstack-dev] [Fuel][Plugin] Contributor license agreement for fuel plugin code?
-----Original Message-----
From: Jeremy Stanley [mailto:fungi@yuggoth.org]
Sent: 06 May 2015 12:58
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Fuel][Plugin] Contributor license agreement for fuel plugin code?
On 2015-05-06 11:02:42 +0000 (+0000), Emma Gordon (projectcalico.org) wrote:
If fuel plugin code is checked into a stackforge repository (as
suggested in the fuel plugin wiki
https://wiki.openstack.org/wiki/Fuel/Plugins#Repo), who owns that
code?
I am not a lawyer, but my understanding is that the individual copyright holders mentioned in comments at the tops of various files, listed in an AUTHORS file (if included) and indicated within the repository's Git commit history retain rights over their contributions in a project relying on the Apache License (or those rights may belong to their individual respective employers in a work-for-hire situation as well).
Is there a contributor license agreement to sign? (For example,
contributors to OpenStack would sign this
If Fuel is planning to apply for inclusion in OpenStack, then it may make sense to get all current and former contributors to its source repositories to agree to the OpenStack Individual Contributor License Agreement. Note that it does _not_ change the ownership of the software (copyrights), it's intended to simply reinforce the OpenStack Foundation's ability to continue to redistribute the software under the Apache License by affirming that the terms of the license are applied correctly and intentionally.
More detailed questions are probably best posed to the legal-discuss@lists.openstack.org<mailto:legal-discuss@lists.openstack.org> mailing list, or to your own private legal representation.
--
Jeremy Stanley
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
Jeremy is correct in saying that the OpenStack CLAs do not transfer ownership, nor would merely checking code in stackforge transfer ownership (regardless of whether OpenStack CLAs would be operative in that situation). However it is not the case that the OpenStack CLAs "simply reinforce the OpenStack Foundation's ability to continue to redistribute the software under the Apache License by affirming that the terms of the license are applied correctly and intentionally". That is what the DCO, or a hypothetical differently-drafted CLA, would do; the OpenStack CLAs are broader license grants to the OpenStack Foundation. On Wed, May 06, 2015 at 08:14:17AM -0600, Monty Taylor wrote:
On 05/06/2015 07:52 AM, Joe Marshall (projectcalico.org) wrote:
Hello,
Following a suggestion from Jeremy Stanley (below), I'm contacting this list. If I understand Jeremy correctly, checking code in to StackForge does not transfer any IP, or grant any rights, other than those granted in the license declaration that we make in our code (in this case, the Apache 2.0 license). Is that correct?
I am also not a lawyer, but I agree with Jeremy's assessment. There is nothing about checking code in to stackforge that transfers ownership.
Many thanks,
Joe Marshall.
-----Original Message-----
From: Emma Gordon
Sent: 06 May 2015 13:06
To: Joe Marshall
Subject: FW: [openstack-dev] [Fuel][Plugin] Contributor license agreement for fuel plugin code?
-----Original Message-----
From: Jeremy Stanley [mailto:fungi@yuggoth.org]
Sent: 06 May 2015 12:58
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Fuel][Plugin] Contributor license agreement for fuel plugin code?
On 2015-05-06 11:02:42 +0000 (+0000), Emma Gordon (projectcalico.org) wrote:
If fuel plugin code is checked into a stackforge repository (as
suggested in the fuel plugin wiki
https://wiki.openstack.org/wiki/Fuel/Plugins#Repo), who owns that
code?
I am not a lawyer, but my understanding is that the individual copyright holders mentioned in comments at the tops of various files, listed in an AUTHORS file (if included) and indicated within the repository's Git commit history retain rights over their contributions in a project relying on the Apache License (or those rights may belong to their individual respective employers in a work-for-hire situation as well).
Is there a contributor license agreement to sign? (For example,
contributors to OpenStack would sign this
If Fuel is planning to apply for inclusion in OpenStack, then it may make sense to get all current and former contributors to its source repositories to agree to the OpenStack Individual Contributor License Agreement. Note that it does _not_ change the ownership of the software (copyrights), it's intended to simply reinforce the OpenStack Foundation's ability to continue to redistribute the software under the Apache License by affirming that the terms of the license are applied correctly and intentionally.
More detailed questions are probably best posed to the legal-discuss@lists.openstack.org<mailto:legal-discuss@lists.openstack.org> mailing list, or to your own private legal representation.
--
Jeremy Stanley
_______________________________________________ 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 2015-05-06 10:39:45 -0400 (-0400), Richard Fontana wrote: [...]
However it is not the case that the OpenStack CLAs "simply reinforce the OpenStack Foundation's ability to continue to redistribute the software under the Apache License by affirming that the terms of the license are applied correctly and intentionally". That is what the DCO, or a hypothetical differently-drafted CLA, would do; the OpenStack CLAs are broader license grants to the OpenStack Foundation.
Thanks for the clarification. I tried to figure out how to word that, but it's still not entirely clear to me _what_ additional broadness is granted by the OpenStack Foundation ICLA. I'd love it if we had an FAQ with a summary of that additional broadness we could point people to, though I gather lawyers are generally against the idea of summaries of legal agreements since they would counter that the agreement itself is already as summarized as it can be (which doesn't help when it takes a lawyer to interpret and explain it every time the question comes up). -- Jeremy Stanley
On Wed, May 06, 2015 at 03:07:34PM +0000, Jeremy Stanley wrote:
On 2015-05-06 10:39:45 -0400 (-0400), Richard Fontana wrote: [...]
However it is not the case that the OpenStack CLAs "simply reinforce the OpenStack Foundation's ability to continue to redistribute the software under the Apache License by affirming that the terms of the license are applied correctly and intentionally". That is what the DCO, or a hypothetical differently-drafted CLA, would do; the OpenStack CLAs are broader license grants to the OpenStack Foundation.
Thanks for the clarification. I tried to figure out how to word that, but it's still not entirely clear to me _what_ additional broadness is granted by the OpenStack Foundation ICLA. I'd love it if we had an FAQ with a summary of that additional broadness we could point people to,
It's not a huge difference, but I think it is important for developers to understand the CLA is not an open source license nor does it incorporate an open source license. (Not just developers, as I've encountered some confusion on this point among lawyers, but we don't ask noncontributor lawyers to sign the ICLA, while we are still asking individual developers to sign the ICLA.) The issue is touched upon here https://wiki.openstack.org/wiki/OpenStackAndItsCLA#Relationship_to_the_Apach... (That is a wiki page I worked on with markmc last year. It is admittedly a piece of advocacy and contains some assertions that have been disputed by at least one person.)
though I gather lawyers are generally against the idea of summaries of legal agreements since they would counter that the agreement itself is already as summarized as it can be (which doesn't help when it takes a lawyer to interpret and explain it every time the question comes up).
I don't think that's a real problem in this context. I think you might find some disagreement on how exactly the CLAs differ from the Apache License, and maybe some reluctance to acknowledge that disagreement. It should be beyond dispute that they are different licenses, however. RF
On 2015-05-06 17:21:09 -0400 (-0400), Richard Fontana wrote: [...]
The issue is touched upon here https://wiki.openstack.org/wiki/OpenStackAndItsCLA#Relationship_to_the_Apach... (That is a wiki page I worked on with markmc last year. It is admittedly a piece of advocacy and contains some assertions that have been disputed by at least one person.) [...]
Thanks again--I had indeed forgotten there was some additional explanation of the differences in that article. It's still vague insofar as it states that the OpenStack ICLA is structured in a way so as to not place "certain conditions" on the OpenStack Foundation (as compared to a basic grant of the contribution to them under the Apache License) but doesn't indicate what those omitted conditions are. It also mentions additional "legal burdens" on OpenStack contributors without enumerating them. Ultimately I worry that pointing someone there will raise more questions than it answers. I could guess at them, based on a lay reading of the agreement, but perhaps that's the intent of the article after all. Probably my greatest confusion is whether these differences over the Apache License have actually been leveraged to date, or are so far merely unexercised. The way in which the OpenStack Foundation "releases" OpenStack software hasn't (yet!) seemed contradictory to typical methods used by other software projects with similar licenses and no CLA. -- Jeremy Stanley
On Wed, May 06, 2015 at 09:43:37PM +0000, Jeremy Stanley wrote:
On 2015-05-06 17:21:09 -0400 (-0400), Richard Fontana wrote: Thanks again--I had indeed forgotten there was some additional explanation of the differences in that article. It's still vague insofar as it states that the OpenStack ICLA is structured in a way so as to not place "certain conditions" on the OpenStack Foundation (as compared to a basic grant of the contribution to them under the Apache License) but doesn't indicate what those omitted conditions are.
Apache License 2.0 section 4, and I suppose in theory section 9. You could argue that the inclusion or omission of such conditions is not very significant, but that raises the question of why you need a lopsided two-license structure. (Mark Radcliffe has argued that the Apache License 2.0 text assumes the use of CLA licenses flowing to a foundation entity which then grants sublicenses downstream under the Apache License. I don't agree with this but I won't start that debate again here.)
It also mentions additional "legal burdens" on OpenStack contributors without enumerating them. Ultimately I worry that pointing someone there will raise more questions than it answers. I could guess at them, based on a lay reading of the agreement, but perhaps that's the intent of the article after all.
It's fairly straightforward; see paragraphs 4, 5, 7 and 8 of the OpenStack ICLA.
Probably my greatest confusion is whether these differences over the Apache License have actually been leveraged to date, or are so far merely unexercised. The way in which the OpenStack Foundation "releases" OpenStack software hasn't (yet!) seemed contradictory to typical methods used by other software projects with similar licenses and no CLA.
Right; by itself this is not a particularly strong argument against the use of the CLAs in OpenStack, and is not really central to the objections to it. That's actually why the wiki article didn't go into those details, frankly, with respect to my contributions to it; I thought it would detract from the main argument. I don't think the OpenStack Foundation has 'leveraged' the different nature of the CLA license grant, except possibly in re-licensing of documentation from the Apache License to CC BY. RF
I think that additional context would be useful. As counsel to the OpenStack Foundation as well as being on the Legal Committee of the Apache Software Foundation, I think that it is important to note that the ICLA (and CCLA) were developed as part of the ecosystem of the Apache licensing system from the beginning. I reviewed over 200 emails from the time of the drafting of the Apache Software License version 2 (ASLv2) and it is quite clear that the drafters assumed that CLAs would be used. CLAs (both ICLA and CCLA) are still used by the Apache Software Foundation for their projects. As Richard noted, I believe that the ASLv2 as a "contribution license" has significant problems because the manner in which it was drafted assumed that CLAs would be employed and the language of the ASLv2. At the simplest level, the use of ASLv2 as a contribution license means that the user of the ASLv2 licensed code does not get a direct patent license (which he would get under the ICLA and CCLA). I have great respect for Richard and his opinions on many legal issues in FOSS. And I agree that the current implementation of the CLA process could be better. However, the wiki which he references is not a simply an advocacy piece, but it is wrong in a number of respects. First, as a matter of context, the wiki was first brought to the attention of the Board during a meeting with the Technical Committee without any prior review by anyone at the Foundation. This approach is very different from the OpenStack tradition of community and transparency. Consequently, some of the facts were simply wrong: the statements about the "famous" Kevin Fox case are incorrect at best and misleading at worst. Since I was the only person to speak with counsel for PNNL, it would have been useful to speak with me prior to making any statements about this "problem". Second, the wiki ignores the requirement that contributions by individuals working for corporations require an individual with "corporate authority" to approve the contract to make the contribution (whether as a CCLA or DCO). The wiki recommends the use of the DCO: however, the DCO originated in the Linux ecosystem which is based on the GPLv2, a "single tier" license, and thus is quite different from the Apache ecosystem which provides (and assumes) the right to sublicense . The DCO (unlike the ICL/CCLA structure) is not clear about the requirement to get appropriate corporate authority. Most developers are not sufficiently senior in the corporation to have that authority. The Linux community has solved this problem from a cultural point of view, by providing for express delegation of the necessary corporate authority to its developers, but the OpenStack community is much newer and does not have that tradition. Third, even if the DCO was signed by the appropriate corporate authority, the use of a DCO for corporate contributions would not provide the user with a direct patent license (as provided under the CCLA). Consequently contributions by individuals working for corporations (which are estimated to be more than 80% of the contributions to the Foundation) need a CCLA to provide the community with the rights that they expect. I agree with Richard that the Foundation has "not leveraged' the different nature of the ICLA grant. Moreover, the Foundation is unlikely to do so, because it has committed in its bylaws that it will " distribute the software in the OpenStack Technical Committee Approved Release under the Apache License 2.0 unless changed as provided in Section 9.1." Section 9.1 requires the highest level of approval to change this provision, including (i) a majority of the Board of Directors, (ii) two-thirds of the Gold Members, (iii) two-thirds of the Platinum Members, and (iv) a majority of the Individual Members voting (but only if at least 10% of the Individual Members vote at an annual or special meeting). I think that any change would be very unlikely. -----Original Message----- From: Richard Fontana [mailto:rfontana@redhat.com] Sent: Wednesday, May 06, 2015 10:08 PM To: Jeremy Stanley Cc: legal-discuss@lists.openstack.org Subject: Re: [legal-discuss] StackForge and IP. On Wed, May 06, 2015 at 09:43:37PM +0000, Jeremy Stanley wrote:
On 2015-05-06 17:21:09 -0400 (-0400), Richard Fontana wrote: Thanks again--I had indeed forgotten there was some additional explanation of the differences in that article. It's still vague insofar as it states that the OpenStack ICLA is structured in a way so as to not place "certain conditions" on the OpenStack Foundation (as compared to a basic grant of the contribution to them under the Apache License) but doesn't indicate what those omitted conditions are.
Apache License 2.0 section 4, and I suppose in theory section 9. You could argue that the inclusion or omission of such conditions is not very significant, but that raises the question of why you need a lopsided two-license structure. (Mark Radcliffe has argued that the Apache License 2.0 text assumes the use of CLA licenses flowing to a foundation entity which then grants sublicenses downstream under the Apache License. I don't agree with this but I won't start that debate again here.)
It also mentions additional "legal burdens" on OpenStack contributors without enumerating them. Ultimately I worry that pointing someone there will raise more questions than it answers. I could guess at them, based on a lay reading of the agreement, but perhaps that's the intent of the article after all.
It's fairly straightforward; see paragraphs 4, 5, 7 and 8 of the OpenStack ICLA.
Probably my greatest confusion is whether these differences over the Apache License have actually been leveraged to date, or are so far merely unexercised. The way in which the OpenStack Foundation "releases" OpenStack software hasn't (yet!) seemed contradictory to typical methods used by other software projects with similar licenses and no CLA.
Right; by itself this is not a particularly strong argument against the use of the CLAs in OpenStack, and is not really central to the objections to it. That's actually why the wiki article didn't go into those details, frankly, with respect to my contributions to it; I thought it would detract from the main argument. I don't think the OpenStack Foundation has 'leveraged' the different nature of the CLA license grant, except possibly in re-licensing of documentation from the Apache License to CC BY. RF _______________________________________________ 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.
participants (5)
-
Jeremy Stanley
-
Joe Marshall (projectcalico.org)
-
Monty Taylor
-
Radcliffe, Mark
-
Richard Fontana