Major projects draw hard lines against substantial LLM patches

Within days of one another, three of the most consequential free-software projects have moved from uneasy tolerance of AI tooling to explicit rejection of substantial LLM-written patches. The triggers look local: a performance patch on the Git list, a Steering Committee policy drop for GCC, and an onslaught of cleanup mail for Linux drivers/staging. The arguments that followed are not local at all. They converge on the same unresolved questions of copyrightability under the GPL and the Developer's Certificate of Origin, of who bears litigation risk when training data provenance is opaque, and of whether automated contributions hollow out the training grounds that produce the next generation of maintainers.

The Git episode is the most concrete. Arijit Banerjee submitted an index-pack change, assisted by OpenAI Codex, that claimed a median 15% wall-clock improvement on blobless clones of linux.git by reading promisor object links directly from reconstructed buffers instead of serializing full object parses under a mutex. Banerjee disclosed the assistance, took responsibility, and asked whether the work could at least stand as an RFC to preserve the technical result. Maintainers declined on policy grounds, not on the benchmark numbers.

Junio C Hamano pointed straight at SubmittingPatches: the DCO requires contributors to know the origin of their work and to have the right to submit it under the project license, and "It's not yet clear that this can be legally satisfied when submitting significant amount of content that has been generated by AI tools." The documented stance is blunt. The project "will reject anything that looks AI generated, that sounds overly formal or bloated, that looks like AI slop, that looks good on the surface but makes no sense, or that senders don’t understand or cannot explain." Hamano's conclusion on this patch was equally direct: "This doesn't look like it's a trivial change, so I don't believe this patch can be accepted."

brian m. carlson separated investigation from authorship. Analysis with an LLM is fine if the human verifies and remains accountable; writing the substantial code with an LLM is not. Allowed mechanical edits, in his framing, are the uncopyrightable fringe: "fixing spelling errors or adding include guards to header files that lack them." The deeper objection is jurisdictional and practical. Fair-use theories that some companies rely on do not travel cleanly to fair-dealing jurisdictions, and Git is shipped everywhere, including places where a proprietary vendor could simply stop distributing. "I, for one, am not willing to be sued over this project and the project does not have the financial means to deal with extensive litigation." Hamano, noting review-bandwidth pressure, floated borrowing LLVM's broader rule that extractive contributions are rejected whether or not AI is involved. Banerjee suggested karma systems or an experimental release train more indulgent toward AI code; neither found traction against the DCO wall.

GCC's move is institutional rather than patch-by-patch. David Edelsohn announced that the Steering Committee had accepted the AI Policy Working Group's recommended policy, with thanks to Jonathan Wakely and the working group, and a promise to revisit as the landscape shifts. The ensuing thread made plain that the policy rests on the same open legal questions that drove the GNU project's provisional guidance to reject significant LLM-developed contributions. Sam James restated the core dilemma: "If it is copyrightable, then who owns the copyright? If it's based on the training data, then the contributor may not have the rights to share such a patch, and it cannot be legally redistributed under the GPL (or any licence)."

Not everyone accepts the risk calculus. Thomas Koenig put it sharply: "To put it bluntly: The current policy is based on a risk assessment that nobody shares." He sketched a GCC-specific inventory: non-copyrightable output might dilute copyleft only as a matter of quantity, given that public-domain material is already allowable; regurgitated training data might, in the compiler proper, tend to come from GPL forks. Richard Biener and Paul Richard Thomas initially leaned toward similar derived-work intuitions, noting that plaintiffs still must prove infringement and that labeled commits can be reverted. Alexander Monakov pushed back on both the technical claim and the policy implication. Runtime libraries such as libstdc++ routinely host novel code with no necessary tie to a GCC fork; even the compiler proper absorbs unrelated new algorithms. More fundamentally, "since when is code being under the GPL is a sufficient condition for adding it to GCC?" Copyright assignment and provenance rules still apply. Parallel policies at OpenJDK, NetBSD, QEMU, and the GNU project overall were cited as evidence that GCC is not inventing a private panic.

A second axis, already explicit in LLVM's AI tool policy, surfaced in the GCC discussion and dominates the Linux staging announcement. Andrea Pinski proposed that GCC adopt LLVM's ban on using AI tools to clear "good first issue" work: those issues exist as learning opportunities, and fully automating them "squanders the learning opportunity and doesn’t add much value to the project." Greg Kroah-Hartman reached the same conclusion for drivers/staging without waiting for a committee. Staging, he wrote, "exists PRIMARILY as a place for new kernel developers to learn how to get involved in kernel development," full of low-hanging cleanups that are left deliberately unfixed so newcomers can practice process in a tree nobody should depend on. Mass style and API fixups generated by tools have always been unwelcome for that reason. LLM-generated cleanups are simply the latest industrial version of the same defeat. "Anyone attempting to use a LLM to cleanup or "fix" any code in drivers/staging/ is EXPLICITLY defeating the whole purpose of it existing in the first place." Such patches will be rejected automatically; non-disclosure will not help, because the artifacts are obvious.

Thread the three episodes together and the pattern is not a fashion cycle of anti-AI sentiment. It is a governance convergence under shared constraints. The DCO and GPL demand that someone human be able to attest origin and license rights; current LLM pipelines make that attestation legally uncomfortable across jurisdictions, and none of these projects can geofence their tarballs the way a proprietary vendor can. Review capacity is already scarce, so maintainers are unwilling to spend it on extractive or unverifiable bulk. And the on-ramps that staging trees, easy hacks, and good-first issues provide are treated as infrastructure, not backlog to be vacuumed by automation.

What remains unsettled is almost everything operational. How trivial is trivial enough to pass? Can a human who fully understands and re-implements an LLM-discovered idea ever land the result, as carlson suggested in principle for Git, without the patch still "looking AI generated"? Will GCC's living policy harden toward LLVM-style protection of newcomer tasks, or will risk assessments like Koenig's reopen room for carefully disclosed assistance inside assigned-copyright workflows? Is staging's bright line a special case of a teaching tree, or a preview of how other subsystems will respond once the volume rises? The projects have drawn the lines. The litigation, the contributor pipelines, and the next non-trivial performance win that an LLM helps find will test how long those lines can hold.