Assisted-by: How open source projects are drawing the line on AI contributions

Every major foundation has taken a position on AI-assisted code: some ban it, some require disclosure, and one git trailer is quietly becoming the standard.

Three years ago, generative AI tools were a curiosity in most open source projects. Today they are everywhere, and every major open source foundation has been forced to publish a position on what to do about them. The Linux Kernel has codified a commit trailer for AI-assisted patches. LLVM bans AI on good first issue tickets. QEMU declines AI-generated code outright. Fedora, Rocky Linux, OpenInfra, OpenTelemetry, and the Apache Software Foundation each have their own published guidance.

It is a fast-moving picture, and it is easy to lose the signal in the noise. After surveying how the major foundations and projects have actually written down their AI rules, two patterns jump out. First, the responses fall on a clear spectrum from total ban to enforced disclosure. Second, the projects in the middle – the ones that allow AI assistance with rules – are quietly converging on a single piece of git metadata: a commit trailer called Assisted-by:.

That trailer is the most important standard that almost nobody is talking about.

How open source projects are responding to AI contributions: A full spectrum

If you read the published AI contribution policies across major open source foundations and projects today, they fall on a clear gradient:

• Total ban: QEMU declines any contribution believed to include AI-generated content. Gentoo’s Council voted unanimously in 2024 to forbid contributions assisted by natural-language AI tools. NetBSD presumes such code “tainted” and bars commits without explicit core approval.
• Burdensome-rejection: LLVM allows AI tools but treats unreviewed AI submissions as “extractive contributions” and flatly bans AI from fixing good first issue items. Curl founder Daniel Stenberg shut down the project’s bug bounty program after a flood of AI-generated reports overwhelmed reviewers.
• Permissive with mandatory disclosure: The largest cluster of foundations and projects sits here. They permit AI assistance, but require contributors to disclose it through commit metadata.
• Mandatory enforced disclosure: Some foundations and projects go further, requiring a specific commit trailer for any AI-assisted contribution and rejecting PRs that lack one.
• Verified embrace: A handful of niche projects experiment with cryptographic provenance receipts and percent-AI gates in CI.

The middle of that spectrum is where most of open source actually lives. And it is the middle that depends on git trailers.

Read more: The AI slop problem threatening open source maintainers

Why git commit trailers are the key to AI contribution governance

Git trailers, sometimes called commit footers, are a long-established convention for adding structured metadata at the end of a commit message. They follow the same format as email headers, are first-class citizens in git interpret-trailers, and are searchable with git log --grep. Most modern CI/CD and code-review tooling already understands them.

For AI-assisted contributions, three trailers have emerged in the open source community. They look similar at a glance, but they imply very different things.

• Co-authored-by: Designed for human collaborators. GitHub Copilot, Cursor, and Claude all default to emitting this trailer. The problem is that it implies legal personhood. Models cannot sign a Contributor License Agreement, hold copyright, or bear legal responsibility, and naming an AI as a co-author quietly undermines the chain of title that open source licenses depend on.
• Generated-by: Useful for the narrow case in which a tool produced essentially all of the content with minimal human revision. Misleading for the much more common case in which a developer prompts, reviews, edits, tests, and ships – because in that case the human is doing most of the actual authorship.
• Assisted-by: Indicates that an AI tool helped a human developer write or improve a contribution. The human committer is the author. The AI Agent and LLM are the tools. This trailer matches the reality of most modern AI-assisted development.

What major open source foundations actually say about AI contributions

The major foundations and projects that have written down policies do not all agree on every detail, but the published recommendations cluster tightly. Here is what each one currently puts in front of contributors:

• Apache Software Foundation: The Generative Tooling Guidance recommends including a Generated-by: token in commit messages so that future release tooling can pull this content into a machine-parsable Tooling-Provenance file.
• Fedora Project: The AI-Assisted Contribution Policy recommends Assisted-by: and requires disclosure when “the significant part of the contribution is taken from a tool without changes.”
• Linux Kernel: The official AI Coding Assistants policy prescribes Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]. The kernel is explicit that AI agents must not add Signed-off-by tags. Only humans can certify the Developer Certificate of Origin.
• LLVM: The AI Tool Use Policy recommends Assisted-by: for transparency, mandates a human in the loop, and bans agentic bots from acting in the project’s digital spaces without human approval.
• OpenInfra Foundation: The Policy for AI Generated Content adopts both labels. Assisted-by: is the default for assistive use. Generated-by: is reserved for the rarer case of substantial AI-generated patches.
• OpenTelemetry: The Generative AI Contribution Policy recommends Assisted-by: and gives concrete examples like Assisted-by: Claude Opus 4.5.
• Rocky Linux: The AI-assisted contribution policy is explicitly modeled on Fedora’s and likewise recommends Assisted-by:.

The pattern across these policies is unmistakable. Assisted-by: is the trailer that has emerged as the default across the ecosystem. Where Generated-by: shows up, it usually shows up alongside Assisted-by:, not in place of it.

Why Assisted-by: is becoming the open source standard for AI disclosure

Assisted-by: is becoming the consensus for three concrete reasons, and each one matters in a different way.

Semantic accuracy. Most AI usage in modern development is assistive. The human prompts, reviews, edits, tests, and takes ownership of the result. Assisted-by: describes that reality. Generated-by: overstates the tool’s role in the typical case. Co-authored-by: overstates it further and creates legal questions that nobody wants to answer in court.

Legal clarity. Every major open source license and contributor agreement rests on clear human authorship. Assisted-by: keeps the human contributor as the sole author and signer of any CLA or DCO while transparently documenting that a tool helped. It does not change the legal status of the commit. It just adds a machine-readable note in the place git already keeps that kind of metadata.

Machine readability. Trailers are easily parsed, searchable with git log --grep="Assisted-by:", and ready to be enforced by pre-commit hooks, CI gates, or SBOM tooling. IDE plugins and AI coding assistants can be configured to emit the correct trailer automatically. This is the part that turns a policy into something a maintainer can actually use during a security audit or a release review.

What open source maintainers need to know about AI contribution policies

If you maintain an open source project today, you almost certainly have AI-assisted commits in your history already, whether you have written down a policy or not. The question is no longer whether AI is in your codebase. It is whether you can find it when you need to.

The good news is that picking a convention is cheap. Add a paragraph to your CONTRIBUTING.md. Add an AGENTS.md to the repository root if you want a machine-readable version that AI tools and human contributors will both read. Recommend Assisted-by: for assistive use, decide whether you want to require it or just suggest it, and let your contributors know how you want them to handle the cases where AI does most of the work.

The bad news: there is no single industry-wide standard yet. Contributors working across multiple projects will need to context-switch between conventions for the next few years. The fact that so many published policies are converging on Assisted-by: is the best signal we have that the friction is going to decrease, not increase.

What’s next for AI governance in open source

The most interesting thing about the open source response to AI is how fast it has happened. Three years ago there were almost no published policies. Today there are dozens, and a clear ecosystem-wide convention is emerging without any single body imposing it. That is the open source process working the way it is supposed to: distributed experimentation, public debate, and convergence on the practices that actually solve the problem.

The hardest part of doing AI in open source responsibly is not technical. It is governance. Projects and foundations that get this right will be the ones whose communities still trust their releases in 2030. That trust starts with one simple convention. The human is the author. The tool assisted. Mark it that way.

Get involved: AI contribution policies worth reading

• Read the published policies side by side: Apache Software Foundation, Fedora, Linux Kernel, LLVM, OpenInfra, OpenTelemetry, and Rocky Linux.
• Start with whichever of the above is closest to your governance model and adapt from there.
• If your project hasn’t picked a trailer yet, adopt Assisted-by: and document it where contributors will read it. The next person reviewing your commit history will thank you.

More from We Love Open Source

• 5 forces driving DevOps and AI in 2026
• How we migrated a 20-year-old open source project
• How to make your first meaningful open source contribution
• The AI slop problem threatening open source maintainers
• 6 must-read Linux and open source tutorials