-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Choose to use a CLA, a DCO, or neither #25
Comments
@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. |
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. |
I'm trying to find out. :) Clearly the goal of the foundation is to support both, how exactly is still TBD. |
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>
.
|
I'm in strong agreement here. CLA, while it looks heavy, tends to be a much lighter barrier than DCO. |
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. |
Here's the OpenJS Foundation IP Policy. My understanding is that the default is DCO, projects may choose CLA. |
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. |
Projects may also choose “neither”, fwiw. |
@ljharb wrote:
According to the IP policy, that requires per project board approval:
|
Do we have any conclusions around whether a lightweight (click-through or at least not |
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). |
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. |
We could also consider delaying IP transfer until that issue is resolved. |
Even better. |
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. |
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. |
There's also a test repo, if you want to look at what the outcome looks like: https://github.com/openjs-foundation/TEST-EasyCLA. |
From the TSC Meeting: Everybody loves the CLA tool that @tobie presented! |
@rudygalfi suggested warning the user upfront about what to expect from the flow. |
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:
@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. |
References ampproject/meta-tsc#25
Great news: we reached consensus with the Foundation to move forward with the following plan:
|
/cc @rsimha and @ampproject/wg-infra |
* update governance for OpenJS charter * delegate legal to foundation * fix charter URL Co-authored-by: Tobie Langel <[email protected]> * fix charter URL Co-authored-by: Tobie Langel <[email protected]> * remove facilitator representing TSC to CPC * Add requirement for OpenJS CPC to approve updated to GOVERNANCE.md * Fix CLA wording References ampproject/meta-tsc#25 Co-authored-by: Tobie Langel <[email protected]>
Members counsel planned this Friday. |
Can this be closed out? |
We're still waiting for board approval to move ahead. |
@tobie Are there any updates on board approval? |
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. |
The TSC must decide whether AMP should:
orstop using either altogether.(That's actually not an option.)@ampproject/ac might have some thoughts on this, too.
The text was updated successfully, but these errors were encountered: