Honesty gets Emacs patch rejected
xlii.space
xlii.space
"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.
You're comparing transparency of used tools versus a cheating in personal relationship. Good that I'm not being accused of grand theft auto here, since it's just as close.
LLM usage is accepted, both legally and morally. 10% of world's population is using it daily, how many "written with help of ChatGPT" disclosures you're seeing. There's absolutely no obligation to disclose and I could just as well omit that fact and that wouldn't be wrong doing.
I disclosed it to lower the trust and invite more scrutiny, what I got a blanket statement that turned 300+ hours of work into garbage.
That's more like: "my fiance after 5 years dumped me because I told her I like mayonesse with my french fries". I have no more self-reflection than that.
Imagine your fiance of 5 years is vegan, and asks you not to put mayo in her food. You sneak it into her food anyway and write a blog post about it. You can tell her all the excuses you want:
- 90% of the world eats animal products daily
- I spent 300+ hours of work finding the best mayo
- I could have kept sneaking slop into your food and not disclosed it
But at the end of the day you're still ignoring her wishes. You can go ahead and keep building this labyrinth of reasoning for yourself, where you're right and everyone else in the world is wrong. And you'll end up dumped with nobody wanting to collaborate with you, talking to ChatGPT late at night who tells you "you're absolutely right, you're a brilliant coder, you deserve better than her!"
People are weird. People plant their gardens their own way. Some like ketchup instead of mayo. Some don't want want AI slop in their codebase. Nobody's stopping you from using your patches privately on your own computer. But if you seek the social validation of having them accepted upstream, you have to learn to respect the people around you.
Probably important for context - there was no official announcement, so no, it's not like I ignored wishes or direction, it was presented to me after the fact.
And (as I mentioned) I'm not mad at policy. I'm mad that:
- that was after fact
- that policy itself is stupid (even if temporary), because it invites under-the-skin slop (though I doubt anyone would go to contribute to core Emacs code slop)
- that actual talks are happening behind closed doors
- and I had lost my time
That's the conclusion. Direction is fine, yet given that I cannot use the tools in my toolset I'm moving on with my work elsewhere (at least until that's settled).
This is a big discussion in open source over all, and checking contribution policies "before the fact" would prevent this waste of time immediately.
Hell, asking your favourite llm about this would clarify the situation in a minute.
GNU has no such contribution policy. As I wrote it's currently a discussions behind the closed doors. Those who inform about usage of LLMs are notified that their contributions won't be accepted, and I think I'm second or third in the whole emacs-devel mailing list history.
Thread about LLM contributions sparked after my piece, not before it.
From my research, the only prior discussion was in March 2026 with conclusion that "lawyers are looking into it" and no followup whatsoever.
Though, if I made a mistake during my research don't hesitate to correct me, because it will prevent me from making similar mistake in future.
Legal problems with LLM-written code are well-known. And copyright law is the cornerstone of open source as an idea in general.
Besides legal issues, major oss projects do not necessarily accept contributions to core subsystems by default. Maintainers can and often will decline patches.
I've lost count of my patches that were declined, or unreviewed, or unnoticed. And that's before the LLM explosion, when patches were small and expensive to write
Your frustration is understandable but could have been avoided.
> 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.htmlOf 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.
> ...who does not clearly have the rights
This claim is baseless. As I wrote in the piece and on mailing lists - it's not the 1:1 copy & paste. It was modified and it all boils to question how much of the salt makes a soup a salty one.
e.g.
- if I put 10.000 words into a prompt and got 500 words out of it, is the author LLM, or me?
- if I got 50 lines, and modified each single one, is the author LLM, or me?
If someone is curious, here's when I don't claim authorship: https://github.com/mawww/kakoune/pull/5515
> This claim is baseless... it all boils to question how much of the salt makes a soup a salty one.
No it doesn't. The very existence of the question means it is not clear.
> - if I put 10.000 words into a prompt and got 500 words out of it, is the author LLM, or me?
Neither. The author is some unknown number of people whose words were scraped.
> - if I got 50 lines, and modified each single one, is the author LLM, or me?
Neither. The author is some unknown number of people whose words were scraped, combined possibly with you. You need all authors to agree on the rights.
You would have to not just modify them, but modify them substantially to either change their meaning or criticise them, or do something because just flip a random number of bits in order to get into the running, and a judge might still disagree with you.
> I'm confident I could prove my case against the court
I'm not even sure you understand the stakes, because not just the authors have claim but also the persons (e.g. z.ai in your case) who assembled the model, and you just blew past both of those people like they were nothing.
You're not even in third-place for rights on this work, and you don't even seem to realise that.
\* Fibonacci hashing spreads packed ARGB keys uniformly.
Used so that low bits don't dominate the cache. */
return (NSUInteger) ((key * 11400714819323198485ULL)
& (NS_COLOR_CACHE_SIZE - 1));
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.
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.
https://lists.gnu.org/archive/html/emacs-devel/2026-06/msg00...
In a different thread about a different LLM-generated package, here's RMS himself:
> • As a disclaimer it was generated with LLM. I think ELPA has a > • prudent policy to not allow this for now until there is legal > • clarify, but does this apply to nonGNU-ELPA also?
RMS: It does apply, for the time being. It is not a final decision, it is tentative.
(link: https://lists.gnu.org/archive/html/emacs-devel/2026-05/msg00...)
GNU (and/or the Emacs project in particular) does not seem to be acting in ludditic or reactionary ways, but thoughtful ones.
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?
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.
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?
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.
- 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.
This website is full of people with a financial vested interested in never accepting that slop is slop, so there's no convincing them.
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.
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.
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.