Company rep signing CLA, but engineer submitting pull request


(Christopher Kampmeier) #1

Our company is pretty keen to start formally issuing pull requests per the standard process, but before we sign the CLA, we need to better understand the Discourse team’s perspective on the following:

Problem

We have certain people that are authorized to execute agreements such as the Discourse CLA, but practically the technologists submitting pull requests to the Discourse project will not always be the same people who are authorized to sign the CLA.

Constraining the source of pull requests to only those technologists with the authorization to sign the CLA will be too limiting.

Potential Solution

Could we include in our officially signed form of the electronic CLA a list of GitHub.com account IDs that we expect will be authorized to submit pull requests on behalf of our company?

If so, would we submit follow-on CLAs as the set of authorized GitHub.com accounts change?


(Robin Ward) #2

Our CLA system right now needs a CLA signed per account submitting a pull request.

Could you not create a “shared” account on github and sign the CLA with that, then have it submit the pull requests on behalf of your organization?

It could receive pull requests from your technologists, accept them into its branch, then create a new PR against Discourse.


(Kevin P. Fleming) #3

As someone who has to deal with this same situation, that’s not a sustainable model. In our case, the people authorized to execute a CLA on behalf of the company are our CTO and our General Counsel (among others). They do not have GitHub accounts and would not create one for this purpose, and if they did have one, they would not allow others to have the credentials to the account to use for submission of PRs. We ran into the same problem with the Facebook CCLA and others, and had to handle them via alternative means.

A number of open source projects have attempted to address this; there are some CLA managers on github.com, and Chef has their ‘Supermarket’ project which does it, but none of them do everything that needs to be done (and some day I’ll finish my blog post about that topic…)

To be able to easily accept submissions from employees of large corporations (or even small-to-medium ones that have their intellectual property policies in order), you’ll need to have a system that can support three personas:

  • A CCLA signer, who only signs CCLAs
  • A CCLA admin, who can add/remove authorized GitHub users to give them permission to contribute under the signed CCLA
  • Contributors, who send PRs and whose PRs are vetted against the active signed CCLAs

There are many more details, but this at least covers the people who are involved in a situation like ours.