REQUEST: Rollback GitHub Coding for opentelemetry-cpp, opentelemetry-cpp-contrib, opentelemetry-rust, opentelemetry-rust-contrib, otel-arrow, semantic-conventions

[svrnm]

Affected Repositories

• opentelemetry-cpp
• opentelemetry-cpp-contrib
• opentelemetry-rust
• opentelemetry-rust-contrib
• otel-arrow
• semantic-conventions

Requested changes

Roll back activation of GitHub Copilot Coding agent for repos listed above.

Purpose

Some maintainers & contributors were caught off guard by that and therefore we should roll this back and individual maintainer groups should raise a repo maintanance issue to have it activated for their repos, such that process is followed.

Expected Duration

Temporarily until SIGs have raised their issue to have the agent re-activated

Repository Maintainers

@open-telemetry/cpp-maintainers @open-telemetry/cpp-contrib-maintainers @open-telemetry/rust-maintainers @open-telemetry/arrow-maintainers @open-telemetry/specs-semconv-maintainers

cc: @open-telemetry/technical-committee @open-telemetry/governance-committee

[marcalff]

I support this request.

Significant changes like this, that have impact on intellectual property, processes, tooling (easyCLA), existing workflows, etc, should be rolled out carefully, and communicated in advance.

Instead, this was forcefully done against repositories, without notice, and without any regard to repository maintainers, who are the first affected.

[marcalff]

To clarify, I am part of @open-telemetry/cpp-maintainers , and I confirm this change was forced without notice.

[trask]

hi @marcalff, I have rolled this back on opentelemetry-cpp and opentelemetry-cpp-contrib. I will draft some process guidelines in this repo for @open-telemetry/admins to follow to make sure maintainers are notified of changes going forward.

fwiw, it is my understanding that this usage is acceptable (if maintainers want to enable it) under OpenTelemetry's Generative AI Contribution Policy.

and to address the EasyCLA failures (until linuxfoundation/easycla#4701 is implemented), I think it's ok to rewrite the commit history to change the author from Copilot (since this is what would happen if you were running Copilot in agent mode locally).

I will double check my understanding with the full GC on Wednesday and get back to you.

[marcalff]

Thanks @trask

About the way to communicate changes, the new admin repository sounds like a good improvement.

If using a generative AI tool is within policy, this is good news.

But this still does not address my main concern, which is a potential pollution of IP within a repository, from data generated by a tool (trained on what ?), where the legal implications are unclear.

I can not find a place where this has been discussed, and somehow making easyCLA "pass" will not magically resolve the legal concerns here.

Last but not least, it does not increase my confidence in all this that the people pushing to adopt the tool (copilot), changing the processes, and deploying the tool on repositories without clarifying or even considering legal implications first ... are in a position of conflict of interest (copilot is a Microsoft product as I understand).

When it is established that:

• (1) using copilot does not put IP at risk
• (2) a quorum of maintainers / TC / GC members, who are not in a position of conflict of interest (i.e., not Microsoft employees), do agree and concur on (1)

then my concerns will be put to rest.

This is the most important part to discuss in GC, in my opinion.

[austinlparker]

for what it's worth, the Linux Foundation has issued guidance on the use of generative AI -- https://www.linuxfoundation.org/legal/generative-ai

I'm not a lawyer so I can't comment on the IP side of things but given the prevalence of projects adopting AI assistance and the factual impossibility of this project policing everyone's use of AI assistance, I can't see a good reason we should forbid the use of agents in organization repos as long as the maintainers agree to have them.

edit - I also don't think we should restrict it to just copilot, for what its worth.

[marcalff]

@austinlparker

Thanks for the clarifications.

To clarify, I am not a laywer either.

It is correct that we can not enforce and inspect how a patch was generated, using AI or not.

However, when a (human) contributor submits a patch:

• The contributor MUST sign the easyCLA
• The contributor is documented as AUTHOR, and takes responsibility for the content
• There is some accountability
• There is the possibility to track all contributions from a given author, which makes it possible to revert all commits from a given author, should it be discovered after the facts that someone acted in bad faith.

My expectations are that:

• a human using AI locally and submitting a patch
• a human using AI on github to submit a patch

should lead to exactly the same results.

From what I have seen so far with the copilot experiment:

From b26221c7693e6b5e509c9602c79f0fb0cbdb7009 Mon Sep 17 00:00:00 2001
From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com>
Date: Wed, 2 Jul 2025 01:28:40 +0000
Subject: [PATCH 2/4] Add configurable cardinality limit support to View class

Co-authored-by: lalitb <1196320+lalitb@users.noreply.github.com>

• The contributor is a bot, the plan it to give this bot a free easyCLA bypass
• easyCLA did not check anything about the Co-authored-by: field
• The Co-authored-by: field may even be lost later in case of squash commits

This provides zero accountability, it just gives people a path to inject code while giving directive to the AI tool to control the actual content.

Something like this instead:

From: lalitb <1196320+lalitb@users.noreply.github.com>
Co-authored-by: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com>

would:

• represent that a human contributor is at the origin of the patch, and takes responsibility for it.
• allow easyCLA to perform a meaningful check
• provide accountability
• provide traceability

If an author uses AI and AI is within policy, this is fine, as long as there is accountability pointing to the Author field.

Currently this is not the case.

[trask]

a quorum of maintainers / TC / GC members, who are not in a position of conflict of interest (i.e., not Microsoft employees), do agree and concur

I raised the issue in the GC meeting last week, and there was consensus that Copilot PRs are acceptable usage within the OpenTelemetry project.

7 out of 9 GC members were present for this discussion:

• Alolita Sharma, Apple
• Austin Parker, Honeycomb
• Daniel Gomez Blanco, New Relic
• Morgan McLean, Splunk
• Pablo Baeyens Fernandez, Datadog
• Ted Young, Grafana Labs
• Trask Stalnaker, Microsoft

That said, none of us are lawyers, and so I can open a CNCF Legal ticket if you still have concerns.

This provides zero accountability, it just gives people a path to inject code while giving directive to the AI tool to control the actual content.

I don't believe this is the case (if I am understanding your concern here), from the docs:

If you have the "Required approvals" rule or branch protection enabled, you won't be able to approve pull requests that you initiated by assigning the related issue to Copilot. Someone else must approve the pull request before it can be merged.

[austinlparker]

@marcalff I think different bots do things differently but I'd actually expect it to work the way it does now -- if the bot creates a PR on its own, then it'd be authored-by the bot, co-authored by the person (i suppose the person who told it to make the PR?). Conversely, if someone works with an AI agent locally then the commits/PRs would be by the person, co-authored by the AI bot.

[trask]

authored-by the bot, co-authored by the person (i suppose the person who told it to make the PR?)

I confirmed this behavior here: trask/opentelemetry-java-contrib#81

[marcalff]

a quorum of maintainers / TC / GC members, who are not in a position of conflict of interest (i.e., not Microsoft employees), do agree and concur

I raised the issue in the GC meeting last week, and there was consensus that Copilot PRs are acceptable usage within the OpenTelemetry project.

Thanks @trask for that.

7 out of 9 GC members were present for this discussion:

* [Alolita Sharma](https://github.com/alolita), Apple

* [Austin Parker](https://github.com/austinlparker), Honeycomb

* [Daniel Gomez Blanco](https://github.com/danielgblanco), New Relic

* [Morgan McLean](https://github.com/mtwo), Splunk

* [Pablo Baeyens Fernandez](https://github.com/mx-psi), Datadog

* [Ted Young](https://github.com/tedsuo), Grafana Labs

* [Trask Stalnaker](https://github.com/trask), Microsoft

Great.

So this is publicly documented at last.

This is the kind of decisions that I expect to be discussed, documented, and communicated before a major change is rolled out.

That said, none of us are lawyers, and so I can open a CNCF Legal ticket if you still have concerns.

This is not necessary.

If there is wide consensus that using Copilot is acceptable, then it is acceptable.

This provides zero accountability, it just gives people a path to inject code while giving directive to the AI tool to control the actual content.

I don't believe this is the case (if I am understanding your concern here), from the docs:

If you have the "Required approvals" rule or branch protection enabled, you won't be able to approve pull requests that you initiated by assigning the related issue to Copilot. Someone else must approve the pull request before it can be merged.

My concern is different.

If someone has NOT signed the easyCLA, can this person leverage copilot to submit a PR, that would be accepted because the bot bypasses easyCLA ?

We don't know yet because the integration with easyCLA is not done, but again, this is the kind of questions I expect to be discussed, documented, and communicated before a major change affecting easyCLA (hence, IP) is rolled out.

[marcalff]

Status summary as of July 13, 2025

On WHAT, about the copilot change itself:

• Using Copilot for PR in opentelemetry is acceptable, and now documented as such. I consider this part resolved.
• The integration with easyCLA is not done, and I still have concerns in this area. I consider this part not resolved.

On HOW, about how the copilot change was rolled out:

• No need to rewrite history, but it should be clear by now that forcefully making significant changes on a repository with neither notice nor explanations is bound to cause frictions.
• Hopefully this part will be resolved as well, and future changes better rolled out.

Last but not least, I hope I am not perceived as difficult to work with, this is not my intention.