Thirty kernel developers sat in an invitation-only room in Prague on 8 October. They voted to delete the only mechanical check the Linux kernel has ever had on whether a patch involved an AI tool. The number that moved them: 10.2 per cent. 1,884 of 18,533 non-merge changesets in the current release carried the "Assisted-by" tag the kernel had required since April [1][2]. Dave Airlie, one of the developers in that room, told the summit his own honest guess was that the true figure was closer to ninety per cent [3]. Nobody in the room tried to split the difference between a measured 10 and a believed 90. Sasha Levin had built the tag's enforcement six months earlier. He posted the patch to remove it.
This series covered this tag when it was six weeks old, in July. Nobody yet knew whether a six-month-old rule written for a contributor class that cannot sign its own name would hold [1]. Eighteen weeks and two kernel releases later, it is dead. The kernel killed it on its own number. The decision answered no argument about whether AI-written code belongs in the project at all. I spent the years after the SCO lawsuit arguing, as a Novell man inside that fight, that a licence only protects what a chain of accountable people is actually willing to stand behind. The kernel ran a six-month experiment on exactly that question. GNU's own compiler project answered it the opposite way, in the same quarter. Together, they are the first real test of that argument since AI tools turned up on the human end of the chain. The kernel did not debate its way to this decision. It ran the rule for exactly as long as it takes to get a real answer, counted the result honestly, and killed the policy on the count, not on anyone's opinion about AI-written code.
Both projects agree on the law underneath this. Copyleft depends on a clean, human-authored copyright chain. Nobody has settled, in any court that binds either project, whether code substantially produced by an AI system carries assignable copyright at all. The Third Circuit touched the edge of this question on 30 September. It ruled that training a non-generative system on copyrighted material to compete with the source is not fair use, and explicitly declined to say anything about generative systems [4]. That leaves the underlying uncertainty live and unresolved, for the kernel, for GCC, and for anyone else shipping code a court has not yet looked at. Both projects built a policy to hedge against exactly that gap. They just hedged in opposite directions. The ruling matters here for a narrow reason. Every patch the kernel just stopped asking contributors to label, and every patch GCC now requires a label for, is the output of a generative system. That is precisely the category the court went out of its way not to decide. Neither project is waiting for that footnote to resolve itself.
The kernel's own Developer Certificate of Origin has not moved an inch through any of this. Its documentation states plainly: "AI agents MUST NOT add Signed-off-by tags." [5] A human submitter still has to review every AI-touched line, confirm it clears licensing, add their own name, and accept responsibility for what they signed. This series covered that mechanism in Episode 32. What changed this month is whether anyone also records that a machine helped write a change.
The Assisted-by tag was never the DCO. It was a second, separate thing: a trailer a contributor could add to a commit message, voluntarily, naming the tool they used. It was written into the kernel's documentation on 6 January, and shipped as policy with Linux 7.0 on 12 April. In August it was simplified from a verbose tool-and-version format down to a single Assisted-by: LLM line. None of that mattered once the summit put a number next to it. The removal patch Levin posted strips 88 lines across seven files, including the eleven lines of checkpatch.pl that were the tag's entire mechanical enforcement [1]. Take those eleven lines out and the tag becomes something a contributor can type or not type, with nothing downstream ever checking either way. The kernel concluded that a self-reported label nobody cross-checks records nothing real.
GNU's compiler collection reached the opposite decision on the identical legal question, in the same quarter. On 29 July, the GCC Steering Committee made an Assisted-by tag mandatory for any contribution containing LLM-generated content below what the project calls a "legally significant" threshold, commonly reported as roughly fifteen lines. Test cases are exempt outright. The policy itself carries a review date at the start of 2027 [6]. The kernel measured its own tag and concluded it was lying to everyone, regardless of which real usage figure was true. GCC built the identical tag into the one place small enough that a human reviewer can actually check it: a short, bounded patch. There, "did an LLM write this" is a question with a checkable answer, not a number averaged across eighteen thousand changesets a release.
A fifteen-line patch is a one-sentence bug fix, or a renamed variable carried through its callers. It is small enough that a human maintainer can read every line in the time it takes to read the commit message. That is close to why GCC drew the line there, rather than somewhere larger. Above that threshold, the committee's own exception stops applying, and the contribution is treated the way any other change too large to read at a glance already is. The kernel had no equivalent ceiling. Its tag applied, or did not apply, to a changeset of any size. That is part of why a single number, 10.2 per cent, ended up standing in for everything from a one-line typo fix to a multi-file subsystem rewrite.
Accountability survives in both projects. Provenance, any durable record of which specific lines an AI tool touched, survives in neither. The kernel never had it for anything above checkpatch.pl's eleven lines, and is about to have even less. GCC has it, but only below a line-count threshold narrow enough that the committee itself is reviewing whether the exception still makes sense in little more than a year. As of this week, the kernel's own documentation file still carries the old Assisted-by guidance, and its public commit history shows no removal commit landing yet. The correct description is that the kernel has decided to remove the tag, not that it has removed it [7].
The eleven lines of checkpatch.pl are not merely going unused. They are being deleted outright. That makes this harder to undo than an ordinary policy reversal. A future maintainer may want to go back and ask which of today's merged changesets were AI-assisted. They will not find an unenforced field sitting quietly in the commit message format, ready to be checked properly another day. They will find a tag that still appears on some historical commits, with no mechanism left anywhere in the tree that ever verified it meant anything. Provenance here is not just unenforced going forward; for the kernel's own history, it is about to become unrecoverable by design.
Anyone running an open-source contribution policy, or deciding whether to trust a dependency from outside, should take the lesson from what the kernel measured, not from what either project decided. A disclosure tag only works as a governance signal if somebody checks it against something. For six months, nobody checked this one against anything, until the summit finally asked. A tag's presence does not prove a tool was used. It tells you only whether that one contributor was willing to say so: a statement about honesty, not usage. The one thing that actually held, in both the kernel and GCC, is the part neither project reconsidered. A named human reviews the change, signs their own name to it, and accepts responsibility for what it does. Build your AI-contribution governance on that part. If your code review process asks contributors to tick a box declaring AI assistance, and stops there, you have built the kernel's six-month experiment without the kernel's willingness to measure it. You have not matched its willingness to remove the tag once the number came in. A named reviewer's signature is a commitment they cannot quietly withdraw.
The open-source dimension of this one is the article itself. The Assisted-by tag was written into a public documentation commit in January, shipped as policy in April, and simplified in August. It was measured at a developer summit in October, and killed the same week, every step argued out where anyone could read it. GCC reached the opposite answer to the identical legal question in its own public steering-committee record, in the same quarter. Neither decision happened behind a vendor's closed door. Both happened where the reasoning, and the specific number that drove it, were visible to a stranger with a web browser. This series has traced that mechanism since Episode 1. A licence that forces an argument into the open does not guarantee the right answer. It guarantees the wrong one gets measured and corrected in public, not discovered later somewhere expensive.
The same choice, formal consideration against informal trust, already has a defence-procurement answer on the books. The United States Department of Defense's 2009 open-source guidance states that open-source software is eligible for the same evaluation as proprietary commercial code, provided someone can show who touched it and under what authority [8]. That question is about a named, accountable chain. It is exactly the distinction the kernel's own six-month experiment just drew, not about a disclosure label on an individual commit. A defence integrator deciding whether an AI-assisted open-source contribution can enter a system that has to clear a security review answers to that chain, not to a mailing list. It is applying the same formal test GCC just wrote into its narrow exception, and the same test the kernel concluded its own tag was too weak to support. Name the reviewer. Certification attaches to the reviewer, never to the tool.
Back in July, this series asked whether I would tag a patch "Assisted-by" if I used an AI tool to help write one. That tag no longer exists in the kernel. The project measured how many contributors actually used it, and found the number did not match what the room believed was really happening. It removed the one mechanism that checked it, rather than keep publishing a count nobody trusted. Suppose a disclosure rule you would genuinely have followed turns out to measure only the honest fraction of a population that was never going to disclose at all. Would you still want it kept, so that honest fraction stays on the record? Or is a tag only the honest half will ever use worse than no tag at all?
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, served as a technology specialist for Novell during the Linux Wars, and is the author of "Generative AI: Skynet or Heaven" and "Space Mafia." A Concise History of Linux chronicles the operating system that changed the world and the lessons it holds for the AI era. 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] Phoronix. "Linux Kernel Developers Plan To Remove 'Assisted-By' Tag Requirement For AI/LLM Usage." 15 October 2026. URL: https://www.phoronix.com/news/Linux-Dropping-Assisted-By-Req
[2] The Register. "Linux kernel devs drop obligatory confession of AI tool usage." 14 October 2026. URL: https://www.theregister.com/ai-and-ml/2026/10/14/linux-kernel-devs-drop-obligatory-confession-of-ai-tool-usage/5303140
[3] LWN.net. "The 2026 Maintainers Summit." URL: https://lwn.net/SubscriberLink/1099594/fba1c2268c3e2fb5/
[4] Courthouse News Service. "AI training of copyrighted material not fair use: Third Circuit." URL: https://www.courthousenews.com/ai-training-of-copyrighted-material-not-fair-use-third-circuit/
[5] GitHub, torvalds/linux. Documentation/process/coding-assistants.rst. Accessed 15 October 2026. URL: https://github.com/torvalds/linux/blob/master/Documentation/process/coding-assistants.rst
[6] GNU Project. "GNU Compiler Collection, AI Policy." Last modified 29 July 2026. URL: https://gcc.gnu.org/ai-policy.html
[7] GitHub, torvalds/linux. Commit history for Documentation/process/coding-assistants.rst. Accessed 21 October 2026. URL: https://github.com/torvalds/linux/commits/master/Documentation/process/coding-assistants.rst
[8] United States Department of Defense. "Clarifying Guidance Regarding Open Source Software (OSS)." DoD CIO memorandum, 16 October 2009. (No public URL captured for this instrument; cited in full per standing register practice, Linux Wednesday Episode 25.)