Remove the usage google CLA choose between CNCF easyCLA vs DCO

[n3wscott]

The @googlebot CLA handling is broken for multi-authors and github suggestion acceptance.

We should make a Knative CLA that does not use the Google CLA so we can allow for correct handling of multi-contributors.

see knative/pkg#1066 for the typical broken interactions with @googlebot CLA.

[duglin]

DCO!

[n3wscott]

@duglin I find DCO to be even more frustrating to use.

[dprotaso]

@duglin I find DCO to be even more frustrating to use.

I've contributed to envoy - it's just a matter of adding a -s like so

git commit -s

[rgregg]

I'm aware of a few issues with the Google CLA bot. I believe we've been working with the team that owns the tool to see if we can improve the issue for multiple owners. The good thing is that we can work around the tool as necessary. If there's more feedback we can take to the team to improve how the bot works on a project like this, I'd love to capture that feedback and share it.

With the structure of the project, the Google CLA is still required to be signed by all contributors or their organizations, which means we're not at the liberty to remove the Google CLA bot.

[duglin]

Can you elaborate? Are you saying the SC can’t change this if they wanted?

…

Sent from my iPad

On Feb 11, 2020, at 6:00 PM, Ryan Gregg ***@***.***> wrote:  I'm aware of a few issues with the Google CLA bot. I believe we've been working with the team that owns the tool to see if we can improve the issue for multiple owners. The good thing is that we can work around the tool as necessary. If there's more feedback we can take to the team to improve how the bot works on a project like this, I'd love to capture that feedback and share it. With the structure of the project, the Google CLA is still required to be signed by all contributors or their organizations, which means we're not at the liberty to remove the Google CLA bot. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[rgregg]

Yes, with Google's ownership of the project and needing contributors to grant a license of the intellectual property, we need the Google contributor license agreement to be signed by all contributors. Creating our own Knative CLA bot to enforce a Knative-specific CLA would not be something that the steering committee can decide directly.

I'd like to better understand the impact of the CLA bot not functioning well in this scenario is causing to the overall productivity for the project, since that appears to be what this issue is about. If there are concerns with the contents or requirements of the Google CLA, I'm also interested in hearing those concerns, but I think that's a separate issue from what was raised here (although the two were conflated in the original post).

We always want to do the right thing for the community -- so I do want to make sure we understand the issue clearly.

[duglin]

While not a blocker for IBM, I do know that having a company specific CLA on an open source project does raise some eyebrows during our internal reviews. And I have heard from other companies that they've run into similar concerns and even roadblocks over it. This falls into the category of "bad optics" when trying to convince people that this really is an open-source project and not just a Google project that allows other people to participate.

This also is related to a question that I believe has been asked before... what exactly does the SC have control over? Most of the conversations have been around Google wanting to retain trademark enforcement, and now we have this. It begs the question... what other areas of control does Google have that people might assume are community/SC owned?

I still question why we can't just use DCOs? Even with "Google's ownership of the project" (which is an interesting phrase unto itself), a DCO should be allowable and help remove some barriers for people.

[n3wscott]

The good thing is that we can work around the tool as necessary.

The only folks who can work around it are from Google. Which leads to a lot of "haallllp I need a googler..."

[mattmoor]

Couple interesting articles that came up on a recent twitter thread:

• https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
• https://opensource.com/article/19/2/cla-problems

Firecracker seems to use inbound=outbound (from the second article)

[duglin]

Quoting the first article:

Meanwhile, the issue of requesting the contributors' assent to the projects' license is
orthogonal to the issue of CLAs. Conservancy does encourage use of clear systems (either
formal or informal) for that purpose. One popular option is called the Developer Certificate of
Origin (DCO). 

[mattmoor]

I don't understand why the CLA bot won't even rescan for non-Googlers 🙄

See here: knative-extensions/net-contour#108 (comment)

[thisisnotapril]

Bot issues aside; I believe everyone on the thread is covered by a corporate CLA already. Information on the Google CLA and the reasoning is here: https://opensource.google/docs/cla/policy/

[thisisnotapril]

I don't understand why the CLA bot won't even rescan for non-Googlers 🙄

See here: knative/net-contour#108 (comment)

That's a good point; I'll ask the team about it and see what we could potentially do to make that process easier. Has there been any success with closing and reopening PRs and force a rescan? That works in other orgs with other bots; curious if it would work here.

[vaikas]

There's some work in redoing the robot to make it less cumbersome. @thisisnotapril to follow up with the team on rough timelines, etc.

[vaikas]

@thisisnotapril do you happen to have any updates on this issue?

[thisisnotapril]

Current ETA for the new bot is end of Q2

[dprotaso]

What's fixed in the new CLA bot?

[vaikas]

Just a quick update on this from yesterdays SC meeting. @thisisnotapril said the target for the new CLA bot is Nov 1st. It will make multi-author / cp much easier.
Also anybody with commit rights can trigger a rescan of the CLA. Flipping the bit still requires Googler magic.

[vaikas]

Did the new bot get deployed? @thisisnotapril

[vaikas]

Today (2022-03-03) during the Steering Meeting we discussed switching over to the DCO. As part of the CNCF onboarding, we need to decide on which one we are using. Steering is leaning towards using DCO for a few reasons. Here's main reasons for switching to DCO:

• Self-service aspect. When DCO fails, the user can by looking at the error message get the cut&paste commands to fix it themselves
• Some companies can't really sign the CLA for one reason or another. This has introduced friction for new community members and adoption.
• CNCF has approved the use of DCO, which was not the case with Google due to legal concerns. With the move to CNCF, this is no longer a blocker.

[rgregg]

It's exciting to see progress on this front and moving towards a better solution here!

[pmorie]

Here is how I see the scope of choice here:

• First, and above all else, I think we should be optimizing for ease of contribution / lowest coefficient of friction in making the first PR, for the highest percentage of potential contributors
• I believe it is fair to say there is no perfect choice that will be equally usable by every potential contributor
• I believe it is also fair to say that the implications of providing a DCO versus signing a CLA are difficult for most people who aren’t IP lawyers to understand
• I believe that most current contributors to any CNCF project have signed the CLA (but I have no proof of this beyond the fact that the CNCF CLA existed before the CNCF allowed the use of DCO)
• I also believe that most organizations with people currently contributing to CNCF projects have had sufficient time to digest the implications of their people signing the CNCF CLA

Some companies can't really sign the CLA for one reason or another.

This got me thinking about how to model the choices here.

Ack that as an issue that we know was present with the Google CLA. Do we know of specific examples where potential contributors are prevented from signing the CNCF CLA? I am not attempting to express skepticism that some folks may be in that situation, but I would be willing to bet that CNCF CLA is lower friction than one specific to a particular company.

I also wonder what the relative frequency of cases where potential contributors may be prevented from using a DCO is. Do we have any idea?

I think these are the buckets of people to quantify:

1. People who have already signed the CNCF CLA and would have zero friction to new contributions if we adopted the CNCF CLA
2. People who have not already signed the CNCF CLA, could sign the CLA, could use DCO
3. People who have not already signed the CNCF CLA, could not sign the CLA, could use DCO
4. People who have not already signed the CNCF CLA, could sign the CLA, could not use DCO

Are those the right buckets? I think we should be framing our choice around the relative quantities of these different buckets. Thoughts?

[lance]

I believe that most current contributors to any CNCF project have signed the CLA (but I have no proof of this beyond the fact that the CNCF CLA existed before the CNCF allowed the use of DCO)

Only a single data point, but I for one have not. I do contribute to and maintain CNCF projects that use DCO. I have signed the Google CLA as an individual contributor, however.

1. People who have already signed the CNCF CLA and would have zero friction to new contributions if we adopted the CNCF CLA

I believe that the CLA / DCO requirement applies to each project. I could be mistaken, but as I understand it, there is not a blanket CLA for all CNCF projects. So there is no scenario where users have zero friction. In any case, the requirements in cncf/sandbox#218 say that each project in the knative and knative-sandbox organizations will need to enable either EasyCLA or DCO in their GitHub orgs. I'm not sure if we will be able to have a single CLA that covers all repositories, but that seems like a reasonable expectation. If this is the case, then the buckets might be more like this.

1. People who could sign the CLA, could use DCO
2. People who could not sign the CLA, could use DCO
3. People who could sign the CLA, could not use DCO

But I'm not sure there really is anyone who fits that last bucket. Using DCO is just adding a signature at the bottom of each commit, declaring yourself as the author, e.g.

Signed-off-by: Lance Ball <lball@redhat.com>

If we can also eliminate the group of those who cannot use DCO as a bucket, then we end up with

1. People who could sign the CLA, could use DCO
2. People who could not sign the CLA, could use DCO

Meaning there simply are more people who can use DCO vs CLA (if you accept all of my statements above, anyway). But the biggest bucket doesn't really mean it's the right answer, if using the DCO is considered to be too much friction. The DCO requires action on every commit, whereas the CLA is once and done. I personally don't have very strong feelings, but I use DCO for CloudEvents and --signoff just what my fingers do naturally when I'm typing git commit now, so I don't find it to be burdensome. That may not be the case for everyone.

[pmorie]

I could be mistaken, but as I understand it, there is not a blanket CLA for all CNCF projects.

I believe there is one and only one. Let’s find out for sure.

[pmorie]

But I'm not sure there really is anyone who fits that last bucket. Using DCO is just adding a signature at the bottom of each commit, declaring yourself as the author, e.g.

The mechanical steps are one thing, whether your organization permits you to do that is another. The permission dimension is the one I was referring to. Does that make sense?

[lance]

I could be mistaken, but as I understand it, there is not a blanket CLA for all CNCF projects.

I believe there is one and only one. Let’s find out for sure.

If this is the case, then it does reduce friction, IMO.

[n3wscott]

There is also this: https://easycla.lfx.linuxfoundation.org/

[lance]

I wrote

I'm not sure if we will be able to have a single CLA that covers all repositories, but that seems like a reasonable expectation.

Scott wrote

There is also this: https://easycla.lfx.linuxfoundation.org/

It looks like EasyCLA will allow us to have one CLA covering all repos, based on my reading of this.

Project managers and maintainers can set up EasyCLA to automatically discover and protect new repositories, or can keep direct control over which repos are protected. (https://lfx.linuxfoundation.org/tools/easycla)

This is not the same as a blanket CNCF CLA (I am skeptical about that even being a thing), but it is "once and done" for ALL Knative repos, which is appealing.

[csantanapr]

Related to [INCUBATING PROJECT ONBOARDING] Knative cncf/sandbox#218

[csantanapr]

I asked in the CNCF Slack #easycla channel about the CLA vs. DCO here what I got back

• moving to easyCLA every current active contributor will be able to onboarded/seed them to initial people into the list, or everyone would need to interact with the tool to signed the new CLA?

  • Yes every current active contributor will be onboarded. We call it migration. They won't have to interact with the CLA tool. If you have CLA Managers for different companies they will also be migrated along with their approved lists.

• Is there a global “CNCF CLA” or we need to create a specific new “Knative CLA”?

  • There is a global CNCF CLA that is applicable to all projects that fall within CNCF.

• Related to global clearance ^^ if someone that signed the easyCLA for kubernetes will not need to sign a CLA to contribute to knative since they already signed the global “CNCF CLA” or there is not such thing and what they signed is “Kubernetes CLA” only for k8s repos?

  • Anyone covered under global CNCF CLA can contribute to any project within CNCF

• When using easyCLA can manage two knative orgs? Can it be configure to handle all repos across the two orgs?

  • Yes

• If your using easyCLA and you had to go in time would you preferred DCO instead?

  • If you are already on EasyCLA you wouldn't switch to DCO. Here is a link to EasyCLA webinar. At the beginning of this webinar Steve Winslow has covered some differences between EasyCLA and DCO. https://www.linuxfoundation.org/webinars/lfx-easycla-streamline-your-development-workflow/

[vaikas]

Unless something else comes up, we're going to finalize the switch to EasyCLA next Thursday: 2022-03-31.

Speak up if you have grave concerns or additions to the great discussion of pros/cons above.

[thisisnotapril]

Are we still moving forward with the switch to EasyCLA? Looks like the Google CLA is still in place here.

[vaikas]

Yes, that was the decision.

[thisisnotapril]

Who is on point for the switch? Wondering what we need to do next.

[vaikas]

@csantanapr is driving it here:
#952

[lance]

I've got it now per #952 (comment)

I have a couple of open tickets - one with the Linux Foundation and one with CNCF, to get access to the EasyCLA dashboard/portal before I can set it all up for Knative.

[upodroid]

@hh ^