Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy

Post by pmarreck » Tue, Mar 10, 2026, 10:45 AM UTC

pm215 wrote: post #41

hparadiz wrote: post #30

Earlier quoted context omitted.

What happens when the PR is clear, reasonable, short, checked by a human, and clearly fixes, implements, or otherwise improves the code base and has no alternative implementation that is reasonably different from the initially presented version?

If you're going to set a firm "no AI" policy, then my inclination would be to treat that kind of PR in the same way the US legal system does evidence obtained illegally: you say "sorry, no, we told you the rules and so you've wasted effort -- we will not take this even if it is good and perhaps the only sensible implementation". Perhaps somebody else will eventually re-implement it later without looking at the AI PR.

Post by lpcvoid » Tue, Mar 10, 2026, 10:47 AM UTC

pmarreck wrote: post #94

yla92 wrote: post #82

Zig has a similar stance on no-LLM policy https://codeberg.org/ziglang/zig#strict-no-llm-no-ai-policy

Yep, that’s why my forks of all their libraries with bugs fixed such as https://github.com/pmarreck/zigimg/commit/52c4b9a557d38fe1e1... will never ever go back to upstream, just because an LLM did it. Lame, but oh well- their loss. Also, this is dumb because anyone who wants fixes like this will have to find a fork like mine with them, which is an increased maintenance burden.

Post by CorrectHorseBat » Tue, Mar 10, 2026, 10:49 AM UTC

swiftcoder wrote: post #61

oytis wrote: post #56

Earlier quoted context omitted.

That's eliminating of an important part of open source culture.

I don't think it really is - drive-by changes have been a net burden on maintainers long before LLMs started writing code. Someone who wants to put in the work to become a repeat contributor to a project is a different story.

Post by ChrisMarshallNY » Tue, Mar 10, 2026, 10:50 AM UTC

stabbles wrote: post #67

ptnpzwqd wrote: post #6

I think this is a reasonable decision (although maybe increasingly insufficient). It doesn't really matter what your stance on AI is, the problem is the increased review burden on OSS maintainers. In the past, the code itself was a sort of proof of effort - you would need to invest some time and effort on your PRs, otherwise they would be easily dismissed at a glance. That is no longer the case, as LLMs can quickly g…

For well-intended open source contributions using GenAI, my current rules of thumb are: * Prefer an issue over a PR (after iterating on the issue, either you or the maintainer can use it as a prompt) * Only open a PR if the review effort is less than the implementation effort. Whether the latter is feasible depends on the project, but in one of the projects I'm involved in it's fairly obvious: it's a package manager…

Post by pmarreck » Tue, Mar 10, 2026, 10:51 AM UTC

hparadiz wrote: post #30

BlackFly wrote: post #15

Earlier quoted context omitted.

It is enforceable, I think you mean to say that it cannot be prevented since people can attempt to hide their usage? Most rules and laws are like that, you proscribe some behavior but that doesn't prevent people from doing it. Therefore you typically need to also define punishments: > This policy is not open to discussion, any content submitted that is clearly labelled as LLM-generated (including issues, merge reques…

What happens when the PR is clear, reasonable, short, checked by a human, and clearly fixes, implements, or otherwise improves the code base and has no alternative implementation that is reasonably different from the initially presented version?