OpenStack and its Contributor License Agreement
Or, if there was ever a license for which CLAs were unnecessary it's the Apache License.
Note: This is some background material prepared by markmc and rfontana which will form the basis for a Juno Design Summit session on the topic.
- 1 OpenStack and its Contributor License Agreement
- 1.1 Introduction
- 1.2 Background
- 1.3 The Need For Change
- 1.4 The Proposal
Since the earliest days of the OpenStack project, contributors have been required to sign an Individual Contributor License Agreement (ICLA) - and, where appropriate, that their employer should sign the Corporate Contributor License Agreement (CCLA) - in order to contribute to the project.
Initially, this may have seemed a natural approach to take given that the projects managed by the Apache Software Foundation use Individual and Corporate CLAs on which the OpenStack CLAs are textually based. In more recent times, the CLA regime has been seen to cause friction for some contributors while we can also observe somewhat of a shift away from CLAs in open-source projects. The time has come for OpenStack to take a step back and examine whether our CLA regime would benefit from a change.
The CLA has been used the project since its launch in July 2010. There does not appear to be a public archive of the discussions which led to choosing this approach.
The intent of the CLA requirement has never been fully articulated. Rather, it seems to either be taken for granted that it is a good requirement to have, or else various post hoc justifications for the requirement have been made by people who were not involved in the original Rackspace decision to impose the requirement. Rick Clark provided one justification from his perspective of having been involved in the initial decision:
- First of all, orthogonally, we are very lucky to not have Copyright Assignment crushing this project. That is what the management at Rackspace wanted, only NASA's inability to sign such a document prevented it.
- IANAL, but I was told by lawyers when we were in the planning stages of starting Openstack, that while in the US submitting code under the Apache License 2.0 was enough to bind the submitter to it, that is not the case in all countries. Some countries require explicit acceptance to be bound to it.
Some of the post hoc justifications made for the CLA requirement, as far as they have been articulated, are as follows:
- The Apache License 2.0 does not properly work other than in conjunction with a CLA. That is, the outbound license grants in the Apache License are ineffective without CLA signature at the contributor level. This is despite the fact that most Apache License 2.0 projects do not use CLAs or (as in the case of the ASF) use them less rigorously than the OpenStack Foundation.
- The CLA requirement is a "belt and suspenders" mechanism which in some way reinforces the outbound license grants associated with the Apache License 2.0, even if it is not strictly necessary given the operation of the latter license. The argument seems to be that maybe it's not really needed, but it does no harm to have the redundancy.
- The CLA requirement is thought specifically to add a layer of patent licensing despite the argument that effectively duplicative patent licenses are provided for under the Apache License 2.0 itself. This argument is closely related to the previous 2, and suggests that the argument for the CLA is bound up more with patent licensing than with copyright licensing.
- Certain lawyers closely associated with OpenStack appear to be believe there is a material difference between the patent license grants in the CLA and the Apache License 2.0.
- The CLA requirement is thought to improve the project's legal "hygiene" (or appearance thereof) in some amorphous way.
- The CLA requirement provides some form of "protection" for OpenStack of a sort that is never described in detail but is assumed to exist.
 - While the Apache Software Foundation's use of CLAs may have been the direct inspiration for the use of the ASF-derived CLAs for OpenStack, there is reason to believe that the current administration of the CLA regime by the OpenStack Foundation is more restrictive than the actual practice by ASF projects. In particular 1) the ASF apparently gives individual project leads substantial discretion over how rigorously to apply their CLA requirement and the CLA requirement is not centrally administered, 2) it is fairly clear that normally CCLAs are not expected to be signed and, 3) it appears that many ASF projects only require committers to sign the ICLA, and do not request CLAs from non-committers who contribute patches.
Relationship to the Apache License
There appears to be some confusion surrounding the relationship between the CLAs and the Apache License. This is somewhat understandable because both the CLAs and the Apache License involve someone granting very broad copyright license grants as well as patent license grants terminable in some cases of initiation of litigation. These license grants are similarly worded in the CLAs and the Apache License. This similarity is the result of a common author or set of authors having written the Apache License 2.0 and the ASF CLAs -- this is generally assumed to have been Roy Fielding working with the assistance of one or more lawyers at IBM.
However, there are substantive differences between the OpenStack CLAs and the Apache License 2.0. The OpenStack CLAs are license grants that effectively 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. There are certain conditions in the Apache License (placed on the person receiving the license) that are not contained in the CLA, notably requirements to preserve attribution and upstream indemnification provisions. There are certain obligations in the CLAs (placed on the individual or organization signing the CLA) that have no counterpart in the Apache License, notably the making of certain representations and warranties. What this means is that the OpenStack CLAs involve OpenStack contributors giving the Foundation a more generous license than the Foundation in turn gives everyone else, and OpenStack contributors taking on legal burdens that the Foundation itself does not take on.
"Contributions" and the Apache License
The Apache License 2.0 actually contains an explicit license condition that says, in effect, that patches submitted to the upstream project are by default to be licensed under the same terms that the contributor received the project code under -- namely the Apache License 2.0.
- 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. [...]
Even ignoring all the other points made above, if there was ever a license for which CLAs were unnecessary it's the Apache License. It has a built-in CLA, one might say. We understand that the ASF explicitly relies on section 5 as a justification for why it does not (as a matter of general policy) ask non-committers to sign CLAs. The existence of section 5 of the Apache License is proof that the Apache License is intended to be usable without CLAs. Indeed, within the ASF, the CLA requirement is described as a "belt-n-suspenders" requirement.
While section 5 is structured as a license condition, it merely formalizes a rule that applies implicitly in the vast majority of open source projects, namely that all code being contributed to the project is (in the absence of a contributor agreement providing otherwise) understood to be under the license of the project.
OpenStack's practice of adding copyright headers to source files suggests that contributors are licensing the code directly under ALv2 despite the fact that they have already licensed their contributions to the OpenStack Foundation under the CLA. This approach was also in use by the project since its earliest days:
- Swift had 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.
This situation is actually highly unusual and quite different from the Apache Foundation's approach. It gives rise to what is apparently an unintended appearance of duplicative licensing, though (for the same reason) it raises questions about why CLAs are required if contributors appear to be directly licensing code under the Apache License. The answer seems to be that contributors are not directly licensing code under the Apache License, but then legal status of licenses is not clear to users of OpenStack code.
The issue here is, essentially: do all the Apache Licenses embodied in OpenStack projects in some sense come from the Foundation, or from contributors (in which case we have double/triple licensing going on), or both? An argument could be made that this is not an important issue, yet it ought to be clear.
CLA Use Outside of OpenStack
Most open source projects do not use CLAs or the similar mechanism of copyright assignment. CLAs do not appear to have been used before Roy Fielding and his colleagues at IBM crafted the CLAs used by the Apache Software Foundation in the early 2000s. From about 2005 to the present CLAs came to be used by many open source projects or pseudo-projects controlled by a single corporation. Some such CLAs were modeled closely on those of the ASF, though often with at least minor changes that benefitted the controlling corporate entity. In some cases, single-corporation-controlled projects used CLA far more restrictive than the ASF's CLAs. Rackspace's decision to use ASF-style CLAs must be understood in this historical context, given Rackspace's stewardship and control of OpenStack prior to the formation of the OpenStack Foundation.
There are thus countless examples of projects that do not use CLAs. Projects that do use CLAs are the oddity. The most important example of a project not using CLAs, because of its community and commercial significance, is the Linux kernel project itself, which began using the Developer Certificate of Origin (DCO) around 2004 (13 or so years after the project got started). We can safely assume that 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 a tiny proportion of code in a typical OpenStack deployment is actually licensed licensed by the OpenStack Foundation. What makes the OpenStack code itself so special that it requires a CLA regime such as this?
The Need For Change
While an argument can be made that OpenStack's CLA regime is unnecessary or overly strict, any change to the regime will require a significant amount of work to make it happen. Such an investment of effort must be justified in terms of benefits to the project and its community.
OpenStack places huge value in its ability to attract new contributors and has been extremely successful in doing so. However, we are increasingly concerned with the ability of OpenStack operators to give feedback to the project and influence its direction. One form this feedback can take is patches to code, docs or deployment tools. Any barrier or friction we introduce to our contribution process necessarily harms our goal of increasing operator feedback.
Note that this issue isn't limited to the integrated projects like Nova, Swift, etc. Contributors to our documentation, project infrastructure, QE tools, developer tools and deployment tools must also sign the CLA. Indeed, over 90% of the projects on stackforge (including projects like Puppet and Chef recipes for OpenStack) also require contributors to agree to the CLA.
It's very easy for those who have never contributed to the project or those who have long been involved with the project to underestimate the significance of the CLA hurdle for new contributors. Once you have become familiar enough with OpenStack and its development process, found a way to contribute, you're ready to submit your contribution to gerrit. But wait! What's this CLA thing about?
- You first need to join the OpenStack Foundation - presumably you take some time to understand what the Foundation is, what the responsibilities of an Individual Member is and are then ok with joining this organization
- Unless you're a US Government employee, you agree to the ICLA in gerrit and supply a bunch of contact information - presumably you take the time to understand the license you are granting to the Foundation, how it is a more permissive license than the Apache License and how you are taking on additional obligations over those in the Apache License. This process is error prone enough that we have a FAQ to cover cases where people sign the wrong CLA, or get their Foundation membership profile and gerrit out of sync, or where they need to submit more contact information in gerrit, or where they have concerns about submitting contact information.
- If you are a US Government employee, you should not sign the ICLA and instead ensure that someone within your agency with the authority to sign the Government CLA does so.
- If you are contributing on behalf of a company, you should sign the ICLA but additionally you should ensure that someone within your company with the authority to sign the CCLA does so and also adds your details to the list of authorized contributors maintained by the Foundation.
There have been a number of concrete examples of the impact of the CLA requirement publically raised recently:
- The infamous "Kevin Fox case". Kevin's employer (PNNL) is a US Government agency and they took issue with the terms of the CLA. In February 2014, the Foundation took a final decision not to make special concessions to PNNL meaning that Kevin's contributions could not be accepted.
- A trivial, one-line contribution to Horizon. The contributor (Ian Kumlien) was asked to submit via gerrit and responded with:
- Since i don't know what affiliation etc i have to have to actually join openstack...
- I can't do this on a company level...
- My contribution will have to be pushed by someone else, I grant whom ever the right according to the Contributor agreement.
- Our initial response was:
- Why can't they sign the CLA? IBM and HP are very sensitive to their IP and they have signed it.
- A patch adding 5 lines to python-keystoneclient from Bo Tang. Luckily the contributor submitted the patch via gerrit the following day. The Keystone PTL raised concerns about what to do if the contributor does not submit via gerrit.
- Alex Conrad documents his experience making his first contribution to OpenStack. Steps 9-16 out of the 27 steps are about signing the CLA.
While this may appear to be a reasonably limited number of cases, they are significant and most likely represent a larger number of cases where new contributors silently walk away from the project or are left with a bad first impression even if they do get through the process.
To re-state unambigously the "friction" we see here:
- A legalistic, bureacratic requirement as one of the first steps involved with contributing to the project.
- Having your employer sign a license agreement with an organization as a very real stumbling block for some
- The inability to submit trivial patches to the project simply by attaching them to a bug report
- The requirement that you personally enter into an asymmetric licensing agreement with an organization that you may not yet trust
- The bizarre requirement to become a member of a non-profit organization in order to contribute
 - This requirement for contributors to join the Foundation is fairly bizarre in itself and deserves to be dealt with separately. In essence, the Foundation bylaws require that in order for contributors to be elligible to vote in TC and PTL elections, they must also be Foundation members. We either need to change this requirement or a way to identify contributors who aren't Foundation members so they can be ellided from the voter manifest for these elections.
The CLA regime we have in place comes with an organizational cost.
Firstly, the OpenStack Infrastructure team have had to put a significant amount of effort into integrating gerrit's CLA support with the OpenStack Foundation member database. While this work is now complete, the system needs to continue to be maintained, tested and re-integrated with new versions of Gerrit. Also, any proposals to evolve the CLA regime should not underestimate the work that would be required by this team to implement those changes. Suffice to say that the infra team members in question are not excited about this.
Secondly, the CCLA requires a list of "approved contributors" to be maintained by the Foundation. It's not clear how actively this is maintained but, in theory, most new contributors would require the Foundation to process a request to change this list from their employer.
There are two basic conceptual elements of the CLA that are beneficial to the project - that contributors explicitly state they have the right to make their contributions and that they are intentionally making their contribution under terms compatible with the project's license.
Increasingly open-source projects are adopting the Developer Certificate of Origin (DCO) approach originally developed for the Linux kernel project.
We propose that the project takes a close look at the DCO and seriously considers moving to this approach.
The Developer Certificate of Origin
The DCO is an attestation attached to every contribution made by every developer. In the commit message of the contribution, the developer simply adds a Signed-off-by statement and thereby agrees to:
Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
Subsequent developers who co-author or otherwise help shepherd the contribution in some way also adds their own attestation so it's not unusual to end up with a contribution which looks like:
Author: Jane Doe <firstname.lastname@example.org> Commtter: Jake Rogers <email@example.com> Modify the widget with latest widgetry We forgot to update the widget in the first pass of the widgetry refactoring. Fix that oversight now. Signed-off-by: Jane Doe <firstname.lastname@example.org> Signed-off-by: Julie Oak <email@example.com> Signed-off-by: Jake Rogers <firstname.lastname@example.org>
It is important to note that the DCO is not a license. The license of the project - in our case the Apache License - is the license under which the contribution is made.
While the agreement was initially developed for use within the Linux kernel project, it is not in any way tied to the license of the kernel (i.e. the GPLv2). The DCO is increasingly seeing adoption outside the kernel - for example Docker, Samba, Git, Open vSwitch, OpenDaylight, Ceph and qemu all now use it.
The advantages of the DCO approach include:
- It is much easier for first time contributors - they read the simple DCO document, immediately understand what they are attesting to and simply add a '-s' argument when they type 'git commit'.
- The attestation is attached to every contribution made. It's not just made once when a contributor first joins the project and then forgotten about. Like the CLA, it is a belt-n-suspenders approach, but it is more explicitly attached to the contribution than the CLA.
- It allows multiple authors to make the attestation rather than assuming the author listed in the code commit is the sole author, as our current CLA enforcement does.
- The attestation can be included in contributions made via email or a bug tracking system, since it is merely some textual metadata attached to the description of the contribution.
- In contrast to the CLA approach - which was invented and promoted by lawyers - the DCO is a kind of contributor agreement created by developers, for developers, familiar with how open-source projects work.
- There is no sense of inequity that the contribution is being made under special terms to a single organization. The contribution is simply licensed to everyone under the terms of ther project's license.
It is worth considering situations where requiring contributors to explicitly agree to license their contribution under the terms of the project's license. For example, a company might have some downstream patches which they do not intend to license under the Apache License (think one of the cloud providers) but one of their developers decides to go ahead and submit it upstream without permission. The DCO aims to be even more effective in preventing these situations by requiring developers to attest to the license of each and every contribution, rather than relying on an agreement they may have signed years before making the contribution in question.
The DCO deserves a more detailed explanation and justification. The Linux Foundation is keen to help projects understand and adopt the approach, so James Bottomley is delivering presentations on the topic and promoting the DCO via developercertificate.org. We can take it as a given that there is a standing offer from the Linux Foundation to help us explore the implications of adopting the DCO.
The bylaws of the OpenStack Foundation has the following to say about contributor agreements:
7.1 Licenses and Contribution Agreements for Software. (a) The Foundation shall generally accept contributions of software made pursuant to the terms of the Contributor License Agreements attached as Appendix 7. The Board of Directors may adopt additional contributor license agreements as may be appropriate for certain organizations or contributions to secure a license on terms which will permit distribution under the Apache License 2.0, and may require inclusion of the Apache License 2.0 license header in code contributions. The Board of Directors may delegate the authority to make non material amendments to the Contributor License Agreement to the Executive Director so long as such modifications permit distribution of the software under Apache License 2.0. (b) The Foundation shall distribute the software in the OpenStack Project under the Apache License 2.0 unless changed as provided in Section 9.1 7.2 Licenses and Contribution Agreements for Documentation. The Foundation shall only accept contributions of documentation under a contribution agreement approved by the Board of Directors.
The intent to have contributors explicitly agree to make their contribution under the terms of the Apache License 2.0 is clear. Also clear is that the Board of Directors has some ability to adopt alternate contributor agreements. What is not clear is whether this flexibility afforded to the Board of Directors extends to an ability to adopt an agreement like the DCO.
If a change to section 7.1 of the bylaws is deemed to be required, then the following process apply:
ARTICLE IX. AMENDMENT 9.1 By the Board of Directors. [..] these Bylaws may be altered, amended or repealed or new bylaws which may be adopted by the affirmative vote of two-thirds of the directors present at any regular or special meeting of the Board of Directors at which a quorum is also present. In addition to an amendment proposed and approved by the Board of Directors, a proposal to amend these Bylaws may be made by one of the following means: (i) a proposal of the Technical Committee approved by at least two-thirds (2/3) of individuals serving on the Technical Committee, [..] The proposal must be in writing, must specifically state the proposed language of the Bylaws Section(s) or Appendix as amended, and must be signed by each approving Technical Committee member, [..], as applicable.
9.2 Special Votes. [..] (d) In addition to the vote of the Board of Directors as provided in Section 9.1, the amendment of the following Sections requires an affirmative vote of (i) two-thirds of the Gold Members, (ii) two-thirds of the Platinum Members, and (iii) a majority of the Individual Members voting (but only if at least 25% of the Individual Members vote at an annual or special meeting): [..] Sections [..] 7.1, [..]
In other words, a proposed bylaws change could first be approved by a vote of the TC, then a vote of the Board of Directors and would further require votes by the Platinum, Gold and Individual members.
It is generally felt that because of the number of Individual Members (some 15000 members) it will be difficult to achieve the required 25% turnout for such a bylaws change. However, there are other proposals for bylaws changes currently in the works which will face the same difficulty and it is hoped that up to 6,000 members will become ineligible to vote from July 2014 thereby making it easier to achieve the required turnout.
If a bylaws change is required, it may be preferable to simply remove any reference to a particular contributor agreement and instead leave it to the Board of Directors discretion how the project should ensure that contributions are made under a license compatible with the Apache License 2.0.
It's easy to forget that we require contributors to our documentation to also sign the CLA including its patent provisions which aren't obviously relevant in this case. That documentation can and should be treated differently is acknowledged by section 7.2 of the bylaws and it could easily be argued that the Board of Directors should quickly move to adopt a frictionless contributor agreement like the DCO for documentation.