Open Source Draws a Hard Line on AI Slop — NetworkManager and Linux Kernel Adopt Formal LLM Contribution Policies

August 7, 2026, 06:42 AM EDT. Josephine Pfeiffer, a Red Hat engineer, merged a formal AI contribution policy into the NetworkManager repository. The same day, the Linux kernel’s networking subsystem continued drowning in LLM-generated patches. The day before, the Linux WiFi maintainer announced his “three-second review” rule. In the span of 48 hours, open source went from irritation to structured action.

NetworkManager’s policy is concise — 87 words — but it establishes three principles that redefine contribution governance:

1. The author is responsible for 100% of submitted code. Don’t submit a patch you can’t explain.
2. Commit messages are written by a human. A tool cannot know why a change was made.
3. Review responses are authored by the contributor. If you can’t discuss your own patch with a reviewer, it won’t be merged.

The policy ends with an explicit enforcement clause: “Large machine-generated Merge Requests that no human has reviewed line by line will be closed.”

From Isolated Incidents to a Structured Movement

This isn’t an isolated case. On August 5, Kalle Valo, maintainer of the Linux kernel’s WiFi subsystem, posted a radical rule to the linux-wireless mailing list: any patch suspected of being AI-generated would receive a three-second review — “If it looks like AI slop, I’ll spend three seconds reviewing it before rejecting.”

Valo backs his position with numbers. Over the past 30 days, the WiFi subsystem received over 200 patches identified as LLM-generated, of which fewer than 15% were technically correct. The rest introduced subtle bugs — uninitialized variables, memory leaks, ignored edge conditions — that only an experienced human reviewer could detect. The review time wasted on these patches is estimated at over 40 hours for the WiFi maintainer alone.

On August 6, the broader networking subsystem sounded the alarm. Jakub Kicinski, co-maintainer, described a situation on netdev where “AI patches are arriving faster than we can reject them.” The phenomenon isn’t anecdotal: LLM patch volume has tripled between June and August 2026 on the networking subsystem.

What the Policies Don’t Address (Yet)

Three blind spots persist in these new rules:

Copyleft vs. training on GPL code. The NetworkManager policy states contributions must be LGPLv2.1+ compatible. But it doesn’t address the fundamental question: can an LLM trained on GPL code legally produce code that will be licensed under LGPL? The Free Software Foundation hasn’t yet taken a position on this specific case, but Bradley Kuhn (Software Freedom Conservancy) stated in July 2026 that “models trained on copyleft code create a gray area that courts have not yet explored.”

Detection isn’t reliable. Neither Valo nor Pfeiffer specify how they identify an LLM patch. Automatic detectors (GPTZero, Copyleaks) produce too many false positives to serve as filters. Detection currently relies on maintainer intuition — a syntactically perfect but semantically empty patch, a generic commit message, a lack of subsystem-specific context.

The chilling effect on new contributors. The open source community depends on a steady stream of new contributors. An overly rigid policy risks discouraging junior developers who legitimately use coding assistants (Copilot, Codeium, Claude Code) as learning aids. The line between “legitimate assistance” and “slop” remains blurry.

What This Means for Your CI/CD Pipelines

CI/CD platforms (GitHub Actions, GitLab CI, Jenkins) will need to integrate these policies into their workflows:

• Author verification. A CI job can require commits to be signed with a GPG key linked to a verified account, excluding throwaway accounts created for AI slop.
• Commit message semantic analysis. Tools like commitlint can be extended to reject commit messages that resemble generated text (repetitions, lack of project-specific context).
• Complexity metrics. A patch modifying over 500 lines with no prior contribution history can be flagged for in-depth manual review.

GitHub hasn’t announced a native feature for this use case yet, but the GitHub Blog of July 15, 2026 mentioned “ongoing experiments in detecting atypical contribution patterns.”

Verdict

If you maintain an open source project:

• Write an explicit policy today. NetworkManager’s 87 words are a reusable template. The mere existence of the policy deters some slop.
• Instrument your CI pipeline. A pre-commit hook blocking patches over 300 lines without a GPG signature is a crude but effective filter.
• Don’t ban LLMs — govern them. A contributor using an assistant for boilerplate or local completion isn’t the problem. The problem is someone submitting 10 patches without reading the code.

If you contribute to open source with an AI assistant:

• Read every line you submit. If you can’t explain why a variable is initialized to NULL on line 147, don’t submit the patch.
• Write your own commit messages. A generic “fix bug” is an immediate red flag for maintainers.
• Respond to review comments yourself. Pasting an LLM’s response into a review thread is the fastest way to get banned.

Open source isn’t saying no to AI. It’s saying no to AI-assisted irresponsibility.

References

• NetworkManager Adopts Policy For AI Coding Assistants, Phoronix, August 7, 2026
• Linux Networking Continues Being Bombarded With AI Patches, Phoronix, August 6, 2026
• Linux Wireless Maintainer Takes Firm Stance Against AI/LLM Generated Slop Patches, Phoronix, August 5, 2026
• NetworkManager AI Coding Policy — Merge Request, FreeDesktop.org GitLab, August 7, 2026