⚖️ Foundations Got It Right, Projects Got It Wrong

Two Paths Diverged

When AI coding tools emerged, the open source world faced a choice: ban the technology or adapt to it. The responses split along a revealing line.

Major foundations — Linux Foundation, Apache Software Foundation, Eclipse Foundation — chose transparency over prohibition. They convened legal committees, coordinated across organizations, and produced policies allowing AI with disclosure requirements.

Individual projects — Gentoo, NetBSD, QEMU, libvirt, Redox OS, PostmarketOS, and SDL — chose blanket bans. Small groups of engineers, without legal expertise or cross-project coordination, prohibited AI-generated contributions entirely.

The difference isn't just in outcomes. It's in how decisions were made.

The Foundation Approach

Linux Foundation: Setting the Standard

The Linux Foundation didn't just create its own Generative AI Policy — it actively encouraged coordination across the entire open source ecosystem.

"Code or other content generated in whole or in part using AI tools can be contributed to Linux Foundation projects."

The policy treats AI-generated code like any other contribution: subject to peer review, licensing compliance, and quality standards. No special prohibition. No moral panic.

Crucially, the Linux Foundation reached out to other foundations to develop common approaches — a stark contrast to individual projects making isolated decisions.

Apache Software Foundation: Legal Committee Deliberation

On July 24, 2023, the ASF Legal Committee published comprehensive AI guidance after careful deliberation.

Key participants:

• Roman Shaposhnik — then VP, Legal Affairs at the ASF; authored the announcement
• Henri Yandell — Recognized for key work on the guidance
• ASF Legal Committee members

Shaposhnik acknowledged the complexity:

"The criteria for what is 'your original creation' is pretty easy to understand if you literally just typed a page of code in a fit of inspiration, but aside from that the line gets pretty blurry pretty quickly."

The ASF explicitly credited the Linux Foundation for "encouraging all the various Open Source Foundations to start thinking about this area in common terms and agreeing on policies that wouldn't be too far from each other."

Result: Allow AI contributions with Generated-by: disclosure tags. Contributors remain responsible for compliance, but the tool itself isn't banned.

Eclipse Foundation: Guidelines with IP Due Diligence

The Eclipse Foundation published guidelines in April 2024, emphasizing that "AI serves as a tool to enhance efficiency."

Executive Director Mike Milinkovich later announced a collaboration with the Open Source Initiative on AI policy:

"As AI reshapes industries and societies, there is no more pressing issue for the open source community than the regulatory recognition of open source AI systems."

Result: Allow AI contributions with IP due diligence, code scanning for training data matches, and committer accountability.

The Linux Kernel: Torvalds Cuts Through

The Linux kernel — the Linux Foundation's flagship project — had its own debate at the 2025 Maintainers Summit. The discussion reveals how experienced leadership handles AI concerns differently than isolated project maintainers.

The Participants

What Triggered the Debate

Sasha Levin demonstrated at Open Source Summit that an LLM-generated patch had been merged into kernel 6.15. One maintainer reacted:

"It appears (from comments below) that it does indeed have a slight bug. Which I would have caught if I had know this was 100% generated, as I would not have trusted the patch as much as I did thinking Sasha did the work."

This sparked a broader discussion about disclosure and policy.

Torvalds' Position

Linus Torvalds dismissed the hand-wringing about AI documentation. On using policy documents to prevent "AI slop":

"The AI slop people aren't going to document their patches as such. That's such an obvious truism that I don't understand why anybody even brings up AI slop. So stop this idiocy. The documentation is for good actors, and pretending anything else is pointless posturing."

On taking an anti-AI stance in kernel documentation:

"I don't want some kernel development docs to take either stance" on whether AI will revolutionize or harm software engineering.

His bottom line:

"It's why I strongly want this to be that 'just a tool' statement."

Torvalds has separately acknowledged that AI "is going to change the world" but expressed frustration with the hype cycle, describing the AI industry as "90 percent marketing and ten percent reality."

The Outcome

• No ban on AI-assisted contributions
• Soft Assisted-by: tag initially included in coding-assistants.rst (April 2026), then moved toward deprecation in October 2026 after Torvalds called mandatory AI disclosure rules "utterly stupid"
• Human accountability remains mandatory via Signed-off-by: (only humans can sign the DCO)
• "Purely machine-generated patches without human involvement are not welcome"
• Focus on code review quality, not tool prohibition — with Torvalds himself using Anthropic's Claude Code in October 2026 to fix 13-year-old kernel bugs and prototype VFS locking refactors

The Individual Project Approach

While foundations deliberated with legal committees and cross-organization coordination, individual projects took a different path.

The Bans

Participant counts and durations are drawn from each project's own public record: the Gentoo council log, the QEMU and libvirt mailing list threads linked in the QEMU and libvirt case studies, and the OpenJDK, Codeberg, GCC, and QGIS announcements cited below. Where a project did not publish its deliberation, the cell says so rather than estimating.

The 2026 Wave: Redox OS, PostmarketOS, SDL

Three more project-level bans landed in the first four months of 2026 — each with its own flavour of the same pattern:

• PostmarketOS (February 26, 2026) revised its AI policy to explicitly forbid generative AI contributions, shortening the prior text and removing ambiguity. The stated concern was review burden: coding assistants "greatly reduce the barrier to contributing something that at least looks okay at the surface." (announcement)
• Redox OS (March 2026) added a non-negotiable no-LLM policy to its contributor guide: content clearly labelled as LLM-generated is immediately closed, and attempts to bypass the policy result in a project ban. The project also removed RustPython from the default desktop variant "to avoid AI-generated code by default." (Redox monthly update, Phoronix)
• SDL (April 15, 2026), the cross-platform media library, added a policy to its PR template and a new AGENTS.md refusing LLM-generated code. Rationale: Zlib-license compatibility concerns, subtle bugs, and contributor accountability. AI may still be used to identify issues, but fixes must be human-authored. (Phoronix, GamingOnLinux)

None of the three involved a legal committee or cross-project coordination.

Mid-to-Late 2026: Different Forces Take Over

The account above holds up as a description of 2024 and 2025. In that period the deliberative bodies really were the permissive ones and the ad-hoc decisions really were the restrictive ones, and process quality was a reasonable predictor of outcome.

What changed in 2026 is not that the pattern was wrong. It is that process stopped being the dominant variable. Three forces that barely featured in the original analysis now do most of the work, and none of them respects the foundation-versus-project line.

• QEMU is moving the other way (May–September 2026). Red Hat virtualization engineer Paolo Bonzini posted a patch series proposing to relax QEMU's blanket ban — one of this article's own case studies — and by September 28, 2026 had expanded it into a dedicated docs/devel/llm-usage.rst policy and repository-root AGENTS.md. The proposal permits AI assistance without prior approval for tests, documentation, mechanical changes and small fixes (≤20 lines), under an AI-used-for: disclosure tag, while requiring maintainer pre-arrangement for core code. His stated reasoning was evidentiary: "projects accepting AI-assisted content have not run into serious legal trouble so far, which suggests the probability of the risk materializing is not high." As of October 17, 2026 the series remains under mailing-list review and QEMU's published policy still carries the 2025 text — but the project that took ~18 months to ban is now actively drafting its replacement. (Phoronix, Freenode)
• Codeberg banned LLM repositories by member vote (July 23, 2026) — while Debian's General Resolution voted the opposite way (August 30, 2026). The Codeberg e.V. annual assembly passed a Terms of Use change refusing to host projects consisting mostly of LLM-generated code without meaningful human oversight. The vote was 358 in favour, 144 against, 14 abstentions, on roughly 50% turnout of active members (announcement).
  
  It is tempting to read Codeberg as a restrictive outcome reached through a broadly participatory process — hundreds of voters rather than three maintainers. That reading needs a heavy qualification. Codeberg's membership is self-selected, and substantially self-selected on this exact question: the platform has grown as a destination for developers leaving GitHub over its Copilot integration and its leadership's AI messaging, with projects including Ghostty, Zig and — notably — Gentoo moving contributor-facing repositories there partly to get away from Copilot (Slashdot, background on the migration). A ballot among people who joined a platform partly to avoid AI tooling is a large electorate, but not an independent one.
  
  Five weeks later, Debian ran the natural control experiment. In General Resolution 2026/vote_002, 425 of 1,045 Debian Developers voted across eight options ranging from strict bans to non-binding guidance. The electorate was not self-selected around AI politics; it was the existing body of credentialed maintainers of a 30-year-old distribution. The winner — defeating "None of the above" 281–126 and beating every other proposal head-to-head — was Choice 5 ("Responsible Use of Generative AI"), which treats LLMs as ordinary tools subject to existing quality, copyright, and human accountability standards. The two flat ban proposals failed even to reach a simple majority (144–257 and 176–230). Within a month of the vote, Debian launched its own Debian Inference Portal giving developers free access to open-weights models. Codeberg and Debian together prove the point: scale of participation and independence of the electorate are different things.
• GCC (July 29, 2026) and OpenJDK (April 9, 2026) declined LLM code on copyright-assignment grounds. The GCC Steering Committee adopted a policy to "decline any legally significant contributions which include LLM-generated content or are derived from LLM-generated content", using the GNU maintainer guidelines' threshold of legal significance, with an explicit carve-out allowing LLM-generated test cases and permitting LLM use for research, analysis and review so long as the output is not submitted. The stated driver is GPL copyright integrity: content of uncertain provenance weakens the licence chain the FSF's assignment model depends on. The committee scheduled a review for early 2027. Similarly, OpenJDK published an Interim Policy on Generative AI on April 9, 2026 prohibiting code or text generated in whole or in part by LLMs pending a permanent legal policy. Both are bans — but argued from specific copyright-assignment models by projects with institutional legal backing, not an engineer's improvised legal conclusion. (Phoronix, Linuxiac, GCC mailing list, OpenJDK Interim Policy)
• QGIS tried a permissive policy and repealed it over review burnout (October 7, 2026). The open-source GIS project initially adopted QEP 408 permitting AI-assisted contributions under human-in-the-loop accountability. Months later, core developers merged QEP 428 ("No AI contributions permitted"), repealing QEP 408 entirely after maintainers reported unsustainable review fatigue from high-volume, low-comprehension pull requests.

Force One: The Employer's Risk Assessment

The clearest signal in the QEMU reversal is not about QEMU. Read the personnel:

• QEMU's ban was proposed by Daniel P. Berrangé — Red Hat.
• libvirt's ban was proposed by Pavel Hrdina and approved by Peter Krempa — both Red Hat, two of the three maintainers involved.
• QEMU's proposed relaxation comes from Paolo Bonzini — Red Hat Distinguished Engineer, KVM maintainer and QEMU submaintainer.

The same employer's engineers drove the restriction and now drive the relaxation, and Bonzini's patch says why in as many words: other organisations, "such as Red Hat, have assessed the risk as acceptable". The reasoning is explicitly institutional rather than technical — a corporate legal department revised its risk estimate, and the maintainers it employs carried that revision upstream.

This is the variable the original article missed entirely. It framed these as engineers making amateur legal judgements in isolation. In practice, several of the most consequential "project-level" decisions were made by employees of one vendor, and moved when that vendor's assessment moved. Whether a maintainer is paid, and by whom, predicts more here than whether a council held a vote.

Force Two: Review Burden, Not Contributor Attrition

A natural guess is that bans cost projects contributors, and that the pain of losing participation is what drives reconsideration. The 2026 record points the other way: the pressure is inbound volume, not scarcity.

• curl shut down its bug bounty at the end of January 2026 after roughly 20% of reports proved AI-generated and the validity rate collapsed — 20 submissions in the first 21 days of the year, seven in a single 16-hour window, zero real vulnerabilities. It reopened the programme in March once quality recovered, which is itself a useful data point about how fast these pressures move (Hackaday, Socket).
• postmarketOS gave exactly this rationale for tightening its policy: assistants "greatly reduce the barrier to contributing something that at least looks okay at the surface."
• QGIS repealed its own human-in-the-loop policy (QEP 408) in October 2026 via QEP 428 specifically because volunteer reviewers were burning out triaging plausible-looking PRs whose submitters could not explain the code.

The constraint being defended is maintainer attention, which is the scarcest resource in most projects and is spent by plausible-looking submissions regardless of whether they are any good. That reframes the bans: less a judgement about copyright than a rate-limit on review load, reached by projects that had no other lever to pull.

Force Three: Who Owns the Forge

Codeberg e.V. does not only host repositories — it is also the non-profit behind Forgejo, the Gitea fork it runs on, owning the project's domains and providing its resources while Forgejo keeps separate governance. So a membership that self-selected partly on hostility to Copilot now sets hosting policy for one of the main alternatives to GitHub, and stands behind the software other people self-host.

That is a different kind of power from a project deciding what it will merge. It is infrastructure-level, it applies to projects that never took a position, and it is governed by whoever showed up — a constituency shaped by why people left the incumbent. None of the analysis above anticipated policy being set at this layer.

What Actually Survives

The original thesis was a fair reading of 2024–2025 and is not withdrawn. But it described a moment when projects were deciding this question mostly on their own, and that moment has passed. Employer risk posture, review-capacity pressure and forge ownership now shape outcomes more than the quality of any given deliberation does.

What still holds is narrower and more useful: the distinction worth caring about is not how many people decided, but whether the decision states a rationale specific enough to be wrong. GCC's policy names a mechanism — uncertain provenance weakening the GPL's assignment chain — and books a review for early 2027. Bonzini's proposal names an observation — the anticipated legal trouble has not appeared. curl named a number and reversed when the number changed. Each can be argued with and revisited. A policy resting on "we don't want AI slop" cannot, whether three people or three hundred endorsed it.

What They Had in Common

• No legal expertise: Engineers making legal conclusions about DCO compliance
• No AI expertise: No ML researchers consulted on how LLMs actually work
• No cross-project coordination: Each project acted in isolation (or copied another)
• Small, homogeneous groups: Similar people reaching similar conclusions
• No evidence of harm: Bans were preemptive, not responses to actual problems

Two of these need qualifying in light of 2026. "No evidence of harm" was fair for the 2024–2025 bans but is no longer true of the later ones: curl's bounty collapse, postmarketOS's stated rationale, and QGIS's repeal of QEP 408 are responses to a measured review burden, not precautionary. And "small, homogeneous groups" turns out to describe two different things — a handful of maintainers in a room, and a self-selected community of several hundred voting the same way. Both are covered under Mid-to-Late 2026: Different Forces Take Over.

The Critical Difference: Legal Committee vs. Engineers

The foundations had something the individual projects lacked: legal affairs leadership.

When QEMU's Daniel Berrangé wrote that DCO compliance is "not credible" for AI code, he was making a legal conclusion. He's a virtualization engineer, not a lawyer. He may be right, he may be wrong — but he doesn't actually know.

The ASF's Roman Shaposhnik, by contrast, is the VP of Legal Affairs. When the ASF Legal Committee says contributors can satisfy their obligations with reasonable diligence, that's an informed legal judgment.

Cross-Foundation Coordination

Perhaps the most striking difference is coordination. The ASF explicitly acknowledged:

"[The Linux Foundation provided] leadership encouraging all the various Open Source Foundations (the ASF included) to start thinking about this area in common terms and agreeing on policies that wouldn't be too far from each other."

This is why the major foundations have remarkably similar policies:

• All allow AI-generated contributions
• All require contributor accountability
• All encourage disclosure (tags, commit messages)
• All emphasize existing review processes

Meanwhile, the individual projects that banned AI didn't coordinate with anyone — except libvirt copying QEMU's policy verbatim.

The Outcomes Compared

What Torvalds Understood

Linus Torvalds' dismissal of the AI documentation debate reveals a key insight that the ban projects missed:

"The documentation is for good actors, and pretending anything else is pointless posturing."

The projects that banned AI assumed their policies would prevent bad contributions. But as Torvalds noted, bad actors won't disclose their AI use regardless of policy. The bans only affect honest contributors — the "good actors" who would follow rules anyway.

The foundations understood this. Their policies focus on quality and accountability, not tool prohibition. If code passes review and the contributor takes responsibility, the tool used to create it is irrelevant.

The Lesson

The split between foundations and individual projects reveals a fundamental truth about governance: expertise matters.

The foundations had:

• Legal committees to evaluate IP and licensing implications
• Cross-organization coordination to develop common approaches
• Professional governance structures for policy development
• Experience balancing innovation with risk management

The ban projects had:

• Engineers making legal judgments outside their expertise
• Isolated decision-making without external input
• Ad-hoc processes (or no process at all)
• Reactive policies driven by fear rather than evidence

The result? The organizations with professional governance produced nuanced, adaptable policies. The projects without it produced blanket bans that their own maintainers now question.

Editorial: Governance Infrastructure Matters

This comparison isn't about whether AI code is good or bad. It's about how open source communities make decisions.

The Linux Foundation, Apache, and Eclipse didn't allow AI contributions because they're AI cheerleaders. They allowed them because their legal experts concluded that existing frameworks — contributor accountability, peer review, licensing compliance — already address the relevant concerns.

Gentoo, NetBSD, QEMU, and libvirt didn't ban AI because they did better analysis. They banned it because small groups of engineers, operating without legal expertise or external coordination, made sweeping decisions based on their own risk assessments.

The foundations asked: "How do we adapt our existing processes to handle this?"

The ban projects asked: "How do we make this go away?"

One approach treats AI as a governance challenge requiring professional expertise. The other treats it as a threat to be eliminated. The foundations' approach scales. The bans create confusion, drive honest contributors away, and solve nothing.

Open source projects that lack foundation-level governance infrastructure should take note: when facing novel challenges, the answer isn't to have your engineers play lawyer. It's to recognize when you're out of your depth and seek appropriate expertise.

References

• Linux Foundation: Generative AI Policy (Official)
• ASF: Legal Committee Issues Generative AI Guidance
• ASF: Generative Tooling Guidance (Official)
• Eclipse Foundation: AI Usage Guidelines (Official)
• LWN: Toward a Policy for Machine-Learning Tools in Kernel Development
• LWN: Supporting Kernel Development with Large Language Models
• Phoronix: Torvalds on AI Slop
• Phoronix: Linux Kernel Dropping Requirement To Tag AI-Assisted Patches (October 2026)
• LKML: Linus Torvalds on mandatory AI disclosure rules (October 13, 2026)
• Phoronix: Linus Torvalds Uses Anthropic's Claude Code On New Linux Kernel Code (October 14, 2026)
• OSI-Eclipse Foundation AI Policy Collaboration
• postmarketOS in 2026-02: formal generative AI ban (February 2026)
• This Month in Redox — March 2026 (No-LLM policy announcement)
• Phoronix: Redox OS Establishes AI Policy To Forbid Contributions Made Using LLMs
• OpenJDK: Interim Policy on Generative AI (April 9, 2026)
• Phoronix: SDL Adds Policy To Forbid LLM/AI Generated Code Contributions (April 2026)
• GamingOnLinux: SDL ban AI / LLM code contributions (April 2026)
• Phoronix: QEMU Shifting On AI Policy To Allow Some AI/LLM-Generated Contributions (May 28, 2026)
• Freenode: QEMU Replaces Blanket AI Ban With Pre-Arrangement Rules (September 2026)
• QEMU: Code Provenance policy (still declining AI-derived contributions while replacement series is under review)
• Codeberg: Protecting our FLOSS commons from LLMs (July 23, 2026; member vote 358–144–14)
• Debian General Resolution 2026/vote_002: AI-generated contributions to Debian (August 30, 2026)
• debian-devel-announce: Debian Inference Portal launch (September 23, 2026)
• Phoronix: GCC To Decline Any Significant Contributions Made Via AI/LLMs — Except For Test Cases (July 29, 2026)
• Linuxiac: GCC Adopts Policy Rejecting Significant AI-Generated Code
• GCC mailing list: Steering Committee AI policy announcement (primary source)
• QGIS Enhancement Proposal 428: No AI contributions permitted (merged October 7, 2026)
• Slashdot: GitHub users rebelling against forced Copilot AI features (September 2025)
• Forgejo FAQ: relationship to Codeberg e.V.
• Hackaday: The curl project drops bug bounties due to AI slop (January 2026)
• Socket: curl shuts down bug bounty after flood of AI slop reports
• Background: developers migrating from GitHub to Codeberg