Jump to: navigation, search


Warning.svg Under Discussion

This article is currently the subject of debate. If you have interest in joining the discussion, see the legal discuss mailing list. If you are a new developer needing to sign the CLA, please refer to the developer's guide

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 formed the basis for a Juno Design Summit session on the topic. See also these slides summarizing the same material.


Since the earliest days of the OpenStack project, contributors have been required to sign an Individual Contributor License Agreement (ICLA), and, where appropriate, to get their employer to 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 use of 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 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 (presumably Roy Fielding).

However, there are substantive differences between the OpenStack CLAs and the Apache License 2.0. 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. There are certain conditions in the Apache License (placed on the person receiving the license) that are not contained in the CLA, and there are certain obligations in the CLAs (placed on the individual or organization signing the CLA) that have no counterpart in the Apache License. In effect, 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. It is also noteworthy that developers must engage in a formal signature ceremony to complete the CLA, while no comparable formality is taken by the Foundation when it nominally makes a release under the Apache License 2.0.

"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, the Vice President for Legal Affairs of the ASF has described the CLA requirement 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. This is the contribution policy governing the projects that produce the vast majority of the code needed to deploy OpenStack in production.

Duplicative Licensing

OpenStack's practice of adding copyright headers to source files gives the appearance 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 expected to be directly licensing code under the Apache License, but then the identity of the licensor 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 copyright assignment. CLAs do not appear to have been used in open source before the adoption of the ASF CLAs in the early 2000s. Beginning around 2005, it became common for CLAs to be imposed as a contribution barrier for open source projects or pseudo-projects that were effectively controlled by a single corporation. Until very recently this practice was particularly associated with companies using copyleft/proprietary dual-licensing business models. Some such CLAs were modeled closely on those of the ASF, though generally with at least minor changes that benefitted the controlling corporate entity. In some cases, single-corporation-controlled projects used CLAs far more restrictive than those of the ASF. The original decision to use Apache-style CLAs must be understood in this historical context.

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). 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. We think arguments for retention of the CLA requirement should address this fact.

Unusual Aspects of OpenStack's CLA System

We have already noted above that OpenStack's application of Apache-based CLAs is done in a manner that is significantly more restrictive than the actual practice of the ASF, the originator of this model of CLAs.

That observation may apply to some of the single-corporate-owner projects adapting Apache-style CLAs as well, but there are additional features of OpenStack's system that are unusually burdensome from the potential individual contributor's perspective.

One is that the ICLA requirement as implemented with Gerrit seems to be more rigorously applied than any other known open source project using Apache-style ICLAs. There is no possibility of an exception for trivial contributions (such as patching a README file or a tiny fix to part of one line of code). Other CLA-using projects that we are familiar with, which otherwise apply the CLA requirement more rigorously than the progenitor ASF, have de facto or explicit exceptions for relatively small contributions.

Another unusual feature of OpenStack's CLA system is that both ICLA and CCLA are required of each contributor. In all other projects using Apache-derived CLAs that we know of (as well as those of the ASF itself), the rule is that the contributor either signs an ICLA or gets his or her employer to sign the CCLA -- not both. While the dual CLA signing requirement may be defensible if one buys into the legal arguments for having CLAs at all, it is clearly noteworthy that OpenStack is alone among all other projects in not using a "sign one or the other, not both" rule. (Historical evidence indicates that for the first few months of its existence OpenStack did have a "one or the other" CLA rule; it is not known why this was changed.)

Related to the last point, a third peculiar feature of the OpenStack CLA system, given the legal justifications that have been made in support of it, is that the rigor of its enforcement is applied entirely on the ICLA side, while the CCLA requirement appears to be something of an honor system. For example, some of the legal justifications that have been made in support of the OpenStack CLA system center on the patent license grants in the CLA (despite the fact that the Apache License 2.0 itself contains a very similar patent license grant). But it is fairly obvious that individual contributors to OpenStack are unlikely themselves to individually hold (now or in the future) patents, let alone patents of some arguable relevance to what they are contributing or contributing to. It is certainly more conceivable that their employers might hold such patents, but then why is so much effort undertaken to ensure that no patch comes into OpenStack without an ICLA on file, and no comparable effort is made to screen patches for corresponding signed CCLAs?

CLAs versus Copyright Assignment

Apache-style CLAs are similar to copyright assignment, in the sense that they are asymmetric legal mechanisms controlling how contributions are made to open source projects that privilege one entity, and in the sense that the contributor is granting a very broad set of rights in both cases to the privileged organization.[1] It seems there is broader developer opposition to copyright assignment than to Apache-style CLAs, yet from a contributor's perspective the difference is in many ways more a matter of form than substance.

The important substantive difference is that with copyright assignment, outright copyright ownership is transferred to the privileged entity and (in typical copyright assignment agreements used for open source projects) the contributor gets a broad license back (covering only the contribution), while with Apache-style CLAs, the contributor keeps ownership but gives the privileged entity a license that is so broad that it gives privileged entity nearly as much as it would get from outright copyright assignment.

It is possible that the ASF adopted CLAs instead of copyright assignment because by the early 2000s political opposition to copyright assignment in the open source development community was well established. The comment by Rick Clark noted above suggests that Rackspace chose to use CLAs as a ready substitute for a preferred copyright assignment approach.

[1] We do not mean to criticize the ASF here. The problems we are pointing out concerning CLAs are, in the case of the ASF, minimized by (a) the ASF's explicit commitment in its CLAs to act within its charitable mission, something that is appropriately inapplicable to the OpenStack CLAs and other "corporate-style" derivatives of ASF CLAs, and (b) the ASF's actual very lenient practice of administering its CLA requirements.

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.[2]
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.
  • CERN was held up for three months initially from being able to contribute to the project because CERN lawyers took issue with some of the wording in the CLA in relation to CERN's status as an international research organization. By contrast, CERN had no issue with the Apache License version 2.0. In the end, after much back-and-forth, CERN signed the CCLA but were not very happy about it.
  • At HGST, it took a month+ to get the CCLA to the correct people and get a response, with a contribution on hold the whole time; then people changed and a new team member had to find out who was responsible to get added to the CCLA and was again delayed from contributing.
  • University of Melbourne/NeCTAR staff were prevented from contributing for months. Technically, situation still not resolved - lawyers refuse to sign.
  • Fusion-io: 6 months with lawyers and to find the correct person to sign the CLA, delaying code submission.
  • From sdague - "a conversation I had to have with a new contributor that wanted to patch the README on one of our projects, which I had to sheepishly point to our how to contribute page. Every single time I have one of these conversations I feel terrible, and that I should apologize profusely, because what we ask new contribs to go through is insane. As someone who's contributed to lots of Open Source on my spare time, a CLA is basically something that I'd never bother to touch."
  • On the more practical side, we see numerous examples of new contributors on IRC or mailing lists having trouble getting through the process of signing the CLA. For example, "I am trying to sign the New Contributor Agreement to be able to submit a new blueprint for review. For several weeks now, I just always get an error message included below."

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 unambiguously 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. See this bug report tracking the issue.

[2] Ian, Kevin and some others have perceived that the OpenStack ICLA has a "loophole" of sorts in its section 7: Should You wish to submit work that is not Your original creation, You may submit it to the Project Manager separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as "Submitted on behalf of a third-party: [named here]".

Developer Recruitment and OpenStack's Image Problem

Developers at conferences have noted serious skepticism from other developers about the "legitimacy" of OpenStack as an Open Source project. In essence, there is a perception that it is a "corporate" project and technically valuable contributions from individual or unaffiliated developers are not welcome. Anecdotal evidence suggests that the CLA regime is a key factor in creating this impression. We strive very hard to make sure that everyone is welcome, but the bureaucracy of the individual membership requirement and the CLA in particular are actions that say otherwise to many developers.

This image problem is compounded by the growing awareness of a trend by some projects to move away from a CLA system - with Node.js and Pump.io being two recent examples.

The CLA has created an "image problem" for our project, and in addition to all of the intangibles associated with that, it may adversely impact the recruiting of new developers. Of particular concern is the tendency for potential future project leaders to be those who most strongly object to CLAs. The pool of talent needed to sustain and grow development of OpenStack is not so abundant that this concern can easily be dismissed by companies with extensive investment in the future of OpenStack.

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. And bear in mind that any time this system breaks (and it does, mostly because of external factors), new contributors are prevented from joining the project. Also, any proposals to evolve the existing CLA regime (rather than adopt a much easier to enforce approach) 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.

The Proposal

While we have pointed to problems with the OpenStack CLA regime, we accept that 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 enabling distribution under the project's license. Apache-style CLAs are not the sole means of achieving these objectives.

Increasingly open-source projects are adopting the Developer Certificate of Origin (DCO) approach. The DCO was originally developed for the Linux kernel project by Diane Peters, former general counsel of Open Source Development Labs, working with Linus Torvalds and other kernel developers.

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
(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 add their own attestation so it's not unusual to end up with a contribution which looks like:

 Author: Jane Doe <j.doe@mycorp.com>
 Commtter: Jake Rogers <jake@openstack.org>
   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 <j.doe@mycorp.com>
   Signed-off-by: Julie Oak <j.oak@mycorp.com>
   Signed-off-by: Jake Rogers <jake@openstack.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. However, the DCO in conjunction with the Apache License may be considered a "best practices" variety of CLA that is superior to the CLAs currently required by OpenStack.

Other Projects Using the DCO

While the DCO was initially developed for use within the Linux kernel project, it is designed for general use and is not in any way tied specifically to the kernel or to the license of the kernel (i.e., 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. Docker and Open vSwitch are projects that use the DCO with the Apache License 2.0. Docker is an example of an Apache License 2.0 project that formerly used an Apache-style CLA like OpenStack but decided to switch to a DCO system to reduce legal barriers to contributing.

OpenStack Foundation Member Companies and the DCO

Most of the OpenStack Foundation's corporate members already contribute to open source projects that use the DCO. Of Platinum members, it appears that at least Canonical, HP, IBM, Intel, Rackspace, Red Hat, and SUSE contribute to one or more DCO-using projects. Of Gold members, it appears that at least Cisco, Dell, DreamHost, EMC, Ericsson, Hitachi, Huawei, Intel, Juniper, Mirantis, NEC, NetApp, Piston Cloud, Symantec, and Yahoo! contribute to one or more DCO-using projects.

IBM is a founding corporate member of the recently-announced Node.js Foundation, which apparently will use the DCO (and not a CLA) for code contributions.


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-and-suspenders approach, but it is more explicitly attached to the contribution than the CLA. This per-contribution attestation system facilitates auditing of contributions in a way that is impractical under a CLA system.
  • 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.
  • 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 the project's license.

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.

Bylaws Implications

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:


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.

Frequently Asked Questions