"Oops, I really should have checked GNU's policy on LLM code generation before submitting an LLM-generated patch. That was a stupid mistake: not only was my patch rejected, I publicly announced myself as a thoughtless blunderer who doesn't read the rules."
- from an alternate reality, where devs still have shame and humility
The author states that they are not a lawyer, which is all good and okay. However, immediately afterwards they seem to claim that they know the law better than GNU, the FSF, and their lawyers. It confuses me how the author does not see that as a problem.
Regardless of the LLM policy, I'd be hesitant to apply an optimization the impact of which can't be measured according to the author:
> If you can provide some metrics that illustrate what the positive
> performance improvement is, someone might volunteer to write a "clean"
> implementation (assuming this contribution is contraband) of an NSColor
> cache. I haven't looked at the code should it wind up being me.
I don't believe it's measurable, because it touches glyph rendering and
framerates.
https://lists.gnu.org/archive/html/emacs-devel/2026-06/msg00527.html
Nonsense. The FSF cannot receive a copyright assignment from someone who does not clearly have the rights. If it is “open” then it is not clear.
Of the two other parties who claim copyright, neither is the submitter; either Facebook (or whoever “made” the model) has it or the persons whose content is in the model has it. Facebook did not assign copyright of the output to the user, and neither did those others.
I'm trying to come to terms with this issue in my own interactions with open source as well. Where I'm at currently: since code is cheap and analysis is expensive, it can be more beneficial to a project's maintainer to get a precise, well-researched report of the issue than a PR. This is an inversion of most of my open source life, where opening an issue was asking for free work while giving a PR implied more reciprocal effort was given. I'll typically just end with "PR available upon request", unless the project has a no-LLM policy.
By stating you used an LLM it sounds as if you haven't vetted it. By mentioning the LLM in this hyped-up time, you're distracting from the actual deep work you've (presumable) done.
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.
I have given plenty of critical thoughts to come to the conclusion I have. You mistake my unwillingness to write a dissertation on why slop is slop for not having a well-reasoned position.
This website is full of people with a financial vested interested in never accepting that slop is slop, so there's no convincing them.
That is not what slop means, though. You're redefining the meaning of the word to suit your view. Why do that? You can just say that LLM generated content is not up to par, or acceptable, ever.
Slop means anything produced en masse with complete disregard for truth, accuracy, or usefulness. 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.
> Slop means anything produced en masse with complete disregard for truth, accuracy, or usefulness.
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.
> This doesn't match at all with what the author described in the article.
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.
I'm not saying your actual point couldn't be valid or fully defensible, just to be clear.
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.
Is it possible to tell slop from non slop if you were not there when the tokens get emitted? Somebody can just lie and pretend that they were not generated
Did you review the code in question and end up rating it slop, or are you just reflexively calling anything AI-generated slop?
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.
I am somewhat sympathetic to the author's frustration, but GNU's stance on LLMs is still up in the air and given the controversy around generated code in general it shouldn't be surprising that GNU rejected this. That said, this post comes off sounding very arrogant, frankly. Especially when it comes to the legal arguments.
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.
I have an exceptionally strong, visceral, negative reaction to people who aren't offended by the arguments the author makes in this post.
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.
> 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.
I think a better frame would be «how could the maintainers have responded in a constructive, collaborative way upon learning about the tooling not being compliant with Emacs-standards, in a way which have helped land what was clearly a good faith effort aiming to make Emacs better?»
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.
> but he never said he was willing to lie, he was offering a hypothetical.
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?
I don't think it's worth it in this case, it's certainly not clear to me who is in the wrong here. Lying is obviously problematic, but like I said, he didn't lie - it was purely hypothetical.
To play devil's advocate, how is a project supposed to distinguish between your patch and "slop" without a reviewer having to put in effort to vet it. Especially since the patch was drafted by LLM, it seems fair to be immediately skeptical. Why should they trust your word that you "reviewed the patch" when that's what every other vibecoder claims?
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.
Neither matter. The maintainer isn't required to adopt how they want to protect their repo, and lower the amount of value they perceive it to have. They can reject any patch for any reason, or no reason at all. No one is owed any control over their repo. If you want your code in the repo, you fork the repo.
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.
Such ultra-liberal approach seems to project unfriendly collaboration culture..?
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.
> It seems to incentivize the contributor to try [to do something unethical]
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?
"Oops, I really should have checked GNU's policy on LLM code generation before submitting an LLM-generated patch. That was a stupid mistake: not only was my patch rejected, I publicly announced myself as a thoughtless blunderer who doesn't read the rules."
- from an alternate reality, where devs still have shame and humility
The LLM-tone of that apology is ironic.
What a pompous, self-aggrandizing takeaway.
"My patch got rejected because I was honest"
"My girlfriend broke up with me because I was honest"
https://www.youtube.com/shorts/Nx0r-_DuDek
I encourage the author to do a bit more self-reflection.
"I'm being punished for being honest" is such a stereotype of childish self-defense, I'm shocked to even see it.
The author states that they are not a lawyer, which is all good and okay. However, immediately afterwards they seem to claim that they know the law better than GNU, the FSF, and their lawyers. It confuses me how the author does not see that as a problem.
Traditionally, loudly declaring your exit like this was met with the reply, “And nothing of value was lost.”
Regardless of the LLM policy, I'd be hesitant to apply an optimization the impact of which can't be measured according to the author:
It makes sense: if you use an LLM, you don’t have the copyright so you can’t assign it to the FSF.
That's still an open legal question. You can't definitively say you don't have the copyright.
Nonsense. The FSF cannot receive a copyright assignment from someone who does not clearly have the rights. If it is “open” then it is not clear.
Of the two other parties who claim copyright, neither is the submitter; either Facebook (or whoever “made” the model) has it or the persons whose content is in the model has it. Facebook did not assign copyright of the output to the user, and neither did those others.
I think the LLM PR future could be mitigated with an invite only approach similar to Hashimoto's with Ghostty
I'm trying to come to terms with this issue in my own interactions with open source as well. Where I'm at currently: since code is cheap and analysis is expensive, it can be more beneficial to a project's maintainer to get a precise, well-researched report of the issue than a PR. This is an inversion of most of my open source life, where opening an issue was asking for free work while giving a PR implied more reciprocal effort was given. I'll typically just end with "PR available upon request", unless the project has a no-LLM policy.
By stating you used an LLM it sounds as if you haven't vetted it. By mentioning the LLM in this hyped-up time, you're distracting from the actual deep work you've (presumable) done.
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.
Absolutism is absolutely terrible. Open source projects that cannot adapt to the times will be replaced by those which can.
Still waiting for these ‘replacements’ to arrive.
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.
Replaced by projects with nebulous ownership of copyright.
Nobody want vibecode slop.
Neither does the author
Then why did he try to submit slop?
He didn't
Yes he did, it was LLM-generated, therefore slop.
Your comments come across more sloppy than that. You're not applying any critical thought.
I have given plenty of critical thoughts to come to the conclusion I have. You mistake my unwillingness to write a dissertation on why slop is slop for not having a well-reasoned position.
This website is full of people with a financial vested interested in never accepting that slop is slop, so there's no convincing them.
Do you consider everything generated by an LLM to be slop, regardless of the quality of the work?
Yes. Anything LLM generated is automatically, irrevocably, slop. Does not matter if you rewrite by hand every single line of it, still slop.
That is not what slop means, though. You're redefining the meaning of the word to suit your view. Why do that? You can just say that LLM generated content is not up to par, or acceptable, ever.
Slop means anything produced en masse with complete disregard for truth, accuracy, or usefulness. 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.
> Slop means anything produced en masse with complete disregard for truth, accuracy, or usefulness.
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.
> This doesn't match at all with what the author described in the article.
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.
I'm not saying your actual point couldn't be valid or fully defensible, just to be clear.
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.
Is it possible to tell slop from non slop if you were not there when the tokens get emitted? Somebody can just lie and pretend that they were not generated
Not always, but the sloperator has to pass it off as human-made every time, and the defenders only need to detect slop once.
Did you review the code in question and end up rating it slop, or are you just reflexively calling anything AI-generated slop?
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.
It's LLM-generated, therefore slop. It does not need more investigation. A human did not produce it so it's not worth my time.
I am somewhat sympathetic to the author's frustration, but GNU's stance on LLMs is still up in the air and given the controversy around generated code in general it shouldn't be surprising that GNU rejected this. That said, this post comes off sounding very arrogant, frankly. Especially when it comes to the legal arguments.
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.
I have an exceptionally strong, visceral, negative reaction to people who aren't offended by the arguments the author makes in this post.
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 made a patch in good faith, not knowing about these rules.
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?
> not knowing about these rules.
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.
> 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.
I think a better frame would be «how could the maintainers have responded in a constructive, collaborative way upon learning about the tooling not being compliant with Emacs-standards, in a way which have helped land what was clearly a good faith effort aiming to make Emacs better?»
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.
[dead]
Entertaining rant, but he never said he was willing to lie, he was offering a hypothetical.
> but he never said he was willing to lie, he was offering a hypothetical.
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?
I don't think it's worth it in this case, it's certainly not clear to me who is in the wrong here. Lying is obviously problematic, but like I said, he didn't lie - it was purely hypothetical.
To play devil's advocate, how is a project supposed to distinguish between your patch and "slop" without a reviewer having to put in effort to vet it. Especially since the patch was drafted by LLM, it seems fair to be immediately skeptical. Why should they trust your word that you "reviewed the patch" when that's what every other vibecoder claims?
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.
Neither matter. The maintainer isn't required to adopt how they want to protect their repo, and lower the amount of value they perceive it to have. They can reject any patch for any reason, or no reason at all. No one is owed any control over their repo. If you want your code in the repo, you fork the repo.
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.
Such ultra-liberal approach seems to project unfriendly collaboration culture..?
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.
No.
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.
> It seems to incentivize the contributor to try [to do something unethical]
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?