Choose to use a CLA, a DCO, or neither

[tobie]

The TSC must decide whether AMP should:

• continue using a Contributor License Agreement (CLA) but with contributors assigning their work to the OpenJS Foundation rather than to Google,
• switch to a Developer Certificate of Origin (DCO), or
• stop using either altogether. (That's actually not an option.)

@ampproject/ac might have some thoughts on this, too.

[tobie]

Related issues: openjs-foundation/cross-project-council#124 (comment) and openjs-foundation/cross-project-council#387.

[mrjoro]

@tobie from the linked openjs-foundation issues I'm not sure what the current state is. :)

Would openjs-foundation have support for either CLA or DCO today?

Does the foundation/CPC have a recommendation for which a project should choose?

@MylesBorins since I remember him talking about this subject before.

[davidstrauss]

Would openjs-foundation have support for either CLA or DCO today?

I believe OpenJS supports either for projects.

In any case, I strongly support a DCO over a CLA. I think lower friction for contribution outweighs both the ability to relicense (which remains possible under Apache licensing, anyway) and the ability to more easily enforce the license against misuse.

[tobie]

I'm trying to find out. :) Clearly the goal of the foundation is to support both, how exactly is still TBD.

[MylesBorins]

Foundation supports either or both. We are finalizing the language of the CLA right currently. It is my understanding that we will also have bots that can be used to help enforce policy. I'm a fan of supporting both, as in some cases properly executing a DCO might actually be harder than executing a CLA (e.g. new developer unfamiliar with git)

…

On Mon, Nov 4, 2019, 12:52 PM Tobie Langel ***@***.***> wrote: I'm trying to find out. :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#25?email_source=notifications&email_token=AADZYVZVSX4OJ3TZWWZ2IE3QSBON5A5CNFSM4JHTNUP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDAEFKA#issuecomment-549470888>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADZYV67AAKPHFLBPUPS6WLQSBON5ANCNFSM4JHTNUPQ> .

[paularmstrong]

as in some cases properly executing a DCO might actually be harder than executing a CLA (e.g. new developer unfamiliar with git)

I'm in strong agreement here. CLA, while it looks heavy, tends to be a much lighter barrier than DCO.

[davidstrauss]

The aspects of executing a DCO that make the process heavier than a CLA seem to be side-effects of how organizations implement DCOs, not intrinsic aspects of them. I personally don't see why it's necessary to collect DCOs using Signed-Off-By in git but CLAs via a web GUI (for example).

The aspects of CLAs that make them heavier than DCOs are intrinsic, as a CLA basically requires a superset of what a DCO requires. This is because everything necessary to contribute code to a project without also contributing the ownership of that code is at least as necessary to contribute code with the associated ownership of that code. This creates friction in large organizations, as it puts a big asterisk next to the assumption that everything the employees create is owned by the company employing them.

I'd be fine with letting developers choose between a CLA and DCO -- whichever they prefer -- but it seems like a weakness in the DCO process if someone would choose the CLA over the DCO simply because of differences in how you execute one versus the other.

[mrjoro]

Here's the OpenJS Foundation IP Policy. My understanding is that the default is DCO, projects may choose CLA.

[tobie]

Following today's request from the TSC to aim for a node.js-inspired, super low friction DCO implementation, I commented accordingly on the related issue in the CPC's repository.

[ljharb]

Projects may also choose “neither”, fwiw.

[tobie]

@ljharb wrote:

Projects may also choose “neither”, fwiw.

According to the IP policy, that requires per project board approval:

Except as may be approved by the Board:

• All new code contributions to any Project shall be made under the Project Code License
  accompanied by a Developers Certificate of Origin (DCO, available at
  http://developercertificate.org/), which will bind the individual contributor and, if
  applicable, their employer to the Project Code License.

[davidstrauss]

Do we have any conclusions around whether a lightweight (click-through or at least not signed-off-by) DCO is possible?

[tobie]

We’re working on it. It might take a little time, though (which means we also need to have a plan for what we do in the meantime).

[davidstrauss]

which means we also need to have a plan for what we do in the meantime

Then I'd propose we go with a CLA in the mean time, assuming the CLA is click-through (and the DCO is still not). Is OpenJS okay with treating people who complete that CLA as fully onboarded even if we ultimately use a DCO? (I assume so, as allowing both was one option presented above.)

I find any other option hard to support, as using a DCO (or nothing) temporarily would undermine the goals behind any CLA and almost force our hand later. While I support a DCO long-term, I don't want to undermine our ability to make a CLA/DCO/nothing decision with less flexibility than we enjoy today.

[tobie]

We could also consider delaying IP transfer until that issue is resolved.

[davidstrauss]

We could also consider delaying IP transfer until that issue is resolved.

Even better.

[cramforce]

Is there documentation of the current OpenJSF supported process? We want to see if there is something we can adopt without changes in the short-term.

[tobie]

Yes. The OpenJSF's board has recently approved a CLA for individual and corporate contributors and is relying on the Linux Foundation's EasyCLA tool to implement it. More info here.

[tobie]

There's also a test repo, if you want to look at what the outcome looks like: https://github.com/openjs-foundation/TEST-EasyCLA.

[cramforce]

From the TSC Meeting: Everybody loves the CLA tool that @tobie presented!

[tobie]

@rudygalfi suggested warning the user upfront about what to expect from the flow.
@davidstrauss suggested improving the tool's accessibility post onboarding.

[tobie]

Update from the foundation onboarding WG:

The next step is to bring AMP's above CLA proposal to the Foundations Members Counsel (a group composed of legal representatives of all Foundation members that advises the Board).

@brianwarner will organize a meeting with the Foundations Members Counsel within the next two weeks on this topic.

The Members Counsel will then advise the Foundation Board which will itself vote on the matter.

There are still a number of open questions which we'll need to have answers to before onboarding, notably:

1. If we don't arrive at a solution by the time AMP is ready to onboard, would AMP continue to rely on Google's CLA and CLA tooling until the Foundation Board makes a decision?
2. If the foundation doesn't agree to change the implementation of its IP policy for all Foundation members (which it seems would be the Foundation's preferred solution), is it willing to carve out a custom solution for AMP as the IP Policy suggests it would?

@brianwarner offered to come discuss those with the TSC. I think it makes sense to do so after we get the initial feedback from the Members Counsel.

[tobie]

Great news: we reached consensus with the Foundation to move forward with the following plan:

1. Work towards a Foundation-wide contributor-friendly solution post onboarding.
2. Move forward with a stopgap solution in the interim based on:
   1. the Apache Individual CLA (pending Foundation Board approval), and
   2. CLA-assistant, deployed and supported by the AMP Infra WG.

[mrjoro]

/cc @rsimha and @ampproject/wg-infra

[tobie]

Members counsel planned this Friday.

[rudygalfi]

Can this be closed out?

[tobie]

We're still waiting for board approval to move ahead.

[rudygalfi]

@tobie Are there any updates on board approval?

[tobie]

Yes. I just got Board approval during yesterday's CPC meeting to move ahead with our preferred solution (Individual CLA only combined with CLA-Assistant). I'm updating ampproject/meta#60 and will be working with @mrjoro and @rsimha to get this implemented.