Jump to: navigation, search


Revision as of 15:48, 8 May 2014 by Markmc (talk | contribs) (The Need For Change)

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.


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:

  1. 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[1]) use them less rigorously than the OpenStack Foundation.
  2. 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.
  3. 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.
  4. 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.
  5. The CLA requirement is thought to improve the project's legal "hygiene" (or appearance thereof) in some amorphous way.
  6. The CLA requirement provides some form of "protection" for OpenStack of a sort that is never described in detail but is assumed to exist.

[1] - 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.

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.

Duplicative Licensing

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.

Contributor Friction

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?

  1. You first need to join the OpenStack Foundation[1] - 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
  2. 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.
  3. 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.
  4. 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:

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.

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:

  1. A legalistic, bureacratic requirement as one of the first steps involved with contributing to the project.
  2. Having your employer sign a license agreement with an organization as a very real stumbling block for some
  3. The inability to submit trivial patches to the project simply by attaching them to a bug report
  4. The requirement that you personally enter into an asymmetric licensing agreement with an organization that you may not yet trust
  5. The bizarre requirement to become a member of a non-profit organization in order to contribute

[1] - 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.

Organizational Cost

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.