Live data from Hacker News

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

gitlab.redox-os.org

41–50 of 504 posts

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

#41

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?

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.

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

#42
post #16

Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense. What makes sense if that of course any LLM-generated code must be reviewed by a good programmer and must be correct and well written, and the AI usage must be precisely disclosed. What they should ban is people posting AI-generated code without mentioning it or replying "I don't know, the AI did it like that" to…

> Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense. Every single production OS, including the one you use right now, was made before LLMs even existed. > What makes sense if that of course any LLM-generated code must be reviewed by a good programmer The time of good programmers, especially ones working for free in their spare time on OSS projects, is a limited…

There are only 4 successful general purpose production OSes (GNU/Linux, Android/Linux, Windows, OS X/iOS) and only one of those made by the open source community (GNU/Linux).

And a new OS needs to be significantly better than those to overcome the switching costs.

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

#43

> any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed Note the word "clearly". Weirdly, as a native English speaker this term makes the policy less strict. What about submarine LLM submissions? I have no beef with Redox OS. I wish them well. This feels like the newest form of OSS virtue signaling.

As a native English speaker I read this as two parts. If it's obvious, the response is immediate and not up for debate. If it's not obvious then it falls in the second part - "any attempt to bypass this policy will result in a ban from the project".

A submarine submission, if discovered, will result in a ban.

Using the phrase "virtual signaling" long ago became a meaningless term other than to indicate one's views in a culture war. 10 years ago David Shariatmadari wrote "The very act of accusing someone of virtue signalling is an act of virtue signalling in itself", https://www.theguardian.com/commentisfree/2016/jan/20/virtue... .

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

#44
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…

Project maintainers will always have the right to decide how to maintain their projects, and "owe" nothing to no one.

That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable. Others have already commented that it's likely unenforceable, but I'd also say it's unreasonable for the sake of utility. It leaves stuff on the table in a time where they really shouldn't. Things like documentation tracking, regression tracking, security, feature parity, etc. can all be enhanced with carefully orchestrated assistance. To simply ban this is ... a choice, I guess. But it's not reasonable, in my book. It's like saying we won't use ci/cd, because it's automated stuff, we're purely manual here.

I think a lot of projects will find ways to adapt. Create good guidelines, help the community to use the best tools for the best tasks, and use automation wherever it makes sense.

At the end of the day slop is slop. You can always refuse to even look at something if you don't like the presentation. Or if the code is a mess. Or if it doesn't follow conventions. Or if a PR is +203323 lines, and so on. But attaching "LLMs aka AI" to the reasoning only invites drama, if anything it makes the effort of distinguishing good content from good looking content even harder, and so on. In the long run it won't be viable. If there's a good way to optimise a piece of code, it won't matter where that optimisation came from, as long as it can be proved it's good.

tl;dr; focus on better verification instead of better identification; prove that a change is good instead of focusing where it came from; test, learn and adapt. Dogma was never good.

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

#45
post #37
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…

I feel like the pattern here is donate compute, not code. If agents are writing most of the software anyway, why deal with the overhead of reviewing other people's PRs? You're basically reviewing someone else's agent output when you could just run your own. Maintainers could just accept feature requests, point their own agents at them using donated compute, and skip the whole review dance. You get code that actually…

Well, it's not quite that easy because someone still has to test the agent's output and make sure it works as expected, which it often doesn't. In many cases, they still need to read the code and make sure that it does what it's supposed to do. Or they may need to spend time coming up with an effective prompt, which can be harder than it sounds for complicated projects where models will fail if you ask them to implement a feature without giving them detailed guidance on how to do so.

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

#46
post #17

While I appreciate the morality and ethics of this choice, the current trend means projects going in this direction are making themselves irrelevant (don't bother quipping at how relevant redox is today, thanks). E.g. top security researches are now using LLMs to find new RCEs and local privilege escalations; no reason why the models couldn't fix these, too - and it's only the security surface. IOW I think this stanc…

Even if we assume that LLMs become good enough for this to be true (some might feel that is the case already - I disagree, but that is beside the point), there is no reason why OSS maintainers should accept such outside contributions that they would need to carefully review, as it comes from an untrusted source, when they could just use the tools themselves directly. Low effort drive-by PRs is a burden with no upside.

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

#47
post #25

Earlier quoted context omitted.

Because it takes a massive amount of developer work (perhaps more than anything else), and it's very unlikely they either have the ability to attract enough human developers to be able to do it without LLM assistance. Not to mention that even finding good developers willing to develop without AI (a significant handicap, even more so for coding things like an OS that are well represented in LLM training) seems difficu…

> Because it takes a massive amount of developer work You know what else takes "a massive amount of developer work"? "any LLM-generated code must be reviewed by a good programmer" And this is the crux of the matter with using LLMs to generate code for everything but really simple greenfield projects: They don't really speed things up, because everything they produce HAS TO be verified by someone, and that someone HAS…

The submitter is supposed to be the good programmer; if not, then maintainers may or may not review it themselves depending on the importance of the feature.

And yes of course they need to be able to write the code themselves, but that's the easy part: any good developer could write a full production OS by themselves given access to documentation and literature and an enormous amount of time. The problem is the time.

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

#48
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…

Isn't the obvious solution to not accept drive by changes?

Sure - and I suspect we will see that soon enough. But it has downsides too, and finding the right way to vet potential contributors is tricky.

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

#49
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…

> Even if we assume LLMs would consistently generate good enough quality code, code submitted by someone untrusted would still need detailed review for many reasons - so even in that case it would like be faster for the maintainers to just use the tools themselves, rather than reviewing someone else's use of the same tools.

Wouldn't an agent run by a maintainer require the same scrutiny? An agent is imo "someone else" and not a trusted maintainer.

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

#50
post #42

Earlier quoted context omitted.

> Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense. Every single production OS, including the one you use right now, was made before LLMs even existed. > What makes sense if that of course any LLM-generated code must be reviewed by a good programmer The time of good programmers, especially ones working for free in their spare time on OSS projects, is a limited…

There are only 4 successful general purpose production OSes (GNU/Linux, Android/Linux, Windows, OS X/iOS) and only one of those made by the open source community (GNU/Linux). And a new OS needs to be significantly better than those to overcome the switching costs.

None of this counters the argument I made above :-)
Post reply on HN