There is an irony at the centre of the open-source world right now. The large language models that write code run on Linux, were trained on freely available open-source code, and are pitched as the future of software development. And a growing number of the projects that produced that code want nothing to do with them.
A recent review of 120 open-source projects found that 37 have adopted an outright ban on AI-assisted contributions. GCC, QEMU, Gentoo, Zig and the game-development library SDL reject all AI-generated work. The Linux kernel allows it but demands the model be named, for transparency. Platforms like Codeberg and app stores like Flathub have banned AI-generated code, documentation and bug reports outright. And Debian, one of the oldest and most influential Linux distributions, is now holding a vote among its developers on whether to bar AI from code, documentation, translations and bug reports entirely.
The reflexive reaction is bafflement. Why would expert engineers refuse the most hyped tool of the decade? The answer, laid out in an essay circulating among maintainers this week, is not technophobia. It is arithmetic about time. An LLM produces output that looks professional and confident, and humans are wired to trust confident-sounding information without checking it. In casual use that costs little. In engineering, where things must actually be correct, it shifts a large and hidden burden onto whoever reviews the work.
Greg Kroah-Hartman, one of the Linux kernel's most senior maintainers, recently wrote that even with the best current tools, "at least one third of the results they generate are flat out wrong or harmful." The strongest model on the SWE-bench coding benchmark resolves just under 77 percent of tasks, which means it is wrong often enough to matter. The trouble is that AI has widened the pool of people who can produce plausible-looking contributions far faster than it has widened the pool of people who can tell good work from bad. Maintainers, often unpaid volunteers with no manager shielding their time, are left proving that confident submissions are quietly broken.
This is an old dynamic in a new gear. The essay compares it to the "script kiddie" who runs a scanner without understanding the output, then files a bug report that takes a maintainer an hour to disprove. What is new is the volume, and the trust: users now believe the machine's output by default. Open source is uniquely exposed, because it runs on goodwill and donated attention rather than paychecks, and there is no employer absorbing the cost of a wasted afternoon.
The bans, then, are less a rejection of the technology than a defence of a scarce resource. The essay's author uses AI tools daily and calls them useful; his objection is to being sent work whose creation cost less effort than reading it will. That principle, that reading code should take less effort than writing it, predates AI by decades. What comes next is enforcement. As these policies move from statements to rules, the interesting question is how the first violations get judged, and whether "a machine wrote it" turns out to be a defence or an admission.