Linux lets AI write the code but never sign for it

The Linux kernel has a document that tells machines how to behave. It sits at Documentation/process/coding-assistants.rst, it runs to fewer than sixty lines, and it settles a question that consumed the project for the better part of two years. AI tools may help write kernel code. AI agents may not sign for it. Only a human can add a Signed-off-by tag, because only a human can certify the Developer Certificate of Origin, and the human who adds that tag owns every consequence that follows: the bug, the regression, the licence problem, the security hole.

The rule the kernel finally wrote down

The document was committed on 23 December 2025 by Sasha Levin, the NVIDIA engineer who co-maintains the long-term stable kernels, and approved by documentation maintainer Jonathan Corbet. Its commit message points at the consensus reached at the 2025 Maintainers Summit. It shipped as part of Linux 7.0, which Linus Torvalds released in April 2026 after a cycle he described as unusually busy. Most of the press coverage arrived in mid-April, when the wider technology media noticed that the world’s most widely deployed codebase had quietly published contribution rules for language models.

The framing in that coverage was mostly wrong. Nobody at the top of the kernel was agonising over whether AI belonged in Linux. By the time the file landed, AI was already there — in fuzzers, in review bots, in changelogs, in refactoring passes on drivers nobody else wants to maintain. The document is not a gate. It is an accounting mechanism. It exists because the kernel needed a way to keep track of what a machine touched, and because the project’s entire legal defence rests on a chain of human attestations that a machine cannot join.

That distinction matters more than the permission question, and it is the reason the argument did not end in December. Six months after the file was merged, the kernel community spent July 2026 arguing about whether the disclosure requirement should be weakened, narrowed, or scrapped entirely. Christian Brauner proposed cutting the tag down to two words. Jeff Layton proposed removing the attribution requirement outright. Jakub Kicinski, who maintains networking, simply started deleting the tags from patches he applied. Greg Kroah-Hartman and Lorenzo Stoakes argued for keeping them. A final decision has been deferred, probably to the Maintainers Summit in October.

Meanwhile the volume kept climbing. Linux 7.0 shipped with 31 commits carrying an Assisted-by tag. Linux 7.1, released on 14 June 2026, carried 299. By 7.2-rc4 the running total across the tree had passed 1,200. Everyone involved agrees the real figure is higher, because a substantial share of machine-generated patches arrive with no tag at all — sometimes through ignorance, sometimes, as Corbet put it in his July write-up, because the origin is being obscured on purpose.

The kernel’s AI story in 2026 is therefore not a story about permission. It is a story about provenance, review capacity, and who absorbs the risk when a plausible-looking patch turns out to be wrong. Those three pressures explain nearly everything that has happened: the disclosure fight, the collapse of the private security mailing list, curl killing its bug bounty, QEMU reversing a ban it had spent a year defending, Red Hat shipping a Fedora variant whose build pipeline is explicitly designed for agents rather than people.

This article works through the mechanics of that shift. It covers what the kernel documents actually say, how the disclosure tag is being used and ignored, what the review tooling looks like in practice, where the legal exposure sits, how other projects have drawn the line differently, and what the whole thing means for anyone who ships a product with Linux inside it. Where a claim is verified — a commit, a release date, a documented policy, a number published by LWN — it is presented as fact. Where a conclusion is interpretation, it is marked as such. That separation is doing real work here, because the loudest claims about AI in open source come from people with something to sell in either direction.

Inside coding-assistants.rst

The file is short enough to read in two minutes, which is part of its design. It opens by pointing AI tools at the documentation that already exists: the guide to the kernel development process, the coding style document, and the guide to submitting patches. No exception, no fast path, no separate standard. A patch produced with a model is judged by the same rules as a patch produced by hand, which in the kernel means checkpatch cleanliness, correct subsystem routing, a changelog that explains the why rather than the what, and a maintainer willing to take it.

The licensing section is equally terse. Everything must be compatible with GPL-2.0-only, SPDX identifiers must be correct, and the kernel’s licensing rules document governs. This is the same requirement that has applied since the SPDX conversion, and it is stated here mainly because model output has no inherent licence and contributors need reminding that the obligation does not evaporate when a tool generates the text.

Then comes the part that carries the legal weight. AI agents must not add Signed-off-by tags. The document uses an emphatic MUST NOT, borrowed from the register of standards documents, and grounds it in a specific claim: only humans can legally certify the Developer Certificate of Origin. The human submitter is then handed four obligations in a list — review all AI-generated code, ensure compliance with licensing requirements, add their own Signed-off-by to certify the DCO, and take full responsibility for the contribution.

That final phrase is where the whole policy lives. The kernel did not solve the question of whether model output can be lawfully contributed. It relocated the question onto a named individual. If the code turns out to be a verbatim reproduction of GPL-incompatible source, the person who signed it made a false certification. If it introduces a use-after-free in a driver that ships on a billion devices, the person who signed it wrote the bug, as far as the project is concerned. The tool has no standing, no liability, and no seat at the table.

The attribution section introduces the tag itself. Contributions should include a trailer in the form Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2], where the agent name identifies the tool or framework, the model version identifies the specific model, and the bracketed entries list specialised analysis tools such as coccinelle, sparse, smatch or clang-tidy. Basic development tools are explicitly excluded — nobody wants to see git, gcc, make or an editor listed. The worked example in the file is Assisted-by: Claude:claude-3-opus coccinelle sparse.

Two details in that example repay attention. First, the kernel drew a line between generative tools and deterministic ones, and put both in the same trailer rather than pretending they are the same kind of thing. Coccinelle has been rewriting kernel code semi-automatically since 2008 and nobody ever considered it a provenance risk; it appears in the bracketed position precisely because it is a known quantity. Second, the example names a commercial model from a specific vendor, which is one of the reasons the tag later came under attack. Several developers came to see model names in the permanent git history as unpaid advertising for the companies supplying the models.

The document says “should include” rather than “must include” for the tag, and Levin acknowledged at the Maintainers Summit that enforcement was deliberately left out. There is no detector, no CI gate, no scanner. Nobody in the kernel community believes AI detection tools work on code, particularly on code that has been edited by hand after generation. The disclosure regime is honour-based by design, and the people who wrote it knew that when they wrote it.

What the file does not do is also worth stating plainly. It does not cap how much of a patch may be generated. It does not require prompts to be published. It does not distinguish between a two-line autocomplete and a wholly synthesised driver. It does not tell maintainers how to treat a tagged patch differently. Those gaps were filled six weeks later by a second document with a wider scope, and the interaction between the two is where the practical rules actually emerge.

Sasha Levin, one undisclosed patch and a trust problem

The policy has an origin story, and it is not a flattering one. In mid-2025, at an Open Source Summit session, Levin disclosed that a patch he had already landed in the 6.15 kernel had been written by a language model — code and changelog both — with no indication of that fact at the time of submission. The patch worked. It also carried a performance regression that survived review, and Torvalds later acknowledged that it had not been examined as closely as it should have been, partly because nothing signalled that it needed extra scrutiny.

The reaction was sharper than the technical facts warranted, and that gap is instructive. A single regression in a merged patch is an ordinary event in kernel development; thousands of commits land every cycle and a fraction of them are wrong. What the community objected to was the missing signal. Reviewers allocate attention based on cues: who sent the patch, which subsystem it touches, whether the author has a track record, how the changelog reads. A fluent, well-structured changelog attached to a plausible diff from a known maintainer consumes very little reviewer scepticism. Generated code exploits exactly the cues that human reviewers use to decide how hard to look.

Levin’s response was to build the disclosure mechanism rather than retreat from the tools. He had already posted an RFC to the kernel mailing list in July 2025 proposing unified configuration files for AI assistants — a scheme in which .cursorrules, CLAUDE.md, .github/copilot-instructions.md and half a dozen other vendor-specific files would all symlink to a single kernel-maintained document. The patch series demonstrated the workflow end to end with a real typo fix in a power-management documentation file.

That RFC did not go well, and the reasons it did not go well shaped the eventual policy. Vlastimil Babka called the approach premature, arguing that the project needed a human-facing policy before it started configuring machines. Lorenzo Stoakes pushed for an official kernel AI policy document to be discussed at the Maintainers Summit rather than settled by patch. David Alan Gilbert floated a Generated-by trailer as an alternative to the Co-developed-by tag Levin had initially proposed. Torvalds himself was unconvinced that a dedicated tag was needed at all, suggesting the changelog body could carry the information.

The compromise that emerged eighteen months later gave each camp something. The humans got a policy document before the machine configuration. The tag sceptics got a trailer that is recommended rather than mandated. Stoakes got a document produced through summit consensus rather than a single maintainer’s patch. Levin got the machine-readable field he wanted, in a format that can be counted with git log --grep.

The GZDoom affair, running in parallel through late 2025, showed what happens when a project handles the same situation badly. Christoph Oelckers, the long-time lead of the widely used Doom source port, was found to have merged undisclosed AI-generated patches. When contributors raised it, his response amounted to an invitation to fork. They took it. The UZDoom fork absorbed the majority of active contributors and the original project was reclassified as historical. The lesson most maintainers drew was not that AI code is dangerous but that concealing it destroys the working relationship that voluntary projects depend on.

Levin’s case and Oelckers’ case differ in one respect that matters. Levin disclosed voluntarily, at a conference, in front of the people affected, and then did the work of building the disclosure infrastructure. That is roughly the maximum available remedy for a breach of this kind, and it is why he retains standing in the community. The kernel’s policy is, in a real sense, a penance document — which may explain both its brevity and its refusal to moralise.

The Developer Certificate of Origin under machine authorship

The DCO is a hundred and eighty words of plain text that every kernel contributor asserts by adding a Signed-off-by line. It was introduced in 2004, during the SCO litigation, to create a documented chain of assertions about where code came from. It says, in effect: I wrote this, or I received it under a compatible licence and have the right to pass it on, or someone else certified it and I am forwarding it unchanged. It also states that the contribution and the record of it are public and will be redistributed.

Model output does not fit any of the three branches cleanly, and that is the whole legal problem. Branch (a) requires the contribution to be created in whole or in part by the person signing. Branch (b) requires knowledge that the work is covered under an appropriate open source licence. Branch (c) requires that the certification came from someone else. A developer who prompts a model and receives forty lines of C has not created them in the ordinary sense, does not know what licence the underlying training material carried, and has no upstream certifier to point at.

QEMU built its ban on exactly this reading. The project’s code provenance policy rejected contributions that might include or derive from AI-generated content, and the reasoning was that the DCO presupposes a human author. In many jurisdictions purely machine-generated output attracts no copyright at all, which leaves nothing for a human to own and therefore nothing to certify. The secondary concern was cleanliness: models trained on large corpora of GPL, AGPL, proprietary and unlicensed code can emit fragments that reproduce training data, and there is no practical way for a contributor to know when that has happened.

Red Hat’s public analysis in late 2025 reached a similar conclusion about the risk while stopping short of a ban. Because models are trained on code that often carries copyleft terms, a developer using a coding assistant cannot genuinely guarantee provenance, and a certification made in that state of uncertainty weakens the DCO framework for everyone who relies on it.

The kernel’s answer was to leave the DCO text untouched and shift the burden of interpretation onto the signer. This is more defensible than it first appears. The DCO has never required the signer to be certain; it requires them to certify to the best of their knowledge, and the standard has always been one of good faith rather than forensic proof. A developer who reviews generated code line by line, understands what it does, can defend it under review, and has no reason to believe it reproduces protected expression is in a position broadly similar to a developer who adapted an approach from a textbook.

The weakness in that position is proportionality. A three-line completion reviewed carefully is one thing. A four-hundred-line driver produced from a single prompt, skimmed for plausibility, and signed off is something else, and the DCO text does not distinguish between them. The kernel’s tool-generated content guidelines address this directly by tying the expected level of scrutiny to the proportion of the contribution that was generated, but that is a norm rather than a rule, and norms are only as strong as the maintainers enforcing them.

There has been recurring discussion in the wider open source legal community about a DCO version two written for machine authorship. The obstacle is adoption. The current DCO is embedded in the tooling and contribution flows of an enormous number of projects and hosting platforms, and revising it would create a long period in which two incompatible certifications circulate. Analysis of QEMU’s ban in 2025 identified this precise trap: the fix is obvious in principle and close to unimplementable in practice.

Assisted-by as a data format rather than a permission slip

Strip away the argument and the Assisted-by trailer is a schema decision. Someone had to choose what fields go into the permanent record of the largest collaborative software project in existence, and the choice they made was: tool name, model version, optional analysis tools. Each of those fields was picked for a reason, and each has since been contested.

The model version field exists to make retrospective triage possible. The reasoning, set out plainly in LWN’s July coverage, is that if a particular model turns out to have a characteristic failure mode — a tendency to get locking wrong, an inclination to reproduce a specific block of training data — the community would want to identify every patch produced with it and re-examine them. Without the version, that query cannot be run. With it, git log --grep becomes a recall mechanism.

That is a genuinely useful property, and it is the strongest argument the tag’s defenders have. It is also the argument that fails first under scrutiny, because it only works if disclosure is near-complete. If half the machine-generated patches carry no tag, a recall based on tags produces false confidence: you clean up the disclosed set and declare the tree safe while the undisclosed set remains untouched. A partial provenance record can be worse than no provenance record, because it invites people to treat the absence of a tag as evidence of human authorship.

The tool-name field serves a different purpose. It tells a reviewer which workflow produced the patch, which in practice correlates with how the patch was constructed — an agentic tool running an edit loop over a repository produces different artefacts from an inline completion engine. A maintainer who has learned that patches from a particular pipeline tend to be structurally sound but weak on error paths can direct attention accordingly. This is craft knowledge, and the tag makes it accumulable.

The bracketed analysis tools are the least controversial part and the most quietly sensible. Kernel developers have run coccinelle, sparse, smatch and clang-tidy for years without disclosing them, and the file’s decision to fold them into the same trailer normalises the whole category. It says, in effect: tools have always been part of this, here is where you record which ones you used, and the generative ones go in the first position because they are the ones that produce novel text rather than rework existing text.

The exclusion list — git, gcc, make, editors — draws the boundary at tools that do not author. Nobody discloses their compiler. The question the file leaves genuinely open is where completion engines sit. An editor with aggressive identifier completion is a typing aid. The same editor running a model that writes whole functions is an author. The line between those two states is a slider, not a switch, and the kernel’s second document is the one that tries to place it.

Levin’s design intent shows through in one further detail: the trailer is machine-parseable. It follows the same Key: value convention as every other kernel trailer, sits in the same block as Signed-off-by and Reviewed-by, and can be extracted by the same scripts that already generate development statistics. The tag was built for measurement first and disclosure second, which is why the people who most want to keep it are the people who want to know how much of the kernel is now machine-written.

Tool-generated content and the wider disclosure net

The second document, Documentation/process/generated-content.rst, shipped in the 7.1 documentation set and does most of the practical work. Where the coding-assistants file addresses AI specifically, this one addresses tooling in general, and its framing is notably calmer: kernel contributors have used tools to generate contributions for a long time, tools increase the volume of contributions, and reviewer bandwidth is scarce. Understanding which parts of a contribution came from a human and which came from a tool helps protect that bandwidth.

The out-of-scope list is precise. Spelling and grammar fixes, including rephrasing into the imperative voice the kernel prefers in changelogs. Typing aids such as identifier completion and boilerplate insertion. Purely mechanical changes such as variable renaming. Reformatting with Lindent, clang-format or rust-fmt. None of these trigger disclosure, though the document adds a nudge: even when your tool use falls outside scope, consider whether telling the reviewer would help them.

The in-scope test is the one that matters. The guidelines apply when, in the document’s own phrasing, a “meaningful amount” of content in a contribution was not written by a person in the Signed-off-by chain but was instead created by a tool. That phrasing does two things at once. It sets a proportionality threshold without quantifying it, and it anchors the test to the signature chain rather than to the technology, which means it catches a patch written by an unnamed colleague as squarely as one written by a model.

The examples are more revealing than the rule. A fix suggested by checkpatch.pl --fix. A coccinelle script. A chatbot generating a new sorting function inside a patch. A .c file originally generated by a coding assistant and then cleaned up by hand. A changelog produced by handing the patch to a generative tool. A changelog translated from another language. That last one is the tell: the document is about the honesty of the authorship record, not about artificial intelligence as a category.

There is a second obligation buried in the in-scope section that most coverage missed. Detection and testing count as part of development, so if a tool was used to find the problem a patch addresses, that belongs in the changelog. The stated reasons are credit and discovery — other developers should learn which tools are finding real bugs. In practice this is the clause that covers fuzzers, static analysers and review bots, and it is the clause Greg Kroah-Hartman has been complying with all year.

The transparency guidance asks contributors to record what tools were used, the input to those tools including the coccinelle source script, the prompts where code was largely generated from a short set of them, a summary of the prompts for longer sessions, which portions of the content the tool affected, and how the submission was tested. Publishing prompts as part of a kernel changelog is a genuinely novel documentation practice, and one that has not yet been widely adopted, but the request is on the record.

The maintainer-discretion list is where the document gets its teeth. A maintainer may treat a tool-assisted contribution like any other, reject it outright, apply extra scrutiny, deprioritise it, ask for additional testing, ask the contributor to explain how the tool or model was trained, ask them to demonstrate that they understand how the code works, or respond by suggesting a better prompt rather than a specific code change. That last option is a small, strange glimpse of a future in which review comments target the generation process instead of the output.

The closing lines set the standard that everything else rests on. Output may be incorrect or inappropriate. You are expected to understand and defend everything you submit. If you cannot, do not submit it — and if you do so anyway, maintainers are entitled to reject the series without detailed review. That is the enforcement mechanism the kernel actually has: not detection, but the withdrawal of reviewer attention from people who waste it.

Counting the tags across 7.0, 7.1 and 7.2

The numbers are the most useful thing in this whole story, because they are the only part of it that cannot be argued into a different shape. LWN’s development statistics for each release now include an Assisted-by count, and the trajectory over three cycles is steep.

Linux 7.0 contained 31 commits carrying the tag. Corbet noted at the time that many contributors were clearly not adding tags when they should. When he checked linux-next during the same period, he found 105 tagged changesets among more than 12,000 waiting to move into mainline. Linux 7.1 contained 299 tagged commits — close to a tenfold increase in a single cycle. By 7.2-rc4, the cumulative total across the tree had passed 1,200.

Bold caveat worth stating once: none of these figures measure how much of Linux was written by AI. They measure how many commits carried a voluntary trailer in a period when the trailer was newly introduced, unenforced, contested by prominent maintainers, and actively stripped by at least one subsystem maintainer. The true proportion is unknown and unknowable with current tooling. Every developer quoted on the subject through 2026 has said the same thing in different words.

Assisted-by disclosure and contributor growth by kernel release

Figures are drawn from LWN’s per-release development statistics and its July 2026 coverage of the disclosure debate; the 7.2 figure is a running total across the tree rather than a single-cycle count, and the developer and first-timer records for 7.1 were reported without a final headline number at the time of writing.

Two of those columns move together, and that correlation is the load-bearing observation of the entire year. Kernel 6.18, released at the end of November 2025, set a participation record with 2,134 developers, beating the 2,090 set by 6.2 in 2023. Linux 7.0 broke that record by more than two hundred, with 2,362 developers and 489 first-timers. Linux 7.1 broke it again, with 530 first-time contributors — the highest figure ever recorded for a single cycle.

For context on how unusual that is: first-time contributor counts sat comfortably under 350 for most of the 6.x series. Kernel 6.12 brought in 335, 6.18 brought in 333, and 6.14 managed only 228. Going back further, 4.12 set what was then a record with 334 in 2017. The jump to 489 and then 530 is not noise. Corbet attributed it, in the 7.1 statistics, to the increasing availability of LLM-based development tools, and observed that these new developers were appearing in surprising places — the SLIP protocol implementation, largely untouched outside maintenance for years, suddenly saw activity.

There is a second reading of the same data that deserves an airing. The number of contributors with unknown corporate affiliation has been growing, and LWN links that growth to the first-timer surge. A model lowers the entry cost for someone with no employer paying them to learn kernel internals. Some of those people will become long-term contributors; most will submit one patch and disappear, as most first-timers always have. What has changed is the ratio of submissions to sustained relationships, and maintainer time is spent on submissions.

The kernel itself kept growing through all of this. Linux 7.2-rc1 crossed 43 million lines, up from roughly 39.8 million in late 2024 and around 19 million in 2015. That growth continued even as 7.1 dropped support for Intel’s i486 and removed more than 140,000 lines of obsolete code including legacy PCMCIA host controllers and ISDN drivers. Corporate developers authored the large majority of kernel commits through 2025 — around 84% by one accounting, spread across more than 1,780 contributing organisations — and there is no indication that the AI surge has changed that balance. The new contributors are additive, not substitutive.

First-time contributors arriving with a model in hand

Roman Gushchin opened a 2026 conference talk on LLM patch review with a slide showing Bag End labelled “LLMs”, a joke about them coming to our pleasant code, and next to it the graph of first-time contributors from the Linux 7.0 statistics with its roughly 50% jump. The two images were on the same slide for a reason. He built a review tool because the input volume changed.

That is the causal chain the kernel is actually dealing with. Models lower the cost of producing a patch that looks correct. The cost of determining whether a patch is correct did not fall by a comparable amount, because that cost is paid in expert attention, and the supply of kernel subsystem experts is fixed in the short term and shrinking in some corners. Every mechanism the project has built this year — the tags, the review bots, the security list rewrite, the guidance on maintainer discretion — is an attempt to manage that asymmetry.

The composition of the new contributions is as interesting as the count. Cleanup work, refactoring passes, error-path fixes, missing bounds checks, resource leaks in unloved drivers: these are the categories where a model performs well and where human contributors have historically been scarce, because the work is unglamorous and confers little status. Linux is being repaired at the edges by people who would not previously have attempted the repair.

That is a real gain, and it should not be waved away by anyone worried about slop. Subsystems like SLIP, or the older graphics drivers, or half the sound and HID code, have survived for years on the attention of one or two volunteers. A tool that lets a competent generalist produce a defensible fix to code they do not know intimately expands the pool of people who can keep that code alive. The counter-argument is that a defensible-looking fix to code you do not know intimately is exactly the failure mode maintainers fear, and both statements are true simultaneously.

The distribution of harm is uneven in a way that shapes the politics. Well-resourced subsystems with multiple active maintainers absorb the extra volume. Thinly staffed subsystems do not. When Torvalds and others discussed removing support for a set of ancient network drivers in 2026, the influx of automated bug reports against code nobody uses was part of the justification: maintenance burden on largely unused systems had become hard to defend. The tools that keep some legacy code alive are simultaneously making other legacy code too expensive to keep.

There is a further effect on the review side that has not yet shown up in statistics. Maintainers who receive a higher volume of plausible patches from unfamiliar names respond by tightening their heuristics — favouring known contributors, demanding more test evidence, deprioritising anything without a clear subsystem fit. That is rational behaviour and it raises the barrier for genuine newcomers who happen to be arriving at the same time. The kernel has spent two decades working on newcomer onboarding. A volume shock of this size pushes in the opposite direction.

Nothing in the published data separates the two populations. LWN’s statistics count first-time contributors, not first-time contributors who used a model, and the tag data is too incomplete to serve as a proxy. Anyone claiming a precise split between genuine new developers and one-shot tool-assisted submitters is guessing. What can be said with confidence is that both populations grew, that the growth is unprecedented in the git era, and that it began in the same cycle in which the disclosure tag was introduced.

Torvalds and the limits of pointless posturing

Torvalds’ position on AI has been consistent since the debate started, and it has almost nothing to do with what AI can or cannot do. It is a position about enforcement.

The argument reached its loudest point in January 2026, when Intel’s Dave Hansen and Oracle’s Lorenzo Stoakes clashed publicly over how aggressively the kernel should police AI tooling. Torvalds shut the argument down by describing debate over outright bans as pointless posturing. His reasoning, reported consistently across the coverage that followed, runs like this: contributors who submit substandard code are not reading the contribution documentation anyway, so a rule aimed at them changes nothing. A ban punishes the conscientious and is invisible to everyone else. The project’s only real influence lies where it has always been — in the willingness of maintainers to accept or reject what lands in their inbox.

This is not a defence of AI. It is a claim about what documentation can accomplish in a distributed project with no employment relationship over most of its contributors. The kernel cannot audit what runs on a developer’s laptop, so it regulates what arrives at the mailing list. Every enforceable rule the project has is downstream of that constraint.

The comparison Torvalds and others have reached for repeatedly is the compiler. Nobody discloses their toolchain. Nobody demands to know which compiler flags produced a submitted binary, because the submitted artefact is source and the source is judged on its merits. The analogy is imperfect and its critics have said so at length — compilers are deterministic, auditable, and do not reproduce fragments of other people’s copyrighted work — but as a description of where the project chooses to place its attention, it holds.

Torvalds has also been more positive about the tools than his reputation would suggest. In the Linux 7.0 release notes he observed that the final week involved an unusual number of small but important fixes and suggested that AI tools were helping developers find corner cases, describing this automated bug hunting as potentially the new normal for keeping Linux stable. He attributed the unusually busy 7.0 cycle partly to a psychological effect from the new major version number, which is a characteristically deflationary explanation, but the point about corner cases was made in earnest.

The version number itself is worth a sentence, because it is routinely over-read. Torvalds has said the jump from 6.19 to 7.0 carried no architectural meaning; he increments the major number when the minor number gets large enough to confuse him. Linux 7.0 is not the AI kernel. It is the kernel that happened to be in the merge window when the policy landed.

Where Torvalds has been genuinely inventive is in following his own logic further than most of the community was ready to go. In the July 2026 discussion about pre-existing bugs found incidentally by review tools, he raised the possibility that a model could produce its own fixes for those bugs and maintain a tree of its own patches — trivial changes the AI has high confidence in, run by a group the community has high confidence in. Nobody rushed to support it. It is nonetheless the only proposal on the table that treats the tooling as a contributor with a tree rather than an accessory to a human, and it will resurface.

Brauner’s patch and the move to strip model names

The disclosure requirement survived exactly six months before a serious attempt was made to dismantle it.

On 1 July 2026, Christian Brauner posted a patch proposing that the Assisted-by tag either be removed or reduced to drop the name of the specific model. His stated position was more radical than the patch: he would abolish disclosure requirements entirely. His argument had three parts. Outside the core contributor group, most people simply do not disclose, so the requirement produces a misleading record rather than an accurate one. The tag introduces undefined legal status. And — a point that landed harder in mid-2026 than it would have a year earlier — recent events in which models were abruptly withdrawn from availability made naming a specific model in permanent history look less prudent than it once did. His fallback proposal was to reduce the trailer to the two words Assisted-by: LLM.

The day after, Jeff Layton posted a separate patch removing the attribution requirement altogether. The two patches together represented a real prospect that the tag would be gone before its first anniversary.

Support materialised quickly from an unexpected quarter. Jakub Kicinski, who maintains networking — one of the highest-volume subsystems in the tree — let it be known that he simply strips those tags from patches he applies. A maintainer unilaterally deleting a field that the Technical Advisory Board and the community had agreed to add is a governance event, not a stylistic preference, and Corbet described it as undermining the earlier decision. Other maintainers stopped short of deletion while expressing little enthusiasm for the tag.

The defence came from Kroah-Hartman and Stoakes. Kroah-Hartman’s argument was operational: the tag signals that a model was involved and that the patch warrants closer review. That is a modest claim and a hard one to argue with, since he has been attaching such tags to his own patches all year. Stoakes framed the policy in terms of maintainer authority — the current arrangement is about giving maintainers grounds to push back, which is a different function from provenance tracking and arguably a more durable one.

The advertising objection deserves to be taken seriously rather than dismissed as pettiness. Kernel git history is permanent, publicly searchable, and mirrored everywhere. A commercial vendor whose model name appears in tens of thousands of commits acquires a form of association with the project that it did not pay for and that the project did not vote on. Reducing the trailer to a generic LLM marker removes that association while preserving the review signal Kroah-Hartman cares about. It also destroys the retrospective triage capability, which is the tag’s strongest justification.

The outcome, as of late July 2026, is a partial one. There was enough support for keeping some form of the tag to block outright removal. Nobody was willing to defend the requirement to name the specific tool. The apparent consensus is Brauner’s fallback — a simplified trailer, perhaps with a better-argued changelog — but no revised patch had appeared, and a final decision looked likely to wait for the Maintainers Summit in October. The kernel spent 2026 with a disclosure policy that a substantial fraction of its senior maintainers had already stopped believing in.

Kicinski, deleted tags and the enforcement vacuum

The kernel has no mechanism to detect undisclosed machine authorship, and everyone involved has said so. The policy’s own author acknowledged that enforcement was deliberately left out. Detection tools built for prose perform poorly on code and worse on code that has been edited after generation. There is no CI gate, no scanner, no heuristic that survives contact with a competent contributor who chooses not to disclose.

What the project has instead is a set of social pressures, and it is worth being precise about how weak they are. Gentoo’s council member Michał Górny described his own project’s ban in similar terms: the point is to make clear what is acceptable and politely ask contributors to respect it. Enforcement happens when a maintainer notices mistakes of a kind a human would be unlikely to make and asks questions. That is the entire apparatus, at Gentoo and at the kernel alike.

Kicinski’s stripping of tags adds a second failure mode on top of non-disclosure: disclosed information being discarded downstream. A contributor who follows the documented process, adds the trailer, and sends the patch to networking will find that the published history contains no record of the tool. From the perspective of anyone later trying to audit the tree, that patch is indistinguishable from one written entirely by hand. Two independent leaks in the same pipeline mean the tag count is a floor with no known ceiling.

There is an argument that this does not matter much. If the human signer is fully responsible regardless, and if the review standard is the same either way, then the provenance record is a nice-to-have rather than a control. That argument works right up until someone needs to run a recall — a licence dispute over a specific model’s output, a class of bug traced to a particular tool, a downstream vendor asked by a regulator to characterise the machine-generated content in a shipped product. At that point the difference between a complete record and a partial one is the difference between a query and an archaeology project.

The comparison to other trailers is instructive. Reviewed-by and Tested-by are also voluntary, also unenforced, and also imperfectly applied — Reviewed-by appeared on roughly 49% of commits in 6.18 and Tested-by on about 9%. Nobody regards those numbers as a scandal, because nobody claims those tags measure the total amount of review or testing that occurred. Assisted-by has been read as a measurement instrument in a way that Reviewed-by never was, and it cannot bear that reading.

The realistic path to better data is not enforcement but incentive. If maintainers consistently gave tagged patches faster or friendlier review — treating disclosure as a signal of good faith rather than a confession — the tag would spread. At present the incentive runs the other way: in some subsystems a tag invites additional scrutiny or outright rejection, which is exactly the behaviour the maintainer-discretion guidance permits. A disclosure regime that raises the cost of disclosing will be under-used, and no amount of documentation fixes that.

Greg Kroah-Hartman’s clanker and local inference on a desktop

While the community argued about attribution, the kernel’s second-most senior maintainer was quietly demonstrating what a defensible workflow looks like.

In April 2026, Greg Kroah-Hartman started running a local language model against kernel code as a fuzzing aid. The setup, which he named gkh_clanker_t1000 in a joint nod to Terminator and to the mildly dismissive slang term for AI, is a Framework Desktop built around AMD’s Ryzen AI Max+ “Strix Halo” — sixteen Zen 5 cores and up to 128GB of unified memory in a 4.5-litre Mini-ITX chassis. He posted a photograph of the hardware to Mastodon in late April after Phoronix drew attention to the patch stream it was producing.

The workflow has four steps and the order matters. The tool bombards code with unexpected inputs and flags suspicious behaviour. Kroah-Hartman, with decades of subsystem knowledge, decides which findings are real. He writes the fix himself. He signs it and takes responsibility. The model is positioned as a detector, not an author, which places the whole exercise squarely inside the tool-generated content guidelines’ clause about disclosing tools used to find problems.

He started with ksmbd and the SMB code, choosing that subsystem because it is straightforward to stand up and test locally in virtual machines, and noted early on that he had potentially found minor problems in the handling of untrusted clients. Since 7 April, close to two dozen assisted patches reached mainline, covering ALSA, HID, SMB, Nouveau and io_uring. A later batch staged in his driver-core tree targeted USB Type-C, input drivers, media drivers and the Industrial I/O subsystem, addressing stack memory leaks, insufficient bounds checking and weak driver-level validation. A successor configuration, gkh_clanker_2000, followed with methodological refinements.

Every commit carries Assisted-by: gregkh_clanker_t1000. His patch submissions include an unusually direct disclaimer telling reviewers that the changes pass only his own limited testing and asking them, in plain terms, to verify rather than trust — “please don’t trust them at all”, as he put it. That instruction does more work than the tag does. It tells a reviewer exactly how much of the verification burden has already been discharged and how much remains.

The local-execution detail is the part with the widest implications. No cloud API, no kernel snippets crossing a network boundary, no dependency on a vendor’s continued goodwill or pricing. For a maintainer handling embargoed security material, sending code fragments to a third-party inference endpoint is not a preference question, and Kroah-Hartman’s setup demonstrates that a consumer-class machine with enough unified memory can run the workload. That single fact undercuts the strongest structural objection to LLM tooling in the kernel — dependence on donated commercial inference — at least for the fuzzing and analysis case.

It does not undercut it for review at scale, which is a different workload with different economics, and that distinction runs through the rest of this story.

Sashiko and the shift from writing code to reviewing it

The most consequential AI deployment in the kernel does not write code at all. It reads it.

Sashiko is an agentic patch-review system announced by Roman Gushchin, a kernel engineer at Google, and first covered publicly in March 2026. The name comes from a Japanese reinforcement stitching technique — small stabs used to strengthen worn cloth — which is a better metaphor than most tool names manage. It is written in Rust, fully self-contained rather than wrapping an external agent CLI, ingests patches from mailing lists or from a local git checkout, and can work with several model providers. Its primary testing was against Gemini 3.1 Pro, with Claude and others supported.

It reviews every patch sent to the linux-kernel mailing list and several others, automatically.

Gushchin’s headline measurement is the number everyone quotes. Against an unfiltered set of 1,000 recent upstream issues identified through Fixes: tags, Sashiko found roughly 53% of the bugs. His own framing of that result is the part worth keeping: some will say 53% is unimpressive, but every one of those issues had been missed by human reviewers in the original pass. A tool that catches half of what experienced kernel reviewers let through is not a marginal addition to the process.

It is built on review prompts Chris Mason — the Btrfs creator — published through LWN in October 2025, meaning the approach predates the tool by about five months. Where Sashiko departs from Mason’s work is in protocol: it runs a multi-stage review that deliberately mimics the human process, forcing the model to look at a change from several angles rather than producing a single pass. Gushchin has been candid about the failure mode as well, describing the tool as rarely flat wrong but prone to nitpicking and to surfacing low-value issues.

Both properties being true at once is the whole argument. Sashiko finds real bugs that humans missed, and it generates noise that consumes the scarce reviewer attention the kernel is trying to protect. Which effect dominates depends on the subsystem, the volume, and the maintainer’s tolerance — which is precisely why the community fought about it rather than simply adopting or rejecting it.

Adoption has been fast. By July 2026 the tool had seen extensive uptake across many subsystems and maintainers were increasingly expecting contributors to read and respond to its reviews. Andrew Morton was named early as one of the maintainers taking that position. Ted Ts’o described Sashiko as finding problems human reviewers might not notice while insisting it is not a substitute for human review, and separately said the thing that most excites him about it is the reduction in his own workload.

Its findings have already changed technical outcomes. During development of the kernel’s multiple-tracepoint attachment work, Sashiko identified an interaction between tracepoints and live kernel patching that produced a lock-inversion deadlock — the kind of cross-subsystem interaction that is genuinely hard for a human reviewer to hold in mind, because it requires simultaneous familiarity with ftrace internals and livepatch semantics. That is the class of bug where the tool’s advantage is structural rather than incidental.

The pre-existing-bugs problem is the friction point nobody has solved. When Sashiko reviews a patch it also finds defects in the surrounding code that were already there, and the kernel code base, it turns out, still contains no shortage of them. Nobody argues those bugs should go unreported. Many argue that the developer who happened to touch nearby code should not be conscripted into fixing them. Torvalds noted that maintainers demanding contributors fix unrelated problems has been a long-running pain point, that it does not work, and that it should not be done with machine-found bugs either. The current direction is to maintain a separate list of pre-existing issues for whoever has time.

Where Sashiko sits in the process is the detail that makes it durable. It is not a gate. It does not block merges. It produces email that a human can act on, argue with, or ignore, and it does so inside the mailing-list workflow the kernel has used for two decades. Compared with the alternative — a mandatory bot check in a forge, which the kernel does not use — this is an unusually low-friction integration, and it explains why a tool announced in March had become an expected part of subsystem workflow by July.

Donated inference and the BitKeeper precedent

Google is paying for Sashiko’s inference. That sentence contains the most serious unresolved risk in the kernel’s AI adoption, and the person who raised it loudest is the tool’s own principal developer.

In his proposal for a Maintainers Summit discussion, Gushchin wrote that several kernel engineers and maintainers had reasonably objected to relying on infrastructure supplied by a single company with no formal guarantees, and asked what a more durable model might look like. Corbet has raised the same concern more than once, and reached for a precedent the kernel community feels in its bones.

Twenty years ago, kernel development depended on BitKeeper, a proprietary distributed version control system. Access was withdrawn abruptly in 2005. The project survived because Torvalds wrote a replacement over a long weekend, and that replacement was git. The community’s ability to absorb that shock was a historical accident that will not repeat, and Corbet’s observation is that nobody should expect a weekend rewrite of a frontier language model.

The structural comparison to Nexus One handsets — freely distributed to developers by Google in an earlier era, with developers subsequently expected to buy their own — captures the pattern without needing malice on anyone’s part. Corporate generosity toward developer tooling is a marketing expense, and marketing expenses get cut. The question is not whether the subsidy ends but what state the community’s own capabilities are in when it does.

The responses from within the community have been notably relaxed, which is either reassuring or the point. Levin’s position is that if AI vanished tomorrow it would be unpleasant but he would go back to writing his tools by hand as before. The sentence immediately preceding that in his email is the interesting one: over the previous year or two he had rewritten most of his rough scripts, automated processes he used to do manually, and improved a long list of quality-of-life items using AI — and much of the infrastructure behind the kernel’s own CVE process, created in 2024, was built with it.

Dave Chinner, a long-time XFS developer, put it more starkly in a separate conversation, saying he had learned to drive the tools well enough that he no longer needs to write code, using the model as a code editor with extremely capable predictive insertion. For a developer who dislikes the physical act of typing code, he called it a revelation. Neither developer describes themselves as dependent, and both descriptions are of workflows that would break if the tools disappeared.

There is work in progress on the obvious mitigation. Mauro Carvalho Chehab and Takashi Iwai have both mentioned efforts to run Sashiko-class review locally using open-weight models. Iwai’s assessment is honest about the gap: many false positives, poor tracking of recent changes, and much lower coverage than Sashiko manages. That gap will narrow — Kroah-Hartman’s local fuzzing setup shows what a consumer machine can already do — but review at mailing-list scale is a heavier workload than periodic analysis of one subsystem, and the arithmetic of running it locally for every patch on linux-kernel does not yet work.

The secondary risk is stratification. Even if commercial tools remain available, they may become priced beyond the reach of developers who do not work for companies that can absorb the cost. A kernel in which corporate-employed maintainers have machine review and independent contributors do not is a kernel with a two-tier contribution process, and the project’s existing corporate concentration — roughly 84% of commits from corporate developers — means that tier already exists in embryo. Nobody has proposed a mechanism to prevent it.

Pinchart, Lyude Paul and the labour argument nobody wanted

The July 2026 discussion started as a narrow request about mailing lists and turned into the most revealing exchange the kernel community has had about AI, because it stopped being about code quality and became about working conditions.

The narrow request came from the media subsystem. Mauro Carvalho Chehab, its maintainer, reported after the 2026 Media Summit in May that a separate mailing list had been created to receive Sashiko’s review emails and keep them off the main media list. He added that some contributors wanted the ability to opt out of receiving machine reviews of their own patches.

Gushchin’s response was that an opt-out seemed as strange as asking to opt out of unit tests. Chehab agreed with him on the etiquette point — community convention is to copy the author on replies — while noting that others saw it differently. Laurent Pinchart countered that etiquette also requires asking before signing someone up for a new mailing list. When Gushchin asked whether even a critical finding should be withheld from a patch author, Pinchart answered that maintainers who want to act on machine reviews should triage and verify them before bothering the author.

Maintainers did not receive that suggestion warmly. Ts’o declined the duty outright and said he feels no obligation to accept patches from contributors who refuse to look at the reviews. Ihor Solodrai argued that making a patch good enough to merge is the contributor’s job and that in the current environment this includes addressing bugs a machine found. Gushchin pointed out that attackers use these tools regardless of whether contributors accept them. James Bottomley put the governance point most bluntly: a contributor does not get to approve the tools a maintainer uses to assess and apply patches.

Pinchart’s counter-argument is the one that has not been answered. Since maintainers are the ones driving adoption, they should spend the time the tools save them on triage rather than passing unverified machine output to contributors. Requiring developers to respond to unchecked reviews, he argued, forces them to justify their value against a machine known to produce a non-trivial quantity of nonsense — and is the mirror image of maintainers being forced to read unchecked machine-generated patches. He also relayed the specific concern from the Media Summit: false positives and hallucinations land hardest on junior developers, who have the best context on their own work but are least equipped to question the validity of a review that sounds authoritative.

That concern is well-founded and rarely discussed. A confident, technically fluent review comment carries social weight. A newcomer who receives one has no calibration for how often the tool is wrong, and the rational response to an authoritative-sounding critique is deference. The people best placed to push back on a bad machine review are exactly the senior maintainers who have delegated the reading of it.

Then Lyude Paul, a Red Hat engineer, made the argument that shifted the register of the entire discussion. Developers need their paychecks, she pointed out, and are in no position to fork the kernel or walk away from it. Employers are explicitly pushing these tools on people, expecting a productivity multiplier that is not compatible with genuine oversight, and in many workplaces the tools are being used as a pretext to abandon review and code quality standards altogether. The kernel has dealt with slop for decades, she acknowledged — but a tool that dramatically lowers the cost of producing large volumes of code that passes a sniff test is not, in fact, like other tools.

Her conclusion is the part that should give the project pause. For developers trying to hold the line on code quality, the kernel’s own guidelines may be the only instrument they have to push back on their employers safely. Written community standards function as labour protection for engineers under management pressure, and weakening them removes cover from the people doing the careful work.

That reframing explains a pattern that otherwise looks like inconsistency. Employer pressure has made many developers unwilling to argue publicly against these tools, which left Pinchart as one of the few prepared to do so, which in turn made his position look more marginal than it is. An argument that cannot be made safely appears to have less support than it has.

Fork it or walk away

Torvalds’ intervention in that thread became the most widely reported thing he said all year, and the context in which he said it is routinely dropped.

Gushchin had responded to the per-developer opt-out request by characterising it as an anti-LLM position in general and as something that would defeat the purpose of helping maintainers. Torvalds’ reply was that Linux is not one of those anti-AI projects, that anyone with a problem can do the open-source thing and fork it, or simply walk away, and that AI is a tool like other tools the project uses — clearly a useful one.

Read in isolation, that is a project lead telling dissenters to leave. Read in context, it is a project lead refusing to let a technical thread about mailing-list plumbing become a referendum on the technology. Both readings are defensible and the first one travelled further.

Where the exchange became harder to defend was on ethics. Pinchart had stated his position without hedging: in his view there is currently no ethical justification for using generative AI in free software development. Torvalds shut that line of discussion down, telling him to keep his ethics in his personal life and not to enforce them on others.

Corbet’s assessment of that moment is worth restating carefully, because it is the most substantive criticism of Torvalds’ handling of the year. Developers, given the chance, will describe a list of ethical misgivings about these tools: an industry decision to disregard copyright, the possibility that model output infringes, the energy consumption of large-scale inference, the effect of data-centre construction on nearby communities, the concentration of control over these models in very few hands, the systemic economic exposure created by the share of the economy now pulled into the sector, and the position of website operators contending with scraping. Whether or not one agrees with any of those concerns, they exist, and a rule that only technical reasons may be discussed does not make them go away.

The kernel community cannot fix any of those problems. It also cannot pretend the tools do not exist. Corbet’s point is that it equally cannot pretend the ethical questions do not exist without risking the alienation of the developers who hold them — and those developers are, disproportionately, the ones doing unglamorous review work that nobody is paid to do.

There is a governance observation underneath all of this that applies well beyond Linux. “Fork it” is a coherent answer in a project where contributors are volunteers and an incoherent one in a project where most contributors are employed to be there. Roughly 84% of kernel commits come from corporate developers. Telling that population to fork is telling them to quit their jobs. The kernel’s governance model was designed for a community of volunteers and now governs a community of employees, and the AI debate is the first issue to expose that mismatch clearly.

The security list collapse and Willy Tarreau’s rewrite

The most concrete damage AI has done to Linux in 2026 was not to the code. It was to the private security mailing list.

On Sunday 17 May 2026, in his announcement of Linux 7.1-rc4, Torvalds described the kernel’s private security list as almost entirely unmanageable, with enormous duplication caused by different people finding the same things with the same tools. He noted that maintainers were spending their time forwarding reports to the right people or explaining that an issue had already been fixed a week or a month earlier, pointing at the public discussion. He called the whole cycle entirely pointless churn.

The volume figures behind that assessment are stark. According to maintainer Willy Tarreau, the list went from two or three reports a week two years earlier to between five and ten per day in early 2026. That is not a change in degree. A private, embargoed channel designed for a handful of genuinely sensitive disclosures per week cannot function at ten reports a day, because every report must be read, routed, deduplicated and answered by a small group of people who are also the people writing the fixes.

The problem first surfaced during the 7.0 release candidate cycle, when the project received a much larger volume of bug reports than usual. Most were minor and none serious enough to delay the release, and Torvalds suspected at the time that more contributors were simply running tools. By 7.1 the pattern had become a structural failure.

Linux 7.1 shipped documentation written by Tarreau to address it. The core instruction is a reversal of the default: a finding produced with AI assistance should be treated as public, not as a private security disclosure. The reasoning stated in the documentation is that bugs discovered this way systematically surface simultaneously across multiple researchers, often on the same day. Torvalds’ version of the same argument is that a bug found by an automated tool is, pretty much by definition, not secret — because anyone else running the same tool against the same code will find it too.

That inference is worth sitting with, because it inverts a premise the security industry has operated on for thirty years. Embargo exists to give defenders time before attackers learn of a flaw. It works when discovery is scarce and unevenly distributed. When discovery becomes cheap and evenly distributed — when any competent person with an API key finds the same use-after-free on the same afternoon — the embargo protects nobody and costs the defenders their coordination bandwidth. The private channel becomes a bottleneck that slows the fix without delaying the attacker.

Routing machine-found bugs privately makes the duplication worse rather than better, for a mechanical reason: the private list prevents reporters from seeing each other’s submissions. Ten researchers who could have seen a public thread and moved on instead each file independently and each require an individual response.

The instruction to reporters is therefore threefold. Report AI-assisted findings publicly, direct to the relevant maintainers rather than the security list. Verify the finding before reporting it. And, ideally, submit a tested patch alongside the report rather than a raw finding. That last part is where Torvalds put the emphasis: the value a researcher adds is understanding and a fix, not the raw output of a scan that anyone can reproduce.

Kroah-Hartman’s clanker workflow is the model this documentation is describing, and the symmetry is deliberate. Find the issue with a tool, verify it yourself, write the fix, submit it publicly, sign it, own it. That is the behaviour the kernel wants and it is the behaviour that most external AI-assisted reporting has not exhibited.

Duplicate findings and the end of the private embargo

Kroah-Hartman described an inflection point in early 2026 that deserves more attention than it received, because it changes the shape of the problem.

For a period, what the kernel security team was mostly handling was what he called AI garbage — obviously wrong, low-quality machine-generated security reports. Then, around February 2026, something flipped. In his description, the whole world switched, and the reports started arriving real. He observed the same shift reported by security teams at other open source projects, and was clear that nobody knows the cause. Either the tools improved sharply or people started using them more seriously. The practical conclusion he drew was the same either way: these tools are here and they are getting stronger.

The kernel’s problem in mid-2026 is therefore not slop. It is genuine findings at a volume the human process cannot absorb. That is a materially harder problem than filtering nonsense, because there is no filter to build. Every report deserves attention on the merits, and the merits are no longer the constraint.

curl’s experience tracks the same curve almost exactly and gives it independent confirmation. Daniel Stenberg shut the project’s HackerOne bug bounty on 31 January 2026 after nearly seven years, 87 confirmed vulnerabilities and more than $100,000 in rewards, because the confirmed-vulnerability rate had collapsed from a historical figure above 15% to under 5%. His summary of 2025 was that not even one in twenty was real. In the first three weeks of 2026 the project received twenty submissions, seven of them inside a single sixteen-hour window, and after full analysis concluded that none of them identified a vulnerability.

Then in March 2026, curl returned to HackerOne — not because the flood had stopped, but because its character had changed. The reports came back technically accurate and did not slow down. Stenberg’s own framing of what AI is good and bad at is the most useful diagnostic anyone has published: the tools are excellent at detecting bugs, poor at judging severity, and poor at writing correct fixes, which leaves the hardest and least automatable work entirely with human maintainers. Duplicates proliferate because different researchers prompt the same model and receive the same answer.

By July 2026 curl had gone further, accepting no vulnerability reports at all between 1 July and 3 August — no HackerOne, no email, no exceptions — in what Stenberg called the summer of bliss. Nextcloud closed its bounty in April. HackerOne’s own Internet Bug Bounty team has restricted programmes for related reasons.

What is breaking is not open source security. It is the bug bounty as an economic instrument. Bounties worked because vulnerability discovery was scarce, skilled labour, which naturally capped submission volume at the number of people capable of doing it. Removing that constraint removes the mechanism that made the payout model solvent, and no project has yet published a replacement design.

The counter-evidence for the value side is real and should be recorded. Autonomous analysis has produced genuine, serious findings — including a critical use-after-free remote code execution flaw in Redis that had gone unnoticed for more than two years, carrying a high severity score. Nobody sensible argues the tools do not find real bugs. The argument is entirely about the ratio of signal to triage cost and about who pays the triage cost, which in open source is almost always an unpaid or under-resourced maintainer.

Tooling in Linux before the models arrived

The kernel has been generating its own code for longer than most of the current argument acknowledges, and the history explains why the community reached the policy it did rather than a ban.

Coccinelle, the semantic patching tool, has been rewriting kernel source since 2008. It takes a specification of a code change and applies it across the tree, and it has produced tens of thousands of commits. checkpatch.pl --fix proposes changes automatically. Sparse and smatch have been finding type and logic errors for two decades. syzkaller, Google’s kernel fuzzer, has been filing bug reports continuously since 2015 and has produced thousands of them, complete with reproducers. Kernel developers have never had a romantic attachment to purely hand-written code.

What distinguishes those tools from language models is determinism and auditability. A coccinelle rewrite is specified by a script that a reviewer can read, and the same script applied to the same input produces the same output every time. A sparse warning points at a specific construct with a specific rule. syzkaller produces a reproducer that either crashes the kernel or does not. None of these tools invent text, and none of them carry provenance risk from training data. That is why the coding-assistants document puts them in a bracketed position rather than the primary field.

The syzkaller precedent is the closest structural analogue to the current situation, and it is oddly under-cited. When automated fuzzing began filing bugs at scale, the kernel had exactly the same volume problem it has now: a machine producing findings faster than humans could triage them, against subsystems whose maintainers had not asked for the attention. The community’s response was to build infrastructure — dashboards, automatic bisection, reproducers attached to reports, dedicated mailing lists — and to accept a permanent backlog as the cost of knowing about the bugs.

That response is instructive because of what it did not include. Nobody proposed banning fuzzers on the grounds that they overwhelmed maintainers. Nobody argued that a bug found by a machine was less real than a bug found by reading. The complaint was about triage cost, the fix was tooling, and the outcome was a substantially more reliable kernel. The current AI debate is the same argument with one new variable — provenance — layered on top of a familiar volume problem.

The Rust integration offers a different kind of precedent, for the governance question rather than the tooling question. Rust in the kernel was contested for years, advanced incrementally, and generated genuine friction between maintainers who saw it as necessary and maintainers who saw it as an imposition on subsystems they were responsible for. It was resolved not by a vote but by a slow accumulation of working code plus explicit statements from Torvalds about who gets to block what. The AI question is following a similar path, with one difference: Rust arrived as a proposal from within, and AI arrived as a fact from outside.

The kernel’s tooling history also explains the specific shape of the disclosure requirement. A project that already had trailers for review, testing, reporting, bisection and co-development had an obvious slot for one more. Reported-by, Suggested-by, Tested-by, Reviewed-by, Co-developed-by, Fixes — the commit trailer is the kernel’s native format for recording who or what contributed and how. Adding Assisted-by required no new infrastructure, no forge feature and no process change. It is the lowest-friction intervention the project could have made, which is both its virtue and the reason it is so easy to ignore.

Gentoo, NetBSD and the ban camp

Other projects reached the opposite conclusion from the same premises, and their reasoning deserves a fair hearing rather than the dismissal it usually receives.

Gentoo moved first. In mid-April 2024 its council voted unanimously to forbid contributions produced with natural-language AI tools, citing three grounds: copyright, quality and ethics. NetBSD followed the same month, updating its commit guidelines to state that code generated by a large language model or similar technology is presumed to be tainted and must not be committed without prior written approval. That phrasing is careful — it presumes rather than concludes, and it leaves a route open through explicit approval — but the practical effect is a ban.

QEMU adopted a code provenance policy in June 2025 declining any contribution known or suspected to include or derive from AI-generated content. Zig maintains one of the strictest positions in open source, with its community lead publishing a detailed rationale in April 2026 framed around what contribution means when the cost of producing a plausible submission falls to nearly zero. GIMP has taken a restrictive line. LLVM permits the tools but treats unreviewed AI submissions as extractive contributions and bars AI entirely from work labelled as suitable for first-time contributors — a small, precise rule that protects the specific resource newcomer-friendly issues exist to allocate.

The strongest argument in the ban camp is not about code quality. It is about what a contribution is for. In a volunteer project, accepting a patch is an investment in a person: the review conversation transfers knowledge, builds a relationship, and produces a contributor who may maintain that code in future. A submission generated at near-zero cost by someone who does not understand it consumes the review investment and produces nothing on the other side. Zig’s framing of contribution as a repeated game with reputational stakes captures this better than the licensing arguments do.

The licensing argument is nonetheless the one most projects lead with, and NetBSD’s word choice — tainted — reveals why. Taint is a term of art from the SCO era and from clean-room reimplementation practice. It describes a state in which you cannot prove your code is free of someone else’s protected expression, and in which the safest response is to discard it. Applied to model output trained on unlabelled corpora of GPL, AGPL, permissive and proprietary code, the term is defensible even if it is unflattering.

Enforcement is where every ban meets the same wall the kernel’s disclosure regime meets. Gentoo’s own council member acknowledged that the policy’s real purpose is to state what is acceptable and ask contributors to respect it, with enforcement limited to maintainers noticing errors a human would be unlikely to make and asking questions. QEMU’s policy applied to contributions where AI use was known or suspected — which in practice means someone volunteered the information or left obvious traces. Detection tools do not work reliably on code, and they work least well on the case that matters most, which is generated code subsequently edited by a competent human.

Gentoo’s February 2026 migration to Codeberg added an unusual wrinkle to its position. Part of the motivation was that GitHub’s Copilot prompts had become difficult to reconcile with a project whose policy forbids the tool, which is a reminder that platform defaults now exert policy pressure of their own. A project can ban a tool from its codebase far more easily than it can ban a tool from the interface its contributors use.

The honest summary is that the ban camp and the disclosure camp are both operating honour systems, differ mainly in what they ask contributors to be honest about, and have produced roughly the same enforcement reality. What differs is the signal each sends to a contributor deciding where to spend their evening.

QEMU’s reversal and Red Hat’s changed risk calculus

The most telling event of the year was not a new policy. It was a project abandoning one.

In late May 2026, Paolo Bonzini — a distinguished engineer at Red Hat and a KVM maintainer — posted a patch to the QEMU mailing list replacing the project’s blanket prohibition on AI-generated contributions. The proposal permits AI assistance in areas where, as he put it, the consequences of a copyright problem are easy to revert and unlikely to spread. Core code would remain off-limits without prior agreement from a maintainer.

The framing in his explanation is what makes this notable. Bonzini stated that the concern motivating the original policy is unchanged, and restated it precisely: the DCO is about whether the submitter has the legal right to contribute the code, not about creative expression. The copyright and licence status of model output remains unsettled, so that question is still open. The policy changed while the underlying legal uncertainty did not.

What changed was the assessment of exposure relative to benefit. Phoronix characterised it as a shift in the balance of believed risk, with Red Hat feeling more comfortable on the matter. Read carefully, the proposal is a risk-segmentation exercise rather than a legal reinterpretation: identify the parts of the codebase where a contaminated contribution can be identified and reverted cheaply, permit the tools there, and hold the line where a problem would propagate into derived work and become expensive to unwind.

That is a more sophisticated position than either a ban or a general permission, and it is one that enterprises will recognise immediately, because it is how they handle every other category of legal risk. The interesting question is why it took two years to arrive at. The plausible answer is that a blanket ban was cheap to adopt when adoption cost nothing and became expensive once a substantial share of contributors were using the tools anyway, at which point the ban started functioning as a filter on honest contributors rather than on risky code.

Red Hat’s position across its various roles in 2026 is worth mapping, because the company sits on several sides of this. Its own published analysis warned that model training on copyleft-licensed code makes provenance guarantees impossible and could weaken the DCO framework. Its engineer proposed relaxing QEMU’s ban. Its engineers argued both for and against AI initiatives inside Fedora. And the company announced a Fedora variant explicitly built by an automated pipeline for consumption by agents. A company that large does not have a position; it has a portfolio of positions calibrated to different risk surfaces, and the QEMU proposal reflects the calculation for a component where reversion is feasible rather than a corporate line.

For anyone tracking where this settles, Bonzini’s segmentation is the most likely template. It maps cleanly onto how large codebases are actually structured — peripheral drivers and tests where a bad change is contained, core interfaces where it is not — and it gives maintainers a defensible basis for saying yes in one directory and no in another without appearing arbitrary.

Debian’s decision not to decide

Debian, which packages roughly 59,000 pieces of software with about 1,400 developers, spent February and March 2026 debating an AI contribution policy and ended without adopting one.

The debate closed without a general resolution vote. The project decided to continue handling AI contributions case by case rather than adopting a project-wide rule. Given Debian’s constitutional machinery — general resolutions, technical committee, a strong tradition of formal process — the absence of a decision is itself a decision, and it was reached deliberately.

The reasoning that emerged was practical rather than philosophical. No detection tool works reliably enough to enforce a ban. Reported false-positive rates on code-oriented detectors are high enough that a policy built on them would generate more disputes than it resolved. A rule that cannot be applied consistently damages the credibility of the rule-making body, and Debian’s authority rests heavily on the perception that its policies mean something. Declining to write an unenforceable rule is a defensible governance choice, even when it looks like paralysis.

There is a second consideration specific to Debian’s position in the ecosystem. Debian does not primarily write code; it packages code written elsewhere. A Debian maintainer’s work consists of build recipes, patch series against upstream sources, dependency declarations and changelog entries. Much of that is exactly the mechanical, template-following work that the kernel’s tool-generated content guidelines place explicitly out of scope. A policy strict enough to catch generated C in an upstream project would sweep in an enormous volume of routine packaging work, and drawing that line coherently is genuinely hard.

The inconsistency across projects that Debian’s inaction leaves in place has consequences for individual developers. A contributor using an autocomplete assistant faces rejection at Gentoo, acceptance under Linux Foundation project rules, disclosure obligations in the kernel, and no defined position in Debian. That contributor’s rational response is to work where the rules are clearest and least hostile, which over time redistributes contribution toward permissive projects — an effect that has been predicted repeatedly and not yet measured.

The Linux Foundation’s own stance sits at the permissive end and is worth stating for completeness: AI-generated code is acceptable where the tool’s terms of service do not conflict with open source licences and where contributors verify compliance. That places the burden on the contributor to read a model provider’s terms, which very few do, and which change without notice.

For anyone building policy inside a company, Debian’s outcome carries a specific lesson. The projects that adopted the strongest positions did so early, when the cost was low; the projects that waited found that the decision had been made for them by contributor behaviour. Debian’s case-by-case approach is a way of acknowledging that without conceding it in writing, and it may prove more durable than either a ban or a disclosure mandate.

Fedora Hummingbird and the agent-native software factory

Everything above concerns AI writing Linux. Fedora Hummingbird concerns AI consuming it, and it is the clearest sign that the industry expects the primary user of an operating system to stop being a person.

Red Hat announced Fedora Hummingbird Linux at Red Hat Summit in Atlanta on 12 May 2026: a free, container-native Linux distribution described as designed for agent-first builders, hosted within the Fedora Project. It is image-based and rolling-release, built around upstream-stable versions of key components, and — the phrase that matters — delivered by what Red Hat’s own announcement calls a lights-out, agent-native software factory.

Parse that description slowly, because it is doing two separate things. The distribution is built by an automated pipeline in which agents perform work that release engineers previously performed. And the distribution is designed to be selected and deployed by agents rather than installed by administrators.

The second half is where the specific design decisions show up. Hummingbird supports anonymous, agent-driven pulls for near-instantaneous deployment across hybrid cloud environments. Registration walls are removed deliberately, on the stated reasoning that any manual registration, form or verification creates a bottleneck for an agent whose sole goal is standing up an environment quickly. Red Hat is explicit that the operating system is engineered to become the default selection by AI agents. It bypasses the six-month release freezes that stability-oriented distributions use, giving access to the newest runtimes and components, and it is positioned as a path from a developer laptop through proof of concept to production on Red Hat Enterprise Linux and OpenShift Virtualization.

Gunnar Hellekson, vice president and general manager for RHEL, framed the rationale as a market split: operations teams need the decade-scale stability of RHEL, while builders — both human and agentic — want upstream velocity and image-based workflows. He described Hummingbird as defining the platform for the agents that build the future of enterprise software.

Removing registration friction because an agent cannot fill in a form is a product decision with a security corollary nobody has fully worked through. Registration walls exist partly for licensing and telemetry, but also as a weak identity check and a rate limiter. A distribution engineered for anonymous automated pulls at high velocity is, by construction, a distribution well suited to the same access pattern an attacker’s automation would use. That is not an argument against the design; it is an argument that the compensating controls have to live somewhere else, and Red Hat has not yet published where.

Commercially the structure is familiar and rational. The distribution is free and community-hosted. Cooperative Community Support is planned as a component of a Red Hat subscription. Extended offerings for compliance, scale and production workloads are planned without requiring migration. Fedora has always functioned as the upstream funnel into RHEL; Hummingbird applies that model to a market segment Red Hat expects to be dominated by automated consumers, and captures the eventual enterprise conversion.

The strategic reading is more interesting than the product. If agents are choosing the operating system, then distribution competition shifts from human factors to machine factors — how fast the image pulls, whether authentication blocks automation, how current the runtimes are, how predictable the layer structure is for caching. Desktop polish, documentation quality and community reputation matter less. Whichever distribution is easiest for an agent to acquire and stand up becomes the default in a very large number of ephemeral environments, and defaults compound.

Whether the demand Red Hat is describing actually exists at the claimed scale is unproven. The announcement is a positioning document, and positioning documents describe markets their authors want to create. The verifiable facts are the design choices: no registration, rolling release, image-based, automated build pipeline, agent-oriented distribution mechanism. Those choices are real regardless of whether the market materialises, and they will be copied if it does.

Governance friction inside Fedora

How Hummingbird reached the world matters as much as what it is, because the process broke Fedora’s own rules and the project is still absorbing the consequences.

An automated approach to building an operating system called Project Hummingbird was raised on the Fedora development list in April 2026. It attracted interest and some confusion about how it differed from existing Fedora variants, but little outright opposition. It was never formally proposed through Fedora’s change process, though the person raising it indicated an intention to do so through a new sandbox initiative that had itself not been approved.

Instead, Red Hat asked the Fedora Council privately for permission to use the Fedora trademark, and announced the project at Red Hat Summit. Fedora contributors outside Red Hat learned about it from the press release. A corporate sponsor bypassing a community project’s public process while using its trademark is precisely the failure mode Fedora’s governance was designed to prevent.

The reaction on Fedora’s discussion forum was measured but pointed. Michael Gruber questioned whether Hummingbird was legitimately a Fedora project at all, allowing that there might be good ideas in it while stating he could place no trust in it given how it started and how it was communicated. Christopher Klooz worried that a funding-based justification implied Fedora being turned step by step into a corporate unit of Red Hat, and noted that it was already unclear when the Council acts as an agent of Red Hat and when as an agent of the community.

Adam Williamson, a Red Hat employee and long-standing Fedora contributor, gave the most useful defence — not of the process, which he agreed should have been more open, but of the outcome. The more work Red Hat does outside Fedora, he argued, the greater the risk the company questions why it funds Fedora at all. His description of how Fedora looks from inside Red Hat to people who do not work on it is worth quoting in spirit: a source of strife full of opinionated people who are not on the payroll, who argue endlessly, and who require you to write a wiki page and convince a stranger that your idea is good. The constant tendency, he said, is for the company to spin things up in channels it fully controls, which seems easiest at first and becomes a mess after a few years.

His counter-proposal is that Fedora competes not by becoming the closely governed upstream some parts of Red Hat superficially want, but by being the loosely coupled project with involved people who make things awkward and usually produce a better long-term result — acting as a check on the company’s own perceptions.

The Hummingbird episode did not occur in isolation. Fedora’s AI-assisted contribution policy deliberation in 2025 had already exposed a gap between Red Hat’s desire to experiment with AI in Fedora and contributors who wanted a much less AI-friendly policy. In March 2026 the Fedora Project Leader proposed a technology-innovation-lifecycle process called the Fedora Sandbox, allowing experiments that break non-legally-binding policies provided there is a reasonable path to resolution. That proposal has been neither accepted nor rejected.

Then a Red Hat developer proposed an AI developer desktop initiative on 31 March 2026, aiming to build a community around AI technologies within Fedora. It met opposition ranging from dislike of AI to concerns about changing Fedora’s policy on out-of-tree kernel modules. The Council initially approved it, then a member changed his vote on 8 May, blocking it. Another changed his vote on 13 May, stating that the community was not supportive of the initiative as it stood.

On 1 July 2026 Fedora’s change wrangler announced that the Council was proposing a pause to the entire community initiatives process, saying the AI developer desktop had shown the process had failed as a framework for surfacing ideas and gaining Council support. A distribution project has suspended its mechanism for setting strategic direction because it could not process one AI proposal, and the AI desktop proposal was formally closed as a consequence of the pause. Whether initiatives are retired or rebuilt has not been decided.

Canonical’s roadmap and the desktop side of the question

Canonical published its plan on 27 April 2026, and the contrast with both Red Hat’s approach and Microsoft’s is deliberate.

Jon Seager, Canonical’s vice president of engineering for Ubuntu, posted a detailed roadmap on the Ubuntu community forum describing AI features arriving throughout 2026. The framing distinguishes implicit features — background improvements where the system simply works better, using on-device models for things like speech-to-text and text-to-speech to improve accessibility — from explicit features, which are new opt-in capabilities such as generative text while writing documents, agents for file management, and troubleshooting assistance. Server-side possibilities mentioned include interpreting system logs.

Three commitments carry the weight. Local inference by default, so requests leave the machine only when a user explicitly configures a cloud provider, a self-hosted server or an enterprise model service. A preference for open-weight models whose licence terms are compatible with Canonical’s values, which determines which weights the company is prepared to distribute. And no forced integration — Seager’s stated position is that Ubuntu is not becoming an AI product.

The delivery mechanism is Canonical’s inference snaps: packages bundling quantised open models tuned for the host hardware, including Qwen and DeepSeek variants, so that users do not have to manage model configuration and dependencies by hand. Reporting on the roadmap indicated the features would appear mainly as experimental previews in Ubuntu 26.10 rather than in the 26.04 LTS release, which is the correct sequencing — long-term support releases are for stability and enterprise deployment, and exploratory desktop features do not belong in a default LTS experience.

The backlash was immediate and it was about trust rather than technology. Users flooded the forum thread demanding hardening of the opt-in model and, in plenty of cases, a global AI kill switch. Some announced they were evaluating other distributions. The reason is not obscure: a large share of recent Ubuntu adopters arrived from Windows specifically to escape unremovable assistant buttons, screenshot-based recall features and a dedicated assistant key placed where a modifier used to be. For that population, any AI roadmap reads as the beginning of the same sequence.

Canonical’s answer has been to emphasise architecture rather than promises. Local inference means the privacy question is answered by where the computation happens rather than by a policy document. Open weights mean the model can be inspected and replaced. Opt-in means the default state is off. Those are structural commitments that are harder to reverse quietly than a stated intention, which is why they are the right things to have committed to.

The system-level integration question is the harder one and it has had less scrutiny. A settings agent that lets users change system configuration in natural language is not a chat window; it is a component with write access to system state. The mature implementation uses controlled internal APIs with explicit definitions of what can be read, what can be changed, when confirmation is required and how failures roll back. The immature implementation scrapes the screen, guesses at controls and simulates clicks. The difference between those two designs is the difference between a feature and a privilege-escalation surface, and the interesting technical detail to watch in Ubuntu is which one ships.

The comparison with Hummingbird is instructive because the two companies are solving different problems with the same technology. Red Hat is building for a machine consumer and removing human-oriented friction. Canonical is building for a human user and keeping the machine subordinate. Both are defensible; they simply describe different bets about who will be operating Linux systems in five years.

Legacy drivers, R600 and the maintenance economy

The most sympathetic case for AI in Linux is also the least discussed, and it involves graphics hardware from 2007.

In June 2026, 59 commits landed in Mesa 26.2 refactoring the AMD R600 Gallium3D driver, largely cleaning up the shader compiler code. The driver covers the Terascale architecture — Radeon HD 2000 through HD 6000 series, spanning 2007 to 2010, plus various rebadged parts that appeared later. AMD stopped contributing upstream work for these GPUs long ago. Gert Wollny is among the very few developers still working on the driver, and has previously added NIR backend support and improved compute capability.

The merge request states that the refactoring was done with the help of Copilot in auto mode, and the individual patches reflect the assistance. Phoronix reported it first, and the story travelled widely under the heading of vibe coding, which several commenters correctly pushed back on: Wollny is an experienced Mesa developer, and the use of a tool in part of the work says nothing about whether he understood the code. Vibe coding properly describes programming without a working understanding of what is being changed. This was refactoring by someone who knows the driver, with machine assistance on the mechanical parts.

The economics here are the entire argument. A large cleanup pass across a shader compiler is weeks of unglamorous work with no new functionality at the end of it. For a driver maintained by one or two volunteers with no vendor support, that work does not happen — not because it is hard but because nobody has the weeks. A tool that compresses it into a manageable effort is the difference between the driver receiving structural maintenance and receiving none.

The generalisation matters well beyond one Radeon driver. Large parts of the Linux hardware support surface are maintained by single individuals: older sound codecs, obscure HID devices, industrial interfaces, network drivers for hardware that shipped in the 1990s, filesystem drivers for formats nobody creates any more. That long tail is one of Linux’s genuine advantages over commercial operating systems, and it survives on unpaid attention that is not replenishing.

The counter-pressure is real and appeared in the same year. Discussion in 2026 about removing support for a set of ancient network drivers cited, among other reasons, an influx of automated bug reports against code that is largely unused — maintenance burden had become hard to justify. Machine assistance is simultaneously extending the life of some legacy code and shortening the life of other legacy code, and the discriminator is whether a human is still willing to be responsible for it. Where a maintainer exists, the tools multiply their reach. Where none exists, machine-generated reports simply document that nobody is home, and the pragmatic response is removal.

Linux 7.1 illustrates both halves. It dropped Intel i486 support and removed more than 140,000 lines including legacy PCMCIA host controllers and ISDN drivers, while the tree overall crossed 43 million lines by 7.2-rc1. The kernel is growing and pruning at the same time, and the pruning decisions are now partly informed by how much automated noise a subsystem generates relative to how many users it has.

Provenance, the Cyber Resilience Act and machine-readable history

The regulatory clock is the reason provenance stopped being an abstract concern in 2026.

The EU Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024 and phases in over roughly three years. From 11 June 2026, the provisions on conformity assessment bodies and notifying authorities apply, and member states designate national authorities and notified bodies. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents, through the CRA Single Reporting Platform operated by ENISA, on a strict cascade: a 24-hour early warning, a 72-hour fuller notification, a final report within 14 days once a fix is available for an exploited vulnerability, and within one month for a severe incident. From 11 December 2027 the remaining obligations apply — secure-by-design requirements, conformity assessment, technical documentation, CE marking and SBOM generation. The Commission published implementation guidance on 27 July 2026, with 67 practical examples and specific attention to microenterprises and SMEs.

The Act introduces a category that did not previously exist in EU law: the open source software steward, defined in Article 24 as a legal person providing sustained support for free and open source software intended for commercial activities. Stewards face a light-touch regime — a documented cybersecurity policy that supports secure development of the products they support, cooperation with market surveillance authorities and provision of security documentation on request, and from 11 September 2026, reporting of actively exploited vulnerabilities and severe incidents affecting the systems they provide for development. No CE marking, no formal conformity assessment, no retention of technical documentation, and no administrative fines. Individual volunteer developers remain outside scope entirely. Purely non-commercial FOSS development is exempt from fines.

Commercial vendors distributing open source components in their products remain fully responsible for those components. That is the sentence that connects the CRA to the kernel’s Assisted-by debate, because a manufacturer shipping a Linux-based product carries manufacturer obligations for the kernel inside it regardless of the kernel project’s own status.

The SBOM requirement is more limited than it is usually described. Manufacturers must produce a machine-readable software bill of materials covering at least the top-level dependencies of every product with digital elements, keep it current, and provide it to market surveillance authorities on reasoned request. It goes into technical documentation as a compliance artefact; there is no obligation to publish it. The standards scaffolding is in place — SPDX under ISO/IEC 5962, CycloneDX under ECMA-424, SLSA for build provenance, Sigstore for artefact verification, CSAF and VEX for exchanging vulnerability and exploitability information — with a European standard under development through CEN/CENELEC.

Nothing in the CRA mentions AI-generated code, and nothing in it requires disclosure of machine authorship. The connection is indirect but firm: the Act pushes the entire industry toward documented, machine-readable, auditable statements about what is in a product and where it came from, at exactly the moment when the authorship of a growing share of that code has become unverifiable.

The practical exposure sits in three places. First, secure-by-design obligations from December 2027 require manufacturers to demonstrate a development process, and a process that accepts generated code without documented review is harder to defend than one that does not. Second, the vulnerability reporting cascade from September 2026 assumes an organisation can determine quickly what a flaw affects, which requires knowing what its dependencies contain. Third, and most speculatively, if a class of vulnerability is ever traced to a specific model’s output, a manufacturer asked to characterise its exposure will need exactly the recall capability that the kernel’s model-version field was designed to provide — and that Brauner’s proposal would remove.

That is the sharpest tension in this entire story: the kernel is debating whether to reduce provenance detail in the same period that its downstream consumers are acquiring legal obligations that reward provenance detail. Neither side is being unreasonable. Kernel developers are prioritising their own workflow and objecting to advertising in permanent history. Product manufacturers are preparing for a conformity assessment two years away. The two constituencies barely talk to each other, and the resolution will probably arrive as a downstream vendor-maintained mapping rather than an upstream policy.

Copyright exposure and the questions courts have not answered

The legal position on model-generated code remains genuinely unsettled, and anyone who tells you otherwise is selling something.

Three questions are open. Whether purely machine-generated output attracts copyright protection at all, which in many jurisdictions it appears not to, leaving nothing for a contributor to own or license. Whether training on copyleft-licensed source and emitting derived output constitutes preparation of a derivative work, which is a question about the mechanics of specific models and specific outputs rather than a general principle. And whether a contributor who cannot determine the answer to either question can make a good-faith DCO certification.

The kernel’s answer to the third question is that they can, provided they review what they submit and are prepared to defend it. QEMU’s original answer was that they cannot. Bonzini’s proposal accepts the uncertainty and manages it by segmenting the codebase according to how expensive a mistake would be to undo. All three are reasonable readings of an unresolved situation, which is itself the most useful fact for anyone setting internal policy.

The specific mechanism that worries lawyers is verbatim regurgitation. A model trained on a corpus containing a distinctive implementation can, under the right prompting, reproduce it closely. The probability is low for any given generation and non-zero across millions of generations, and it rises for code that is idiomatic, widely copied and structurally constrained — which describes a great deal of systems code. Nobody has a practical detection method for this at contribution time, and the tools that exist compare against public repositories, which is a subset of any large training corpus.

The GPL amplifies the consequence relative to permissive licences. A permissively licensed fragment that finds its way into a GPL codebase creates an attribution problem. A GPL fragment that finds its way into a proprietary codebase creates a licence-compliance problem with a well-established enforcement history. Linux is GPL-2.0-only, which means the risk direction that matters for the kernel is inbound contamination from incompatible sources, and the risk direction that matters for companies shipping Linux-based products is their own proprietary code acquiring obligations it was not meant to have.

There is also a quieter risk on the model-availability side that Brauner raised and that most commentary skipped. Models have been withdrawn from availability abruptly, for commercial, regulatory and export-control reasons. A permanent commit history that names a specific model version creates a durable public record of dependency on an artefact that may no longer exist, may have been withdrawn under legal pressure, or may later be found to have been trained improperly. Whether that record is an asset or a liability depends entirely on facts not yet known, and reasonable people are choosing differently.

For practical purposes, the defensible position for an organisation contributing to Linux in 2026 has four elements. Require human review proportional to how much of a change was generated. Keep an internal record of tool and model use even if the upstream project does not want it in the commit. Prefer tools whose terms of service explicitly address output ownership and indemnification. And assume that the disclosure requirements of the projects you contribute to will change at least once more before they settle.

Mapping the four positions open source has taken

Reduced to its structure, the open source world has produced four distinct answers to the same question, and knowing which one a project has adopted tells you most of what you need to know before contributing to it.

Open source AI contribution policies compared

Positions are drawn from each project’s published policy documents and from reporting through 2024 to 2026; LLVM sits between the second and third rows, permitting tools generally while barring them from newcomer-designated issues.

The fifth position, held by nobody formally, is the one operating in practice: permission without disclosure. That is what a policy produces when it recommends a trailer, provides no detection, and permits maintainers to strip the trailer. It is not a policy anyone chose; it is the equilibrium the incentives produce, and treating it as the real baseline avoids a great deal of confusion when reading tag counts.

A useful diagnostic for anyone assessing a project is to ask what the policy is protecting. Bans built on licensing are protecting the project’s legal position. Bans built on contribution philosophy, as at Zig, are protecting the review relationship and the pipeline of future maintainers. Disclosure regimes are protecting reviewer attention allocation. LLVM’s narrow rule about newcomer-designated issues is protecting a specific scarce resource. Policies that try to protect all four at once tend to be the ones that get abandoned, because the mechanisms required are mutually inconsistent.

The convergence pressure is toward the third row, for an unglamorous reason. Corporate contributors — who write the large majority of kernel commits and a substantial share of everything else — are being instructed by their employers to use these tools. A project that bans them either loses those contributors or receives their work undeclared. Neither outcome improves the project’s position, which is roughly the calculation Red Hat made at QEMU.

Sector impact across hardware, cloud, embedded and security

The consequences fall unevenly, and the differences are worth setting out sector by sector rather than as a general observation about disruption.

Hardware vendors carry the largest direct exposure because they are the largest source of kernel code. Drivers and architecture support dominate every release, GPU drivers alone routinely account for a substantial share of the diff, and vendors employ the engineers who write them. For these organisations the immediate questions are procedural: whether internal engineering policy permits assistant use on upstream-destined code, whether the Assisted-by trailer is applied consistently, whether an internal record survives if a maintainer strips the trailer, and whether the same code is also shipped in a product subject to CRA obligations. A vendor whose driver appears both upstream and in a CE-marked product has two different provenance regimes applying to the same source.

Cloud and hyperscale operators face the review-capacity problem more than the authorship problem. They run enormous custom kernel trees, backport aggressively, and depend on upstream stability. Their interest is in the reliability of the review process, which is why Google is funding Sashiko’s inference and why a Google engineer built it. The risk they are managing is not bad AI code entering the kernel; it is the maintainer bandwidth that their own patch volume depends on being consumed by other people’s automated submissions.

Embedded and industrial vendors have the longest support horizons and the least slack. A device shipping a 6.x LTS kernel with a ten-year field life needs a provenance story that remains coherable a decade from now, when the model that generated part of a vendor driver may not exist and the tool vendor may not either. These are also the organisations for whom the CRA’s December 2027 secure-by-design and SBOM obligations bite hardest, because their products are physical, CE-marked and long-lived. The correct posture here is to record more than upstream asks for and to keep it internally, because the internal record is the only one you control.

Security teams and vulnerability researchers are experiencing the sharpest structural change. The bug bounty as a payment model is under real strain: curl closed its programme, Nextcloud closed its programme, and HackerOne’s own Internet Bug Bounty team has restricted activity. The discovery of vulnerabilities has stopped being scarce skilled labour and become a commodity, while triage, severity assessment and fix authorship remain expensive human work. Stenberg’s diagnostic — good at detection, poor at severity, poor at fixes — is the operational summary a security leader should be planning around. The reasonable response is to invest in triage capacity and reproduction infrastructure rather than in discovery incentives.

Distribution vendors sit between the two worlds and are being pulled in opposite directions. Red Hat is building a variant for machine consumers while its own contributors argue about AI policy inside Fedora. Canonical is committing to local inference and opt-in behaviour to retain a user base that arrived specifically to avoid imposed assistants. Debian has declined to decide. All three are rational given their commercial positions, and the divergence means downstream integrators can no longer assume a common upstream posture on this question.

Enterprise IT and procurement functions have a narrower but immediate task. Any organisation that will be asked, from September 2026, to report exploited vulnerabilities within 24 hours needs a current inventory of what it runs and what those components depend on. That requirement exists independently of AI, but the AI-driven increase in vulnerability discovery raises the probability that the reporting obligation is triggered. The volume of publicly known kernel flaws has been rising because the tools finding them are cheap and widely available, and a reporting process rehearsed only in theory will not survive its first real use.

Independent developers and small consultancies face the tier problem described earlier. If commercial review tooling becomes a de facto expectation in some subsystems — maintainers already expect contributors to respond to Sashiko’s reviews — then contributors without access are at a disadvantage that has nothing to do with skill. Local open-weight alternatives exist and are improving, with kernel developers actively working on them, but they currently produce more false positives and cover fewer changes. Watching that gap close is the single most useful indicator of whether kernel contribution stays broadly accessible.

Practical steps for developers submitting AI-assisted patches

The kernel’s documentation states the standard but does not translate it into a workflow. Here is the translation, derived from what the two documents require and from what maintainers have said they actually want.

Start by establishing whether disclosure applies at all. Spelling and grammar fixes, imperative-voice rephrasing, identifier completion, boilerplate insertion, mechanical variable renaming and running a formatter are all explicitly out of scope. If a tool wrote a function, generated a source file you then cleaned up, produced your changelog, or translated your changelog from another language, you are in scope. The document’s instruction when in doubt is to choose transparency.

Read the DCO before you sign it, not after. Its rules are short, they predate this debate by two decades, and they have always covered tool-generated contributions. The certification you are making is about your right to submit the code, not about who typed it. If you cannot honestly make that certification, the submission stops there.

Understand the change well enough to defend it under review, and treat that as a hard gate rather than an aspiration. The kernel’s guidance is explicit that if you are unable to understand and defend everything you submit, you should not submit it — and that maintainers are entitled to reject your series without detailed review if you do anyway. In practice this means being able to explain why each error path returns what it returns, why the locking is correct, and what happens on the failure branches you did not exercise.

Test it yourself, on hardware or in a virtual machine, and say what you tested. Kroah-Hartman’s own submissions state plainly that the changes pass only his limited local testing and ask reviewers not to trust them without verification. That kind of specificity about the boundary of your own confidence is more useful to a reviewer than any tag.

Add the Assisted-by trailer in the documented format, with tool name and model version, plus any specialised analysis tools in brackets. Do not list git, gcc, make or your editor. Accept that some maintainers will strip it and that a revised, simplified format may be adopted after the October Maintainers Summit — check the current documentation rather than copying an example from a blog post.

Put the substance in the changelog. The tool-generated content guidance asks for what tools were used, the input to them including any coccinelle script, the prompts where a change came from a short set of them, a summary of the prompts and the nature of the assistance for longer sessions, which portions the tool affected, and how the work was tested. Publishing prompts is not yet common practice, but a changelog that describes the generation process honestly gives a maintainer grounds to trust the rest of it.

Never route an AI-assisted security finding through the private security list. Linux 7.1’s documentation instructs researchers to treat such findings as public and to send them directly to the relevant maintainers. Verify the finding first. Bring a tested patch if you possibly can — that is the specific behaviour Torvalds asked for, and it is the difference between adding value and adding load.

Finally, respond to machine review rather than ignoring it. Maintainers in several subsystems now expect contributors to read and address Sashiko’s comments, and at least one has said he feels no obligation to accept patches from people who refuse to. You are entitled to disagree with a machine review and say why; you are not, in most subsystems, entitled to pretend it did not happen.

Maintainer discretion and the downstream checklist

For maintainers, the useful starting point is that the kernel’s guidance hands you explicit discretion and enumerates your options. You may treat a tool-assisted contribution like any other, reject it outright, apply extra scrutiny, deprioritise it below human-written work, ask for additional testing, ask the contributor to explain how the tool or model was trained, ask them to demonstrate that they understand the code, or respond with a better prompt instead of a specific code change. Choosing among those publicly and consistently is worth more than choosing well privately, because contributors calibrate to observed behaviour.

Set the scrutiny proportional to the generated fraction, which is what the documentation asks for, and say so in your subsystem’s contribution notes. A contributor who knows that a wholly generated driver will receive line-by-line examination while a reviewed completion will not is a contributor who can plan their effort.

Consider what your handling of the trailer signals. Stripping it removes provenance from the permanent record and, more importantly, teaches contributors that disclosure has no upside. Keeping it while treating tagged patches punitively teaches them the same lesson faster. If you want accurate provenance data, disclosure has to be at worst neutral for the person disclosing, and nobody in the kernel has yet designed an incentive that satisfies that constraint.

On review tooling, the argument Pinchart lost on procedure but won on substance is worth taking seriously. If you adopt a machine reviewer and forward its output directly to contributors, you are transferring your triage cost to them, and the people least equipped to absorb it are junior contributors who cannot yet judge when the tool is wrong. Triaging findings before forwarding them is more work than not doing so; it is also the only version of the workflow that does not degrade the newcomer experience.

Treat pre-existing bugs found incidentally as a separate backlog, not as a condition of merging the patch that surfaced them. Torvalds has been clear that demanding unrelated fixes has never worked and should not start working now that a machine is finding them. Maintaining a project-level list of known pre-existing issues, as the community has been discussing, keeps the information without conscripting whoever touched nearby code.

For downstream and product teams, four items are worth actioning now rather than in 2027. Build the dependency inventory, because the September 2026 vulnerability reporting cascade is not executable without it and the December 2027 SBOM obligation will otherwise become an archaeology project. Keep an internal record of tool and model use for code you contribute upstream or ship, independent of whether upstream retains the trailer. Establish who in your organisation makes the DCO certification for AI-assisted contributions and confirm they understand what they are certifying. And check whether you meet the CRA’s open source steward definition, because the obligations are light but they are not nothing, and they begin in September 2026.

The one recommendation that applies to everyone is unglamorous. Write down what your organisation’s practice actually is, because in this area the gap between stated policy and observed behaviour has been the source of every reputational failure so far — Levin’s undisclosed patch, the GZDoom fork, Red Hat’s private trademark request at Fedora. None of those were technology failures. All of them were disclosure failures.

Skill atrophy and the cost of a rugpull

The long-term worry inside the kernel community is not bad code. It is the quiet disappearance of a capability nobody notices losing until they need it.

Corbet set the argument out plainly in July 2026. Machine review finds classes of problem that human reviewers tend to miss. Maintainers will take advantage of the workload reduction — Ts’o has said outright that reduced workload is what most excites him about Sashiko — and having taken advantage of it, they will stop looking for the specific problems the tool reliably catches. It is difficult to imagine the skills needed for that kind of review surviving indefinitely under those conditions.

If the tools are permanent, that loss is no more tragic than the loss of low-level assembly fluency. Those skills stopped being needed and people moved on to work that mattered more. If the tools are not permanent, the community will regret the atrophy. Compilers cannot be taken away from us; data-centre-scale models can, and that asymmetry is the whole of the risk.

The BitKeeper precedent is the community’s reference point and it cuts both ways. Access to a proprietary tool was withdrawn abruptly in 2005, and the kernel recovered because Torvalds wrote git. That recovery is now treated as evidence of resilience when it should be treated as evidence of luck: a single unusually capable person happened to be able to replace the missing component in days. Nobody is going to replace a frontier model over a long weekend.

The developers closest to the tools are the least worried, and their reassurance is oddly self-undermining. Levin says that if AI vanished tomorrow it would be unpleasant but he would go back to writing his tools manually as before — in the same message in which he describes having rewritten most of his scripts, automated processes he used to do by hand, and built much of the infrastructure behind the kernel’s CVE process with it. Chinner says he has learned to drive the tools well enough that he no longer needs to write code, describing the model as a very capable predictive editor and the experience as a revelation for someone who dislikes typing code. Neither man considers himself dependent. Both describe workflows that would need rebuilding from scratch.

There is a second-order risk that has had almost no discussion. Review skill is transmitted by apprenticeship — a newcomer sends a patch, an experienced maintainer explains what is wrong with it, and over several years the newcomer learns to see what the maintainer sees. If a substantial share of that feedback comes from a machine instead, the transmission channel changes character. Machine review is consistent and tireless and it does not explain its reasoning in a way that builds a mental model of the subsystem. A generation of contributors trained largely on automated feedback may end up competent at satisfying reviewers without acquiring the judgement that made the reviewers worth satisfying.

The mitigations under way are the right ones and they are early. Chehab and Iwai are both working on running Sashiko-class review locally with open-weight models, and Iwai’s honest assessment is that the results are not yet comparable — many false positives, poor tracking of recent changes, much lower coverage. That gap will narrow. Kroah-Hartman’s local fuzzing setup already demonstrates that a consumer machine with enough unified memory handles a serious analysis workload without a cloud dependency. Whether the same holds for reviewing every patch on linux-kernel is an open engineering question rather than a settled one.

Open questions heading into the October Maintainers Summit

Several things about this story are genuinely unresolved, and it is worth being clear about which, because the confident predictions circulating are mostly unsupported.

The disclosure format is unresolved. There was enough support to keep some form of the Assisted-by tag and no willingness to defend naming the specific tool, which points toward Brauner’s simplified Assisted-by: LLM. No revised patch had appeared by late July 2026, and the decision may wait for the Maintainers Summit in October. If the model version goes, the tag’s retrospective triage capability goes with it, and the CRA-driven demand for provenance detail will have to be satisfied somewhere downstream.

Enforcement is unresolved and probably unresolvable. There is no reliable detection for machine-generated code, particularly code edited afterwards, and nobody in the kernel community claims otherwise. Any figure describing the AI share of Linux is a floor with an unknown ceiling.

Whether the contributor surge persists is unresolved. First-time contributors jumped to 489 in 7.0 and 530 in 7.1, against a prior norm below 350. Corbet allowed that this might be a temporary blip that settles back under 300, or the beginning of a phase in which the community grows faster. Two cycles is not a trend, and the composition of that population — durable contributors versus one-shot submitters — has not been measured.

The funding of review infrastructure is unresolved. Sashiko runs on inference donated by a single company, its principal developer has raised the sustainability question himself, and it is on the Maintainers Summit agenda. No alternative funding model has been proposed publicly.

Whether machine review can be run locally at mailing-list scale is unresolved. Local efforts exist and produce materially worse results today.

Whether Torvalds’ suggestion goes anywhere is unresolved. He floated the idea of a model maintaining its own tree of high-confidence trivial fixes, run by a group the community trusts. There was no clamour of support. It is nonetheless the only proposal that treats the tooling as a participant with a tree rather than an accessory to a person, and the pressure that produced the suggestion — a growing backlog of machine-identified pre-existing bugs nobody has time to fix — is not going away.

The ethics question is unresolved and has been ruled out of order, which is not the same thing. Copyright practice, energy consumption, data-centre siting, concentration of control and systemic economic exposure are all live concerns held by real contributors. Torvalds has restricted the discussion to technical grounds. Ruling a question out of order does not settle it; it relocates it to private conversations and to the decisions people make about where to spend their time.

Whether agents become the primary consumers of Linux is unresolved, and Red Hat has bet money that they will. Fedora Hummingbird removes registration walls specifically so automated systems can pull images without human intervention, and Hellekson’s stated ambition is to define the platform for the agents that build enterprise software. If that bet pays off, distribution competition reorients around machine-facing properties, and the compensating security controls for anonymous high-velocity automated access have not yet been described.

What is settled is narrow and firm. AI-assisted code is permitted in the Linux kernel. AI agents cannot certify the Developer Certificate of Origin. The human who submits owns the outcome. Machine-found security bugs are treated as public rather than embargoed. Those four rules are in the tree, they shipped in 7.0 and 7.1, and they are the load-bearing structure everything else is being argued around.

Questions readers ask about AI-written Linux code

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

AI Coding Assistants — The Linux Kernel documentation The kernel’s official policy document on AI-assisted contributions, covering licensing, the Signed-off-by prohibition for agents, and the Assisted-by trailer format.

Kernel Guidelines for Tool-Generated Content The broader kernel guidance defining what counts as tool-generated content, what falls out of scope, and the discretion available to maintainers.

Debating the role of large language models in the kernel community Jonathan Corbet’s July 2026 account of the Assisted-by reconsideration, the Sashiko dependence question, and the ethics dispute that followed.

Development statistics for the 7.0 kernel LWN’s per-release statistics recording 2,362 developers, 489 first-time contributors and 31 commits carrying an Assisted-by tag.

Development statistics for the 7.1 kernel The following cycle’s figures, including 530 first-time contributors and 299 tagged commits, with Corbet’s attribution of the surge to LLM-based tooling.

The Sashiko patch-review system LWN’s first coverage of Gushchin’s automated review tool and its measured 53% bug-detection rate against previously missed upstream issues.

Reviewing kernel patches with LLMs Gushchin’s own conference account of why he built Sashiko, its probabilistic behaviour, and its position between static analysis and human review.

Fedora grapples with change LWN’s examination of Fedora’s governance strain, including the Hummingbird trademark request, the blocked AI developer desktop and the paused initiatives process.

linux/Documentation/process/coding-assistants.rst at master The policy file in the mainline kernel source tree as maintained upstream.

PATCH v2 docs: add AI Coding Assistants documentation Sasha Levin’s submitted patch introducing the document, showing the original diff and revision history.

Linux lays down the law on AI-generated code Reporting on the policy’s publication, the Hansen–Stoakes dispute, the Levin disclosure incident and the GZDoom fork.

Linus Torvalds says AI bug reports have made the Linux security mailing list almost entirely unmanageable Coverage of the 7.1-rc4 announcement and the new documentation requiring AI-found bugs to be reported publicly.

Linux kernel’s second-in-command uses local AI bot to hunt bugs Details of Kroah-Hartman’s local fuzzing setup, the hardware behind it, and the subsystems its patches have touched.

Ubuntu’s AI roadmap revealed Reporting on Jon Seager’s roadmap post, the inference snaps mechanism and Canonical’s local-first commitments.

Linux distros ban tainted AI-generated code Contemporary coverage of the Gentoo council decision and NetBSD’s commit guideline change in 2024.

Gentoo and NetBSD ban AI code, but Debian doesn’t yet Analysis of the three grounds Gentoo cited — copyright, quality and ethics — and the provenance problem underneath them.

The new Linux kernel AI bot uncovering bugs is a local LLM on Framework Desktop Phoronix’s report on the clanker hardware and the patch stream it has produced since April 2026.

QEMU shifting on AI policy to allow some AI/LLM-generated contributions Coverage of Bonzini’s patch replacing QEMU’s blanket prohibition, with his statement on the DCO and unsettled copyright status.

Vintage AMD R600 graphics driver sees code cleanups thanks to GitHub Copilot The 59-commit Mesa 26.2 refactoring of the shader compiler, with Wollny’s own note on the assistance used.

Linux driver for vintage AMD GPUs gets an update with a helping hand from Copilot AI Context on the Terascale hardware generations involved and the maintenance economics of an unsupported driver.

Fedora Hummingbird Linux Brings Agentic Linux to Builders Red Hat’s announcement describing the lights-out agent-native software factory, anonymous agent-driven pulls and the planned subscription support model.

Fedora Hummingbird Linux Brings Agentic Linux to Builders The wire release carrying Gunnar Hellekson’s statement on the split between operations stability and builder velocity.

AI code gets approved in the Linux kernel but with strings attached A close reading of the policy document alongside Kroah-Hartman’s clanker branch workflow.

New Linux kernel rules put the onus on humans for AI tool usage A concise summary of the responsibility shift the policy creates for the human signing a generated commit.

Curl ending bug bounty program after flood of AI slop reports Stenberg’s submission figures for early 2026 and his stated aim of removing the incentive for poorly researched reports.

Drowning in AI slop, cURL ends bug bounties Interview-based coverage of Stenberg’s position that the problem is thoughtless use rather than AI itself.

The cURL project drops bug bounties due to AI slop An account of why fabricated reports are expensive to dismiss, with reference to Stenberg’s published examples.

Assisted-by: how open source projects are drawing the line on AI contributions A survey grouping projects into total bans, burdensome rejection and permissive disclosure, with the specific rules each uses.

Linux kernel 7.0 is officially released Release coverage including Torvalds’ comments on the unusually busy cycle, AI tools surfacing corner cases, and the version numbering rationale.

Linux kernel 7.2 hits 43 million lines Code-size measurement across four counters, with the i486 removal and the contributor figures for 7.1.

Sashiko: agentic review of Linux kernel code changes The tool’s own repository, documenting its self-contained design, provider support and local review mode.

Ubuntu is getting AI features in 2026 Coverage of the implicit and explicit feature split, the inference snaps groundwork and the models Canonical is packaging.

EU Cyber Resilience Act — Open Source Security Foundation The standards and tooling landscape supporting CRA due diligence, covering SPDX, CycloneDX, SLSA, Sigstore, CSAF and VEX.

Cyber Resilience Act and open source software An account of the Article 24 open source steward category, the obligations it carries, and where the line falls for organisations that both steward and sell.

Linus Torvalds: AI-detected bug reports make kernel security list almost entirely unmanageable The announcement text alongside the documentation note on findings surfacing simultaneously across multiple researchers.