community
community copied to clipboard
open-telemetry
Re-evaluate Project CLA
A recent Twitter thread discussed challenges in contributing due to the requirements of EasyCLA (namely, legal name/address information being on file).
In the past, we opted for EasyCLA in lieu of DCO due to issues with contributions from the web editor/PR suggestions (see #300 for more info). However, recent GitHub updates allow for signoff for web-based commits.
In addition to the privacy concerns raised in the thread, I'm sure we all have had our various run-ins with the... quirks of EasyCLA, especially frustrating in repositories like open telemetry.io (where we receive a larger-than-usual amount of 'drive by' PRs to fix docs issues/misspellings/etc. and blog content).
Given that, I propose we re-evaluate our use of EasyCLA and consider DCO instead to address -- at the very least -- the privacy concerns. While the primary contributors to OpenTelemetry may be corporate devs, I think it behooves us to consider least-restrictive covenants, especially as we hope to continue to grow the community.
In addition to the privacy concerns raised in the thread, I'm sure we all have had our various run-ins with the... quirks of EasyCLA, especially frustrating in repositories like open telemetry.io (where we receive a larger-than-usual amount of 'drive by' PRs to fix docs issues/misspellings/etc. and blog content).
Agreed, this is probably stopping a lot of people from contributing something.
I'd love to see this made easier. Are there any stats on the number of PRs closed right after the CLA check fails? I don't know if this is something github querying can provide. I understand this wouldn't account for folks that aren't even submitting because of the CLA, but it would be one data point to consider in making this decision.
Anecdotally, I've seen a few instances where:
- folks have opened PRs and they've lingered for weeks while they were trying to get CLA approvals through their organizations
- contributors open PRs, only to close them with a note regarding the CLA they have no intention on signing
+1 I'm a fan of removing this barrier to entry given we can safely do so.
EasyCLA is also causing technical difficulties. Here is a PR that is blocked by EasyCLA where every commit except dependabot passes EasyCLA: https://github.com/open-telemetry/experimental-arrow-collector/pull/6
- folks have opened PRs and they've lingered for weeks while they were trying to get CLA approvals through their organizations
I'm not sure the DCO would solve this problem necessarily... although I suppose it depends on a lot of letter vs. spirit of the law factors. The following is the text of the Developer Certification:
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
IANAL but I suspect that if your organization has problems approving the CLA, they'd also be equally skittish about approving this since it's an IP sign-off.
I guess a salient question to answer would be "Are there existing contributors whose organizations would not be OK with them contributing under the DCO but are OK with them contributing under the CLA?"
+1 to removing this barrier to entry, especially because there is a simple elegant solution in the form of the DCO.
DCO and CLA have legal implications for companies. EasyCLA makes managing a company easier across projects legally where the DCO is untraceable centrally. Personally both are fine. It's one time work.
I've seen DCO/commit-signing creating constant friction, on every PR from people not accustomed to git commit -s (a muscle memory for me now). So I agree that one-time pain of CLA is better than DCO.
Having said that, this walkthrough for EasyCLA is like 10 steps, not so "easy". On top of that, asking to type full name, email and physical address (wut? DCO does not require that!) seems completely unnecessary.
I guess a salient question to answer would be "Are there existing contributors whose organizations would not be OK with them contributing under the DCO but are OK with them contributing under the CLA?"
This is definitely a question worth asking. I 100% agree that requiring a physical address is completely uncalled for, and we should definitely find a contribution process that doesn't have such unreasonable requirements, but we want to make sure if we change the process we do it in a considered way. We don't want to just end up excluding a different set of people. Whatever we decide should be done with an eye to including as many people as possible.
We should also make sure we have a good handle on what is required by cncf and what we have control over early in the process. EasyCLA afaik is a tool that was at least suggested if not mandated by the cncf/lf.
I would assume that OTel is not the first CNCF project having that kind of discussion, can we learn from any other project how they went about it, why they picked DCO, EasyCLA, ... and not the other one?
I've seen DCO/commit-signing creating constant friction, on every PR from people not accustomed to
git commit -s(a muscle memory for me now). So I agree that one-time pain of CLA is better than DCO.
I agree, not to mention the extra git setup, I work on 6 different machines, and always I am checking my username.... I have to do the work for other projects anyway, so this wouldn't change with Otel.
I wonder if it is possible to convince the CNCF to remove the physical mailing address requirement? There is already a "public name" for those users who wish not to provide their real name in public.
There's a #maintainers-circle on CNCF Slack if you're looking for more opinions from other projects.
Thanks @castrojo, I've opened a slack thread over there to solicit opinions.
Link to thread for visibility/archival purposes https://cloud-native.slack.com/archives/C014YQ8CDCG/p1665592687862959
Is it possible to also have a legal team look over the risks this organization takes by switching to this new form of licensing?
I assume the CLA is there to reduce the risk of a contributor or their employer suing CNCF/Otel for copyright or patent infringement. If we make it easier to contribute, is there additional risk? Are the risks different?
An interesting idea was brought up by @oleg-nenashev from Dynatrace who helps manage the Keptn project (another cncf project). They are considering a hybrid solution where a contributor can choose to sign a CLA or can use a DCO, whichever works for them. The flow is as follows:
- DCO is enabled across the board in the project
- there is a special CLA repository with configured EasyCLA. Everyone can submit a short pull request with their or company name, and to sign CLA for this request
- Once the pull request is merged, the users are added to the global DCO ignore list on .github. After that the DCO bot will skip commits from those users
(3) requires a simple patch on the DCO bot side. Oleg has already made contact with the bot maintainer about the possibility of this and they seemed receptive.
@beeme1mr also expressed interest in this for open feature (yet another cncf project)
The @open-telemetry/governance-committee discussed this at this week's meeting and it was agreed to propose the solution here and gather feedback. Next week the governance committee will vote to move forward with this or not.
I assume the CLA is there to reduce the risk of a contributor or their employer suing CNCF/Otel for copyright or patent infringement. If we make it easier to contribute, is there additional risk? Are the risks different?
Not a layer. From what I am told the risk for companies was never challenged in court so there is no precedence. Some companies prefer CLA over DCO as a better "potential" protection. But since neither was challenged in court and has no precedence, this is just an opinion and desire to get as much protection as possible.
I don't think CLA is a CNCF requirement either as there are many projects with different models are currently under CNCF umbrella. But CNCF may have an opinion here (cc @caniszczyk).
I'd say the easiest fix for corp contributors would be to keep CLA, but simplify the EasyCLA process for smaller contributions.
The hybrid CLA/DCO approach is interesting to me, that seems like it satisfies all use cases? Just to check my thinking, these would be the paths for contributors -
- Individual CLA Contributor: Creates PR in CLA repo w/EasyCLA check, if CLA is filled out/valid then their commits are automatically considered signed via DCO ignore list.
- Corporate CLA Contributor: Same as individual, except using a corporate CLA
- DCO Contributor: Does not have to fill out the CLA nor make a PR in CLA repo, but does have to sign-off on all commits.
Is that the long and short of it?
The hybrid CLA/DCO approach is interesting to me, that seems like it satisfies all use cases? Just to check my thinking, these would be the paths for contributors -
- Individual CLA Contributor: Creates PR in CLA repo w/EasyCLA check, if CLA is filled out/valid then their commits are automatically considered signed via DCO ignore list.
- Corporate CLA Contributor: Same as individual, except using a corporate CLA
- DCO Contributor: Does not have to fill out the CLA nor make a PR in CLA repo, but does have to sign-off on all commits.
Is that the long and short of it?
yeah that's basically what i'm thinking
Just to put a different light on this: there are two perspectives here, a contributor perspective and a consumer perspective. I think the hybrid CLA/DCO proposal solves the contributor perspective, but does not address the consumer side.
Some companies may say they don't want to use a project that only uses DCO because it provides weaker guarantees than the CLA-only project. And if they can't use such project they don't want to contribute to it either. This was precisely the rationale raised by one of the participant companies when were were forming OpenTelemetry.
As @SergeyKanzhelev mentioned (https://github.com/open-telemetry/community/issues/1252#issuecomment-1278268361), neither DCO nor CLA were tried in court. Personally (not a lawyer) I think "CLA is stronger" reasoning doesn't hold water because all these companies are using Linux which has DCO only. But for us as a project to decide to not enforce CLA is essentially answering this question: will it turn off potential consumers (and, respectively, contributors funded by those consumers)?
It would be nice if CNCF TOC or even GB would make this call instead of doing it per-project (cc @caniszczyk).
+1 to @yurishkuro that automation is important, but secondary to the primary decision.
Updated: I misread the proposal
As @SergeyKanzhelev mentioned (#1252 (comment)), neither DCO nor CLA were tried in court. Personally (not a lawyer) I think "CLA is stronger" reasoning doesn't hold water because all these companies are using Linux which has DCO only. But for us as a project to decide to not enforce CLA is essentially answering this question: will it turn off potential consumers (and, respectively, contributors funded by those consumers)?
This is effectively the question behind the question I asked upthread; for current corporate contributors, does DCO cause problems? Does it imperil our ability for Splunk, Datadog, Dynatrace, Lightstep, et. al. to adopt and push OpenTelemetry as a primary instrumentation/data format standard? To your consumer-side question, does it imperil the AWSes, Microsofts, Googles, and other cloud providers/managed service providers of the world ability or desire to integrate OpenTelemetry into their commercial offerings?
I don't necessarily want the CNCF GB to make this decision for us, and I'm not entirely sure if this is an answerable question. I think you're right that everyone I just named is using Linux somehow (and potentially thousands of other non-copyleft licensed projects that don't use either a CLA or a DCO), so it seems unlikely to actually make a difference, but that's a guess and not a fact.
edit -- to clarify, I don't want the CNCF to answer it by mandating a solution. If they have insight into the likelihood of this change causing difficulties with adoption, then I'd like to hear it.
FYI Linux uses DCO and was the original project for the DCO.
On Fri, Oct 14, 2022 at 8:34 PM Austin Parker @.***> wrote:
As @SergeyKanzhelev https://github.com/SergeyKanzhelev mentioned (#1252 (comment) https://github.com/open-telemetry/community/issues/1252#issuecomment-1278268361), neither DCO nor CLA were tried in court. Personally (not a lawyer) I think "CLA is stronger" reasoning doesn't hold water because all these companies are using Linux which has DCO only. But for us as a project to decide to not enforce CLA is essentially answering this question: will it turn off potential consumers (and, respectively, contributors funded by those consumers)?
This is effectively the question behind the question I asked upthread; for current corporate contributors, does DCO cause problems? Does it imperil our ability for Splunk, Datadog, Dynatrace, Lightstep, et. al. to adopt and push OpenTelemetry as a primary instrumentation/data format standard? To your consumer-side question, does it imperil the AWSes, Microsofts, Googles, and other cloud providers/managed service providers of the world ability or desire to integrate OpenTelemetry into their commercial offerings?
I don't necessarily want the CNCF GB to make this decision for us, and I'm not entirely sure if this is an answerable question. I think you're right that everyone I just named is using Linux somehow (and potentially thousands of other non-copyleft licensed projects that don't use either a CLA or a DCO), so it seems unlikely to actually make a difference, but that's a guess and not a fact.
— Reply to this email directly, view it on GitHub https://github.com/open-telemetry/community/issues/1252#issuecomment-1279626211, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAPSINQ7JTQ6AIFONE2X6TWDICYRANCNFSM6AAAAAARBX7GSA . You are receiving this because you were mentioned.Message ID: @.***>
-- Cheers,
Chris Aniszczyk https://aniszczyk.org
FWIW, the CLA has definitely stopped me from making any contributions to OpenTelemetry. With other projects, I can and do submit PRs when I run into issues. With OpenTelemetry, I don't, because the CLA is in place.
Simplifying the CLA process wouldn't change that; it's having to agree to a CLA at all that's the blocker.
By contrast, the DCO would not be an imposition at all.
Thank you very much for re-evaluating the CLA.
+1 to removing the CLA. The DCO is good enough for the kernel. In my experience the only things CLAs do is erect barriers to entry to participation.
@joshtriplett Quick question; would a hybrid solution where the CLA exists, but contributions can be made under DCO, satisfy this concern or do you view the CLA itself as a taint on the project/code overall? Thanks in advance.
FWIW, offering DCO would be already a great improvement, and I would appreciate getting rid of CLA altogether. It's most often a red flag, creating a strong imbalance between the involved parties. Most certainly it's a blocker for many companies and individual contributors to participate in projects with CLA.
I wonder: what is the actual/official reason for this project to demand signing the CLA? Is it the mere fact that otherwise contributors would have to sign-off all their commits? Or is there a strategical reason?
@austinlparker wrote:
@joshtriplett Quick question; would a hybrid solution where the CLA exists, but contributions can be made under DCO, satisfy this concern or do you view the CLA itself as a taint on the project/code overall? Thanks in advance.
That would be enough to contribute, as long as I wouldn't have to agree to the CLA. Having it as an alternative is odd, but if there are companies that want it as an alternative, that seems fine as long as it's positioned as such ("here's an alternative if your company wants it"). I wouldn't want to see it as a preferred thing that people are pushed towards.