I have this exact problem at the moment. There’s a bug in click-default-group which I opened 3 years ago and then failed to resolve without AI.
The other day I pointed Claude at it and got a simple one-line fix. Then I read the governing AI policy which made it clear that, with no exceptions, my solution that had been found with the help of AI was not welcome:
If your contribution looks like it was generated by such tools, or you attempt to obfuscate that, it will be closed and you are likely to be blocked.
I’m not going to obfuscate it - that would be unethical.
It’s a one-line fix. I’ve now seen it, so my knowledge of the fix is polluted.
So I guess I leave that issue open and hope someone else stumbles across the same fix that I did!
with no exceptions, my solution that had been found with the help of AI was not welcome
I don’t actually think that’s the case.
This policy focuses on generated contributions more than anything else. If you read a generated description of the bug and its fix, then implement it and write the PR yourself, that isn’t explicitly banned. I don’t think that’s a shortcoming of the policy considering what I think is their primary focus:
We value contributions that are genuinely understood, created, and communicated by humans.
The overall message I get is: don’t use LLMs to substitute your own personal development (and definitely don’t use them to substitute actual communication).
I think the end of this paragraph is most relevant to this situation (emphasis mine):
If you are a new contributor, do not use LLM or AI tools to contribute at all; you do not have the trust or experience to take responsibility for what is generated. If you are someone who is familiar to the maintainers, and know that they already trust you to make high quality contributions, your contribution must still genuinely be understood and created personally by you, regardless of what tools you may use to assist you.
Which puts me in the awkward position of knowing that your code is computing incorrect answers, or corrupting user data, or leaving your users vulnerable to attack. And then I have to guess whether you want to know about a bug discovered using AI. If you have a strict no-AI policy, I’m not going to hide the AI use.
So I guess I leave that issue open and hope someone else stumbles across the same fix that I did!
There is something quite odd about these comments.
As I understand it, the policies of an open source project do not prohibit individuals from publicising independent work. I suspect, irrespective of the policy of the open source project, if one were to find some mistake, one could fix it in a fork, one could write a blog post about it, one could comment on it (in a forum provided by the project… or even just as corroborating detail when making factual claims in other contexts on entirely other websites…) Surely there’s no need to be so coy.
There is something quite odd about these comments.
I think there’s a disconnect which might explain some of the oddness. Let me try to explain. I have seen two types of attitudes towards AI, even here on lobste.rs:
“Our project does not want slop PRs.” This is an entirely rational policy for many projects. I run many of my projects this way! If I really want slop PRs, I can always ask an agent myself. Slop PRs are dirt cheap, and I can get more than I want to read in an hour or two.
“AI is morally wrong, and I don’t want it involved in my project.”
When I say “strict no AI policies”, I’m thinking about group (2).
if one were to find some mistake, one could fix it in a fork, one could write a blog post about it,
As I suggested in my original post, yes, I might quietly fork someone’s project. Or If I believed a data corruption bug affected lots of users, I might write a blog post to get the word out. Or sometimes it’s easier to switch to something else.
If I publish a personal fork with my one-line fix am I now making it harder for that fix to make it into the upstream project? I don’t know if there are alternative fixes, and my fix was AI-assisted.
I think everyone is getting extremely legalistic about other projects’ AI policies on their behalf. No one wants the actual output of the AI, especially unchecked. But if you read the output and actually understand it - a pretty minimal bar for a contribution - and then fix the thing yourself, it has none of the associated issues with AI PRs.
And if there’s only one possible fix, a one liner, then that’s by definition the fix you’d write yourself once you understand the issue. Write it yourself and submit it. There’s no “fruit of the poisonous tree,” this isn’t a courtroom.
In fact, perhaps one might even go so far as to suggest that where an open source project’s policy disagrees with an individual’s preferences, the necessary reaction does not seem to be wounded antagonism. Surely when the project authors set policy, they are aware that they may exclude some desirable contributions; that project may be disinterested in certain contributions, does not require one to make a show of withholding (completed) work under the pretense of following established policy.
The project is, as we all agree, free to set policy as it sees fit.
Irrespective of said policy, nothing enjoins an individual from, say, posting publicly—“here’s a mistake I found”; “here’s a one line-fix I found.” (In fact, as I recall, websites hosting independently maintained patches were quite common prior to wide-spread use and centralisation around version control tooling…)
In fact, I would suggest that if one were to disagree with a project’s policies, and if one were to firmly believe that these policies were detrimental, then maintaining a site with all of the excluded contributions would be very strong corroborating evidence. I use an LLM frequently in my own work and studies, so I know that generating a Github-hosted <html><body><ul><li><ahref="patches/some-fix.diff">Fix for … issue in some-project</a></li></ul></body></html> is well within their capabilities… (In fact, if you write it by hand, you can even skip some of the closing tags!)
Altogether, I think the original comments we are replying to are still quite odd.
I think everyone is getting extremely legalistic about other projects’ AI policies on their behalf. No one wants the actual output of the AI, especially unchecked. But if you read the output and actually understand it - a pretty minimal bar for a contribution - and then fix the thing yourself, it has none of the associated issues with AI PRs.
Well great, then they can write that in their policy instead of “absolutely no AI”!
To avoid arguing with strawmen let’s stick with the actual example Simon provided. The word “absolutely” doesn’t appear anywhere. Here are some quotes:
Pallets is affected by a large increase in low quality contributions generated with LLM (large language model) or “AI” (artificial intelligence) tools.
There’s the motivating problem behind the ban. It’s certainly one we can all understand, right?
We strongly encourage everyone to participate and contribute without using LLM or AI tools.
That’s a “strongly encourage,” not an “absolutely no,” which seems intentionally weakened to provide a tiny bit of space for exercising judgement.
This policy applies to all interactions with our projects and community, not only code and pull requests. This includes code, documentation, tests, PR descriptions, comments, reviews, answers, and all other interactions.
“Interactions with our projects and community” - note that they are specifying interactions between people here. You shouldn’t subject other people to AI output under this policy. It says nothing about using them to help you understand something. The requirement to understand is still there, as it should be.
When you choose to use an LLM tool to generate output, you look like every other person who did so, rather than a unique contributor. Therefore, you inherit the distrust maintainers have based on every prior low quality interaction that looked exactly like yours.
So actually the vast majority of the policy is explaining the harm caused by generated output. We’ve all seen large chunks of generated output and know exactly what they mean.
In most cases a lot of work goes into crafting these policies, which are extremely controversial right now, and they are very descriptive, tell you what problems they’re solving, and are nuanced. That effort seems wasted when people argue with a caricature of them instead of what they actually say.
I mean, tbh I wouldn’t contribute to this project because this is a weird policy in the sense that it only actually mandates two things:
Do not use LLMs to translate or improve communication
“Carefully consider” ESQ issues before using them.
Does that mean I can make LLM PRs? Well they’re telling me I am “likely to be blocked”… is that a no? Will they say, “fair cop, it’s a good LLM PR but we’ll block you now”? I think this policy is written so carefully and defensively that it doesn’t actually tell the contributor what to do and what not to do. It’s hard to have an opinion on what it’s saying because it’s not actually saying much.
They were IMO super clear about this exact point too:
If you are a new contributor, do not use LLM or AI tools to contribute at all; you do not have the trust or experience to take responsibility for what is generated.
So no, you can’t. And this is a completely pragmatic stance for them that balances the harm they’re receiving with the risk of not getting some potential quality contributions.
For a one line easy fix I sort of agree, but I don’t think this is true in general. I don’t think if I write a patch with LLM help. Then put it away and recreate the exact same patch this time “without help” that I’m following the spirit of a ban.
For many maintainers I’ve talked to the point is to ban anyone who might be using LLM related tools from being a contributor.
I have this exact problem at the moment. There’s a bug in click-default-group which I opened 3 years ago and then failed to resolve without AI.
The other day I pointed Claude at it and got a simple one-line fix. Then I read the governing AI policy which made it clear that, with no exceptions, my solution that had been found with the help of AI was not welcome:
I’m not going to obfuscate it - that would be unethical.
It’s a one-line fix. I’ve now seen it, so my knowledge of the fix is polluted.
So I guess I leave that issue open and hope someone else stumbles across the same fix that I did!
score 1 · canonical
I don’t actually think that’s the case. This policy focuses on generated contributions more than anything else. If you read a generated description of the bug and its fix, then implement it and write the PR yourself, that isn’t explicitly banned. I don’t think that’s a shortcoming of the policy considering what I think is their primary focus:
The overall message I get is: don’t use LLMs to substitute your own personal development (and definitely don’t use them to substitute actual communication).
I think the end of this paragraph is most relevant to this situation (emphasis mine):
score 1 · canonical
Total madness. This highlights how with these AI policies, common sense is thrown out of the window.
score 1 · canonical
There is something quite odd about these comments.
As I understand it, the policies of an open source project do not prohibit individuals from publicising independent work. I suspect, irrespective of the policy of the open source project, if one were to find some mistake, one could fix it in a fork, one could write a blog post about it, one could comment on it (in a forum provided by the project… or even just as corroborating detail when making factual claims in other contexts on entirely other websites…) Surely there’s no need to be so coy.
score 2 · canonical
I think there’s a disconnect which might explain some of the oddness. Let me try to explain. I have seen two types of attitudes towards AI, even here on lobste.rs:
When I say “strict no AI policies”, I’m thinking about group (2).
As I suggested in my original post, yes, I might quietly fork someone’s project. Or If I believed a data corruption bug affected lots of users, I might write a blog post to get the word out. Or sometimes it’s easier to switch to something else.
score 1 · canonical
Yes. I think publishing a personal fork is a reasonable choice
score 1 · canonical
If I publish a personal fork with my one-line fix am I now making it harder for that fix to make it into the upstream project? I don’t know if there are alternative fixes, and my fix was AI-assisted.
score 1 · canonical
I guess it depends on the one-line fix and the project.
Publish it and make the project aware. Let them decide. If they reject it, you have the fix. Move on.
No offence but the way you’re dealing with this doesn’t feel completely honest.
score 1 · canonical
I think everyone is getting extremely legalistic about other projects’ AI policies on their behalf. No one wants the actual output of the AI, especially unchecked. But if you read the output and actually understand it - a pretty minimal bar for a contribution - and then fix the thing yourself, it has none of the associated issues with AI PRs.
And if there’s only one possible fix, a one liner, then that’s by definition the fix you’d write yourself once you understand the issue. Write it yourself and submit it. There’s no “fruit of the poisonous tree,” this isn’t a courtroom.
score 1 · canonical
It is not.
In fact, perhaps one might even go so far as to suggest that where an open source project’s policy disagrees with an individual’s preferences, the necessary reaction does not seem to be wounded antagonism. Surely when the project authors set policy, they are aware that they may exclude some desirable contributions; that project may be disinterested in certain contributions, does not require one to make a show of withholding (completed) work under the pretense of following established policy.
The project is, as we all agree, free to set policy as it sees fit.
Irrespective of said policy, nothing enjoins an individual from, say, posting publicly—“here’s a mistake I found”; “here’s a one line-fix I found.” (In fact, as I recall, websites hosting independently maintained patches were quite common prior to wide-spread use and centralisation around version control tooling…)
In fact, I would suggest that if one were to disagree with a project’s policies, and if one were to firmly believe that these policies were detrimental, then maintaining a site with all of the excluded contributions would be very strong corroborating evidence. I use an LLM frequently in my own work and studies, so I know that generating a Github-hosted
<html><body><ul><li><a href="patches/some-fix.diff">Fix for … issue in some-project</a></li></ul></body></html>is well within their capabilities… (In fact, if you write it by hand, you can even skip some of the closing tags!)Altogether, I think the original comments we are replying to are still quite odd.
score 1 · canonical
Well great, then they can write that in their policy instead of “absolutely no AI”!
score 1 · canonical
To avoid arguing with strawmen let’s stick with the actual example Simon provided. The word “absolutely” doesn’t appear anywhere. Here are some quotes:
There’s the motivating problem behind the ban. It’s certainly one we can all understand, right?
That’s a “strongly encourage,” not an “absolutely no,” which seems intentionally weakened to provide a tiny bit of space for exercising judgement.
“Interactions with our projects and community” - note that they are specifying interactions between people here. You shouldn’t subject other people to AI output under this policy. It says nothing about using them to help you understand something. The requirement to understand is still there, as it should be.
So actually the vast majority of the policy is explaining the harm caused by generated output. We’ve all seen large chunks of generated output and know exactly what they mean.
In most cases a lot of work goes into crafting these policies, which are extremely controversial right now, and they are very descriptive, tell you what problems they’re solving, and are nuanced. That effort seems wasted when people argue with a caricature of them instead of what they actually say.
score 2 · canonical
I mean, tbh I wouldn’t contribute to this project because this is a weird policy in the sense that it only actually mandates two things:
Does that mean I can make LLM PRs? Well they’re telling me I am “likely to be blocked”… is that a no? Will they say, “fair cop, it’s a good LLM PR but we’ll block you now”? I think this policy is written so carefully and defensively that it doesn’t actually tell the contributor what to do and what not to do. It’s hard to have an opinion on what it’s saying because it’s not actually saying much.
score 1 · canonical
They were IMO super clear about this exact point too:
So no, you can’t. And this is a completely pragmatic stance for them that balances the harm they’re receiving with the risk of not getting some potential quality contributions.
score 1 · canonical
For a one line easy fix I sort of agree, but I don’t think this is true in general. I don’t think if I write a patch with LLM help. Then put it away and recreate the exact same patch this time “without help” that I’m following the spirit of a ban.
For many maintainers I’ve talked to the point is to ban anyone who might be using LLM related tools from being a contributor.
score 1 · canonical