Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

A Major Overhaul of Eclipse’s IP Process: CLAs, signed-off-by and more

I’m very happy to announce that we are going to be making some fairly significant changes to the workflows and processes around how contributions flow into Eclipse projects, and how Eclipse committers will process them. The good news is that we think that the new approaches are going to make things a lot easier for everyone. For more details, you can take a look at the presentation I did at a recent Architecture Council meeting.

First, a quick summary of how contributions come into Eclipse today.

  • A contributor makes some changes to an Eclipse project and sends them to Eclipse for review and acceptance by an Eclipse committer. The first complication is that there are several different ways that can happen: contributions can come as push to Gerrit, or a patch in Bugzilla. Which means that the conversations about contributions can occur in multiple places.
  • Assuming the committer likes the contribution and wants to take it, they are then required to ask the contributor “The Three Questions” on either Gerrit or Bugzilla. The Three Questions are:
    1. Did you author 100% of the content you’re contributing?
    2. Do you have the rights to contribute this content to Eclipse?
    3. Are you willing to contribute the content under the project’s license(s) (e.g. EPL)

The problem with this approach is that it’s very manual, error prone, and annoying. In particular, asking a prolific contributor the same three questions each and every time they try to help you out is just not helpful. It is particularly annoying in the context of the normal git workflows, where there there are numerous conventions for dealing with contributions.

So here’s how we are going to make it better:

  • First, we are going to implement Contributor License Agreements (CLAs) for all contributors at Eclipse. The CLA will be a short document that essentially asks The Three Questions once. We will collect some information about the contributor so that we have a record on file of who is giving us code or documentation. Note that the Eclipse Foundation CLA will be quite different from those in use at other organizations. For example, Apache’s CLAs basically give the ASF a license equivalent to ownership for contributions. The Oracle Contributor Agreement (OCA) used by OpenJDK community gives Oracle joint ownership of contributions. The Eclipse CLA is much more modest. In terms of licenses, all it says is that the contributor agrees that their contributions will be provided under the license(s) for the project they’re contributing to. You can review and discuss the draft CLA on bug 401349.
  • Second, we are going to support signed-off-by for contributions which flow to Eclipse project via git and Gerrit. The goal here is to make it as simple as possible for Eclipse projects to accept contributions via the community best practices which have grown up around git. As part of this, we will be developing a contributor certificate of originality, inspired by the one used by the Linux community.
  • And finally, we are going to automate as much of this workflow as possible. Our CLAs will be presented and completed on-line. There will be Gerrit support so committers get an immediate indication as to whether a contributor has a CLA on file. There will be git triggers which will reject a commit where there is no CLA on file for the author of the code commit.

There are a ton of details to be worked out, not least of which is the timetable to roll all of this out. Stay tuned for that. If you want to get involved in the conversation, please join in on bug 401236.

Update: fixed typo “we think we think” in the first paragraph.

Written by Mike Milinkovich

February 21, 2013 at 8:00 am

Posted in Foundation, Open Source

7 Responses

Subscribe to comments with RSS.

  1. Important stuff. Surprised at the number of open source developers that don’t understand what a CLA is and also don’t understand how important it is to have some established process around this. Everyone seems to think this is all about protecting corporate interests when a CLA is really more about protecting the viability of the project itself. There are even whole communities that purposefully avoid CLAs because they think that CLAs restrict freedom (this view is insane BTW). More work needs to be done to make something that every developer understands.

    One question, one complaint about Eclipse that surfaced during the whole Tim Fox, vert.x discussion was that Eclipse IP review is often a very long and unpredictable process. Will the changes you propose putting in place help to address those complaints? (Also, I’m not making the complaints myself, I just noted that this was a part of the discussion.)

    Tim O'Brien

    February 21, 2013 at 8:38 am

    • Tim,

      Thanks for the feedback. I certainly agree that CLAs are important. Frankly, we really struggled with whether we should even call ours a “CLA”, because of the baggage that the term carries, and how lightweight ours is. In the end we decided that creating yet another term would be even more confusing.

      On the IP process, we do have some ideas on how we can improve things. Mostly around the notion of doing more in parallel, so the process doesn’t put a new project into a wait state for any longer than absolutely necessary. We’ve also hired another analyst, which has really helped. But it in the end, the process does take time. On the positive side, we’ve had lots of projects that have gone through it say complimentary things about the outcome. There are lots of cases where we’ve really helped a project clean up their dependencies.

      Mike Milinkovich

      February 21, 2013 at 8:55 am

  2. Thanks for helping make committers work simpler!

    Marc Khouzam

    February 22, 2013 at 1:39 pm

  3. Thank you for the heads up!
    If I understand correctly, both a CLA and a DCO are being written. I’m not sure I see how does the DCO need to differ from the CLA (or the other way around). Isn’t it the same thing, to ‘sign-off’ that you can submit the work under the license of the project? (basically.)


    March 9, 2013 at 1:19 pm

    • Enyst,

      Good question.

      The two documents are complementary.

      The CLA is something that a contributor signs, and is a legal agreement.

      The DCO is a statement that clarifies what we expect from contributors when they use the “signed-off-by” feature in git.

      There is a saying that many lawyers use: “belts and suspenders”. Yes, there is some overlap between these two approaches, but there since the DCO is not something that a contributor is expected to sign, I don’t think that it adds any extra burden to the process.

      Mike Milinkovich

      March 11, 2013 at 11:40 am

  4. […] for people to build than it has been for the last 10 years – just a single command. The major overhaul of Eclipse’s IP process also makes things a lot easier. The Long Term Support working group and forge offer new […]

  5. […] few weeks ago, I talked about a major overhaul of our IP processes. As part of that, we have posted our Public Review Drafts of our Eclipse Foundation Contributor […]

Comments are closed.

%d bloggers like this: