Live data from Hacker News

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

gitlab.redox-os.org

51–60 of 504 posts

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

#51
post #26

Earlier quoted context omitted.

> The LLM ban is unenforceable Just require that the CLA/Certificate of Origin statement be printed out, signed, and mailed with an envelope and stamp, where besides attesting that they appropriately license their contributions ((A)GPL, BSD, MIT, or whatever) and have the authority to do so, that they also attest that they haven't used any LLMs for their contributions. This will strongly deter direct LLM usage. Indir…

> As an aside, I've noticed a huge drop off in license literacy amongst developers What do you mean by this? I always assumed this was the case anyway; MIT is, if I'm not mistaken, one of the mostly used licenses. I typically had a "fuck it" attitude when it came to the license, and I assume quite a lot of other people shared that sentiment. The code is the fun bit.

> I always assumed this was the case anyway; MIT is, if I'm not mistaken, one of the mostly used licenses

No, it wasn't that way in the 2000s, e.g., on platforms like SourceForge, where OSS devs would go out of their way to learn the terms and conditions of the popular licenses and made sure to respect each other's license choices, and usually defaulted to GPL (or LGPL), unless there was a compelling reason not to: https://web.archive.org/web/20160326002305/https://redmonk.c...

Now the corporate-backed "MIT-EVERYTHING" mindvirus has ruined all of that: https://opensource.org/blog/top-open-source-licenses-in-2025

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

#52

Hm, wondering how to enforce this rule. Rules without any means to enforce them can put the honest people into a disadvantage.

> This policy is not open to discussion, any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed, and any attempt to bypass this policy will result in a ban from the project.

It sounds serious and strict, but it applies to content that's 'clearly labelled as LLM-generated'. So what about content that isn't as clear? I don't know what to make of it.

My guess is that the serious tone is to avoid any possible legal issues that may arise from the inadvertent inclusion of AI-generated code. But the general motivation might be to avoid wasting the maintainers' time on reviewing confusing and sloppy submissions that are made using the lazy use of AI (as opposed finely guided and well reviewed AI code).

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

#53
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. Th…

> Or if the code is a mess. Or if it doesn't follow conventions.

In my experience these things are very easily fixable by ai, I just ask it to follow the patterns found and conventions used in the code and it does that pretty well.

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

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

Who reviews the correctness of the second agents' review?

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

#55
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. Th…

Your analogy with CI/CD is flawed because while not all were convinced of the merits of CI/CD, it's also not technology built on vast energy use and copyright violation at a scale unseen in all of history, which has upended the hardware market, shaken the idea of job security for developers to its very foundation and done it while offering no really obvious benefits to groups wishing to produce really solid software. Maybe that comes eventually, but not at this level of maturity.

But you're right it's probably unenforceable. They will probably end up accepting PRs which were written with LLM assistance, but if they do it will be because it's well-written code that the contributor can explain in a way that doesn't sound to the maintainers like an LLM is answering their questions. And maybe at that point the community as a whole would have less to worry about - if we're still assuming that we're not setting ourselves up for horrible licence violation problems in the future when it turns out an LLM spat out something verbatim from a GPLed project.

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

#56
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?

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

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

#57
post #42

Earlier quoted context omitted.

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 :-)

Just because they have been made before LLMs doesn't mean it can be done again, since there was just one success (GNU/Linux) and that success makes it much harder for new OSes since they need to better then it

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

#58
post #41

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.

How funny would it be if the path to actually implement that thing is then cut off because of a PR that was submitted with the exact same patch. I'm honestly sitting here grinning at the absurdity demonstrated here. Some things can only be done a certain way. Especially when you're working with 3rd party libraries and APIs. The name of the function is the name of the function. There's no walking around it.

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

#59
While I am more on the AI-hater side, I don't consider this to be a good idea:

"any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed"

For example:

- What if a non-native English speaker uses the help of an AI model in the formulation of some issue/task?

- What about having a plugin in your IDE that rather gives syntax and small code fragment suggestions ("autocomplete on steroids")? Does this policy mean that the programmers are also restricted on the IDE and plugins that they are allowed to have installed if they want to contribute?

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

#60

> 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.

Don't ask don't tell looks like a reasonable policy. If no one can tell that your code was written by an LLM and you claim authorship, then whether you have actually written it is a matter of your conscience.
Post reply on HN