AI Contribution Policy

[DancingEmptier667]

Hello,

I would like to request that an anti-AI policy be considered for contributions. I really like murex; I use it as my primary shell, occasionally switching back to zsh if something goes wrong. I wouldn’t want one of my favorite projects to be tainted by AI.

There are a number of issues surrounding the use of AI: legal, environmental, and those purely related to code quality. I would like to propose a complete ban on the use of LLMs, as Zig, Elementary, and OpenJDK have done.

Thank you and best regards.

[lmorg]

Hi @DancingEmptier667

Thanks for your kind words about Murex.

I do also share your concern about unfettered AI contributions. But at this point in time, the only AI contributions I've received has been small, targeted PRs that have been easy to review.

I think so long as AI contributions remain simple enough that they could have been coded by hand, and simple enough that there isn't any uncertainty about the change upon reviewing, then I'm happy to accept AI-assisted PRs.

The longer, slower release cadence for develop being merged with master also works in our favor here because it allows for changes to undergo weeks of usage (even if just by myself) in addition to the test suites, before anything is formally released. Which gives me a little more confidence about the quality of the changes.

So at this point in time, I don't want to outright ban AI-assisted development. Particularly when Murex is a large code base and there isn't the same scale of contributors that Zig et al has. However, I will not merge any PRs that are slop (AI-assisted or hand written). Though I may occasionally cherry pick the good parts and throw away the bad parts if there is some nugget of gold in the PR.

I'll also be continually reviewing this stance. So if we do start to see a noticeable decline in the quality of PRs, then we can reassess whether a stricter policy is required.

And to further that last point, I'll keep this issue open so everyone can add their thoughts and thus ensure Murex's stance on AI remains current.

[DancingEmptier667]

Thank you for your response, @lmorg.

There are more issues with AI-assisted contributions than just code quality (I've already highlighted some of them in my original message). Licensing is one of the issues that, in my opinion, warrants the most concern. Given that murex is licensed under the GPL-2.0, we cannot be certain that any generated code complies with the license. In fact, we cannot be certain of this even if the person submitting the PR used a local LLM.

Allowing AI-assisted PRs could lead to bigger problems in the future than banning them. I still hope that an anti-AI policy can be considered.

Best regards.

[lmorg]

@DancingEmptier667 I've been giving this some thought over the last couple of weeks.

How do you feel about the Linux Foundation / Fastify approach? This is where PRs must be opened by a human and they must 'sign' the Developer's Certificate of Origin 1.1 (https://developercertificate.org/). So this says they're responsible for the code regardless of how it is composed.

I think with the current state of AI, it would be very hard to differentiate between a human developed and AI-assisted development (ie where a human is in the loop and AI tools were used in the same way that traditional tools such as LSPs, debuggers, etc might be used). But what we do want to filter out is AI "slop" where no humans were in the loop. So a "Certificate of Origin" pushes for human oversight and accountability.

[sjh9714]

@lmorg — the DCO instinct holds up unusually well against the policies that already exist, if that's worth anything to the decision.

I classified 70 operative clauses across 13 published AI-contribution policies (curl, Fedora, Gentoo, Ghostty, Godot, Kubernetes, llama.cpp, LLVM, NetBSD, QEMU, Rust's proposal, servo, tldraw) by whether each can be checked from what a pull request actually contains. 24 (34%) are checkable today, 8 (11%) need a signal that doesn't exist yet, 38 (54%) are not checkable in principle.

The bans land almost entirely in that last bucket. Gentoo, QEMU's, servo's, NetBSD's default, and the Rust proposal's ban-on-creation all turn on establishing that a model was involved — which is exactly the thing you said is very hard to differentiate, and the artifact cannot settle it. Bevy is the only policy I found that admits this in its own text, exempting LSP autocompletion because it is "by definition not detectable".

DCO sits at the other end. Signed-off-by: scored bucket 1 — a trailer check on commit metadata, no judgment involved, and QEMU already requires it alongside its ban. So the mechanism you're considering is one of the small number in this corpus that a project can actually enforce rather than merely state.

Two things from the data that bear on the thread rather than just confirming it:

On @DancingEmptier667's licensing concern — DCO is the mechanism built for precisely that. The certification is that the contributor has the right to submit the code under the project's licence; it doesn't ask how the code was composed. That doesn't make the underlying legal question go away, but it does put a named human on the record for each commit, which a ban cannot do, because a ban depends on detecting the thing it forbids.

On what a ban would actually buy you — the two most mechanically enforceable policies in the whole corpus got there by abandoning the AI question rather than answering it. tldraw closes external pull requests regardless of provenance; Godot has the agent prefix its own PR titles with 🤖. Neither tries to detect anything. Of the 24 checkable clauses, none requires determining whether AI was involved: fifteen have no AI subject matter at all (scope, size, gates, account identity, DCO), and the other nine work only because the project reduced an AI question to a literal marker someone states in a fixed place.

One caveat on disclosure clauses if you add one alongside the DCO. I scored Fedora's Assisted-by: requirement as bucket 1 for presence, bucket 3 for obligation: whether the trailer is there is a trailer check, but whether it should have been there depends on a threshold word like "significant" that nothing defines. And the conventions are actively incompatible — Fedora requires Assisted-by:, Kubernetes forbids it. There's nothing to inherit; whichever you pick, you're picking.

Full clause-by-clause tables, including the calls I'd consider arguable: ecogetaway/oss-ai-contribution-policy#22

None of this argues for a particular answer for murex — a small shell with a slow develop→master cadence and one reviewer is a genuinely different situation from Fedora. It's just that "human accountability, no detection" is the shape that survives contact with enforcement, and you'd arrived at it independently.