Stefano suggested that I bring this to the legal-discuss list. I know that this has been discussed in the past, so I don't anticipate a great shift in sentiment, but it seemed worth discussing. My full thoughts are on my blog - http://drbacchus.com/copyright-statements-in-source-files - and I know some of you have seen this discussed on the docs mailing list, or seen it on planet.openstack Anyways, it has been my experience in Open Source communities that having a copyright statement at the top of a source file can be very off-putting to people who want to contribute to that file, due to the perception that it is "owned" by someone in particular. The statement is not necessary: copyright law ensures that contributors have copyright on the content that they author, and git keeps a permanent record of who contributed what. Some folks have claimed (the last time this came up on this list) that the statement was necessary, and this is not the case. It's also unscalable - think in terms of 10 years from now when every file potentially lists hundreds of copyright holders - or perhaps only those who saw fit to add their name to the growing list. What would this contribute? And if people are contributing solely for recognition - which seems at least part of the motivation for a copyright statement, perhaps 1) they're missing the point of Open Source and 2) we should provide a more public means of thanking the enormous list of contributors, rather than having it scattered across thousands of files that relatively few people will ever see. -- Rich Bowen - rbowen@redhat.com OpenStack Community Liaison http://openstack.redhat.com/
I wonder if we could just replace the copyright lines with a generic statement Copyright by various authors. See source control for contribution history. or something to that effect? There has also been concern that the name / email of an author doesn’t make it clear who the copyright owner of the code is. We could allow an optional copyright notice in the commit message to address this. Vish On Jan 21, 2014, at 9:31 AM, Rich Bowen <rbowen@redhat.com> wrote:
Stefano suggested that I bring this to the legal-discuss list. I know that this has been discussed in the past, so I don't anticipate a great shift in sentiment, but it seemed worth discussing.
My full thoughts are on my blog - http://drbacchus.com/copyright-statements-in-source-files - and I know some of you have seen this discussed on the docs mailing list, or seen it on planet.openstack
Anyways, it has been my experience in Open Source communities that having a copyright statement at the top of a source file can be very off-putting to people who want to contribute to that file, due to the perception that it is "owned" by someone in particular.
The statement is not necessary: copyright law ensures that contributors have copyright on the content that they author, and git keeps a permanent record of who contributed what. Some folks have claimed (the last time this came up on this list) that the statement was necessary, and this is not the case.
It's also unscalable - think in terms of 10 years from now when every file potentially lists hundreds of copyright holders - or perhaps only those who saw fit to add their name to the growing list. What would this contribute?
And if people are contributing solely for recognition - which seems at least part of the motivation for a copyright statement, perhaps 1) they're missing the point of Open Source and 2) we should provide a more public means of thanking the enormous list of contributors, rather than having it scattered across thousands of files that relatively few people will ever see.
-- Rich Bowen - rbowen@redhat.com OpenStack Community Liaison http://openstack.redhat.com/ _______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
On Tue, Jan 21, 2014 at 10:07:51AM -0800, Vishvananda Ishaya wrote:
I wonder if we could just replace the copyright lines with a generic statement
Copyright by various authors. See source control for contribution history.
or something to that effect?
I believe I may have suggested "Copyright OpenStack Project developers" or something similar to that in the earlier thread. There might be some disagreement over whether that's a formally accurate copyright notice, though I've come around to thinking it is, and the formal correctness of a copyright notice in an individual source file is of very low legal significance. 'Copyright ProjectName' achieves some of the non-legal goals of having explicit copyright notices. Some projects also use the approach you've suggested, though thus far I've never recommended that. If the license notice remains in the file, this mitigates the concern that having no legal information in a source file could lead to one of two bad future events if a source file ends up being indirectly taken out of context by some other project: either the project is too afraid to use the code because of unclear licensing, or the project will assume it's 'public domain' with no conditions attached.
There has also been concern that the name / email of an author doesn t make it clear who the copyright owner of the code is. We could allow an optional copyright notice in the commit message to address this.
Indeed perhaps it is better to try to attempt to address the copyright issue through commit messages instead of source file headers (the latter tradition having arisen prior to widespread use of VCSes by open source projects). Some have argued for this in the past. - RF
On Tue, Jan 21, 2014 at 11:31 AM, Richard Fontana <rfontana@redhat.com>wrote:
If the license notice remains in the file, this mitigates the concern that having no legal information in a source file could lead to one of two bad future events if a source file ends up being indirectly taken out of context by some other project: either the project is too afraid to use the code because of unclear licensing, or the project will assume it's 'public domain' with no conditions attached.
Note that this is not a hypothetical problem for many downstream consumers; it turns out that when you tell people "I want you to use my code" they do that, and then other people do further downstream, and then when they want to comply with your license they get very confused :) I wrote about this somewhat at length a few years ago: http://tieguy.org/blog/2012/03/17/on-the-importance-of-per-file-license-info... So if I understand Richard correctly, I think his suggested approach is right: per-file *license* information, but not per-file information about copyright holders/authors (except perhaps a generic "copyright by the contributors" statement). Luis
On Tue, Jan 21, 2014 at 11:41:59AM -0800, Luis Villa wrote:
On Tue, Jan 21, 2014 at 11:31 AM, Richard Fontana <rfontana@redhat.com> wrote:
If the license notice remains in the file, this mitigates the concern that having no legal information in a source file could lead to one of two bad future events if a source file ends up being indirectly taken out of context by some other project: either the project is too afraid to use the code because of unclear licensing, or the project will assume it's 'public domain' with no conditions attached.
Note that this is not a hypothetical problem for many downstream consumers; it turns out that when you tell people "I want you to use my code" they do that, and then other people do further downstream, and then when they want to comply with your license they get very confused :)
Yes, I have been on both sides of this. :)
I wrote about this somewhat at length a few years ago:
http://tieguy.org/blog/2012/03/17/ on-the-importance-of-per-file-license-information/
So if I understand Richard correctly, I think his suggested approach is right: per-file *license* information, but not per-file information about copyright holders/authors (except perhaps a generic "copyright by the contributors" statement).
It's at least an option to consider among various others. - RF
On 01/21/2014 03:11 PM, Richard Fontana wrote:
On Tue, Jan 21, 2014 at 11:41:59AM -0800, Luis Villa wrote:
On Tue, Jan 21, 2014 at 11:31 AM, Richard Fontana <rfontana@redhat.com> wrote:
If the license notice remains in the file, this mitigates the concern that having no legal information in a source file could lead to one of two bad future events if a source file ends up being indirectly taken out of context by some other project: either the project is too afraid to use the code because of unclear licensing, or the project will assume it's 'public domain' with no conditions attached.
Note that this is not a hypothetical problem for many downstream consumers; it turns out that when you tell people "I want you to use my code" they do that, and then other people do further downstream, and then when they want to comply with your license they get very confused :)
Yes, I have been on both sides of this. :)
I wrote about this somewhat at length a few years ago:
http://tieguy.org/blog/2012/03/17/ on-the-importance-of-per-file-license-information/
So if I understand Richard correctly, I think his suggested approach is right: per-file *license* information, but not per-file information about copyright holders/authors (except perhaps a generic "copyright by the contributors" statement).
It's at least an option to consider among various others.
For what it's worth, we are actually enforcing the inclusion of license headers in our test automation systems. https://github.com/openstack-dev/hacking/blob/master/hacking/core.py#L186 So all projects that use Hacking get enforcement of this automatically. -Sean -- Sean Dague Samsung Research America sean@dague.net / sean.dague@samsung.com http://dague.net
For reference, past answer on that topic: https://wiki.openstack.org/wiki/LegalIssuesFAQ#Copyright_Headers Rich Bowen wrote:
Stefano suggested that I bring this to the legal-discuss list. I know that this has been discussed in the past, so I don't anticipate a great shift in sentiment, but it seemed worth discussing.
My full thoughts are on my blog - http://drbacchus.com/copyright-statements-in-source-files - and I know some of you have seen this discussed on the docs mailing list, or seen it on planet.openstack
Anyways, it has been my experience in Open Source communities that having a copyright statement at the top of a source file can be very off-putting to people who want to contribute to that file, due to the perception that it is "owned" by someone in particular.
The statement is not necessary: copyright law ensures that contributors have copyright on the content that they author, and git keeps a permanent record of who contributed what. Some folks have claimed (the last time this came up on this list) that the statement was necessary, and this is not the case.
It's also unscalable - think in terms of 10 years from now when every file potentially lists hundreds of copyright holders - or perhaps only those who saw fit to add their name to the growing list. What would this contribute?
And if people are contributing solely for recognition - which seems at least part of the motivation for a copyright statement, perhaps 1) they're missing the point of Open Source and 2) we should provide a more public means of thanking the enormous list of contributors, rather than having it scattered across thousands of files that relatively few people will ever see.
-- Rich Bowen - rbowen@redhat.com OpenStack Community Liaison http://openstack.redhat.com/
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
-- Thierry Carrez (ttx)
On Tue, Jan 21, 2014 at 12:31:02PM -0500, Rich Bowen wrote:
Anyways, it has been my experience in Open Source communities that having a copyright statement at the top of a source file can be very off-putting to people who want to contribute to that file, due to the perception that it is "owned" by someone in particular.
Out of interest I just looked at some of the source code for Ceilometer. In what I sampled, what struck me as unusual was that each file I saw listed one copyright holder and one author (an employee of the company indicated as copyright holder -- in certain cases this was done through a kind of nonstandard copyright notice [1]), followed by the boilerplate Apache License 2.0 license notice. I saw no exceptions to this - no file with two or more copyright notices, no file with more than one author noted -- bearing in mind that my sample was small. I assume this isn't in any sense reflective of how Ceilometer actually operates (i.e., it's not the case that one developer creates a file and thereafter no patch from anyone else will be accepted for that file, which would be rather bizarre for an open source project, or any software development project with more than one human involved). Of course it's very common in large-scale open source projects for source files to give an incomplete or inaccurate record of the copyright and authorship provenance of particular source files, where legal notices appear in files at all, and this tendency has probably only increased over the years/decades (the earliest open source projects did not use version control systems) and is probably unavoidable. Nevertheless, what I saw in Ceilometer supports your complaint, again assuming my sample was representative, as I could see how a newcomer to the project, especially a newcomer who had experience in other large-ish projects, could get the vague impression that individual source files were somehow 'owned' (in a broader-than-legal sense) by particular individual developers. Not sure what to suggest beyond whatever I said in the thread several months ago. Different open source projects have adopted wildly different approaches to this issue, and with certain exceptions it's hard to say that any one of the more common ones are more legally correct than the others. Maybe you could propose a specific suggestion for how OpenStack might consistently deal with this in a way that avoids the problem you believe exists? - RF [1] Of the form "Copyright Joe Developer for CompanyName, Inc."
On 01/21/2014 02:12 PM, Richard Fontana wrote:
Not sure what to suggest beyond whatever I said in the thread several months ago. Different open source projects have adopted wildly different approaches to this issue, and with certain exceptions it's hard to say that any one of the more common ones are more legally correct than the others. Maybe you could propose a specific suggestion for how OpenStack might consistently deal with this in a way that avoids the problem you believe exists?
I would suggest language like what you see here: http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/server/vhost.c So, perhaps: /* Licensed to the OpenStack Foundation under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 If you want detailed copyright information on any given file `git blame` gives it to you. It's unclear to me why someone is concerned about that, given that they're contributing their changes to a project licensed under the Apache License, but I expect that people have various reasons or perceived reasons. To me, the large social and/or community impact of per-author per-company copyright statements in files *far* outweigh the (largely imaginary) legal benefit of doing it. -- Rich Bowen - rbowen@redhat.com OpenStack Community Liaison http://openstack.redhat.com/
On Tue, Jan 21, 2014 at 02:46:29PM -0500, Rich Bowen wrote:
I would suggest language like what you see here: http://svn.apache.org/repos/ asf/httpd/httpd/branches/2.2.x/server/vhost.c
So, perhaps:
/* Licensed to the OpenStack Foundation under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0
I can't resist using this as an opportunity for a rant related to some things I've said before, not entirely off-topic. It's my understanding, and this is reinforced by the existing practice of copyright and license notices in OpenStack source files, that there is an understanding that a contributor is both granting a license under the relevant CLA and granting a license under the terms of the Apache License. I could point out that it is potentially even more complicated than that but let's keep it there for simplicity. I've contended that this is a form of duplicative licensing unprecedented in open source software development; if anyone has a counterexample I'd be happy to know about it. The reason it's unprecedented is that CLAs exist precisely so that contributors won't be granting in licenses under the project license (leave aside whether that's a good or bad thing). There are tons of Apache License projects that have contributors licensing contributions under the Apache License, like oVirt and OpenShift Origin, but these are the projects that don't use CLAs. While -- as was noted today in a Twitter conversation -- ASF projects normatively accept 'smaller' patches without a CLA (the understanding being they are licensed under the Apache License itself), the only thing recorded in source code is the license grant from the ASF and, in some cases, the note that the code was largely licensed in under (nonpublic) CLAs, as in the ASF notice that you've adapted. Your suggestion might make perfect sense, particularly to someone coming from the ASF tradition, but it calls into question why this duplicative licensing appears to be taking place. This is not the case for ASF projects. As an arbitrary example, a lot of Red Hat copyright licenses flow into Apache Camel, but Red Hat isn't granting an Apache License on Apache Camel (via apache.org at least), because Red Hat is the licensor of a CLA covering employee contributors to Apache Camel and that's the extent of the licenses it is granting in to that project. A copyright notice from Red Hat in Apache Camel would violate ASF standards but would be accurate. A Red Hat copyright notice immediately followed by an Apache License grant would be inaccurate, because the Apache License isn't coming from Red Hat; it's coming (mostly) from the ASF. To understand my point here, look at any other project that uses CLAs, and you will see that there are no contributor copyright notices other than, in some cases, copyright notices from the main CLA licensee (here the OpenStack Foundation). OpenStack is the only exception I'm aware of, and I believe the rationale for having such contributor copyright notices at all is to make visible that, separate from the CLA, direct Apache License grants are being made by CLA signers. Your proposal is one visible way to cease the practice of duplicative licensing. However, OpenStack developers and fellow travelers who have criticized the CLA regime won't like this, because it signifies full reliance on the CLA regime. - RF
On 01/21/2014 05:02 PM, Richard Fontana wrote:
On Tue, Jan 21, 2014 at 02:46:29PM -0500, Rich Bowen wrote:
I would suggest language like what you see here: http://svn.apache.org/repos/ asf/httpd/httpd/branches/2.2.x/server/vhost.c
So, perhaps:
/* Licensed to the OpenStack Foundation under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0
I can't resist using this as an opportunity for a rant related to some things I've said before, not entirely off-topic.
It's my understanding, and this is reinforced by the existing practice of copyright and license notices in OpenStack source files, that there is an understanding that a contributor is both granting a license under the relevant CLA and granting a license under the terms of the Apache License. I could point out that it is potentially even more complicated than that but let's keep it there for simplicity. I've contended that this is a form of duplicative licensing unprecedented in open source software development; if anyone has a counterexample I'd be happy to know about it. The reason it's unprecedented is that CLAs exist precisely so that contributors won't be granting in licenses under the project license (leave aside whether that's a good or bad thing). There are tons of Apache License projects that have contributors licensing contributions under the Apache License, like oVirt and OpenShift Origin, but these are the projects that don't use CLAs.
While -- as was noted today in a Twitter conversation -- ASF projects normatively accept 'smaller' patches without a CLA (the understanding being they are licensed under the Apache License itself), the only thing recorded in source code is the license grant from the ASF and, in some cases, the note that the code was largely licensed in under (nonpublic) CLAs, as in the ASF notice that you've adapted.
Your suggestion might make perfect sense, particularly to someone coming from the ASF tradition, but it calls into question why this duplicative licensing appears to be taking place. This is not the case for ASF projects. As an arbitrary example, a lot of Red Hat copyright licenses flow into Apache Camel, but Red Hat isn't granting an Apache License on Apache Camel (via apache.org at least), because Red Hat is the licensor of a CLA covering employee contributors to Apache Camel and that's the extent of the licenses it is granting in to that project. A copyright notice from Red Hat in Apache Camel would violate ASF standards but would be accurate. A Red Hat copyright notice immediately followed by an Apache License grant would be inaccurate, because the Apache License isn't coming from Red Hat; it's coming (mostly) from the ASF.
To understand my point here, look at any other project that uses CLAs, and you will see that there are no contributor copyright notices other than, in some cases, copyright notices from the main CLA licensee (here the OpenStack Foundation). OpenStack is the only exception I'm aware of, and I believe the rationale for having such contributor copyright notices at all is to make visible that, separate from the CLA, direct Apache License grants are being made by CLA signers.
Your proposal is one visible way to cease the practice of duplicative licensing. However, OpenStack developers and fellow travelers who have criticized the CLA regime won't like this, because it signifies full reliance on the CLA regime.
For what it's worth, from my direct experience, < 20% of our developer community understands this distinction. And probably < 50% of our core review team members. For many this is the first open source project they've ever worked on. Which, on the one hand, is very cool. OpenStack is bringing new people to Open Source development. On the other hand, it means at a certain point people just generally agreed not to -1 code over people screwing up the copyright line, because it was getting exhausting, and confusing to new contributors. We've had 1000 active developers over the last 12 months. That's a ton of education to provide. The copyright lines in OpenStack are thus terribly inaccurate, and I don't really see that changing unless there were a team of people reviewing for them. Honestly, I'd be happy to see that, especially if it got us away from the CLA. But realize this is about review mental bandwidth, and a pragmatic policy was adopted in most projects to ignore the issue lacking clear guidance on policy. -Sean -- Sean Dague Samsung Research America sean@dague.net / sean.dague@samsung.com http://dague.net
On Tue, 2014-01-21 at 17:02 -0500, Richard Fontana wrote:
On Tue, Jan 21, 2014 at 02:46:29PM -0500, Rich Bowen wrote:
I would suggest language like what you see here: http://svn.apache.org/repos/ asf/httpd/httpd/branches/2.2.x/server/vhost.c
So, perhaps:
/* Licensed to the OpenStack Foundation under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0
I can't resist using this as an opportunity for a rant related to some things I've said before, not entirely off-topic.
It's my understanding, and this is reinforced by the existing practice of copyright and license notices in OpenStack source files, that there is an understanding that a contributor is both granting a license under the relevant CLA and granting a license under the terms of the Apache License.
I think I've seen you allude to this before but it went right over my head. Contributors sign the CLA and this grants the OpenStack Foundation a license (which is slightly more broad than ALv2) to the code. The Foundation then distributes the code under ALv2. You're saying that our copyright notices also signifies that contributors are also granting a license under ALv2 directly to whomever receives a copy of the code. I'd agree with Sean that <20% of our contributors understand this distinction (or its practical significance). In fact I'd guess it's approaching 0% :)
I could point out that it is potentially even more complicated than that but let's keep it there for simplicity. I've contended that this is a form of duplicative licensing unprecedented in open source software development; if anyone has a counterexample I'd be happy to know about it. The reason it's unprecedented is that CLAs exist precisely so that contributors won't be granting in licenses under the project license (leave aside whether that's a good or bad thing). There are tons of Apache License projects that have contributors licensing contributions under the Apache License, like oVirt and OpenShift Origin, but these are the projects that don't use CLAs.
While -- as was noted today in a Twitter conversation -- ASF projects normatively accept 'smaller' patches without a CLA (the understanding being they are licensed under the Apache License itself), the only thing recorded in source code is the license grant from the ASF and, in some cases, the note that the code was largely licensed in under (nonpublic) CLAs, as in the ASF notice that you've adapted.
Your suggestion might make perfect sense, particularly to someone coming from the ASF tradition, but it calls into question why this duplicative licensing appears to be taking place. This is not the case for ASF projects. As an arbitrary example, a lot of Red Hat copyright licenses flow into Apache Camel, but Red Hat isn't granting an Apache License on Apache Camel (via apache.org at least), because Red Hat is the licensor of a CLA covering employee contributors to Apache Camel and that's the extent of the licenses it is granting in to that project. A copyright notice from Red Hat in Apache Camel would violate ASF standards but would be accurate. A Red Hat copyright notice immediately followed by an Apache License grant would be inaccurate, because the Apache License isn't coming from Red Hat; it's coming (mostly) from the ASF.
To understand my point here, look at any other project that uses CLAs, and you will see that there are no contributor copyright notices other than, in some cases, copyright notices from the main CLA licensee (here the OpenStack Foundation). OpenStack is the only exception I'm aware of, and I believe the rationale for having such contributor copyright notices at all is to make visible that, separate from the CLA, direct Apache License grants are being made by CLA signers.
Ok, wow - I never understood that most CLA-using projects don't have individual per-file copyright notices.
Your proposal is one visible way to cease the practice of duplicative licensing. However, OpenStack developers and fellow travelers who have criticized the CLA regime won't like this, because it signifies full reliance on the CLA regime.
This sort of stuff struggles to be seen as a priority issue amongst our contributors IMHO. The issue of copyright notices became a hot topic purely because developers were frustrated when their patches were -1ed for copyright notice nitpicks. This was seen as a waste of time signifying (I guess) that they generally are not seen as important. Your description of their significance (i.e. as a direct license grant) could change that slightly. The issue of our CLA regime is grumbled about regularly but, since it's a pretty low friction process, so there's little urgency around it. I came across one sad/unhappy developer outside the developer lounge in Hong Kong who had been refused access because he's not an ATC. Although he has contributed some small fixes via other people and would contribute more, he (quietly) refuses to sign the CLA even though he fully understands the terms of the CLA. My understanding is he rejects the notion that he needs to enter into an agreement with the foundation in order to be able to contribute code. I think it's time we stepped back and considered all the angles here - not just "drop the CLA", "delete the copyright notices". What do we (the project) want? What are our values? I'd suggest: - We want to be able to distribute OpenStack under the Apache License v2, so: - All code to the project must be contributed under the ALv2 - We can incorporate BSD/MIT licensed code from other projects - We can use LGPL, BSD, MIT, etc. licensed libraries; currently, we're being conservative and not using GPL/AGPL libraries - There is no need for contributors to grant the foundation a special license. - We copy the kernel's Signed-off-by/DCO method of having all developers who contribute to a patch state they have the right to contribute the patch under ALv2 - We consolidate all copyright notices into a single "copyright multiple authors" notice above the ALv2 header, making it clear the code is directly licensed by the authors under ALv2 without the foundation acting as an intermediary This is just a strawman idea to draw some comments. What am I missing? Thanks, Mark.
On Wed, 2014-01-22 at 11:27 +0000, Mark McLoughlin wrote:
On Tue, 2014-01-21 at 17:02 -0500, Richard Fontana wrote:
On Tue, Jan 21, 2014 at 02:46:29PM -0500, Rich Bowen wrote:
I would suggest language like what you see here: http://svn.apache.org/repos/ asf/httpd/httpd/branches/2.2.x/server/vhost.c
So, perhaps:
/* Licensed to the OpenStack Foundation under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0
I can't resist using this as an opportunity for a rant related to some things I've said before, not entirely off-topic.
It's my understanding, and this is reinforced by the existing practice of copyright and license notices in OpenStack source files, that there is an understanding that a contributor is both granting a license under the relevant CLA and granting a license under the terms of the Apache License.
I think I've seen you allude to this before but it went right over my head.
Contributors sign the CLA and this grants the OpenStack Foundation a license (which is slightly more broad than ALv2) to the code. The Foundation then distributes the code under ALv2.
You're saying that our copyright notices also signifies that contributors are also granting a license under ALv2 directly to whomever receives a copy of the code.
I'd agree with Sean that <20% of our contributors understand this distinction (or its practical significance). In fact I'd guess it's approaching 0% :)
I could point out that it is potentially even more complicated than that but let's keep it there for simplicity. I've contended that this is a form of duplicative licensing unprecedented in open source software development; if anyone has a counterexample I'd be happy to know about it. The reason it's unprecedented is that CLAs exist precisely so that contributors won't be granting in licenses under the project license (leave aside whether that's a good or bad thing). There are tons of Apache License projects that have contributors licensing contributions under the Apache License, like oVirt and OpenShift Origin, but these are the projects that don't use CLAs.
While -- as was noted today in a Twitter conversation -- ASF projects normatively accept 'smaller' patches without a CLA (the understanding being they are licensed under the Apache License itself), the only thing recorded in source code is the license grant from the ASF and, in some cases, the note that the code was largely licensed in under (nonpublic) CLAs, as in the ASF notice that you've adapted.
Your suggestion might make perfect sense, particularly to someone coming from the ASF tradition, but it calls into question why this duplicative licensing appears to be taking place. This is not the case for ASF projects. As an arbitrary example, a lot of Red Hat copyright licenses flow into Apache Camel, but Red Hat isn't granting an Apache License on Apache Camel (via apache.org at least), because Red Hat is the licensor of a CLA covering employee contributors to Apache Camel and that's the extent of the licenses it is granting in to that project. A copyright notice from Red Hat in Apache Camel would violate ASF standards but would be accurate. A Red Hat copyright notice immediately followed by an Apache License grant would be inaccurate, because the Apache License isn't coming from Red Hat; it's coming (mostly) from the ASF.
To understand my point here, look at any other project that uses CLAs, and you will see that there are no contributor copyright notices other than, in some cases, copyright notices from the main CLA licensee (here the OpenStack Foundation). OpenStack is the only exception I'm aware of, and I believe the rationale for having such contributor copyright notices at all is to make visible that, separate from the CLA, direct Apache License grants are being made by CLA signers.
Ok, wow - I never understood that most CLA-using projects don't have individual per-file copyright notices.
Your proposal is one visible way to cease the practice of duplicative licensing. However, OpenStack developers and fellow travelers who have criticized the CLA regime won't like this, because it signifies full reliance on the CLA regime.
This sort of stuff struggles to be seen as a priority issue amongst our contributors IMHO.
The issue of copyright notices became a hot topic purely because developers were frustrated when their patches were -1ed for copyright notice nitpicks. This was seen as a waste of time signifying (I guess) that they generally are not seen as important. Your description of their significance (i.e. as a direct license grant) could change that slightly.
The issue of our CLA regime is grumbled about regularly but, since it's a pretty low friction process, so there's little urgency around it.
I came across one sad/unhappy developer outside the developer lounge in Hong Kong who had been refused access because he's not an ATC. Although he has contributed some small fixes via other people and would contribute more, he (quietly) refuses to sign the CLA even though he fully understands the terms of the CLA. My understanding is he rejects the notion that he needs to enter into an agreement with the foundation in order to be able to contribute code.
I think it's time we stepped back and considered all the angles here - not just "drop the CLA", "delete the copyright notices". What do we (the project) want? What are our values?
I'd suggest:
- We want to be able to distribute OpenStack under the Apache License v2, so: - All code to the project must be contributed under the ALv2 - We can incorporate BSD/MIT licensed code from other projects - We can use LGPL, BSD, MIT, etc. licensed libraries; currently, we're being conservative and not using GPL/AGPL libraries
- There is no need for contributors to grant the foundation a special license.
- We copy the kernel's Signed-off-by/DCO method of having all developers who contribute to a patch state they have the right to contribute the patch under ALv2
- We consolidate all copyright notices into a single "copyright multiple authors" notice above the ALv2 header, making it clear the code is directly licensed by the authors under ALv2 without the foundation acting as an intermediary
This is just a strawman idea to draw some comments. What am I missing?
Ok, I missed this comment from Alice back in December: http://lists.openstack.org/pipermail/legal-discuss/2013-December/000122.html The value of the CLA to my mind is that it creates a single rights holder for the community. This could be key if there are material patent threats, and it would be a lynchpin of a some of the patent cooperation strategies that have been discussed. Assuming that all contributions are licensed under ALv2 to all recipients including the OpenStack Foundation, what additional patent rights are granted to the foundation via the CLA? Basically, I don't understand the point. But that doesn't mean it isn't correct :) Anyone care to explain? Thanks, Mark.
On 01/22/2014 06:27 AM, Mark McLoughlin wrote:
On Tue, 2014-01-21 at 17:02 -0500, Richard Fontana wrote:
On Tue, Jan 21, 2014 at 02:46:29PM -0500, Rich Bowen wrote:
I would suggest language like what you see here: http://svn.apache.org/repos/ asf/httpd/httpd/branches/2.2.x/server/vhost.c
So, perhaps:
/* Licensed to the OpenStack Foundation under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0
I can't resist using this as an opportunity for a rant related to some things I've said before, not entirely off-topic.
It's my understanding, and this is reinforced by the existing practice of copyright and license notices in OpenStack source files, that there is an understanding that a contributor is both granting a license under the relevant CLA and granting a license under the terms of the Apache License.
I think I've seen you allude to this before but it went right over my head.
Contributors sign the CLA and this grants the OpenStack Foundation a license (which is slightly more broad than ALv2) to the code. The Foundation then distributes the code under ALv2.
You're saying that our copyright notices also signifies that contributors are also granting a license under ALv2 directly to whomever receives a copy of the code.
I'd agree with Sean that <20% of our contributors understand this distinction (or its practical significance). In fact I'd guess it's approaching 0% :)
I could point out that it is potentially even more complicated than that but let's keep it there for simplicity. I've contended that this is a form of duplicative licensing unprecedented in open source software development; if anyone has a counterexample I'd be happy to know about it. The reason it's unprecedented is that CLAs exist precisely so that contributors won't be granting in licenses under the project license (leave aside whether that's a good or bad thing). There are tons of Apache License projects that have contributors licensing contributions under the Apache License, like oVirt and OpenShift Origin, but these are the projects that don't use CLAs.
While -- as was noted today in a Twitter conversation -- ASF projects normatively accept 'smaller' patches without a CLA (the understanding being they are licensed under the Apache License itself), the only thing recorded in source code is the license grant from the ASF and, in some cases, the note that the code was largely licensed in under (nonpublic) CLAs, as in the ASF notice that you've adapted.
Your suggestion might make perfect sense, particularly to someone coming from the ASF tradition, but it calls into question why this duplicative licensing appears to be taking place. This is not the case for ASF projects. As an arbitrary example, a lot of Red Hat copyright licenses flow into Apache Camel, but Red Hat isn't granting an Apache License on Apache Camel (via apache.org at least), because Red Hat is the licensor of a CLA covering employee contributors to Apache Camel and that's the extent of the licenses it is granting in to that project. A copyright notice from Red Hat in Apache Camel would violate ASF standards but would be accurate. A Red Hat copyright notice immediately followed by an Apache License grant would be inaccurate, because the Apache License isn't coming from Red Hat; it's coming (mostly) from the ASF.
To understand my point here, look at any other project that uses CLAs, and you will see that there are no contributor copyright notices other than, in some cases, copyright notices from the main CLA licensee (here the OpenStack Foundation). OpenStack is the only exception I'm aware of, and I believe the rationale for having such contributor copyright notices at all is to make visible that, separate from the CLA, direct Apache License grants are being made by CLA signers.
Ok, wow - I never understood that most CLA-using projects don't have individual per-file copyright notices.
Your proposal is one visible way to cease the practice of duplicative licensing. However, OpenStack developers and fellow travelers who have criticized the CLA regime won't like this, because it signifies full reliance on the CLA regime.
This sort of stuff struggles to be seen as a priority issue amongst our contributors IMHO.
The issue of copyright notices became a hot topic purely because developers were frustrated when their patches were -1ed for copyright notice nitpicks. This was seen as a waste of time signifying (I guess) that they generally are not seen as important. Your description of their significance (i.e. as a direct license grant) could change that slightly.
The issue of our CLA regime is grumbled about regularly but, since it's a pretty low friction process, so there's little urgency around it.
I came across one sad/unhappy developer outside the developer lounge in Hong Kong who had been refused access because he's not an ATC. Although he has contributed some small fixes via other people and would contribute more, he (quietly) refuses to sign the CLA even though he fully understands the terms of the CLA. My understanding is he rejects the notion that he needs to enter into an agreement with the foundation in order to be able to contribute code.
I think it's time we stepped back and considered all the angles here - not just "drop the CLA", "delete the copyright notices". What do we (the project) want? What are our values?
I'd suggest:
- We want to be able to distribute OpenStack under the Apache License v2, so: - All code to the project must be contributed under the ALv2 - We can incorporate BSD/MIT licensed code from other projects - We can use LGPL, BSD, MIT, etc. licensed libraries; currently, we're being conservative and not using GPL/AGPL libraries
+1. I think OpenStack shared culture believes in all those things. I'd go as far as saying "we hold these truths to be self evident..."
- There is no need for contributors to grant the foundation a special license.
- We copy the kernel's Signed-off-by/DCO method of having all developers who contribute to a patch state they have the right to contribute the patch under ALv2
- We consolidate all copyright notices into a single "copyright multiple authors" notice above the ALv2 header, making it clear the code is directly licensed by the authors under ALv2 without the foundation acting as an intermediary
This is just a strawman idea to draw some comments. What am I missing?
Honestly, I'd be happy with all that. I think the technical implementation with our toolchain to enforce something like that would be pretty easy. (We're actually really good at encoding policy into code once we've agreed on the policy.) I think this all just hinges on who can make that policy decision. I feel like past discussions here largely fell apart on the fact that there was neither a clear concensus (at least not at the TC level), nor a clear decision making authority on it. -Sean -- Sean Dague http://dague.net
On Wed, 2014-01-22 at 08:35 -0500, Sean Dague wrote:
On 01/22/2014 06:27 AM, Mark McLoughlin wrote:
On Tue, 2014-01-21 at 17:02 -0500, Richard Fontana wrote:
On Tue, Jan 21, 2014 at 02:46:29PM -0500, Rich Bowen wrote:
I would suggest language like what you see here: http://svn.apache.org/repos/ asf/httpd/httpd/branches/2.2.x/server/vhost.c
So, perhaps:
/* Licensed to the OpenStack Foundation under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0
I can't resist using this as an opportunity for a rant related to some things I've said before, not entirely off-topic.
It's my understanding, and this is reinforced by the existing practice of copyright and license notices in OpenStack source files, that there is an understanding that a contributor is both granting a license under the relevant CLA and granting a license under the terms of the Apache License.
I think I've seen you allude to this before but it went right over my head.
Contributors sign the CLA and this grants the OpenStack Foundation a license (which is slightly more broad than ALv2) to the code. The Foundation then distributes the code under ALv2.
You're saying that our copyright notices also signifies that contributors are also granting a license under ALv2 directly to whomever receives a copy of the code.
I'd agree with Sean that <20% of our contributors understand this distinction (or its practical significance). In fact I'd guess it's approaching 0% :)
I could point out that it is potentially even more complicated than that but let's keep it there for simplicity. I've contended that this is a form of duplicative licensing unprecedented in open source software development; if anyone has a counterexample I'd be happy to know about it. The reason it's unprecedented is that CLAs exist precisely so that contributors won't be granting in licenses under the project license (leave aside whether that's a good or bad thing). There are tons of Apache License projects that have contributors licensing contributions under the Apache License, like oVirt and OpenShift Origin, but these are the projects that don't use CLAs.
While -- as was noted today in a Twitter conversation -- ASF projects normatively accept 'smaller' patches without a CLA (the understanding being they are licensed under the Apache License itself), the only thing recorded in source code is the license grant from the ASF and, in some cases, the note that the code was largely licensed in under (nonpublic) CLAs, as in the ASF notice that you've adapted.
Your suggestion might make perfect sense, particularly to someone coming from the ASF tradition, but it calls into question why this duplicative licensing appears to be taking place. This is not the case for ASF projects. As an arbitrary example, a lot of Red Hat copyright licenses flow into Apache Camel, but Red Hat isn't granting an Apache License on Apache Camel (via apache.org at least), because Red Hat is the licensor of a CLA covering employee contributors to Apache Camel and that's the extent of the licenses it is granting in to that project. A copyright notice from Red Hat in Apache Camel would violate ASF standards but would be accurate. A Red Hat copyright notice immediately followed by an Apache License grant would be inaccurate, because the Apache License isn't coming from Red Hat; it's coming (mostly) from the ASF.
To understand my point here, look at any other project that uses CLAs, and you will see that there are no contributor copyright notices other than, in some cases, copyright notices from the main CLA licensee (here the OpenStack Foundation). OpenStack is the only exception I'm aware of, and I believe the rationale for having such contributor copyright notices at all is to make visible that, separate from the CLA, direct Apache License grants are being made by CLA signers.
Ok, wow - I never understood that most CLA-using projects don't have individual per-file copyright notices.
Your proposal is one visible way to cease the practice of duplicative licensing. However, OpenStack developers and fellow travelers who have criticized the CLA regime won't like this, because it signifies full reliance on the CLA regime.
This sort of stuff struggles to be seen as a priority issue amongst our contributors IMHO.
The issue of copyright notices became a hot topic purely because developers were frustrated when their patches were -1ed for copyright notice nitpicks. This was seen as a waste of time signifying (I guess) that they generally are not seen as important. Your description of their significance (i.e. as a direct license grant) could change that slightly.
The issue of our CLA regime is grumbled about regularly but, since it's a pretty low friction process, so there's little urgency around it.
I came across one sad/unhappy developer outside the developer lounge in Hong Kong who had been refused access because he's not an ATC. Although he has contributed some small fixes via other people and would contribute more, he (quietly) refuses to sign the CLA even though he fully understands the terms of the CLA. My understanding is he rejects the notion that he needs to enter into an agreement with the foundation in order to be able to contribute code.
I think it's time we stepped back and considered all the angles here - not just "drop the CLA", "delete the copyright notices". What do we (the project) want? What are our values?
I'd suggest:
- We want to be able to distribute OpenStack under the Apache License v2, so: - All code to the project must be contributed under the ALv2 - We can incorporate BSD/MIT licensed code from other projects - We can use LGPL, BSD, MIT, etc. licensed libraries; currently, we're being conservative and not using GPL/AGPL libraries
+1. I think OpenStack shared culture believes in all those things. I'd go as far as saying "we hold these truths to be self evident..."
- There is no need for contributors to grant the foundation a special license.
- We copy the kernel's Signed-off-by/DCO method of having all developers who contribute to a patch state they have the right to contribute the patch under ALv2
- We consolidate all copyright notices into a single "copyright multiple authors" notice above the ALv2 header, making it clear the code is directly licensed by the authors under ALv2 without the foundation acting as an intermediary
This is just a strawman idea to draw some comments. What am I missing?
Honestly, I'd be happy with all that.
I think the technical implementation with our toolchain to enforce something like that would be pretty easy. (We're actually really good at encoding policy into code once we've agreed on the policy.)
I think this all just hinges on who can make that policy decision. I feel like past discussions here largely fell apart on the fact that there was neither a clear concensus (at least not at the TC level), nor a clear decision making authority on it.
We (the TC) can probably do the copyright notice change pretty easily, understanding that it would mean the "duplicative licensing" situation continues. Removing the need for a CLA (and adding the requirement for Signed-off-by) would be a change to 7.1(a) of the bylaws and require a majority vote of >=25% of the individual members. Mark.
On 01/22/2014 06:27 AM, Mark McLoughlin wrote:
I'd suggest:
- We want to be able to distribute OpenStack under the Apache License v2, so: - All code to the project must be contributed under the ALv2 - We can incorporate BSD/MIT licensed code from other projects - We can use LGPL, BSD, MIT, etc. licensed libraries; currently, we're being conservative and not using GPL/AGPL libraries
- There is no need for contributors to grant the foundation a special license.
- We copy the kernel's Signed-off-by/DCO method of having all developers who contribute to a patch state they have the right to contribute the patch under ALv2
- We consolidate all copyright notices into a single "copyright multiple authors" notice above the ALv2 header, making it clear the code is directly licensed by the authors under ALv2 without the foundation acting as an intermediary
This is just a strawman idea to draw some comments. What am I missing? This sounds good to me. Major contributors should be encouraged to sign a CLA, to protect the Foundation, but smaller contributions (no idea where to draw the line here) don't seem to require that. (This is, anyways, how the ASF handles this.)
-- Rich Bowen - rbowen@redhat.com OpenStack Community Liaison http://openstack.redhat.com/
On Wed, 2014-01-22 at 09:28 -0500, Rich Bowen wrote:
On 01/22/2014 06:27 AM, Mark McLoughlin wrote:
I'd suggest:
- We want to be able to distribute OpenStack under the Apache License v2, so: - All code to the project must be contributed under the ALv2 - We can incorporate BSD/MIT licensed code from other projects - We can use LGPL, BSD, MIT, etc. licensed libraries; currently, we're being conservative and not using GPL/AGPL libraries
- There is no need for contributors to grant the foundation a special license.
- We copy the kernel's Signed-off-by/DCO method of having all developers who contribute to a patch state they have the right to contribute the patch under ALv2
- We consolidate all copyright notices into a single "copyright multiple authors" notice above the ALv2 header, making it clear the code is directly licensed by the authors under ALv2 without the foundation acting as an intermediary
This is just a strawman idea to draw some comments. What am I missing? This sounds good to me. Major contributors should be encouraged to sign a CLA, to protect the Foundation, but smaller contributions (no idea where to draw the line here) don't seem to require that. (This is, anyways, how the ASF handles this.)
That's not what I'm describing. I don't know exactly what protection for the Foundation you're talking about, but I'm proposing we achieve that without a special agreement between contributors and the Foundation. Mark.
On Wed, Jan 22, 2014 at 09:28:16AM -0500, Rich Bowen wrote:
This sounds good to me. Major contributors should be encouraged to sign a CLA, to protect the Foundation, but smaller contributions (no idea where to draw the line here) don't seem to require that. (This is, anyways, how the ASF handles this.)
Although that is not actually what Mark is suggesting, thanks for pointing this out. I have been separately pointing out in an off-list email thread involving the legal affairs committee (relevant to the Kevin Fox case) that the ASF does not have the same CLA system as OpenStack, but a far more liberal system. Yet I have had the impression that OpenStack's system may have been based on a belief that it was in line with what the ASF does (I'm not sure if that's so, admittedly). I can't imagine that there was any point at which someone at Rackspace or the OpenStack Foundation looked at the ASF system, the actual practice of which is not well known outside the ASF, and decided it was insufficiently comprehensive or restrictive. OpenStack's CLA system is in line with how I see Apache-style CLAs used by open source projects that are tightly controlled by one corporation, which is not the situation we have with OpenStack. But even in those cases I wonder whether the difference in the CLA system is the result of inadequate knowledge about what the ASF, the originator of these kinds of CLAs, actually does. - RF
On Wed, Jan 22, 2014 at 11:27:28AM +0000, Mark McLoughlin wrote:
Contributors sign the CLA and this grants the OpenStack Foundation a license (which is slightly more broad than ALv2) to the code. The Foundation then distributes the code under ALv2.
You're saying that our copyright notices also signifies that contributors are also granting a license under ALv2 directly to whomever receives a copy of the code.
Not 'signifies' but certainly gives the impression. If I see in a source file Copyright 2014 eNovance Licensed under the Apache License 2.0 [etc. boilerplate] That would reasonably be understood to mean eNovance is granting a license directly under ALv2. This is in part because AFAIK all other projects that use these kinds of CLAs only have copyright notices from the privileged entity, if there are copyright notices at all (ignoring third-party code from other projects). Now of course when looking at such things you always have to keep in mind that they may be bad approximations of whatever the truth is. Nonetheless when explicit legal notices like this are contained in source files there is a natural tendency to assume they mean what they say. But I also say this because a number of times I've heard it suggested that OpenStack has this deliberate duplicative licensing policy, which seems then to shape the meaning of 'Copyright eNovance, Licensed under the Apache License...'. That's partly why I've brought it up a few times, in the hopes that someone will tell me I'm wrong (or right). I think perhaps in the end this is all a matter of confusion but if so it might be useful to clear it up. Normally, a CLA is a substitute for direct licensing under the outbound project license. So with respect to a given copyright holder, if a CLA hasn't been signed, fine, the license is the outbound license. That's how most ALv2 projects work, after all. If a CLA has been signed, it is nonstandard for the contributor to be additionally granting a separate license under the Apache License. I will admit that at the moment I am confused about what is supposed to be going on in this respect in OpenStack. Maybe this supposition about duplicative licensing is a misunderstanding on my own part.
I'd agree with Sean that <20% of our contributors understand this distinction (or its practical significance). In fact I'd guess it's approaching 0% :)
The distinction is ultimately minor, but there's something about it that bothers me if it turns out to be in some sense intentional. If there is a desire to have everyone sign a CLA, the project shouldn't have any expectation that CLA signers additionally grant a similar though overall slightly less permissive license. If there is some belief that everyone is granting Apache Licenses, then there shouldn't be any CLA.
Ok, wow - I never understood that most CLA-using projects don't have individual per-file copyright notices.
Yes, this is a key to my whole argument, even if I turn out to be the one who is confused, in which case I apologize for wasting anyone's time. If I'm confused, though, there's a good chance that some others are as well, and as unimportant as this all might be it seems better to have less confusion. Again to contrast things with ASF projects, I know what's going on there. For a given project, if you regard it as a set of Apache Licenses and a set of CLAs, the 'big' Apache License is granted by the ASF and some 'smaller' Apache Licenses are being granted by minor contributors, Then you have a bunch of CLA-based licenses that are (nontransparently) granted to everyone, mostly granted by individuals. (You may also have 'software grants' licensed broadly to the ASF for large code donations.) I don't have the same certainty about what's happening in OpenStack. But I don't want to exaggerate the importance or significance of this. It's more of an annoyance. - RF
On Wed, 2014-01-22 at 11:52 -0500, Richard Fontana wrote:
On Wed, Jan 22, 2014 at 11:27:28AM +0000, Mark McLoughlin wrote:
Contributors sign the CLA and this grants the OpenStack Foundation a license (which is slightly more broad than ALv2) to the code. The Foundation then distributes the code under ALv2.
You're saying that our copyright notices also signifies that contributors are also granting a license under ALv2 directly to whomever receives a copy of the code.
Not 'signifies' but certainly gives the impression. If I see in a source file
Copyright 2014 eNovance
Licensed under the Apache License 2.0 [etc. boilerplate]
That would reasonably be understood to mean eNovance is granting a license directly under ALv2. This is in part because AFAIK all other projects that use these kinds of CLAs only have copyright notices from the privileged entity, if there are copyright notices at all (ignoring third-party code from other projects).
Now of course when looking at such things you always have to keep in mind that they may be bad approximations of whatever the truth is. Nonetheless when explicit legal notices like this are contained in source files there is a natural tendency to assume they mean what they say.
Sounds reasonable.
But I also say this because a number of times I've heard it suggested that OpenStack has this deliberate duplicative licensing policy, which seems then to shape the meaning of 'Copyright eNovance, Licensed under the Apache License...'. That's partly why I've brought it up a few times, in the hopes that someone will tell me I'm wrong (or right). I think perhaps in the end this is all a matter of confusion but if so it might be useful to clear it up. Normally, a CLA is a substitute for direct licensing under the outbound project license. So with respect to a given copyright holder, if a CLA hasn't been signed, fine, the license is the outbound license. That's how most ALv2 projects work, after all. If a CLA has been signed, it is nonstandard for the contributor to be additionally granting a separate license under the Apache License. I will admit that at the moment I am confused about what is supposed to be going on in this respect in OpenStack. Maybe this supposition about duplicative licensing is a misunderstanding on my own part.
FWIW, if it's intentional, I've never heard it articulated or defended by anyone. I just had a quick look at Nova and Swift's early history. I've lost my notes, so from memory: - Swift just has Copyright OpenStack LLC or OpenStack Foundation since the beginning, except for one tiny exception - Nova originally was Copyright Anso Labs, then in June 2010 NASA notices were added and in July 2010 the Anso notices were removed. - In July/August 2010, OpenStack LLC, Citrix, FathomDB, etc. notices started appearing gradually So, my guess would be that the Anso guys naturally favoured direct licensing when launching Nova and when Rackspace/OpenStack LLC came on the scene with a CLA it was seen as a natural thing to add to the existing copyright notices. Whether a discussion about removing the copyright notices ever happened when it was decided to add a CLA, I have no idea. But the CLA was there from July 2010: https://web.archive.org/web/20100722183712/http://wiki.openstack.org/HowToCo... I struggle to imagine anyone in July 2010 recognizing what they were doing as "duplicative licensing" and consciously deciding to take that approach over the ASF approach. But maybe someone who was around then can shed more light on it.
I'd agree with Sean that <20% of our contributors understand this distinction (or its practical significance). In fact I'd guess it's approaching 0% :)
The distinction is ultimately minor, but there's something about it that bothers me if it turns out to be in some sense intentional. If there is a desire to have everyone sign a CLA, the project shouldn't have any expectation that CLA signers additionally grant a similar though overall slightly less permissive license. If there is some belief that everyone is granting Apache Licenses, then there shouldn't be any CLA.
I guess my interpretation is that yes, everyone is granting Apache Licenses but we all also grant some additional rights (I don't know what they are exactly) to the foundation (I don't know why exactly). That's a pretty worthless defensive of our CLA regime though :)
Ok, wow - I never understood that most CLA-using projects don't have individual per-file copyright notices.
Yes, this is a key to my whole argument, even if I turn out to be the one who is confused, in which case I apologize for wasting anyone's time. If I'm confused, though, there's a good chance that some others are as well, and as unimportant as this all might be it seems better to have less confusion.
Again to contrast things with ASF projects, I know what's going on there. For a given project, if you regard it as a set of Apache Licenses and a set of CLAs, the 'big' Apache License is granted by the ASF and some 'smaller' Apache Licenses are being granted by minor contributors,
I'm with you until here ... However, I'm still struggling to understand the benefit of the ASF being granted a special license. Why can't it be licensed the code under the Apache License? Or is the benefit of this situation that the vast bulk of code is licensed outbound from a single licensor? Is that a benefit in terms of a perception, or some "single throat to choke" legal benefit? or?
Then you have a bunch of CLA-based licenses that are (nontransparently) granted to everyone, mostly granted by individuals. (You may also have 'software grants' licensed broadly to the ASF for large code donations.)
Say what? :)
I don't have the same certainty about what's happening in OpenStack. But I don't want to exaggerate the importance or significance of this. It's more of an annoyance.
Am I right in saying you're being the dog with the proverbial bone on this because clarifying this could help to undermine the need for our CLA regime? Thanks, Mark.
On Thu, Jan 23, 2014 at 12:38:10PM +0000, Mark McLoughlin wrote:
However, I'm still struggling to understand the benefit of the ASF being granted a special license. Why can't it be licensed the code under the Apache License?
This is an interesting question and in fact the former long-time counsel for the ASF used to say from time to time (while he was still in that role) that the Apache License could well serve as the CLA for ASF or other Apache License projects. The fact that so-called 'drive-by patches' and, as I understand it, many more substantial ones are often handled in this way by ASF projects also demonstrates this. The current legal director of the ASF (who irrelevantly happens also to be a Red Hat employee) has said without elaboration that the benefit is 'belt and suspenders'. One could point to a few subtle differences between the Apache CLA and Apache License 2.0 to make an argument that some benefit exists, but I've argued that those particular sorts of benefits are unlikely to have practical significance.
Or is the benefit of this situation that the vast bulk of code is licensed outbound from a single licensor? Is that a benefit in terms of a perception, or some "single throat to choke" legal benefit? or?
For an Apache License-outbound community project with diverse participants I personally do not see any benefit to this. The 'single throat to choke' (or in this context 'single organization to deal with') can matter -- the OpenStack Foundation fills this role -- but not for reasons having to do with licensing of the code.
Am I right in saying you're being the dog with the proverbial bone on this because clarifying this could help to undermine the need for our CLA regime?
Not really, because frankly my influence on this is limited. What I'm saying might have some educational value to people reading this (I do feel I have a special responsibility to the Red Hat developers reading this to explain this issue). Or that could be wishful thinking. As you know, the bylaws of the OpenStack Foundation unwisely baked the CLA regime into the difficult-to-amend IP policy, unprecedented AFAIK for any open source project-oriented foundation. Red Hat criticized this as an obvious flaw that would cause problems in the future,[1] but as I recall no one outside of Red Hat even saw an issue there. I think you'd need a major crisis or a massive shift in existing sentiment (particularly among lawyers involved in the OpenStack Foundation) to see a change to the CLA regime. That's unlikely. What is likely is more situations like Kevin Fox or the person you spoke with in Hong Kong. - RF [1]A few tweaks were made to the IP Policy as a result of these criticisms, but the basic flaw remains.
On Wed, Jan 22, 2014 at 11:27:28AM +0000, Mark McLoughlin wrote:
I think it's time we stepped back and considered all the angles here - not just "drop the CLA", "delete the copyright notices". What do we (the project) want? What are our values?
I'd suggest:
- We want to be able to distribute OpenStack under the Apache License v2, so: - All code to the project must be contributed under the ALv2 - We can incorporate BSD/MIT licensed code from other projects - We can use LGPL, BSD, MIT, etc. licensed libraries; currently, we're being conservative and not using GPL/AGPL libraries
- There is no need for contributors to grant the foundation a special license.
- We copy the kernel's Signed-off-by/DCO method of having all developers who contribute to a patch state they have the right to contribute the patch under ALv2
- We consolidate all copyright notices into a single "copyright multiple authors" notice above the ALv2 header, making it clear the code is directly licensed by the authors under ALv2 without the foundation acting as an intermediary
This is just a strawman idea to draw some comments. What am I missing?
The one thing is my intuition that the lawyers for several of the corporate members of the OpenStack Foundation, and lawyers for the Foundation itself, would object to adoption of the Linux kernel-style DCO. (Though perhaps mainly due to lack of familiarity with the approach and some belief that the CLA system currently in use is a best practice of some sort.) I myself think an unadulterated DCO method is a fine idea, have said so before and feel confident in saying that that would be Red Hat's official view. As to the issue of handling copyright notices, that sounds fine to me too and that part would address Rich Bowen's concerns. - RF
On 01/22/2014 12:25 PM, Richard Fontana wrote:
This is just a strawman idea to draw some comments. What am I missing? The one thing is my intuition that the lawyers for several of the corporate members of the OpenStack Foundation, and lawyers for the Foundation itself, would object to adoption of the Linux kernel-style DCO. (Though perhaps mainly due to lack of familiarity with the approach and some belief that the CLA system currently in use is a best practice of some sort.) I myself think an unadulterated DCO method is a fine idea, have said so before and feel confident in saying that that would be Red Hat's official view.
As to the issue of handling copyright notices, that sounds fine to me too and that part would address Rich Bowen's concerns. +1
-- Rich Bowen - rbowen@redhat.com OpenStack Community Liaison http://openstack.redhat.com/
On Wed, 2014-01-22 at 12:25 -0500, Richard Fontana wrote:
On Wed, Jan 22, 2014 at 11:27:28AM +0000, Mark McLoughlin wrote:
I think it's time we stepped back and considered all the angles here - not just "drop the CLA", "delete the copyright notices". What do we (the project) want? What are our values?
I'd suggest:
- We want to be able to distribute OpenStack under the Apache License v2, so: - All code to the project must be contributed under the ALv2 - We can incorporate BSD/MIT licensed code from other projects - We can use LGPL, BSD, MIT, etc. licensed libraries; currently, we're being conservative and not using GPL/AGPL libraries
- There is no need for contributors to grant the foundation a special license.
- We copy the kernel's Signed-off-by/DCO method of having all developers who contribute to a patch state they have the right to contribute the patch under ALv2
- We consolidate all copyright notices into a single "copyright multiple authors" notice above the ALv2 header, making it clear the code is directly licensed by the authors under ALv2 without the foundation acting as an intermediary
This is just a strawman idea to draw some comments. What am I missing?
The one thing is my intuition that the lawyers for several of the corporate members of the OpenStack Foundation, and lawyers for the Foundation itself, would object to adoption of the Linux kernel-style DCO. (Though perhaps mainly due to lack of familiarity with the approach and some belief that the CLA system currently in use is a best practice of some sort.) I myself think an unadulterated DCO method is a fine idea, have said so before and feel confident in saying that that would be Red Hat's official view.
I think it's worth having a properly informed discussion involving the Foundation Board and Legal Affairs Committee. To do so, we'd need to pull together some points into a document: - why the CLA process is causing friction - a review of practices adopted by some other large, well known and comparable projects - how OpenStack's process differs from other projects using CLAs, like the ASF - enumerating the perceived benefits and explaining why they are a misconception, not a major benefit or that a similar effect can be achieved differently - a concrete proposal for a change to DCO, including infra changes, education, bylaws amendment, etc. - a FAQ section which anticipates additional concerns people may have I'd take this to the TC first to double-check that there's consensus amongst the contributor community to make a move like this. Unfortunately, there's no quick way to make this happen, but I think if we can get the process moving we should be able to make it happen. Mark.
Hey Along the lines of what I laid out in below email from January, Richard and I completed a first draft of such a document last Friday: https://wiki.openstack.org/wiki/OpenStackAndItsCLA It's a 5000 word document that attempts to capture as much of the nuances of this as we could. No doubt there are many conflicting opinions about this and much discussion is needed ... just as we anticipated in the below email. Please do feel free to react here to any of the points made in the wiki page. Any and all feedback is welcome. We also had a design summit session today where we gathered some feedback from the technical community, particularly about where we're seeing the CLA cause contributor friction or an image problem for the project. See here: https://etherpad.openstack.org/openstack-and-its-cla My interpretation of the session is that there's a good level of consensus amongst the technical project leadership that there are issues and a change to the DCO should be seriously considered. Thanks, Mark. On Thu, 2014-01-23 at 10:55 +0000, Mark McLoughlin wrote:
I think it's worth having a properly informed discussion involving the Foundation Board and Legal Affairs Committee.
To do so, we'd need to pull together some points into a document:
- why the CLA process is causing friction
- a review of practices adopted by some other large, well known and comparable projects
- how OpenStack's process differs from other projects using CLAs, like the ASF
- enumerating the perceived benefits and explaining why they are a misconception, not a major benefit or that a similar effect can be achieved differently
- a concrete proposal for a change to DCO, including infra changes, education, bylaws amendment, etc.
- a FAQ section which anticipates additional concerns people may have
I'd take this to the TC first to double-check that there's consensus amongst the contributor community to make a move like this.
Unfortunately, there's no quick way to make this happen, but I think if we can get the process moving we should be able to make it happen.
Mark.
Mark, The "OpenStack and its Contributor License Agreement" paper that you authored shows a lot of thought, time and effort. I can appreciate the amount of effort you and others have put into investigating this issue. I recognize the need for the paper to be written as a persuasive argument to propose change but there is more that needs to be written for completeness if this is intended as a proposal to the Board. I will leave it to you to determine if that material belongs in this paper or somewhere in addition. I simply know that If we don't write it up, the questions and issues will still come up at the meeting and we will simply chew more time and encounter decision delay. Also to give a little timeline, before putting this on a board meeting agenda I want all the info possible input into a Board packet to be distributed to the Directors 1 week prior to a meeting. I also think that it is important that the information be run through the Legal Affairs Committee for their consideration prior to a Board discussion. Here's some of the info that may need to be added: 1. What is the real world feasibility / effort required to transition from the CLA to a DCO? I'm familiar with the Linux kernel model, the how, why and impetus for implementing the DCO. Any estimates on the size of effort this would entail? For example, does our current repositories have the data needed to give us a clear chain of trust? How would a transition be handled? What effort would be needed to setup the attestation? (include CI, documentation, education, adoption) My sense is that a DCO system is simpler to maintain (as you argue in the paper), but we do need to understand the effort that would be needed to get there with some confidence that OpenStack could actually do it and at what cost - people, time, impact to release, etc. 2. In the section, "Relationship to the Apache License" the paper makes the statement, "...structured to privilege one entity (the OpenStack Foundation itself)...". The paper makes it sound like the Foundation is an evil empire. (Teasing&Smiling). There is a reason the CLA was setup that way and that reasoning needs to be spelled out. (Doesn't mean that it can't change, just makes for a better informed decision.) 3. In "The Need For Change" section, the paper describes the "Contributor Friction". I get the need to make the persuasive argument, but the impact also needs to be explained. There is also a need for a similar section to cover the 'Corporate member / Sponsor Friction'. We have multiple member classes. The proposal should cover all of them, making the persuasive argument as well as describing the impact. The Corporate member section should not only describe the impact to them as a corporate entity, but also the impact to the Foundation in terms of corporate members and sponsors. Next I have an ask and I am not implying that it is happening. I just want you to be sensitive to it, so that it does not inadvertently happen. My ask is that you be the guard against any alienation between any of the governing bodies, advisory boards and members. It's important to understand that each will look at this issue from differing responsibilities and perspectives, sometimes those perspectives can get minimalized. If we keep the groups focused on providing insight in relation to their areas of responsibility and ensure they respect others responsibilities, we'll arrive to the correct conclusion together and the community will be stronger from it. Thanks, AlanClark
On 5/13/2014 at 03:28 PM, Mark McLoughlin <markmc@redhat.com> wrote: Hey
Along the lines of what I laid out in below email from January, Richard and I completed a first draft of such a document last Friday:
https://wiki.openstack.org/wiki/OpenStackAndItsCLA
It's a 5000 word document that attempts to capture as much of the nuances of this as we could.
No doubt there are many conflicting opinions about this and much discussion is needed ... just as we anticipated in the below email.
Please do feel free to react here to any of the points made in the wiki page. Any and all feedback is welcome.
We also had a design summit session today where we gathered some feedback from the technical community, particularly about where we're seeing the CLA cause contributor friction or an image problem for the project. See here:
https://etherpad.openstack.org/openstack-and-its-cla
My interpretation of the session is that there's a good level of consensus amongst the technical project leadership that there are issues and a change to the DCO should be seriously considered.
Thanks, Mark.
On Thu, 2014-01-23 at 10:55 +0000, Mark McLoughlin wrote:
I think it's worth having a properly informed discussion involving the Foundation Board and Legal Affairs Committee.
To do so, we'd need to pull together some points into a document:
- why the CLA process is causing friction
- a review of practices adopted by some other large, well known and comparable projects
- how OpenStack's process differs from other projects using CLAs, like the ASF
- enumerating the perceived benefits and explaining why they are a misconception, not a major benefit or that a similar effect can be achieved differently
- a concrete proposal for a change to DCO, including infra changes, education, bylaws amendment, etc.
- a FAQ section which anticipates additional concerns people may have
I'd take this to the TC first to double-check that there's consensus amongst the contributor community to make a move like this.
Unfortunately, there's no quick way to make this happen, but I think if we can get the process moving we should be able to make it happen.
Mark.
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
Alan, You¹d indicated there was a reason the CLA was structured to privilege the Foundation and suggested that Mark elaborateŠ but I¹m not familiar w/ the background or reasoning - could you expand upon that in advance of Mark amending his treatise? Thanks! Rob Esker NetApp, Inc. On 5/21/14, 5:55 PM, "Alan Clark" <aclark@suse.com> wrote:
Mark,
The "OpenStack and its Contributor License Agreement" paper that you authored shows a lot of thought, time and effort. I can appreciate the amount of effort you and others have put into investigating this issue.
I recognize the need for the paper to be written as a persuasive argument to propose change but there is more that needs to be written for completeness if this is intended as a proposal to the Board. I will leave it to you to determine if that material belongs in this paper or somewhere in addition. I simply know that If we don't write it up, the questions and issues will still come up at the meeting and we will simply chew more time and encounter decision delay. Also to give a little timeline, before putting this on a board meeting agenda I want all the info possible input into a Board packet to be distributed to the Directors 1 week prior to a meeting. I also think that it is important that the information be run through the Legal Affairs Committee for their consideration prior to a Board discussion.
Here's some of the info that may need to be added:
1. What is the real world feasibility / effort required to transition from the CLA to a DCO? I'm familiar with the Linux kernel model, the how, why and impetus for implementing the DCO. Any estimates on the size of effort this would entail? For example, does our current repositories have the data needed to give us a clear chain of trust? How would a transition be handled? What effort would be needed to setup the attestation? (include CI, documentation, education, adoption) My sense is that a DCO system is simpler to maintain (as you argue in the paper), but we do need to understand the effort that would be needed to get there with some confidence that OpenStack could actually do it and at what cost - people, time, impact to release, etc.
2. In the section, "Relationship to the Apache License" the paper makes the statement, "...structured to privilege one entity (the OpenStack Foundation itself)...". The paper makes it sound like the Foundation is an evil empire. (Teasing&Smiling). There is a reason the CLA was setup that way and that reasoning needs to be spelled out. (Doesn't mean that it can't change, just makes for a better informed decision.)
3. In "The Need For Change" section, the paper describes the "Contributor Friction". I get the need to make the persuasive argument, but the impact also needs to be explained. There is also a need for a similar section to cover the 'Corporate member / Sponsor Friction'. We have multiple member classes. The proposal should cover all of them, making the persuasive argument as well as describing the impact. The Corporate member section should not only describe the impact to them as a corporate entity, but also the impact to the Foundation in terms of corporate members and sponsors.
Next I have an ask and I am not implying that it is happening. I just want you to be sensitive to it, so that it does not inadvertently happen. My ask is that you be the guard against any alienation between any of the governing bodies, advisory boards and members. It's important to understand that each will look at this issue from differing responsibilities and perspectives, sometimes those perspectives can get minimalized. If we keep the groups focused on providing insight in relation to their areas of responsibility and ensure they respect others responsibilities, we'll arrive to the correct conclusion together and the community will be stronger from it.
Thanks, AlanClark
On 5/13/2014 at 03:28 PM, Mark McLoughlin <markmc@redhat.com> wrote: Hey
Along the lines of what I laid out in below email from January, Richard and I completed a first draft of such a document last Friday:
https://wiki.openstack.org/wiki/OpenStackAndItsCLA
It's a 5000 word document that attempts to capture as much of the nuances of this as we could.
No doubt there are many conflicting opinions about this and much discussion is needed ... just as we anticipated in the below email.
Please do feel free to react here to any of the points made in the wiki page. Any and all feedback is welcome.
We also had a design summit session today where we gathered some feedback from the technical community, particularly about where we're seeing the CLA cause contributor friction or an image problem for the project. See here:
https://etherpad.openstack.org/openstack-and-its-cla
My interpretation of the session is that there's a good level of consensus amongst the technical project leadership that there are issues and a change to the DCO should be seriously considered.
Thanks, Mark.
On Thu, 2014-01-23 at 10:55 +0000, Mark McLoughlin wrote:
I think it's worth having a properly informed discussion involving the Foundation Board and Legal Affairs Committee.
To do so, we'd need to pull together some points into a document:
- why the CLA process is causing friction
- a review of practices adopted by some other large, well known and comparable projects
- how OpenStack's process differs from other projects using CLAs, like the ASF
- enumerating the perceived benefits and explaining why they are a misconception, not a major benefit or that a similar effect can be achieved differently
- a concrete proposal for a change to DCO, including infra changes, education, bylaws amendment, etc.
- a FAQ section which anticipates additional concerns people may have
I'd take this to the TC first to double-check that there's consensus amongst the contributor community to make a move like this.
Unfortunately, there's no quick way to make this happen, but I think if we can get the process moving we should be able to make it happen.
Mark.
_______________________________________________ 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
The OpenStack Foundation ICLA and CCLA were not written from scratch. The real historical reason for them having the content and structure they have is simply that the Foundation adopted the CLAs that were used by Rackspace with some minor changes. Rackspace for its part had reused the texts of the ICLA and CCLA of the Apache Software Foundation with some minor changes. - Richard On Thu, May 22, 2014 at 01:25:52AM +0000, Esker, Robert wrote:
Alan,
You¹d indicated there was a reason the CLA was structured to privilege the Foundation and suggested that Mark elaborateŠ but I¹m not familiar w/ the background or reasoning - could you expand upon that in advance of Mark amending his treatise?
Thanks!
Rob Esker NetApp, Inc.
On 5/21/14, 5:55 PM, "Alan Clark" <aclark@suse.com> wrote:
Mark,
The "OpenStack and its Contributor License Agreement" paper that you authored shows a lot of thought, time and effort. I can appreciate the amount of effort you and others have put into investigating this issue.
I recognize the need for the paper to be written as a persuasive argument to propose change but there is more that needs to be written for completeness if this is intended as a proposal to the Board. I will leave it to you to determine if that material belongs in this paper or somewhere in addition. I simply know that If we don't write it up, the questions and issues will still come up at the meeting and we will simply chew more time and encounter decision delay. Also to give a little timeline, before putting this on a board meeting agenda I want all the info possible input into a Board packet to be distributed to the Directors 1 week prior to a meeting. I also think that it is important that the information be run through the Legal Affairs Committee for their consideration prior to a Board discussion.
Here's some of the info that may need to be added:
1. What is the real world feasibility / effort required to transition from the CLA to a DCO? I'm familiar with the Linux kernel model, the how, why and impetus for implementing the DCO. Any estimates on the size of effort this would entail? For example, does our current repositories have the data needed to give us a clear chain of trust? How would a transition be handled? What effort would be needed to setup the attestation? (include CI, documentation, education, adoption) My sense is that a DCO system is simpler to maintain (as you argue in the paper), but we do need to understand the effort that would be needed to get there with some confidence that OpenStack could actually do it and at what cost - people, time, impact to release, etc.
2. In the section, "Relationship to the Apache License" the paper makes the statement, "...structured to privilege one entity (the OpenStack Foundation itself)...". The paper makes it sound like the Foundation is an evil empire. (Teasing&Smiling). There is a reason the CLA was setup that way and that reasoning needs to be spelled out. (Doesn't mean that it can't change, just makes for a better informed decision.)
3. In "The Need For Change" section, the paper describes the "Contributor Friction". I get the need to make the persuasive argument, but the impact also needs to be explained. There is also a need for a similar section to cover the 'Corporate member / Sponsor Friction'. We have multiple member classes. The proposal should cover all of them, making the persuasive argument as well as describing the impact. The Corporate member section should not only describe the impact to them as a corporate entity, but also the impact to the Foundation in terms of corporate members and sponsors.
Next I have an ask and I am not implying that it is happening. I just want you to be sensitive to it, so that it does not inadvertently happen. My ask is that you be the guard against any alienation between any of the governing bodies, advisory boards and members. It's important to understand that each will look at this issue from differing responsibilities and perspectives, sometimes those perspectives can get minimalized. If we keep the groups focused on providing insight in relation to their areas of responsibility and ensure they respect others responsibilities, we'll arrive to the correct conclusion together and the community will be stronger from it.
Thanks, AlanClark
On 5/13/2014 at 03:28 PM, Mark McLoughlin <markmc@redhat.com> wrote: Hey
Along the lines of what I laid out in below email from January, Richard and I completed a first draft of such a document last Friday:
https://wiki.openstack.org/wiki/OpenStackAndItsCLA
It's a 5000 word document that attempts to capture as much of the nuances of this as we could.
No doubt there are many conflicting opinions about this and much discussion is needed ... just as we anticipated in the below email.
Please do feel free to react here to any of the points made in the wiki page. Any and all feedback is welcome.
We also had a design summit session today where we gathered some feedback from the technical community, particularly about where we're seeing the CLA cause contributor friction or an image problem for the project. See here:
https://etherpad.openstack.org/openstack-and-its-cla
My interpretation of the session is that there's a good level of consensus amongst the technical project leadership that there are issues and a change to the DCO should be seriously considered.
Thanks, Mark.
On Thu, 2014-01-23 at 10:55 +0000, Mark McLoughlin wrote:
I think it's worth having a properly informed discussion involving the Foundation Board and Legal Affairs Committee.
To do so, we'd need to pull together some points into a document:
- why the CLA process is causing friction
- a review of practices adopted by some other large, well known and comparable projects
- how OpenStack's process differs from other projects using CLAs, like the ASF
- enumerating the perceived benefits and explaining why they are a misconception, not a major benefit or that a similar effect can be achieved differently
- a concrete proposal for a change to DCO, including infra changes, education, bylaws amendment, etc.
- a FAQ section which anticipates additional concerns people may have
I'd take this to the TC first to double-check that there's consensus amongst the contributor community to make a move like this.
Unfortunately, there's no quick way to make this happen, but I think if we can get the process moving we should be able to make it happen.
Mark.
_______________________________________________ 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
I also don't know the full background either, but think that it is worth asking the question. I remember discussions of modeling around Apache, Eclipse and similar organizations, it may also be 'historical'. But even if it was for historical reasons, as the paper points out there must have been some underlying basis such as risk mitigation. So we have 3 1 - historical 2 - modeling from other open source projects 3 - risk Are there others? Historical and modeling are less interesting. For risk, we can argue if risk mitigation is a valid argument, but by listing the reason we can ensure that with or without a CLA risk mitigation gets appropriate coverage. -AlanClark
On 5/21/2014 at 09:16 PM, Richard Fontana <rfontana@redhat.com> wrote: The OpenStack Foundation ICLA and CCLA were not written from scratch. The real historical reason for them having the content and structure they have is simply that the Foundation adopted the CLAs that were used by Rackspace with some minor changes. Rackspace for its part had reused the texts of the ICLA and CCLA of the Apache Software Foundation with some minor changes.
- Richard
On Thu, May 22, 2014 at 01:25:52AM +0000, Esker, Robert wrote:
Alan,
You¹d indicated there was a reason the CLA was structured to privilege the Foundation and suggested that Mark elaborate* but I¹m not familiar w/ the background or reasoning - could you expand upon that in advance of Mark amending his treatise?
Thanks!
Rob Esker NetApp, Inc.
On 5/21/14, 5:55 PM, "Alan Clark" <aclark@suse.com> wrote:
Mark,
The "OpenStack and its Contributor License Agreement" paper that you authored shows a lot of thought, time and effort. I can appreciate the amount of effort you and others have put into investigating this issue.
I recognize the need for the paper to be written as a persuasive argument to propose change but there is more that needs to be written for completeness if this is intended as a proposal to the Board. I will leave it to you to determine if that material belongs in this paper or somewhere in addition. I simply know that If we don't write it up, the questions and issues will still come up at the meeting and we will simply chew more time and encounter decision delay. Also to give a little timeline, before putting this on a board meeting agenda I want all the info possible input into a Board packet to be distributed to the Directors 1 week prior to a meeting. I also think that it is important that the information be run through the Legal Affairs Committee for their consideration prior to a Board discussion.
Here's some of the info that may need to be added:
1. What is the real world feasibility / effort required to transition from the CLA to a DCO? I'm familiar with the Linux kernel model, the how, why and impetus for implementing the DCO. Any estimates on the size of effort this would entail? For example, does our current repositories have the data needed to give us a clear chain of trust? How would a transition be handled? What effort would be needed to setup the attestation? (include CI, documentation, education, adoption) My sense is that a DCO system is simpler to maintain (as you argue in the paper), but we do need to understand the effort that would be needed to get there with some confidence that OpenStack could actually do it and at what cost - people, time, impact to release, etc.
2. In the section, "Relationship to the Apache License" the paper makes the statement, "...structured to privilege one entity (the OpenStack Foundation itself)...". The paper makes it sound like the Foundation is an evil empire. (Teasing&Smiling). There is a reason the CLA was setup that way and that reasoning needs to be spelled out. (Does n't mean that it can't change, just makes for a better informed decision.)
3. In "The Need For Change" section, the paper describes the "Contributor Friction". I get the need to make the persuasive argument, but the impact also needs to be explained. There is also a need for a similar section to cover the 'Corporate member / Sponsor Friction'. We have multiple member classes. The proposal should cover all of them, making the persuasive argument as well as describing the impact. The Corporate member section should not only describe the impact to them as a corporate entity, but also the impact to the Foundation in terms of corporate members and sponsors.
Next I have an ask and I am not implying that it is happening. I just want you to be sensitive to it, so that it does not inadvertently happen. My ask is that you be the guard against any alienation between any of the governing bodies, advisory boards and members. It's important to understand that each will look at this issue from differing responsibilities and perspectives, sometimes those perspectives can get minimalized. If we keep the groups focused on providing insight in relation to their areas of responsibility and ensure they respect others responsibilities, we'll arrive to the correct conclusion together and the community will be stronger from it.
Thanks, AlanClark
On 5/13/2014 at 03:28 PM, Mark McLoughlin <markmc@redhat.com> wrote: Hey
Along the lines of what I laid out in below email from January, Richard and I completed a first draft of such a document last Friday:
https://wiki.openstack.org/wiki/OpenStackAndItsCLA
It's a 5000 word document that attempts to capture as much of the nuances of this as we could.
No doubt there are many conflicting opinions about this and much discussion is needed ... just as we anticipated in the below email.
Please do feel free to react here to any of the points made in the wiki page. Any and all feedback is welcome.
We also had a design summit session today where we gathered some feedback from the technical community, particularly about where we're seeing the CLA cause contributor friction or an image problem for the project. See here:
https://etherpad.openstack.org/openstack-and-its-cla
My interpretation of the session is that there's a good level of consensus amongst the technical project leadership that there are issues and a change to the DCO should be seriously considered.
Thanks, Mark.
On Thu, 2014-01-23 at 10:55 +0000, Mark McLoughlin wrote:
I think it's worth having a properly informed discussion involving the Foundation Board and Legal Affairs Committee.
To do so, we'd need to pull together some points into a document:
- why the CLA process is causing friction
- a review of practices adopted by some other large, well known and comparable projects
- how OpenStack's process differs from other projects using CLAs, like the ASF
- enumerating the perceived benefits and explaining why they are a misconception, not a major benefit or that a similar effect can be achieved differently
- a concrete proposal for a change to DCO, including infra changes, education, bylaws amendment, etc.
- a FAQ section which anticipates additional concerns people may have
I'd take this to the TC first to double-check that there's consensus amongst the contributor community to make a move like this.
Unfortunately, there's no quick way to make this happen, but I think if we can get the process moving we should be able to make it happen.
Mark.
_______________________________________________ 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
I agree with Richard's summary and will provide some additional information. My understanding during the drafting of the bylaws was that the ICLA and CCLA (which are based on standard Apache documents) had been used from the beginning of the project and had become part of the project's culture. Moreover the form of ICLA and CCLA were sufficiently important to the community that the form of CLAs were "locked" into the bylaws by making them exhibits (with some flexibility granted to the Board) and were included among the limited number of sections whose amendment requires a vote of the Board, the Individual Members, the Gold Members and the Platinum Members. We have discussed this issue twice at the Legal Affairs Committee, particularly in the context of so called "trivial contributions". Each time we considered the history of the project, the commitments of the existing participants under the CLAs, our perception of the modest "friction" caused by the requirement to click the CLA and the expectations of existing members about future participants providing rights under the CLA. Both times we concluded that change was not appropriate. The Legal Affairs Committee is ready to work with the community to assist the Board to understand the issues in adopting the DCO procedure for some or all contributions. The ultimate decision belongs to the Board. We should also ensure that we note that the issue of "friction" caused by CLAs may have been misplaced because of confusion about the link between contributors and Individual Members. Until recently the Technical Committee was requiring all individual contributors to become an Individual Members. As I noted in response to that question about a month ago, this condition was a misunderstanding of the bylaws. The bylaws only require that a contributor join if he wants to qualify to vote for the Technical Committee. Anyone can make a contribution if they have signed the CLA. -----Original Message----- From: Alan Clark [mailto:aclark@suse.com] Sent: Thursday, May 22, 2014 1:26 PM To: Robert Esker; Richard Fontana Cc: legal-discuss@lists.openstack.org Subject: Re: [legal-discuss] OpenStack and its CLA [was Re: Copyright statements in source] I also don't know the full background either, but think that it is worth asking the question. I remember discussions of modeling around Apache, Eclipse and similar organizations, it may also be 'historical'. But even if it was for historical reasons, as the paper points out there must have been some underlying basis such as risk mitigation. So we have 3 1 - historical 2 - modeling from other open source projects 3 - risk Are there others? Historical and modeling are less interesting. For risk, we can argue if risk mitigation is a valid argument, but by listing the reason we can ensure that with or without a CLA risk mitigation gets appropriate coverage. -AlanClark
On 5/21/2014 at 09:16 PM, Richard Fontana <rfontana@redhat.com> wrote: The OpenStack Foundation ICLA and CCLA were not written from scratch. The real historical reason for them having the content and structure they have is simply that the Foundation adopted the CLAs that were used by Rackspace with some minor changes. Rackspace for its part had reused the texts of the ICLA and CCLA of the Apache Software Foundation with some minor changes.
- Richard
On Thu, May 22, 2014 at 01:25:52AM +0000, Esker, Robert wrote:
Alan,
You¹d indicated there was a reason the CLA was structured to privilege the Foundation and suggested that Mark elaborate* but I¹m not familiar w/ the background or reasoning - could you expand upon that in advance of Mark amending his treatise?
Thanks!
Rob Esker NetApp, Inc.
On 5/21/14, 5:55 PM, "Alan Clark" <aclark@suse.com> wrote:
Mark,
The "OpenStack and its Contributor License Agreement" paper that you authored shows a lot of thought, time and effort. I can appreciate the amount of effort you and others have put into investigating this issue.
I recognize the need for the paper to be written as a persuasive argument to propose change but there is more that needs to be written for completeness if this is intended as a proposal to the Board. I will leave it to you to determine if that material belongs in this paper or somewhere in addition. I simply know that If we don't write it up, the questions and issues will still come up at the meeting and we will simply chew more time and encounter decision delay. Also to give a little timeline, before putting this on a board meeting agenda I want all the info possible input into a Board packet to be distributed to the Directors 1 week prior to a meeting. I also think that it is important that the information be run through the Legal Affairs Committee for their consideration prior to a Board discussion.
Here's some of the info that may need to be added:
1. What is the real world feasibility / effort required to transition from the CLA to a DCO? I'm familiar with the Linux kernel model, the how, why and impetus for implementing the DCO. Any estimates on the size of effort this would entail? For example, does our current repositories have the data needed to give us a clear chain of trust? How would a transition be handled? What effort would be needed to setup the attestation? (include CI, documentation, education, adoption) My sense is that a DCO system is simpler to maintain (as you argue in the paper), but we do need to understand the effort that would be needed to get there with some confidence that OpenStack could actually do it and at what cost - people, time, impact to release, etc.
2. In the section, "Relationship to the Apache License" the paper makes the statement, "...structured to privilege one entity (the OpenStack Foundation itself)...". The paper makes it sound like the Foundation is an evil empire. (Teasing&Smiling). There is a reason the CLA was setup that way and that reasoning needs to be spelled out. (Does n't mean that it can't change, just makes for a better informed decision.)
3. In "The Need For Change" section, the paper describes the "Contributor Friction". I get the need to make the persuasive argument, but the impact also needs to be explained. There is also a need for a similar section to cover the 'Corporate member / Sponsor Friction'. We have multiple member classes. The proposal should cover all of them, making the persuasive argument as well as describing the impact. The Corporate member section should not only describe the impact to them as a corporate entity, but also the impact to the Foundation in terms of corporate members and sponsors.
Next I have an ask and I am not implying that it is happening. I just want you to be sensitive to it, so that it does not inadvertently happen. My ask is that you be the guard against any alienation between any of the governing bodies, advisory boards and members. It's important to understand that each will look at this issue from differing responsibilities and perspectives, sometimes those perspectives can get minimalized. If we keep the groups focused on providing insight in relation to their areas of responsibility and ensure they respect others responsibilities, we'll arrive to the correct conclusion together and the community will be stronger from it.
Thanks, AlanClark
On 5/13/2014 at 03:28 PM, Mark McLoughlin <markmc@redhat.com> wrote: Hey
Along the lines of what I laid out in below email from January, Richard and I completed a first draft of such a document last Friday:
https://wiki.openstack.org/wiki/OpenStackAndItsCLA
It's a 5000 word document that attempts to capture as much of the nuances of this as we could.
No doubt there are many conflicting opinions about this and much discussion is needed ... just as we anticipated in the below email.
Please do feel free to react here to any of the points made in the wiki page. Any and all feedback is welcome.
We also had a design summit session today where we gathered some feedback from the technical community, particularly about where we're seeing the CLA cause contributor friction or an image problem for the project. See here:
https://etherpad.openstack.org/openstack-and-its-cla
My interpretation of the session is that there's a good level of consensus amongst the technical project leadership that there are issues and a change to the DCO should be seriously considered.
Thanks, Mark.
On Thu, 2014-01-23 at 10:55 +0000, Mark McLoughlin wrote:
I think it's worth having a properly informed discussion involving the Foundation Board and Legal Affairs Committee.
To do so, we'd need to pull together some points into a document:
- why the CLA process is causing friction
- a review of practices adopted by some other large, well known and comparable projects
- how OpenStack's process differs from other projects using CLAs, like the ASF
- enumerating the perceived benefits and explaining why they are a misconception, not a major benefit or that a similar effect can be achieved differently
- a concrete proposal for a change to DCO, including infra changes, education, bylaws amendment, etc.
- a FAQ section which anticipates additional concerns people may have
I'd take this to the TC first to double-check that there's consensus amongst the contributor community to make a move like this.
Unfortunately, there's no quick way to make this happen, but I think if we can get the process moving we should be able to make it happen.
Mark.
_______________________________________________ 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
_______________________________________________ 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 Thu, May 22, 2014 at 11:12 PM, Radcliffe, Mark < Mark.Radcliffe@dlapiper.com> wrote:
I agree with Richard's summary and will provide some additional information. My understanding during the drafting of the bylaws was that the ICLA and CCLA (which are based on standard Apache documents) had been used from the beginning of the project and had become part of the project's culture. Moreover the form of ICLA and CCLA were sufficiently important to the community that the form of CLAs were "locked" into the bylaws by making them exhibits (with some flexibility granted to the Board) and were included among the limited number of sections whose amendment requires a vote of the Board, the Individual Members, the Gold Members and the Platinum Members.
We have discussed this issue twice at the Legal Affairs Committee, particularly in the context of so called "trivial contributions". Each time we considered the history of the project, the commitments of the existing participants under the CLAs, our perception of the modest "friction" caused by the requirement to click the CLA and the expectations of existing members about future participants providing rights under the CLA. Both times we concluded that change was not appropriate. The Legal Affairs Committee is ready to work with the community to assist the Board to understand the issues in adopting the DCO procedure for some or all contributions. The ultimate decision belongs to the Board.
We should also ensure that we note that the issue of "friction" caused by CLAs may have been misplaced because of confusion about the link between contributors and Individual Members. Until recently the Technical Committee was requiring all individual contributors to become an Individual Members. As I noted in response to that question about a month ago, this condition was a misunderstanding of the bylaws. The bylaws only require that a contributor join if he wants to qualify to vote for the Technical Committee. Anyone can make a contribution if they have signed the CLA.
Ah, this aspect is good to uncover, especially for documentation. Does the infra team have a task to decouple the "join the Foundation" steps and identity from the git review required setup steps? Anne
-----Original Message----- From: Alan Clark [mailto:aclark@suse.com] Sent: Thursday, May 22, 2014 1:26 PM To: Robert Esker; Richard Fontana Cc: legal-discuss@lists.openstack.org Subject: Re: [legal-discuss] OpenStack and its CLA [was Re: Copyright statements in source]
I also don't know the full background either, but think that it is worth asking the question. I remember discussions of modeling around Apache, Eclipse and similar organizations, it may also be 'historical'. But even if it was for historical reasons, as the paper points out there must have been some underlying basis such as risk mitigation.
So we have 3 1 - historical 2 - modeling from other open source projects 3 - risk Are there others?
Historical and modeling are less interesting. For risk, we can argue if risk mitigation is a valid argument, but by listing the reason we can ensure that with or without a CLA risk mitigation gets appropriate coverage.
-AlanClark
On 5/21/2014 at 09:16 PM, Richard Fontana <rfontana@redhat.com> wrote: The OpenStack Foundation ICLA and CCLA were not written from scratch. The real historical reason for them having the content and structure they have is simply that the Foundation adopted the CLAs that were used by Rackspace with some minor changes. Rackspace for its part had reused the texts of the ICLA and CCLA of the Apache Software Foundation with some minor changes.
- Richard
Alan,
You¹d indicated there was a reason the CLA was structured to privilege the Foundation and suggested that Mark elaborate* but I¹m not familiar w/ the background or reasoning - could you expand upon that in advance of Mark amending his treatise?
Thanks!
Rob Esker NetApp, Inc.
On 5/21/14, 5:55 PM, "Alan Clark" <aclark@suse.com> wrote:
Mark,
The "OpenStack and its Contributor License Agreement" paper that you authored shows a lot of thought, time and effort. I can appreciate the amount of effort you and others have put into investigating this issue.
I recognize the need for the paper to be written as a persuasive argument to propose change but there is more that needs to be written for completeness if this is intended as a proposal to the Board. I will leave it to you to determine if that material belongs in this paper or somewhere in addition. I simply know that If we don't write it up, the questions and issues will still come up at the meeting and we will simply chew more time and encounter decision delay. Also to give a little timeline, before putting this on a board meeting agenda I want all the info possible input into a Board packet to be distributed to the Directors 1 week prior to a meeting. I also think that it is important that the information be run through the Legal Affairs Committee for their consideration prior to a Board discussion.
Here's some of the info that may need to be added:
1. What is the real world feasibility / effort required to transition from the CLA to a DCO? I'm familiar with the Linux kernel model, the how, why and impetus for implementing the DCO. Any estimates on the size of effort this would entail? For example, does our current repositories have the data needed to give us a clear chain of trust? How would a transition be handled? What effort would be needed to setup the attestation? (include CI, documentation, education, adoption) My sense is that a DCO system is simpler to maintain (as you argue in the paper), but we do need to understand the effort that would be needed to get there with some confidence that OpenStack could actually do it and at what cost - people, time, impact to release, etc.
2. In the section, "Relationship to the Apache License" the paper makes the statement, "...structured to privilege one entity (the OpenStack Foundation itself)...". The paper makes it sound like the Foundation is an evil empire. (Teasing&Smiling). There is a reason the CLA was setup that way and that reasoning needs to be spelled out. (Does n't mean that it can't change, just makes for a better informed decision.)
3. In "The Need For Change" section, the paper describes the "Contributor Friction". I get the need to make the persuasive argument, but the impact also needs to be explained. There is also a need for a similar
to cover the 'Corporate member / Sponsor Friction'. We have multiple member classes. The proposal should cover all of them, making the persuasive argument as well as describing the impact. The Corporate member section should not only describe the impact to them as a corporate entity, but also the impact to the Foundation in terms of corporate members and sponsors.
Next I have an ask and I am not implying that it is happening. I just want you to be sensitive to it, so that it does not inadvertently happen. My ask is that you be the guard against any alienation between any of the governing bodies, advisory boards and members. It's important to understand that each will look at this issue from differing responsibilities and perspectives, sometimes those perspectives can get minimalized. If we keep the groups focused on providing insight in relation to their areas of responsibility and ensure they respect others responsibilities, we'll arrive to the correct conclusion together and the community will be stronger from it.
Thanks, AlanClark
> On 5/13/2014 at 03:28 PM, Mark McLoughlin <markmc@redhat.com> wrote: Hey
Along the lines of what I laid out in below email from January, Richard and I completed a first draft of such a document last Friday:
https://wiki.openstack.org/wiki/OpenStackAndItsCLA
It's a 5000 word document that attempts to capture as much of the nuances of this as we could.
No doubt there are many conflicting opinions about this and much discussion is needed ... just as we anticipated in the below email.
Please do feel free to react here to any of the points made in the wiki page. Any and all feedback is welcome.
We also had a design summit session today where we gathered some feedback from the technical community, particularly about where we're seeing the CLA cause contributor friction or an image problem for the project. See here:
https://etherpad.openstack.org/openstack-and-its-cla
My interpretation of the session is that there's a good level of consensus amongst the technical project leadership that there are issues and a change to the DCO should be seriously considered.
Thanks, Mark.
On Thu, 2014-01-23 at 10:55 +0000, Mark McLoughlin wrote:
I think it's worth having a properly informed discussion involving the Foundation Board and Legal Affairs Committee.
To do so, we'd need to pull together some points into a document:
- why the CLA process is causing friction
- a review of practices adopted by some other large, well known and comparable projects
- how OpenStack's process differs from other projects using CLAs, like the ASF
- enumerating the perceived benefits and explaining why they are a misconception, not a major benefit or that a similar effect can be achieved differently
- a concrete proposal for a change to DCO, including infra changes, education, bylaws amendment, etc.
- a FAQ section which anticipates additional concerns people may have
I'd take this to the TC first to double-check that there's consensus amongst the contributor community to make a move like
On Thu, May 22, 2014 at 01:25:52AM +0000, Esker, Robert wrote: section this.
Unfortunately, there's no quick way to make this happen, but I think if we can get the process moving we should be able
to make it happen.
Mark.
_______________________________________________ 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
_______________________________________________ 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 23/05/14 14:11, Anne Gentle wrote:
On Thu, May 22, 2014 at 11:12 PM, Radcliffe, Mark < Mark.Radcliffe@dlapiper.com> wrote:
I agree with Richard's summary and will provide some additional information. My understanding during the drafting of the bylaws was that the ICLA and CCLA (which are based on standard Apache documents) had been used from the beginning of the project and had become part of the project's culture. Moreover the form of ICLA and CCLA were sufficiently important to the community that the form of CLAs were "locked" into the bylaws by making them exhibits (with some flexibility granted to the Board) and were included among the limited number of sections whose amendment requires a vote of the Board, the Individual Members, the Gold Members and the Platinum Members.
We have discussed this issue twice at the Legal Affairs Committee, particularly in the context of so called "trivial contributions". Each time we considered the history of the project, the commitments of the existing participants under the CLAs, our perception of the modest "friction" caused by the requirement to click the CLA and the expectations of existing members about future participants providing rights under the CLA. Both times we concluded that change was not appropriate. The Legal Affairs Committee is ready to work with the community to assist the Board to understand the issues in adopting the DCO procedure for some or all contributions. The ultimate decision belongs to the Board.
We should also ensure that we note that the issue of "friction" caused by CLAs may have been misplaced because of confusion about the link between contributors and Individual Members. Until recently the Technical Committee was requiring all individual contributors to become an Individual Members. As I noted in response to that question about a month ago, this condition was a misunderstanding of the bylaws. The bylaws only require that a contributor join if he wants to qualify to vote for the Technical Committee. Anyone can make a contribution if they have signed the CLA.
Ah, this aspect is good to uncover, especially for documentation. Does the infra team have a task to decouple the "join the Foundation" steps and identity from the git review required setup steps?
Anne
FYI, I filed a bug about this [1] when we had the previous conversation. The last comment on the bug suggests that because the requirement was added at the Foundation's request, some additional discussion is likely to be required first. Thanks, Julie [1] https://bugs.launchpad.net/openstack-ci/+bug/1311665
On Fri, May 23, 2014 at 12:12 AM, Radcliffe, Mark <Mark.Radcliffe@dlapiper.com> wrote:
I agree with Richard's summary and will provide some additional information. My understanding during the drafting of the bylaws was that the ICLA and CCLA (which are based on standard Apache documents) had been used from the beginning of the project and had become part of the project's culture. Moreover the form of ICLA and CCLA were sufficiently important to the community that the form of CLAs were "locked" into the bylaws by making them exhibits (with some flexibility granted to the Board) and were included among the limited number of sections whose amendment requires a vote of the Board, the Individual Members, the Gold Members and the Platinum Members.
We have discussed this issue twice at the Legal Affairs Committee, particularly in the context of so called "trivial contributions". Each time we considered the history of the project, the commitments of the existing participants under the CLAs, our perception of the modest "friction" caused by the requirement to click the CLA and the expectations of existing members about future participants providing rights under the CLA. Both times we concluded that change was not appropriate. The Legal Affairs Committee is ready to work with the community to assist the Board to understand the issues in adopting the DCO procedure for some or all contributions. The ultimate decision belongs to the Board.
It would be really useful for those of us interested in this discussion but without the benefit of being present for all of the history you refer to here to have some sort of write-up of the analysis the Legal Affairs Committee has done to help us understand the current position. Does something like that exist?
We should also ensure that we note that the issue of "friction" caused by CLAs may have been misplaced because of confusion about the link between contributors and Individual Members. Until recently the Technical Committee was requiring all individual contributors to become an Individual Members. As I noted in response to that question about a month ago, this condition was a misunderstanding of the bylaws. The bylaws only require that a contributor join if he wants to qualify to vote for the Technical Committee. Anyone can make a contribution if they have signed the CLA.
It was my impression from the summit session where we discussed this that we do want to look into separating foundation membership from the signup process to allow contributions, but that doing so isn't as simple as turning it off because of the way the TC and PTL voter roles are extracted from gerrit. That's not an insurmountable problem, just one that will require some thought and effort. That said, have we had any cases where people *could not* contribute because of the membership requirement? Perhaps some *would not* contribute under those terms? We've certainly had people say the requirement was annoying or surprising or both. Still, it doesn't seem like the sort of roadblock that a requirement to sign a binding legal agreement like the ICLA or CCLA presents to some of the potential contributors detailed in https://wiki.openstack.org/wiki/OpenStackAndItsCLA#Contributor_Friction. AFAICT, the two issues both cause friction for new contributors, but are otherwise unrelated. Doug
-----Original Message----- From: Alan Clark [mailto:aclark@suse.com] Sent: Thursday, May 22, 2014 1:26 PM To: Robert Esker; Richard Fontana Cc: legal-discuss@lists.openstack.org Subject: Re: [legal-discuss] OpenStack and its CLA [was Re: Copyright statements in source]
I also don't know the full background either, but think that it is worth asking the question. I remember discussions of modeling around Apache, Eclipse and similar organizations, it may also be 'historical'. But even if it was for historical reasons, as the paper points out there must have been some underlying basis such as risk mitigation.
So we have 3 1 - historical 2 - modeling from other open source projects 3 - risk Are there others?
Historical and modeling are less interesting. For risk, we can argue if risk mitigation is a valid argument, but by listing the reason we can ensure that with or without a CLA risk mitigation gets appropriate coverage.
-AlanClark
On 5/21/2014 at 09:16 PM, Richard Fontana <rfontana@redhat.com> wrote: The OpenStack Foundation ICLA and CCLA were not written from scratch. The real historical reason for them having the content and structure they have is simply that the Foundation adopted the CLAs that were used by Rackspace with some minor changes. Rackspace for its part had reused the texts of the ICLA and CCLA of the Apache Software Foundation with some minor changes.
- Richard
On Thu, May 22, 2014 at 01:25:52AM +0000, Esker, Robert wrote:
Alan,
You¹d indicated there was a reason the CLA was structured to privilege the Foundation and suggested that Mark elaborate* but I¹m not familiar w/ the background or reasoning - could you expand upon that in advance of Mark amending his treatise?
Thanks!
Rob Esker NetApp, Inc.
On 5/21/14, 5:55 PM, "Alan Clark" <aclark@suse.com> wrote:
Mark,
The "OpenStack and its Contributor License Agreement" paper that you authored shows a lot of thought, time and effort. I can appreciate the amount of effort you and others have put into investigating this issue.
I recognize the need for the paper to be written as a persuasive argument to propose change but there is more that needs to be written for completeness if this is intended as a proposal to the Board. I will leave it to you to determine if that material belongs in this paper or somewhere in addition. I simply know that If we don't write it up, the questions and issues will still come up at the meeting and we will simply chew more time and encounter decision delay. Also to give a little timeline, before putting this on a board meeting agenda I want all the info possible input into a Board packet to be distributed to the Directors 1 week prior to a meeting. I also think that it is important that the information be run through the Legal Affairs Committee for their consideration prior to a Board discussion.
Here's some of the info that may need to be added:
1. What is the real world feasibility / effort required to transition from the CLA to a DCO? I'm familiar with the Linux kernel model, the how, why and impetus for implementing the DCO. Any estimates on the size of effort this would entail? For example, does our current repositories have the data needed to give us a clear chain of trust? How would a transition be handled? What effort would be needed to setup the attestation? (include CI, documentation, education, adoption) My sense is that a DCO system is simpler to maintain (as you argue in the paper), but we do need to understand the effort that would be needed to get there with some confidence that OpenStack could actually do it and at what cost - people, time, impact to release, etc.
2. In the section, "Relationship to the Apache License" the paper makes the statement, "...structured to privilege one entity (the OpenStack Foundation itself)...". The paper makes it sound like the Foundation is an evil empire. (Teasing&Smiling). There is a reason the CLA was setup that way and that reasoning needs to be spelled out. (Does n't mean that it can't change, just makes for a better informed decision.)
3. In "The Need For Change" section, the paper describes the "Contributor Friction". I get the need to make the persuasive argument, but the impact also needs to be explained. There is also a need for a similar section to cover the 'Corporate member / Sponsor Friction'. We have multiple member classes. The proposal should cover all of them, making the persuasive argument as well as describing the impact. The Corporate member section should not only describe the impact to them as a corporate entity, but also the impact to the Foundation in terms of corporate members and sponsors.
Next I have an ask and I am not implying that it is happening. I just want you to be sensitive to it, so that it does not inadvertently happen. My ask is that you be the guard against any alienation between any of the governing bodies, advisory boards and members. It's important to understand that each will look at this issue from differing responsibilities and perspectives, sometimes those perspectives can get minimalized. If we keep the groups focused on providing insight in relation to their areas of responsibility and ensure they respect others responsibilities, we'll arrive to the correct conclusion together and the community will be stronger from it.
Thanks, AlanClark
> On 5/13/2014 at 03:28 PM, Mark McLoughlin <markmc@redhat.com> wrote: Hey
Along the lines of what I laid out in below email from January, Richard and I completed a first draft of such a document last Friday:
https://wiki.openstack.org/wiki/OpenStackAndItsCLA
It's a 5000 word document that attempts to capture as much of the nuances of this as we could.
No doubt there are many conflicting opinions about this and much discussion is needed ... just as we anticipated in the below email.
Please do feel free to react here to any of the points made in the wiki page. Any and all feedback is welcome.
We also had a design summit session today where we gathered some feedback from the technical community, particularly about where we're seeing the CLA cause contributor friction or an image problem for the project. See here:
https://etherpad.openstack.org/openstack-and-its-cla
My interpretation of the session is that there's a good level of consensus amongst the technical project leadership that there are issues and a change to the DCO should be seriously considered.
Thanks, Mark.
On Thu, 2014-01-23 at 10:55 +0000, Mark McLoughlin wrote:
I think it's worth having a properly informed discussion involving the Foundation Board and Legal Affairs Committee.
To do so, we'd need to pull together some points into a document:
- why the CLA process is causing friction
- a review of practices adopted by some other large, well known and comparable projects
- how OpenStack's process differs from other projects using CLAs, like the ASF
- enumerating the perceived benefits and explaining why they are a misconception, not a major benefit or that a similar effect can be achieved differently
- a concrete proposal for a change to DCO, including infra changes, education, bylaws amendment, etc.
- a FAQ section which anticipates additional concerns people may have
I'd take this to the TC first to double-check that there's consensus amongst the contributor community to make a move like this.
Unfortunately, there's no quick way to make this happen, but I think if we can get the process moving we should be able to make it happen.
Mark.
_______________________________________________ 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
_______________________________________________ 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 Fri, May 23, 2014 at 09:41:45AM -0400, Doug Hellmann wrote:
On Fri, May 23, 2014 at 12:12 AM, Radcliffe, Mark <Mark.Radcliffe@dlapiper.com> wrote:
We have discussed this issue twice at the Legal Affairs Committee, particularly in the context of so called "trivial contributions". Each time we considered the history of the project, the commitments of the existing participants under the CLAs, our perception of the modest "friction" caused by the requirement to click the CLA and the expectations of existing members about future participants providing rights under the CLA. Both times we concluded that change was not appropriate. The Legal Affairs Committee is ready to work with the community to assist the Board to understand the issues in adopting the DCO procedure for some or all contributions. The ultimate decision belongs to the Board.
It would be really useful for those of us interested in this discussion but without the benefit of being present for all of the history you refer to here to have some sort of write-up of the analysis the Legal Affairs Committee has done to help us understand the current position. Does something like that exist?
No, I would describe this as a couple of informal discussions.
That said, have we had any cases where people *could not* contribute because of the membership requirement? Perhaps some *would not* contribute under those terms? We've certainly had people say the requirement was annoying or surprising or both. Still, it doesn't seem like the sort of roadblock that a requirement to sign a binding legal agreement like the ICLA or CCLA presents to some of the potential contributors detailed in https://wiki.openstack.org/wiki/OpenStackAndItsCLA#Contributor_Friction. AFAICT, the two issues both cause friction for new contributors, but are otherwise unrelated.
Yes, though to join the Foundation as an Individual member you have to enter into a binding agreement as well, so, currently, to become a new OpenStack contributor you have to individually enter into two different legal agreements as well as potentially get someone with signing authority in your company to sign a third agreement. - Richard
I want to correct a potential misunderstanding in the discussion below: any contributor will need to enter into a binding legal agreement in order to ensure that the Foundation has the right to distribute the software. In fact, the DCO is a binding legal document (it incorporates the terms of an unspecified open source license by "reference" to a license in the file) and therefor does not differ from the iCLA or CCLA from that point of view. -----Original Message----- From: Doug Hellmann [mailto:doug.hellmann@dreamhost.com] Sent: Friday, May 23, 2014 6:42 AM To: Radcliffe, Mark Cc: Alan Clark; Robert Esker; Richard Fontana; legal-discuss@lists.openstack.org Subject: Re: [legal-discuss] OpenStack and its CLA [was Re: Copyright statements in source] On Fri, May 23, 2014 at 12:12 AM, Radcliffe, Mark <Mark.Radcliffe@dlapiper.com> wrote:
I agree with Richard's summary and will provide some additional information. My understanding during the drafting of the bylaws was that the ICLA and CCLA (which are based on standard Apache documents) had been used from the beginning of the project and had become part of the project's culture. Moreover the form of ICLA and CCLA were sufficiently important to the community that the form of CLAs were "locked" into the bylaws by making them exhibits (with some flexibility granted to the Board) and were included among the limited number of sections whose amendment requires a vote of the Board, the Individual Members, the Gold Members and the Platinum Members.
We have discussed this issue twice at the Legal Affairs Committee, particularly in the context of so called "trivial contributions". Each time we considered the history of the project, the commitments of the existing participants under the CLAs, our perception of the modest "friction" caused by the requirement to click the CLA and the expectations of existing members about future participants providing rights under the CLA. Both times we concluded that change was not appropriate. The Legal Affairs Committee is ready to work with the community to assist the Board to understand the issues in adopting the DCO procedure for some or all contributions. The ultimate decision belongs to the Board.
It would be really useful for those of us interested in this discussion but without the benefit of being present for all of the history you refer to here to have some sort of write-up of the analysis the Legal Affairs Committee has done to help us understand the current position. Does something like that exist?
We should also ensure that we note that the issue of "friction" caused by CLAs may have been misplaced because of confusion about the link between contributors and Individual Members. Until recently the Technical Committee was requiring all individual contributors to become an Individual Members. As I noted in response to that question about a month ago, this condition was a misunderstanding of the bylaws. The bylaws only require that a contributor join if he wants to qualify to vote for the Technical Committee. Anyone can make a contribution if they have signed the CLA.
It was my impression from the summit session where we discussed this that we do want to look into separating foundation membership from the signup process to allow contributions, but that doing so isn't as simple as turning it off because of the way the TC and PTL voter roles are extracted from gerrit. That's not an insurmountable problem, just one that will require some thought and effort. That said, have we had any cases where people *could not* contribute because of the membership requirement? Perhaps some *would not* contribute under those terms? We've certainly had people say the requirement was annoying or surprising or both. Still, it doesn't seem like the sort of roadblock that a requirement to sign a binding legal agreement like the ICLA or CCLA presents to some of the potential contributors detailed in https://wiki.openstack.org/wiki/OpenStackAndItsCLA#Contributor_Friction. AFAICT, the two issues both cause friction for new contributors, but are otherwise unrelated. Doug
-----Original Message----- From: Alan Clark [mailto:aclark@suse.com] Sent: Thursday, May 22, 2014 1:26 PM To: Robert Esker; Richard Fontana Cc: legal-discuss@lists.openstack.org Subject: Re: [legal-discuss] OpenStack and its CLA [was Re: Copyright statements in source]
I also don't know the full background either, but think that it is worth asking the question. I remember discussions of modeling around Apache, Eclipse and similar organizations, it may also be 'historical'. But even if it was for historical reasons, as the paper points out there must have been some underlying basis such as risk mitigation.
So we have 3 1 - historical 2 - modeling from other open source projects 3 - risk Are there others?
Historical and modeling are less interesting. For risk, we can argue if risk mitigation is a valid argument, but by listing the reason we can ensure that with or without a CLA risk mitigation gets appropriate coverage.
-AlanClark
On 5/21/2014 at 09:16 PM, Richard Fontana <rfontana@redhat.com> wrote: The OpenStack Foundation ICLA and CCLA were not written from scratch. The real historical reason for them having the content and structure they have is simply that the Foundation adopted the CLAs that were used by Rackspace with some minor changes. Rackspace for its part had reused the texts of the ICLA and CCLA of the Apache Software Foundation with some minor changes.
- Richard
On Thu, May 22, 2014 at 01:25:52AM +0000, Esker, Robert wrote:
Alan,
You¹d indicated there was a reason the CLA was structured to privilege the Foundation and suggested that Mark elaborate* but I¹m not familiar w/ the background or reasoning - could you expand upon that in advance of Mark amending his treatise?
Thanks!
Rob Esker NetApp, Inc.
On 5/21/14, 5:55 PM, "Alan Clark" <aclark@suse.com> wrote:
Mark,
The "OpenStack and its Contributor License Agreement" paper that you authored shows a lot of thought, time and effort. I can appreciate the amount of effort you and others have put into investigating this issue.
I recognize the need for the paper to be written as a persuasive argument to propose change but there is more that needs to be written for completeness if this is intended as a proposal to the Board. I will leave it to you to determine if that material belongs in this paper or somewhere in addition. I simply know that If we don't write it up, the questions and issues will still come up at the meeting and we will simply chew more time and encounter decision delay. Also to give a little timeline, before putting this on a board meeting agenda I want all the info possible input into a Board packet to be distributed to the Directors 1 week prior to a meeting. I also think that it is important that the information be run through the Legal Affairs Committee for their consideration prior to a Board discussion.
Here's some of the info that may need to be added:
1. What is the real world feasibility / effort required to transition from the CLA to a DCO? I'm familiar with the Linux kernel model, the how, why and impetus for implementing the DCO. Any estimates on the size of effort this would entail? For example, does our current repositories have the data needed to give us a clear chain of trust? How would a transition be handled? What effort would be needed to setup the attestation? (include CI, documentation, education, adoption) My sense is that a DCO system is simpler to maintain (as you argue in the paper), but we do need to understand the effort that would be needed to get there with some confidence that OpenStack could actually do it and at what cost - people, time, impact to release, etc.
2. In the section, "Relationship to the Apache License" the paper makes the statement, "...structured to privilege one entity (the OpenStack Foundation itself)...". The paper makes it sound like the Foundation is an evil empire. (Teasing&Smiling). There is a reason the CLA was setup that way and that reasoning needs to be spelled out. (Does n't mean that it can't change, just makes for a better informed decision.)
3. In "The Need For Change" section, the paper describes the "Contributor Friction". I get the need to make the persuasive argument, but the impact also needs to be explained. There is also a need for a similar section to cover the 'Corporate member / Sponsor Friction'. We have multiple member classes. The proposal should cover all of them, making the persuasive argument as well as describing the impact. The Corporate member section should not only describe the impact to them as a corporate entity, but also the impact to the Foundation in terms of corporate members and sponsors.
Next I have an ask and I am not implying that it is happening. I just want you to be sensitive to it, so that it does not inadvertently happen. My ask is that you be the guard against any alienation between any of the governing bodies, advisory boards and members. It's important to understand that each will look at this issue from differing responsibilities and perspectives, sometimes those perspectives can get minimalized. If we keep the groups focused on providing insight in relation to their areas of responsibility and ensure they respect others responsibilities, we'll arrive to the correct conclusion together and the community will be stronger from it.
Thanks, AlanClark
> On 5/13/2014 at 03:28 PM, Mark McLoughlin <markmc@redhat.com> wrote: Hey
Along the lines of what I laid out in below email from January, Richard and I completed a first draft of such a document last Friday:
https://wiki.openstack.org/wiki/OpenStackAndItsCLA
It's a 5000 word document that attempts to capture as much of the nuances of this as we could.
No doubt there are many conflicting opinions about this and much discussion is needed ... just as we anticipated in the below email.
Please do feel free to react here to any of the points made in the wiki page. Any and all feedback is welcome.
We also had a design summit session today where we gathered some feedback from the technical community, particularly about where we're seeing the CLA cause contributor friction or an image problem for the project. See here:
https://etherpad.openstack.org/openstack-and-its-cla
My interpretation of the session is that there's a good level of consensus amongst the technical project leadership that there are issues and a change to the DCO should be seriously considered.
Thanks, Mark.
On Thu, 2014-01-23 at 10:55 +0000, Mark McLoughlin wrote:
I think it's worth having a properly informed discussion involving the Foundation Board and Legal Affairs Committee.
To do so, we'd need to pull together some points into a document:
- why the CLA process is causing friction
- a review of practices adopted by some other large, well known and comparable projects
- how OpenStack's process differs from other projects using CLAs, like the ASF
- enumerating the perceived benefits and explaining why they are a misconception, not a major benefit or that a similar effect can be achieved differently
- a concrete proposal for a change to DCO, including infra changes, education, bylaws amendment, etc.
- a FAQ section which anticipates additional concerns people may have
I'd take this to the TC first to double-check that there's consensus amongst the contributor community to make a move like this.
Unfortunately, there's no quick way to make this happen, but I think if we can get the process moving we should be able to make it happen.
Mark.
_______________________________________________ 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
_______________________________________________ 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 Fri, 2014-05-23 at 04:12 +0000, Radcliffe, Mark wrote:
We should also ensure that we note that the issue of "friction" caused by CLAs may have been misplaced because of confusion about the link between contributors and Individual Members. Until recently the Technical Committee was requiring all individual contributors to become an Individual Members. As I noted in response to that question about a month ago, this condition was a misunderstanding of the bylaws. The bylaws only require that a contributor join if he wants to qualify to vote for the Technical Committee. Anyone can make a contribution if they have signed the CLA.
Thanks, and yes I think this is pretty well understood now. Some work remains to actually remove the requirement to be a member of the foundation in order to contribute, but I think everyone is in agreement that it should happen. FWIW, I expect the infra team are unlikely to make these changes in the short term because the change would automatically happen as part of a switch to the DCO, whereas trying to implement the change with our current CLA system would actually require a bunch of additional work. That said, the requirement to become an individual member is only one small element of the contributor friction described in the wiki page. Indeed, we deliberately barely mentioned it since we understand it's only related to the CLA friction for historical reasons. Mark.
On Thu 12 Jun 2014 08:04:48 AM PDT, Mark McLoughlin wrote:
FWIW, I expect the infra team are unlikely to make these changes in the short term because the change would automatically happen as part of a switch to the DCO, whereas trying to implement the change with our current CLA system would actually require a bunch of additional work.
Just to clarify, removing the committer == foundation's individual member is not simply a gerrit issue and I think requires deeper thoughts. We have a couple of other processes that are built around that assumption and changing those will require changes, whether we switch to DCO or not. Voting for PTL and TC elections are examples of such processes. Another thing that may be impacted by the removal of constraint are the free invitations to Design Summits, currently sent to 'ATCs' (defined in 3.b.i http://www.openstack.org/legal/technical-committee-member-policy/).
On 06/12/2014 11:46 AM, Stefano Maffulli wrote:
On Thu 12 Jun 2014 08:04:48 AM PDT, Mark McLoughlin wrote:
FWIW, I expect the infra team are unlikely to make these changes in the short term because the change would automatically happen as part of a switch to the DCO, whereas trying to implement the change with our current CLA system would actually require a bunch of additional work.
Just to clarify, removing the committer == foundation's individual member is not simply a gerrit issue and I think requires deeper thoughts. We have a couple of other processes that are built around that assumption and changing those will require changes, whether we switch to DCO or not. Voting for PTL and TC elections are examples of such processes. Another thing that may be impacted by the removal of constraint are the free invitations to Design Summits, currently sent to 'ATCs' (defined in 3.b.i http://www.openstack.org/legal/technical-committee-member-policy/).
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
One of the issues the TC is currently trying to address is a decrease in voter turnout for the TC elections [0]. If Foundation Membership is not required to contribute to the code base, then I feel that membership and the benefits of membership (ATC status and what that means) should be a well communicated opt-in process rather than a requirement of submitting a patch. Thank you, Anita. [0] Item 3: Election Stats and Review Discussion: http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-06-03-20.03.html
Hi Alan, Thanks for the thoughtful response, and apologies for the slowness of my response. Just catching up now. On Wed, 2014-05-21 at 16:55 -0600, Alan Clark wrote:
Mark,
The "OpenStack and its Contributor License Agreement" paper that you authored shows a lot of thought, time and effort. I can appreciate the amount of effort you and others have put into investigating this issue.
I recognize the need for the paper to be written as a persuasive argument to propose change but there is more that needs to be written for completeness if this is intended as a proposal to the Board. I will leave it to you to determine if that material belongs in this paper or somewhere in addition. I simply know that If we don't write it up, the questions and issues will still come up at the meeting and we will simply chew more time and encounter decision delay.
I'm happy to try and capture any relevant information in the wiki page. That was the intent all along - do our very best to capture as much as possible, then invite others to fill in any gaps. We've also tried to be even handed in our analysis, but it's pretty clear we've come to a pretty strong conclusion. I'd imagine it would be a pretty futile effort to capture other strong conclusions in the opposite direction and debate the nuances of every point within the same wiki page, so I'm totally happy for there to be separate writeups of any opposing viewpoints.
Also to give a little timeline, before putting this on a board meeting agenda I want all the info possible input into a Board packet to be distributed to the Directors 1 week prior to a meeting. I also think that it is important that the information be run through the Legal Affairs Committee for their consideration prior to a Board discussion.
Sounds good. I would like us to figure out some way for the input from the Legal Affairs Committee to be shared openly, though. There's now a lot of people interested in any nuanced discussion on this topic.
Here's some of the info that may need to be added:
1. What is the real world feasibility / effort required to transition from the CLA to a DCO? I'm familiar with the Linux kernel model, the how, why and impetus for implementing the DCO. Any estimates on the size of effort this would entail? For example, does our current repositories have the data needed to give us a clear chain of trust? How would a transition be handled? What effort would be needed to setup the attestation? (include CI, documentation, education, adoption) My sense is that a DCO system is simpler to maintain (as you argue in the paper), but we do need to understand the effort that would be needed to get there with some confidence that OpenStack could actually do it and at what cost - people, time, impact to release, etc.
Cool. Happy to do that, and it was obviously something we were going to have to dig into sooner or later. We didn't spend much time on it in advance, though, because the implementation details here are pretty straightforward.
2. In the section, "Relationship to the Apache License" the paper makes the statement, "...structured to privilege one entity (the OpenStack Foundation itself)...". The paper makes it sound like the Foundation is an evil empire. (Teasing&Smiling).
The full sentence is: https://wiki.openstack.org/wiki/OpenStackAndItsCLA#Relationship_to_the_Apach... The OpenStack CLAs are contracts that are structured to privilege one entity (the OpenStack Foundation itself), whereas the Apache License is a typical open source license in that it is granted to the general public. I really don't think we're painting the Foundation as evil, but the simple fact of this being an asymmetric arrangement is concerning to some. And it's important to recognize that way the Foundation's governance is dominated by paying sponsors means some assume the Foundation is (or will be in the future) evil. That's also covered by this section: https://wiki.openstack.org/wiki/OpenStackAndItsCLA#Developer_Recruitment_and...
There is a reason the CLA was setup that way and that reasoning needs to be spelled out. (Doesn't mean that it can't change, just makes for a better informed decision.)
The reason the CLA was setup this way is covered by: https://wiki.openstack.org/wiki/OpenStackAndItsCLA#History We're obviously interested to hear about angles which aren't already covered there.
3. In "The Need For Change" section, the paper describes the "Contributor Friction". I get the need to make the persuasive argument, but the impact also needs to be explained.
Hmm, we try hard to describe that impact: https://wiki.openstack.org/wiki/OpenStackAndItsCLA#Contributor_Friction There have been a number of concrete examples of the impact of the CLA requirement publically raised recently: There were some other anecdotes offered during the design summit session that I have yet to capture in this section.
There is also a need for a similar section to cover the 'Corporate member / Sponsor Friction'. We have multiple member classes. The proposal should cover all of them, making the persuasive argument as well as describing the impact. The Corporate member section should not only describe the impact to them as a corporate entity, but also the impact to the Foundation in terms of corporate members and sponsors.
I think we cover cases of contributor friction describing friction caused by both the CCLA and ICLA, so I think this covers some of the impact you're talking about here - i.e. the CCLA can hinder some corporate members from contributing while they get legal clearance for the agreement. But I think you're looking for something more here - a description of the positive impact that the CLA has by creating the impression of "legal hygiene" - i.e. something similar to: http://www.eclipse.org/org/#IP%20Management The Eclipse Foundation also undertakes a number of steps to attempt to ensure the pedigree of the intellectual property contained within Eclipse projects. Sure we can add that, but bear in mind we're also saying that such arguments don't make sense given the context: https://wiki.openstack.org/wiki/OpenStackAndItsCLA#CLA_Use_Outside_of_OpenSt... The vast majority of the projects that provide the code used as library and system dependencies of all OpenStack projects do not use any sort of CLA. This is particularly important when you consider that only a tiny proportion of code in a typical OpenStack deployment is actually code that can be said to originate (as Apache License 2.0 code) from the OpenStack Foundation, or at least from the collective body of OpenStack developers.
Next I have an ask and I am not implying that it is happening. I just want you to be sensitive to it, so that it does not inadvertently happen. My ask is that you be the guard against any alienation between any of the governing bodies, advisory boards and members. It's important to understand that each will look at this issue from differing responsibilities and perspectives, sometimes those perspectives can get minimalized. If we keep the groups focused on providing insight in relation to their areas of responsibility and ensure they respect others responsibilities, we'll arrive to the correct conclusion together and the community will be stronger from it.
Absolutely. What you're talking about is building and maintaining trust between all parties involved in this process. IMHO that is best achieved by regular and open communication. I'm very keen to see all input captured in a way that is visible to everyone interested. The body of input on this is building. The wiki page, slides, etherpad from the design summit: https://wiki.openstack.org/wiki/OpenStackAndItsCLA https://docs.google.com/presentation/d/1_7rbUpz6NPWLnVMLXEr-msKsR-NUyy9vksHo... https://etherpad.openstack.org/p/openstack-and-its-cla and the archives of this mailing list. I'll make my usual effort to summarize any board discussions on the topic. Any TC discussions will be automatically archived and minuted. The main discussion forum where we're not capturing the discussions is the Legal Affairs Committee. I'd love to see one of the attendees of those meetings send a brief summary of the discussion to this list. Thanks, Mark.
On 05/13/2014 02:28 PM, Mark McLoughlin wrote:
Along the lines of what I laid out in below email from January, Richard and I completed a first draft of such a document last Friday:
One thing still not clear to me is how legal risks change when an individual signs the Individual CLA but the corporation the person is working for doesn't sign the corresponding Corporate CLA. As you may know, we automatically enforce that any committer signs the Individual CLA but at the moment we have no way to automatically enforce a Corporate CLA on top of that. The Corporate CLA is now completed based on 'best effort': the Foundation makes sure that any company approaching us personally is informed about the Corporate CLA, we have it documented and all. What is the current legal risk for iCLA signed without a CCLA (when it should be signed) and how would this situation "iCLA without CCLA" would change with DCO? /stef
participants (15)
-
Alan Clark
-
Anita Kuno
-
Anne Gentle
-
Doug Hellmann
-
Esker, Robert
-
Julie Pichon
-
Luis Villa
-
Mark McLoughlin
-
Radcliffe, Mark
-
Rich Bowen
-
Richard Fontana
-
Sean Dague
-
Stefano Maffulli
-
Thierry Carrez
-
Vishvananda Ishaya