Skip to main content
Jump to: navigation, search

Difference between revisions of "ECA/Implementation Requirements"

Line 82: Line 82:
Access control to this service is TBC.
Access control to this service is TBC.
''This page is moderated by the EMO.''

Revision as of 16:30, 11 April 2013

The Eclipse Foundation is implementing Contributor License Agreements (CLA) to improve its intellectual property (IP) management and workflow. In part, CLAs are a portion of the work required to implement signed-off-by for all contributions coming to Eclipse via git.

The desire is to completely automate the workflows associated with CLAs in order to significantly reduce the effort required by contributors and committers to provide and accept contributions to Eclipse projects.


Committer: A person who is covered by an Eclipse Foundation Committer Agreement and who has write access to the Eclipse Foundation source code repositories.

Contributor: A person who wishes to contribute code or documentation to one or more Eclipse projects. A Contributor must be covered by a CLA.

User: A person who has an Eclipse Foundation user id (e.g. an "Eclipse account").

Workflow Examples

Completing a CLA

A high-level description of the workflow for CLAs is as follows. This description assumes that the person involved has never been involved with Eclipse before. To assist in the narrative, we will refer to the contributor as “Joe”.

  1. Joe becomes interested in an Eclipse project (let’s use EGit as an example) and gets access to the source code (this may be via a social coding website such as Github, but not necessarily).
  2. Screenshot 1: User Registration
    Joe hacks some code and comes up with a feature enhancement or bug fix that he would like to contribute to to EGit. The first thing Joe has to do is register at as a User. This is done via the existing registration page, with one addition: asking the user if they want to provide a CLA after registration. See Screenshot 1.
  3. Once Joe has created his user id, he will be prompted to also complete the CLA.
    • When the CLA comes up, it will be filled with the data already provided when he created the userid (e.g. his email address, and public name). See Screenshot 2.
      Screenshot 2: Signing a CLA
  4. When completing the CLA, Joe has to tick the boxes beside the three questions in the CLA, as well as providing all of the information at the bottom of the form.
    • Once Joe presses “Accept”, he immediately has an active CLA in place and proceed with contributing his code.

Contributing Code Via Bugzilla

Contributor (Joe) contributes code to a project via Bugzilla attachment.

  1. Joe attaches his code to a bug as a Git commit record, with Joe as the Author of the commit
    • i.e. Joe’s name and email address are in the author fields in the commit record).
  2. The project Committer on the project who wishes to apply the patch to the EGit project uses look-up service (i.e. web page) to verify that Joe has an active CLA (using Joe's email address)
  3. When the Committer attempts to push the commit to the Git repository at Eclipse, a check is initiated to confirm that the commit author (i.e. the contributor) has a valid CLA on file.
    • The push is rejected if an active CLA cannot be identified.

Note that project committers do not require CLAs. Any checks performed to identify a CLA will consider the committer status of the author.

Contributing Code Via Gerritt

  1. For Joe to contribute code via Gerritt, he will have to push his code to Gerritt as a git commit record, with Joe as the Author of the commit (i.e. Joe’s name and email address are in the commit record).
  2. Gerrit will verify that a CLA is on file for every commit in the push
    1. The push operation will be rejected if a CLA cannot be identified for each commit.

Project committers assume that the author of any commit that has made it into Gerrit is either a project committer, or has a valid CLA on file.

Other Use Cases

  • A Contributor changes his email address.
  • A Contributor changes his physical address.
  • A Contributor changes his country of residence.
  • A Contributor changes his employer and has to re-submit his CLA.
  • A Contributor becomes a Committer.
  • A Contributor requests that their CLA be terminated.


Data Requirements

The following data elements will have to be stored for retrieval:

The actual CLA documents will have to be either stored as they are completed (in HTML or PDF), or we will have to be able to recreate them on demand. For example, if the IP team needed to print a copy of a user's CLA five years after it was submitted, we need to be able to do that.

All of the data on the CLA document will have to be stored for retrieval and archival. Currently this includes:

  • Contributor legal name
  • Contributor public name
  • Email address
  • Physical mailing address
  • Country
  • (TBC) Electronic signature (“I ACCEPT”)
  • Active date (e.g. date the CLA was submitted)
  • (TBC) Expiry date (e.g. Active date plus three years)

RESTful Service Requirements

It must be possible to programmatically confirm that a given email address has an active CLA on file. This service will return true if the email address corresponds to an active CLA, or to an active Committer Agreement.

So the call would be simply passing an email address, and the return values could include:

  • true or false (if false, the following values are null)
  • role: (committer or contributor)
  • date: the date of the agreement.

Results will be provided in JSON (default) or XML Format.

Access control to this service is TBC.

This page is moderated by the EMO.

Back to the top