For thirty years I have trusted a changelog the way other professions trust a signature. A name on a commit was supposed to mean something: a person stood behind the line, and if it broke, someone could be asked why. In October 2026 the people who run the largest collaborative software project on Earth tried to extend that trust to a new kind of contributor, a model. They spent nine and a half months finding out it did not work the way they had hoped.
They did not patch it. They deleted it. In the six weeks that followed, the thing it was supposed to measure went up.
This is the story of a kernel that tried to write trust down as a rule. It measured how well the rule worked, and chose to say so rather than keep a control it could no longer vouch for.
The rule was called Assisted-by. It was a line a contributor could add to a commit message, naming the AI tool that helped write the change. It sat alongside the decades-old Signed-off-by line, which still carries the human's legal certification under the kernel's Developer Certificate of Origin. The two were never meant to do the same job. Signed-off-by says a named person takes responsibility. Assisted-by was only ever meant to say a model had a hand in it.
The tag's life ran across two Maintainers Summits and three edits. Reading the commit history shows a shape more interesting than introduced, then removed. The 2025 summit wrote it into the documentation tree that December, committed in January 2026, and shipped with kernel 7.0 that April. The rule that was eventually deleted was not reversed by the same people who wrote it, in the same room, having second thoughts. A different gathering, ten months later, made the opposite call. By July, Christian Brauner narrowed what the tag was allowed to say, dropping the requirement to name a specific model. His own reasoning, read straight from the commit: naming the model gave "free advertising to proprietary software companies" for no real benefit. That was a smaller, more defensible edit than removing the tag outright. A proposal to drop the tag outright was raised the same month, and turned down.
Three months later, at the 2026 Maintainers Summit in Prague, the same proposal came back and passed. The commit that carried it out is unambiguous about why. The kernel's own measurement found the tag on 10.2 per cent of non-merge Linux 7.3 changesets, 1,884 of 18,533. Actual AI use, the room agreed, was far more widespread. Some contributors did not know the rule existed. Others left the tag off deliberately. Few maintainers ever asked. The commit's own words: "the tag does not provide the signal it was kept for." The fix removed the tag's sections from the documentation, from the submitting-patches guide and its translations, and from the eleven lines of checkpatch.pl that had enforced it. The Developer Certificate of Origin, the commit states plainly, stays exactly as it was.
I did not take the removal on faith, and neither should you. GitHub's own comparison tool confirms the removal commit is an ancestor of the kernel's default branch: zero commits ahead, more than twenty-three thousand behind. It did not land on some side branch waiting to be quietly reverted. If a commit is going to change how a project works, the first thing worth checking is whether the project actually accepted it, not whether someone wrote a convincing commit message about it.
Greg Kroah-Hartman had argued to keep the tag in July. By October, the commit records, he supported removing it: a position changed in public, on the record.
Linus Torvalds weighed in on the same thread. What he actually wrote is sharper than the version that has been doing the rounds this week. He was not comparing a model to a compiler out of calm principle. He was telling one developer, directly, that a tool ban was an idiotic place to draw a line: "do you not see how UTTERLY STUPID those kinds of rules would be?" What matters, in the end, is whether the person submitting the code understands it. That survived into the removal itself. It has very little to do with which tools they used to write it.
I have written about this exact kind of count before. As I wrote in The Hallucination Economy, a figure like Corbet's is "crude and admittedly incomplete," re-runnable by any stranger with the same public history. It was never built to answer the question the summit eventually put to it: not how many commits carried the tag, but how many should have.
The rule was consulted. Enough people followed it, across two full release cycles, to produce thousands of tagged commits. It was deleted anyway. The people who built it had the clearest evidence this project has produced that a documented control was ineffective, and they said so rather than letting it stand as decoration.
I keep coming back to the oldest framework this series has, because it still explains more than anything newer. Eric Raymond's essay gave us two models of how software gets built: the cathedral, a small group working behind closed doors until the design is finished, and the bazaar, thousands of strangers reading each other's work in the open, on the theory that enough eyes make bugs shallow. This series has mostly asked that question from the consumer's side: can you trust code you did not write, reviewed by people you have never met? October's vote asks it from the other direction, the maintainer's own. The cathedral's answer to provenance is a review process with gates, people, title, sign-off, before anything ships. The bazaar just built one of those gates for itself, measured how well it worked, and deleted it when the number came back wrong, in public, on a mailing list anyone can read. That is a harder thing to do than keeping a gate nobody checks.
One trade outlet counted tagged commits in the very next merge window at roughly 2.4 times the prior cycle's figure, 3,008 against 1,257. That number is single-sourced and should be read that way. It is also not evidence of what caused it. The documentation change reached the tree on 13 October. The merge window it landed inside had already been open two weeks and ran another three after. A count spanning both the old rule and no rule at all cannot tell you which regime produced the rise, and nobody who has published the figure has split it to find out.
What stays constant through all of it is the Signed-off-by line. Humans still certify. A kernel that just finished admitting it cannot reliably tell who used an assistant has left exactly one line in the commit message that still means what it has always meant.
This is also the oldest argument this project has ever won, run on a new subject. The kernel has never waited for a perfect design before shipping. It ships something, watches what actually happens, and fixes what the evidence says is broken. Assisted-by was exactly that kind of experiment: a reasonable guess about how to disclose machine help. It was tried for nine and a half months, measured against real commit history rather than a committee's prediction, and corrected once the measurement disagreed with the guess. A rule designed in a conference room and never tested against production would have been harder to kill. Nobody would have had a number to kill it with.
The same quarter the kernel narrowed its own tag, the GNU Compiler Collection's Steering Committee made the opposite call on the same underlying premise. It required the identical disclosure below a line-count threshold rather than loosening it. Two governing bodies, one legal question, one quarter, two different answers: whether a weak signal is worth the paperwork it costs to collect. That disagreement is where the sovereignty question sits. Two community-governed projects, answering to no single company, reached opposite conclusions about how to prove who wrote a line of code. Both conclusions are published, inspectable, and open to being reversed again the same way this one was. A closed project does not have to show you its vote. The kernel's own documentation tree is the record of a rule written, measured against its own purpose, and taken back out in public when the measurement said it had failed.
The United States Department of Defense has been here before. DoD Instruction 8500.2 requires open source software to be formally considered rather than defaulted out of government systems. It has never depended on anyone's good intentions. It depends on someone actually checking, the same way the kernel's tag depended on someone actually tagging. A procurement requirement nobody audits is just a line in a policy document. A disclosure tag nobody enforces is the same failure in different clothes. The instrument that holds is the one somebody measures, and is willing to retire the day the measurement says it has stopped working.
If your own organisation runs a rule shaped like this one, a disclosure requirement, a review gate, a sign-off step somebody has to tick before a change ships, the kernel's own example gives you a question worth asking on a Monday morning. It is not a theory. Not whether the rule exists. Whether anyone has ever measured what it actually catches, against what it was supposed to catch. A rule nobody measures is a sentence in a policy document. A rule somebody measures, and is willing to delete the day the number says it has stopped working, is the only kind that has ever told anyone anything true.
You have spent thirty years in a field that mostly trusts a name and a changelog line to tell you how something was made. The kernel tried writing that trust down as a rule, measured how often people actually followed it, and found the number told it almost nothing. It deleted the rule rather than keep pretending it worked. If a disclosure requirement you rely on today turned out to be measuring the wrong thing, would you find out from the rule, or only from what happens after someone finally stops enforcing it?
This is one of seven weekly series in The Hamberger Report. Subscribe on LinkedIn and the next one arrives in your feed.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. I write as director of Te Pono Limited; the views are personal and do not represent the position of any client, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance, and it is politically neutral.
About the Author: Andreas Hamberger is a New Zealand-based enterprise architect and technology strategist. Over 30 years, he has moved from compiling kernels on a 486 to leading cloud, cyber, and AI transformation programmes across government, banking, transport, and aviation. He founded Yoper Linux and served as a technology specialist for Novell during the Linux Wars. Free as in Theft is the hidden history of open source software. He can be reached at andreas@thehambergerreport.com.
This article was produced with AI assistance under my direction. Research, drafting and images pass through a pipeline I built and govern: automated gates for source verification, forbidden language and political neutrality, and my own review before anything is published. The tools include Claude, Gemini and Openart. The frameworks, arguments and editorial judgements are mine and are the same discipline I apply to the AI systems I audit for clients. AI accelerated the work; the thinking, and the responsibility for it, are mine.
[1] GitHub. "Commit 1e035297ffdadf2184c3c773b8c098e372324aaf, torvalds/linux." Fetched 4 November 2026. https://api.github.com/repos/torvalds/linux/commits/1e035297ffdadf2184c3c773b8c098e372324aaf
[2] GitHub. "Compare master...1e035297ffdadf2184c3c773b8c098e372324aaf, torvalds/linux." Fetched 4 November 2026. https://api.github.com/repos/torvalds/linux/compare/master...1e035297ffdadf2184c3c773b8c098e372324aaf
[3] GitHub. "Commit 78d979db6cef, torvalds/linux." Fetched 4 November 2026. https://api.github.com/repos/torvalds/linux/commits/78d979db6cef
[4] GitHub. "Commit 816d9992d9ed, torvalds/linux." Fetched 4 November 2026. https://api.github.com/repos/torvalds/linux/commits/816d9992d9ed
[5] Linux Kernel Mailing List (mirror). Linus Torvalds to Laurent Pinchart, 13 October 2026. https://lkml.iu.edu/2610.1/13255.html
[6] LWN.net. "The 2026 Maintainers Summit." Fetched 4 November 2026. https://lwn.net/Articles/1099594/
[7] XenoSpectrum. "Linux 7.4 Sees AI-Tagged Commits Jump About 2.4x, and Torvalds Calls It a 'Healthier Model'." Fetched 4 November 2026. https://xenospectrum.com/en/linux-74-ai-assisted-commits/
[8] LWN.net. "Kernel prepatch 7.4-rc1." Fetched 4 November 2026. https://lwn.net/Articles/1104654/