Your patch was rejected because the maintainer objects to the source and tooling used to generate the patch. If you agree with the maintainers opinions or object because you wanna do it your way, does not matter.
Honesty didn't get your patch rejected, root cause analysis shows the origin of the rejection was the patch was LLM generated. If the author had decided to lie, but the maintainer still knew it was LLM generated, it would still have been rejected. Honesty isn't implicated at all, and framing it as such is also dishonest.
The title of the post can only exist if the author would gladly lie to get what he wanted ignoring the others involved in the process. That behavior is extremely disgusting.
> I don't care about what you want, so I'll gladly lie to you about my submission so that I get what I want... what you care about, and what you want don't matter!
-- Przemysław Alexander Kamiński, presumably?
I'm embarrassed by proxy that the author^ was willing to write this, and then publish it on the internet. Because this kinda behavior makes all of us working in and around software look bad. Please, adopt some personal ethics that include consideration and respect for others, and expend even a basic about of thought into if you're treating other humans with said respect. Because reading this, you're obviously not.
He’s point is that because he was coming at this with an honest, open approach he saw his work rejected.
His observation is that this will reward dishonest submissions which are NOT made in good faith. Ie rewarding the wrong things.
Incentives drives the outcome. What incentives does this give people?
I understand this argument to be, if you stop people from doing something you don't want them to do to you, you're only incentivizing them to lie to you, before the do that exact same thing to you.
Is that the argument you're trying to make? Because I don't think the solution to wanting to exclude LLM codegen, is to ... not reject LLM generated patches because it might force other people to lie to get around the exclusion.
But, just to be clear, I think the argument that enforcing rules would induce someone to lie, is an insane argument to try to make.
It's true that they may not have known if the source was hidden. But on the flipside, if blanket banning any patch mentioning LLMs filters out 99% of garbage, in a maintainer's eyes that seems like a good tradeoff. There was an HN post a few days back about how LLMs are like a DDOS on OSS maintainers' time, and this just becomes collateral damage.
The hurdle you have to clear as the devils advocate, is what rules is the maintainer allowed to enforce about their repo, and what are those limits. The maintainer doesn't want to introduce LLM generated code. Until you solve for that, nothing else matters.
It seems to incentivize the contributor to try our proposing their patch multiple times repeatedly with varied introductory words just to test if the maintainer had a good day to accept the improved code.
I find the argument that the act of enforcing rules to protect the things that you want to protect, as the thing that incentivizes someone else to lie, stupid.
If I tell you no, I'm not encouraging you to try to figure out how to get around what I want. Why do you feel saying no counts as encouragement to ignore or evade it?
By ensuring the patch is truly tight, and that the correspondence it tight (not LLM slop), there is no reason to suspect slop or reject it. Assuming it's a concentrated, well motivated patch.
That being said, this patch set is very large with very wordy comments. I'm not sure if he submitted all of them at once. Personally I would not accept such wordy comments in my code. A typical LLMism. These comments should be smaller and part of the email. I also suspect the code change could be smaller.
Today's LLMs do have a way of slowly poisoning a codebase by not being a tight as they could be. It tends to bloat the code up. Okay for some code, especially when bounded (e.g. module X is written by LLM, API authored by human). But in massive, established codebases, you can't accept even slightly bloated code since it will drag everything down.
Also, GLM is a lot weaker than GPT and Claude I think.
What’s likely is that people will fork, decide to go all in on maintaining with LLMs, and die pretty early because of rapidly increasing tech debt, while the original project keeps chugging along.
- from an alternate reality, where devs still have shame and humility
Just to break down a few of the issues I had with this:
> I don’t claim to known full context around the policy because - adding insult to the injury - this policy is discussed on the internal GNU lists. What I learned from past conversation around LLMs, however, is that the doubts about LLM contributions are around them being “open enough” and “legal to use”.
I'm not sure what the insult is here. 5 minutes of research indicated that GNU has a working group for an LLM policy, and that the policy is not fully decided. And the current state of things seems to be logged here: https://gcc.gnu.org/wiki/working-group-ai-policy but there's at least a dozen other articles discussing this too.
> When we’re talking about open-weight models, I find the argument about being open absurd. It means that Qwen 3.6 on my local setup is fine, but if I use it from OpenRouter - then it’s not. GLM 5.2 IS Open Weights model and if I had 256 GB of RAM (which I don’t) and 24GB of VRAM (which I have), I could run it on my local machine escaping the whole “SaaS is closed” argument. By the same measure, maybe Internet access should not be available during crafting of submissions? Internet is full of non-free content, and thus patch might have been tainted? Who knows, maybe the inspiration was taken from gasp non-free book or article.
I'm going to ignore the first part of this, I don't think it's surprising that the GNU is prioritizing things which can be run without dependencies on external service providers. That is completely in keeping with the GNU's philosophy.
As for the second part, I hate when people play this game. "Taking Inspiration" from something is not the same thing as having an LLM generate code. Copy-pasting from an online source would also taint the patch.
This gets worse as we descend into the legal opinions.
> Regarding legality argument - I think it’s hubris talking.
> With all the sympathy I have for GNU organization, it neither is the biggest, smartest or the most legal-wise caring organization in the world. E.g. gaming companies are way more paranoid about IP and LLMs and yet usage there is visible as well; ChatGPT has a billion of active users; hundreds of thousands, if not millions of organizations - commercial and not, are using LLMs output every day. And for them the case is clear.
GNU is pretty much ENTIRELY concerned with copyright and legal issues around it. We might recognize GNU for the code they maintain, but the various versions of the GPL are by far their most impactful project. It is the fullest expression of the vision for the open source world.
I would argue that GNU is one of the most experienced organizations in the US when it comes to copyright law. Secondly, gaming companies, Microsoft, EA - all of them have billions of dollars to pay lawyers if there is a major copyright issue around LLM generated code. GNU does not have that luxury and if their code base were tainted with copyrighted code, the consequences would be huge.
> And as far as my, IANAL, personality understands is: the problem is with putting a copyright stamp on it and not other way around.
> Yet GNU believes that THEIR lawyers and THEIR opinion has the most weight. I won’t deprive them from the right of deciding for they own, but this lack of self-awareness is almost caricatural [sic].
Yes, that may indeed be how you understand it but I am going to defer to the team of copyright lawyers who have dedicated years to this stuff instead. I'm sorry OP, your IANAL opinion is not going to bear that same weight.
I also want to dig into this in particular:
> First of all, I could’ve hidden the fact of LLM usage, and yet decided to declare it explicitly. By being truthful I already lost my footing. This alone makes the policy stupid. If admittance is punished it’s better to push submissions without admitting. It punishes integrity, not usage per se. Because who will find out? I don’t trust LLMs at all thus I believe LLM-assisted work require actually MORE scrutiny and eyes - not less.
Being able to lie about it doesn't really matter either way. Yes, you could have hidden the LLM usage. You can also lie about stealing code from your job and hiding in GNU submissions. Being able to lie about this doesn't mean anything, and I find it concerning that "I could have just lied" was a major part of this complaint.
What the author describes are all the usual defenses of LLM slop, all the usual weasel words that boil down to "But I'm different and smart, my slop isn't slop."
> This is called a Kafkatrap. It works in any direction, in any situation, making the disagreement moot. Also not considered good faith rhetoric.
Applying a label to my reasoning to discredit it is also not done in good faith, and simultaneously does not make it any less true.
LLM slop is fundamentally a "what color are your bits" kind of situation. And you cannot, in any way, ship-of-theseus it away from slop.
My view is that there are people capable of vetting LLM generated code, and people who are not capable of it, based on their previous track record of vetting non-LLM generated code and the quality of their own non-LLM generated code.
For example: I would trust the capability of John Carmack to vet an LLM generated bug fix, to his own game engine. Even if it was LLM generated by him, and vetted by him.
Outright rejecting the patches was IMO not a pragmatic or constructive choice and will drive the wrong incentives wether you morally approve of it or not.
He didn’t look at the t&c for whatever model he was using and didn’t understand he had no copyright claim over its output?
He doesn’t have any rights to the code; he can’t assign them to the FSF.
> What incentives does this give people?
Hopefully to learn how to code so they can make their own contributions.
I disagree with your assessment.
> First of all, I could’ve hidden the fact of LLM usage, and yet decided to declare it explicitly. By being truthful I already lost my footing. This alone makes the policy stupid. If admittance is punished it’s better to push submissions without admitting. It punishes integrity, not usage per se.
The author values getting what he wants over interacting fairly and honestly with others. Literally saying "it’s better to push submissions without admitting [the truth]".
I think your predictions are inaccurate, but will gladly acknowledge the facts do show the author decided not lie this time (perhaps because it was too late he already admitted and would have lied if he knew about the policy. Which does seem more inline with the recommendations in post). Unfortunately he was still willing to advocate and argue that honesty was the root cause reason his patch was rejected. I think generally speaking, you wouldn't willingly encourage others to lie if you weren't willing to lie yourself, would you?
The “contributor” doesn’t have the ability to contribute; They do not have copyright over the code so they can’t assign it.
The maintainer should not read it because then they could be tainted and perform accidental copyright infringement in the future.
jandeboevrie•1h ago
greenavocado•1h ago
hananova•1h ago
N_Lens•1h ago
hananova•1h ago
N_Lens•1h ago
hananova•51m ago
This website is full of people with a financial vested interested in never accepting that slop is slop, so there's no convincing them.
maximilianburke•1h ago
hananova•1h ago
helloplanets•56m ago
hananova•49m ago
helloplanets•44m ago
This doesn't match at all with what the author described in the article.
> Anyone trying to say "but my slop isn't slop, I vetted it" clearly is not in possession of the necessary critical thinking skills to differentiate between slop and non-slop.
This is called a Kafkatrap. It works in any direction, in any situation, making the disagreement moot. Also not considered good faith rhetoric.
josteink•1h ago
Humans can produce garbage code. As can AI. So therefore the process around the code matters, and it seems clear to me the author has had a reasonable process around the code, as opposed to blindly accepting some 1-shotted output.
To me this looks like good use of AI.
hananova•1h ago