Redox OS Draws a Hard Line on LLM-Generated Code, and It Makes Sense

Redox OS recently updated its contributing guidelines with two significant additions: a Developer Certificate of Origin (DCO) requirement and a strict prohibition on LLM-generated code. The DCO is standard practice at this point — the Linux kernel has used it for years, and it’s a reasonable way to establish that contributors have the right to submit what they’re submitting. But the no-LLM clause is the part worth sitting with.

The policy is blunt: no code generated by large language models, full stop. Not “disclose if you used Copilot.” Not “LLM-assisted code is fine if you review it carefully.” Just no.

Why This Actually Makes Sense

Redox is a microkernel written in Rust, built from the ground up with memory safety and correctness as first principles. The threat model for this kind of project is different from, say, a web app or a CLI tool. Kernel bugs don’t just crash a process — they compromise the integrity of the entire system. A subtle use-after-free or an off-by-one in privilege handling is the difference between a secure OS and an owned one.

LLM-generated code has a specific failure mode that’s particularly dangerous here: it looks correct. It compiles, it passes basic tests, it even looks idiomatic. The bugs it introduces are the quiet kind — incorrect assumptions about invariants, missing edge cases in concurrent code, security properties that hold in the common case but not under adversarial input. These are exactly the bugs you don’t want in a kernel.

There’s also the copyright question, which nobody has fully resolved. LLMs are trained on code with various licenses, and when a model reproduces a pattern or snippet that originates from GPL-licensed code, the resulting contribution’s license status is genuinely unclear. For a project that takes its legal standing seriously — as any long-lived open source project should — that ambiguity is unacceptable.

The Auditability Argument

The DCO requirement ties directly into this. The point of a Certificate of Origin is that a human being is attesting: I wrote this, I have the right to contribute it, I understand what I’m submitting. An LLM can’t make that attestation. You can’t ask it why it made a particular decision, whether it considered a specific edge case, or where a piece of logic came from. That’s not a knock on the tools — it’s just a statement about what auditable, attributable authorship means.

For a project that has to maintain contributor accountability over years and potential security disclosures, that matters.

What This Means More Broadly

I don’t think every open source project needs this policy. For most projects, the risk profile is different and the tradeoffs land elsewhere. But I do think Redox is being honest about something the rest of the ecosystem is still dancing around: LLM-assisted code is not the same as human-authored code, and pretending otherwise has costs.

The question of whether those costs are acceptable depends on what you’re building. For a security-focused OS that’s making a serious long-term bet on correctness, the answer is clearly no. Other projects will have to decide for themselves — but they should actually decide, rather than just defaulting to “sure, whatever gets the PR merged.”

Redox’s policy is a principled stance, not a luddite one. There’s a difference.