Signed-off-by meets the model: projects split on LLM patches

Two contribution pipelines that rarely share a mailing list are suddenly arguing about the same signature line. On emacs-devel, an ELPA hopeful who built a Magit-style client for Meta's Sapling version-control tool with heavy LLM help ran into questions about headers, authorship, and what maintainers will accept. On the Git list, a treewide migration off legacy utime APIs arrived with an explicit admission that Gemini produced the change. In both places the practical question is no longer whether someone might use a model. It is whether a Signed-off-by still means what projects thought it meant, who absorbs the legal and review cost when it does not, and whether disclosure is enough.

The Emacs thread began as a packaging request, not a policy paper. Swithin Chan explained a corporate Windows constraint, slow Git, and a small Sapling-based interface written after burning tokens, and asked for NonGNU ELPA (or ideally GNU ELPA) placement. Review discussion tangled with security side-channels and CVE-2024-30205, which concerns older Emacs Org mode trusting remote file contents. Richard Stallman drew a line that accepted machine-assisted bug leads while insisting on human verification: "We don't object to getting information about bugs and problems that is based on someone's running an LLM. Maintainers should verify that the bug is real, because LLMs and humans both make mistakes, and if so, fix the bug." Chan later stripped a header and wrote, "I have removed the header. All errors are solely by mine," while promising ongoing maintenance and adding Transient menus and command options. The exchange left the deeper packaging question hanging: what provenance story an ELPA submission must tell when substantial surface area was model-shaped, even if a human claims final responsibility.

The Git thread made the same stakes concrete with a larger blast radius. Alexey Samsonov proposed migrating the codebase from the legacy utime interface and header, removed from POSIX.1-2024, toward utimensat with nanosecond precision and an utimes fallback, plus MinGW wrapping. Newer libcs may omit utime entirely; older systems still need a path. Behavior was meant to stay equivalent aside from finer timestamps reaching the kernel. The cover letter did not hide the tool chain: "This change is generated by Gemini Flash from Antigravity, but all the code has been manually verified by me, and, where applicable, adjusted to match the existing behavior as closely as possible," followed by the usual Signed-off-by.

That disclosure pulled the Developer Certificate of Origin into the foreground. Junio C Hamano restated the project's long-standing risk calculus. If material under a DCO later proves legally unusable, "the submitter may of course be in trouble, but we would also need to bear the cost of ripping it out; the later we discover the problem, the more substantial the effort necessary to deal with the fallout will be." Trust in a known contributor's diligence is not the same as trust in opaque model output. Discussing patches from Johannes Schindelin, Hamano clarified what diligence looks like in ordinary human work: checking resemblance to prior in-tree fixes, or relying on learning from permissively licensed sources, so the project is not silently importing alien copyright. "By 'sufficient due diligence', what I meant was that I trust Dscho well enough that he's done a similar analysis to make sure that he is copying from ourselves."

Oswald Buddenhagen pressed the opposite steelman: that assumption collapses once an AI tool is in the loop. "i think the salient point is that it is never reasonable to make that assumption when an AI tool is used." Even if some tools claim self-detection of plagiarism, failure modes leave reviewers without a practical audit. "Literally No-one (TM) will use multiple code search engines to check whether the generated code doesn't contain sufficiently large fragments that are (near-)verbatim copies from incompatibly licensed code bases." On that view, a Signed-off-by from a careful human still cannot reconstruct training-set provenance, so labeling the tool is weak assurance and rejection or quarantine becomes the only honest policy for significant generated bulk.

Weijie Yuan's back-and-forth with Hamano tried to reconcile those poles: how personal trust in a submitter interacts with systemic DCO fear when "a significant amount of a contribution is generated by an AI." The clarification that landed was not a bright-line ban. It was that provenance control depends on human-scale analysis the project can still perform, resemblance checks against its own history, license-aware reuse, and the submitter's willingness to own the result. That is a workable story for small, reviewable edits. It is thinner for treewide mechanical migrations or for a fresh Emacs package whose author openly optimized under token burn and corporate toolchain pressure.

Technically the two cases differ, which is why the policy collision stings. Samsonov's series is the kind of API hygiene Git has done for years: drop a dying POSIX surface, prefer utimensat, keep compatibility shims, avoid behavior change except intentional precision. Reviewers can reason about syscall choice, fallbacks, and Windows wrappers without needing the model. Chan's sl.el is integration work: Transient UX, Sapling's journal and Windows behavior, Magit familiarity, ELPA expectations around maintenance and headers. Reviewers can read Lisp, but they cannot replay the prompt history that shaped it. In both settings the DCO's original social function, a lightweight attestation that the contributor has the right to submit and that the project may relicense under its terms, is being asked to cover a new production method whose training data and license hygiene are outside the contributor's direct knowledge.

Liability, review burden, and provenance therefore travel together. A project that accepts undisclosed or lightly disclosed LLM patches concentrates removal cost on itself if incompatible fragments surface later. A project that demands tool trailers gains signal but not proof. A project that rejects model-assisted work outright preserves a clean attestation story at the price of slowing contributors who already treat assistants as default editors, especially on Windows or in corporate environments where the alternative VCS or editor path is painful. Stallman's Emacs stance separates machine-assisted diagnosis from unexamined code landing; Git's discussion separates trusted human diligence from the impossibility of exhaustive plagiarism search over model output. Neither community has yet written a single rule that satisfies both the DCO's legal conservatism and the reality that such patches are becoming routine.

Where it stands is awkward coexistence. Disclosures like Samsonov's make the debate possible; removals of AI-flavored headers like Chan's try to restore a human-only narrative after the fact. Maintainers still want verified bugs fixed and dead APIs retired. What remains unresolved is the attestation itself: whether Signed-off-by can remain a personal warranty when substantial text originates in a system no signer can fully audit, whether mandatory labeling helps or merely documents the risk, and how small packaging communities and large systems codebases apply one standard without either rubber-stamping opaque origin or freezing out contributors who will not work without assistants.