Live data from Hacker News

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

gitlab.redox-os.org

131–140 of 504 posts

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

#131

Earlier quoted context omitted.

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…

Unfortunately, LLMs generate useless word salad and nonsense even when working on issues text, you absolutely have to reword the writing from scratch otherwise it's just an annoyance and a complete waste of time. Even a good prompt doesn't help this all that much since it's just how the tool works under the hood: it doesn't have a goal of saying anything specific in the clearest possible way and inwardly rewording it…

[flagged]

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

#132

Earlier quoted context omitted.

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.

how in the heck do you disambiguate a first time long term contributor and a first time drive by contributor?

Mostly by whether they check in first to see if the fix is actually welcome?

Drive-by folks tend to blindly fix the issue they care about, without regard to how/whether it fits into the overall project direction

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

#134
post #53

Earlier quoted context omitted.

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

I've recently worked extensively with "prompt coding", and the model we're using is very good at following such instructions early on. However after deep reasoning around problems, it tends to focus more on solving the problem at hand than following established guidelines. Still haven't found a good way to keep it on course other than "Hey, remember that thing that you're required to do? Still do that please."

A separate pre-planning step, so the context window doesn’t get too full too early on.

Off the shelf agentic coding tools should be doing this for you.

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

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

> That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable.

The response to a large enough amount of data is always vibes. You cannot analyze it all so you offload it to your intuition.

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

What’s stopping the maintainers themselves from doing just that? Nothing.

Producing it through their own pipeline means they don’t have to guess at the intentions of someone else.

Maintainers just doing it themselves is just the logical conclusion. Why go through the process of vetting the contribution of some random person who says that they’ve used AI “a little” to check if it was maybe really 90%, whether they have ulterior motives... just do it yourself.

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

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

I've gotta disagree with you here - it's not uncommon for me to be diving into a library I'm using at work, find a small issue or something that could be improved (measurably, not stylistically), and open a PR to fix it. No big rewrites or anything crazy, but it would definitely fit the definition of "drive by change" that _thus far_ has been welcomed.

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

#137
post #97
post #82

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

If you rely on llms, you're simply not going to make it. The person who showed their work on the math test is 9/10 times is doing better in life than the person that only knew how to use a calculator. Now how do we think things are going to turn out for the person that doesn't even think they need to learn how to use a calculator. Just like when people started losing their ability to navigate without a GPS/Maps app,…

I went into software because I like building things and coming up with solid solutions to business problems that are of use to society. I would not describe myself with "love to code". It's a means to an end to pay bills and have a meaningful career. I think of myself more like a carpenter or craftsman.

I used a coding agent for the majority of my current project and I still got the "build stuff" itch scratched because Engineers are still responsible for the output and they are needed to interface between technical teams, UX, business people etc

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

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

owing "nothing to no one" means you are allowed to be unreasonable...

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

#139

Earlier quoted context omitted.

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…

> That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable. To outright accept LLM contributions would be as much "pure vibes" as banning it. The thing is, those that maintain open source projects have to make a decision where they want to spend their time. It's open source, they are not being paid for it, they should and will decide what it acceptable and what is n…

Your reply is based on a 100% bad-faith, intellectually dishonest interpretation of the comment to which you’re replying. You know that. Nobody claimed that LLM code should be outright accepted. Also, nobody claimed that open source maintainers have the right to accept or decline based on whichever criteria they choose. To always come back to this point is so…American. It’s a cop-out. It’s a thought-terminating cliche. If you aren’t interested in discussing the merits of the decision, don’t bother joining the conversation. The world doesn’t need you to explain what consent is.

Most of all, I’m sick of the patronising “don’t forget that you can fork the project!” What’s the point of saying this? We all know. Nobody needs to be reminded. Nobody isn’t aware. You aren’t being clever. You aren’t adding anything to the conversation. You’re being snarky.

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

#140
post #122

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?

How would you tell that it's LLM-generated in that case? If the submitter is prepared to explain the code and vouch for its quality then that might reasonably fall under "don't ask, don't tell". However, if LLM output is either (a) uncopyrightable or (b) considered a derivative work of the source that was used to train the model, then you have a legal problem. And the legal system does care about invisible "bit colou…

It's (c) copyright of the operator.

For one simple reason. Intention.

Here's some code for example: https://i.imgur.com/dp0QHBp.png

Both sides written by an LLM. Both sides written based on my explicit prompts explaining exactly how I want it to behave, then testing, retesting, and generally doing all the normal software eng due diligence necessary for basic QA. Sometimes the prompts are explicitly "change this variable name" and it ends up changing 2 lines of code no different from a find/replace.

Also I'm watching it reason in real time by running terminal commands to probe runtime data and extrapolate the right code. I've already seen it fix basic bugs because an RFC wasn't adhered to perfectly. Even leaving a nice comment explaining why we're ignoring the RFC in that one spot.

Eventually these arguments are kinda exhausting. People will use it to build stuff and the stuff they build ends up retraining it so we're already hundreds of generations deep on the retraining already and talking about licenses at this point feels absurd to me.

Post reply on HN