Repository navigation
Add guideline about crediting tools as authors #1950
Description
Describe the enhancement or feature you would like
We now have many commits created with so-called AI tools. Many of them default to adding their name in a co-authored-by line in the commit message, which can end up in the upstream repo commit message if the person merging does not clean up the text box (this is a GitHub issue of defaulting to concatenating all commit messages, but can be changed per-repo to take the PR description).
There is an issue with considering this bots as authors. If a program is an author, is its output copyrightable? Does it infringe on the licenses of projects ingested in the training data? Do the bots need to sign a contributor agreement?
I don’t know why these tools do that; maybe it’s just for marketing (as the authors are visible in all pages with lists of commits), and maybe people keep it in good faith in order to disclose tool usage.
I think these lines should not be present, as they have risky implications or are just dubious free publicity.
Thanks for considering!
Describe alternatives you have considered
No response
Additional context
No response
Activity
merwok commentedon Oct 28, 2026
Adding some people involved in other policies PR: @hugovk @willingc @Mariatta @nedbat @savannahostrowski @StanFromIreland
willingc commentedon Oct 28, 2026
Thanks for raising the issue @merwok. Copyright and AI-generated code are still (and likely will be for the near future) a grey area in U.S. Law. I've seen pros and cons to co-author statements in other projects. Personally, I think legal counsel should weigh in on Python's interests and recommend a reasonable approach.
Mariatta commentedon Oct 28, 2026
Personally I have local agents instructions to exclude those trailers as part of the coding/pr creation skill. I wonder if we could add to the agents.md file to never add those commit attribution.
Not a lawyer so I won't comment about copyright or legality issues.
nedbat commentedon Oct 28, 2026
I guess the risk you mean is the copyright and authorship issue? I don't see how removing the line removes the risk. If the code was written by an LLM, it still was even if the message is gone. In the spirit of transparency, wouldn't it be better to keep the line?
I know some people don't like them because they are free publicity, but a footer line in a git commit message is hardly "publicity". You have to work pretty hard to find them.
hugovk commentedon Oct 28, 2026
The presence or absence of Co-authored-by trailers doesn't make any difference as far as the CLA goes.
The CLA bot ignores trailers, and ensures that the Git author of each commit has signed the CLA for that email.
See also @gpshead's reply at
https://discuss.python.org/t/cla-bot-and-ai-agents/106635/8.
vgnaik2004 commentedon Nov 1, 2026
merwok commentedon Nov 2, 2026
The consensus seems to be that things are fine as is.
I don’t like the in-between position. Either people believe these chatbots really understand things and really author code, in which case we should hold off until copyright issues are settled. Or they are just text generators with wiring automation and like any other tools shouldn’t be noted as co-authors.
nedbat commentedon Nov 2, 2026
I don't know which position is the in-between position.
No one can define "understand", so I wouldn't gate anything on agreement about that. And "we should hold off": on using AI tools? That doesn't seem like a possibility at this point.
At the very least, the polarizing and strong opinions about AI tooling separate them from other tools like text editors.
Mariatta commentedon Nov 2, 2026
To me llm-generated PRs are not any different than the PRs made by miss-islington and dependabots. In those PRs they already carry commit attribution to the bots. Now everyone could have their own bots/llm agents if they want to.
Asking contributors to remove the llms attribution is fine to me if the "advertisment" is the part you're concerned with. But just because there is no llm attribution, doesn't mean that llm wasn't used.
willingc commentedon Nov 3, 2026
I think it makes sense for the SC/PSF to have legal counsel weigh in on "Co-authored."
Sadly, the industry has overused anthropomorphism and personification of these tools. It is also unfortunate that attribution wasn't given more thought prior to training these models.
Personally, I view the tools as tools. People will use them or not, as they see fit. I think the best we can do today is to review PRs thoughtfully, independent of the creation process.
encukou commentedon Nov 3, 2026
Is attributing backports to miss-islington a feature?
To me it seems that we don't want to give a bot the rights to push changes to a contributor's fork and open PRs as them, so the bot has its own account, but that comes with the downside of putting the real authors in
Co-Authored-By.We also don't attribute anything to GitHub.com, even though that's what generates every squash commit.
gpshead commentedon Nov 4, 2026
Yes attributing miss-islington is a feature. It says that it was probably blindly automated as a git cherrypick.
Requiring people to comply with specific formats of commit messages is adding friction to development for a bureaucratic purpose.
Ex: All of us on the core team are already supposed to manually edit # references into GH- references and we're supposed to craft some ideal squash merge commit message. we really should not have to do any of this toil. github could automate it. but they don't. so the best we can do is either suffer manual the clickops and text box editing or instruct our Claude or otherwise how to do merges of PRs for us to save us the pain. while we could adopt the configuration of "the PR description becomes the message" - even that is often not right as PR descriptions have a different purpose of communication and would then also need editing/rewriting. you'll also see models including attribution in PR descriptions at times. those are even more free-form than what is typically seen in commit messages.
Our https://devguide.python.org/getting-started/ai-tools/ already covers that AI disclosure is welcome but not required.
IMNSHO co-authored-by's are not worth worrying about. There is no risk in including them. When they do represent actual people, excluding them can cause unintended harm by appearing to remove credit. I don't even like that I get included in one sometimes when all I did was make a trivial typo fix on someones PR or merge main via the github UI to get around flaky CI. But it's even less worth the time trying to perfect this.
I intentionally left Claude attribution in my commit messages for a while throughout 2025 to help normalize that it was okay to use AI in public for OSS work. These days, while i haven't meaningfully used an editor for my coding in over a year, I tend to configure my cpython one to leave the Claude line out just to reduce clutter. But if I'm working on landing someone else's PR and the author left an AI co-authored-by line in, I find that useful signal just as much as optional disclosures in PR descriptions and I will often leave one of those in the squash merge commit message when manually editing to respect the PR authors choice.
I understand the feeling that they are advertising. It probably was initially, in part due to github's sad choice to gamify account activity. At this point I think that ship has sailed and most of the world is already aware of them; the remaining utility is now that iff you believe you can trust the PR author (copycat distilled models often lie), it can indicate the capability level of the model + harness the contributor used. That reputation can be one more signal to shape how you approach a review and how you want to communicate back about issues.
(if you want project specific legal advice, follow others suggestions: you can't get that here)
encukou commentedon Nov 4, 2026
Oh, I agree that it's good to have that signal. My point is that the main author field isn't the ideal place for it.
If I trust the author (to submit code that they understand and are responsible for), I don't care what tools they used. I'm communicating with the human, not their harness.
An for tools in general, no, I wouldn't add
Co-Authored-By: Emacsfor code completion or autoindent or copy&paste, even if it happens that most of the bytes in a PR don't actually come directly from my keyboard. And if I saw that message, it would mostly tell me what the author thinks aboutvimusers.