I find it more than a bit sad that in conversations about banning LLM-driven contributions, the first objection that often comes up is that the rule is unenforceable.
-
I find it more than a bit sad that in conversations about banning LLM-driven contributions, the first objection that often comes up is that the rule is unenforceable.
That is undeniably true and telling at the same time. It is essentially confirming that there are a significant number of people who - if told "we don't want LLM-generated contributions" will say "I don't care what you want, I'm going to use them anyway and you should take this whether you want it or not."
There is a massive amount of entitlement that lies behind that.
I think it'd be dumb for a project to refuse contributions created in Vim, or Emacs. Yet, if that was the rule, I'd either observe it or go away. I wouldn't even bother to argue it for a large and popular project or for a single-maintainer project, because I would conclude they'd already had the debate and made up their minds.
Maintainers have a right to set conditions for reviewing and accepting patches. If something is FOSS they've already given users the ability to fork off and do something that doesn't fit with the maintainer's vision, schedule, or whatever.
It seems wrong to me to have that freedom and insist that a maintainer compromise their standards because a person doesn't agree with them.
There's always _somebody_ that feels entitled to do whatever the hell they want; so if this was just one-offs it wouldn't bug me. What bugs me is that this seems to be a widely held position.
-
I find it more than a bit sad that in conversations about banning LLM-driven contributions, the first objection that often comes up is that the rule is unenforceable.
That is undeniably true and telling at the same time. It is essentially confirming that there are a significant number of people who - if told "we don't want LLM-generated contributions" will say "I don't care what you want, I'm going to use them anyway and you should take this whether you want it or not."
There is a massive amount of entitlement that lies behind that.
I think it'd be dumb for a project to refuse contributions created in Vim, or Emacs. Yet, if that was the rule, I'd either observe it or go away. I wouldn't even bother to argue it for a large and popular project or for a single-maintainer project, because I would conclude they'd already had the debate and made up their minds.
Maintainers have a right to set conditions for reviewing and accepting patches. If something is FOSS they've already given users the ability to fork off and do something that doesn't fit with the maintainer's vision, schedule, or whatever.
It seems wrong to me to have that freedom and insist that a maintainer compromise their standards because a person doesn't agree with them.
There's always _somebody_ that feels entitled to do whatever the hell they want; so if this was just one-offs it wouldn't bug me. What bugs me is that this seems to be a widely held position.
-
I find it more than a bit sad that in conversations about banning LLM-driven contributions, the first objection that often comes up is that the rule is unenforceable.
That is undeniably true and telling at the same time. It is essentially confirming that there are a significant number of people who - if told "we don't want LLM-generated contributions" will say "I don't care what you want, I'm going to use them anyway and you should take this whether you want it or not."
There is a massive amount of entitlement that lies behind that.
I think it'd be dumb for a project to refuse contributions created in Vim, or Emacs. Yet, if that was the rule, I'd either observe it or go away. I wouldn't even bother to argue it for a large and popular project or for a single-maintainer project, because I would conclude they'd already had the debate and made up their minds.
Maintainers have a right to set conditions for reviewing and accepting patches. If something is FOSS they've already given users the ability to fork off and do something that doesn't fit with the maintainer's vision, schedule, or whatever.
It seems wrong to me to have that freedom and insist that a maintainer compromise their standards because a person doesn't agree with them.
There's always _somebody_ that feels entitled to do whatever the hell they want; so if this was just one-offs it wouldn't bug me. What bugs me is that this seems to be a widely held position.
-
I find it more than a bit sad that in conversations about banning LLM-driven contributions, the first objection that often comes up is that the rule is unenforceable.
That is undeniably true and telling at the same time. It is essentially confirming that there are a significant number of people who - if told "we don't want LLM-generated contributions" will say "I don't care what you want, I'm going to use them anyway and you should take this whether you want it or not."
There is a massive amount of entitlement that lies behind that.
I think it'd be dumb for a project to refuse contributions created in Vim, or Emacs. Yet, if that was the rule, I'd either observe it or go away. I wouldn't even bother to argue it for a large and popular project or for a single-maintainer project, because I would conclude they'd already had the debate and made up their minds.
Maintainers have a right to set conditions for reviewing and accepting patches. If something is FOSS they've already given users the ability to fork off and do something that doesn't fit with the maintainer's vision, schedule, or whatever.
It seems wrong to me to have that freedom and insist that a maintainer compromise their standards because a person doesn't agree with them.
There's always _somebody_ that feels entitled to do whatever the hell they want; so if this was just one-offs it wouldn't bug me. What bugs me is that this seems to be a widely held position.
@jzb I kinda think there should be such a thing as the "unenforceability fallacy", crystallising this situation.
-
I find it more than a bit sad that in conversations about banning LLM-driven contributions, the first objection that often comes up is that the rule is unenforceable.
That is undeniably true and telling at the same time. It is essentially confirming that there are a significant number of people who - if told "we don't want LLM-generated contributions" will say "I don't care what you want, I'm going to use them anyway and you should take this whether you want it or not."
There is a massive amount of entitlement that lies behind that.
I think it'd be dumb for a project to refuse contributions created in Vim, or Emacs. Yet, if that was the rule, I'd either observe it or go away. I wouldn't even bother to argue it for a large and popular project or for a single-maintainer project, because I would conclude they'd already had the debate and made up their minds.
Maintainers have a right to set conditions for reviewing and accepting patches. If something is FOSS they've already given users the ability to fork off and do something that doesn't fit with the maintainer's vision, schedule, or whatever.
It seems wrong to me to have that freedom and insist that a maintainer compromise their standards because a person doesn't agree with them.
There's always _somebody_ that feels entitled to do whatever the hell they want; so if this was just one-offs it wouldn't bug me. What bugs me is that this seems to be a widely held position.
@jzb yeah I saw a couple of comments like that on the vi lwn article.
Thank you for commenting on this.
As a woman I found it rather jarring reading the "how could you tell" type commentary.
It really gives huge vibes of entitlement and reminds me of pickup culture and I honestly expected better of FOSS.
But we're only as good as the culture around us. But folks attitudes to projects having a no LLM policy reminds me of why I wrote this:
AI and that Guy at the bar
In tech we've always had evangelists, weither it's for FOSS, or Blockchain or now AI. It's a natural thing to do. You have a tech you'r...
cobbles (dotart.blog)
-
I find it more than a bit sad that in conversations about banning LLM-driven contributions, the first objection that often comes up is that the rule is unenforceable.
That is undeniably true and telling at the same time. It is essentially confirming that there are a significant number of people who - if told "we don't want LLM-generated contributions" will say "I don't care what you want, I'm going to use them anyway and you should take this whether you want it or not."
There is a massive amount of entitlement that lies behind that.
I think it'd be dumb for a project to refuse contributions created in Vim, or Emacs. Yet, if that was the rule, I'd either observe it or go away. I wouldn't even bother to argue it for a large and popular project or for a single-maintainer project, because I would conclude they'd already had the debate and made up their minds.
Maintainers have a right to set conditions for reviewing and accepting patches. If something is FOSS they've already given users the ability to fork off and do something that doesn't fit with the maintainer's vision, schedule, or whatever.
It seems wrong to me to have that freedom and insist that a maintainer compromise their standards because a person doesn't agree with them.
There's always _somebody_ that feels entitled to do whatever the hell they want; so if this was just one-offs it wouldn't bug me. What bugs me is that this seems to be a widely held position.
@jzb I mean, these people are using products based on ignoring consent, and that has bled over into their attitude to the world
-
@jzb yeah I saw a couple of comments like that on the vi lwn article.
Thank you for commenting on this.
As a woman I found it rather jarring reading the "how could you tell" type commentary.
It really gives huge vibes of entitlement and reminds me of pickup culture and I honestly expected better of FOSS.
But we're only as good as the culture around us. But folks attitudes to projects having a no LLM policy reminds me of why I wrote this:
AI and that Guy at the bar
In tech we've always had evangelists, weither it's for FOSS, or Blockchain or now AI. It's a natural thing to do. You have a tech you'r...
cobbles (dotart.blog)
-
I find it more than a bit sad that in conversations about banning LLM-driven contributions, the first objection that often comes up is that the rule is unenforceable.
That is undeniably true and telling at the same time. It is essentially confirming that there are a significant number of people who - if told "we don't want LLM-generated contributions" will say "I don't care what you want, I'm going to use them anyway and you should take this whether you want it or not."
There is a massive amount of entitlement that lies behind that.
I think it'd be dumb for a project to refuse contributions created in Vim, or Emacs. Yet, if that was the rule, I'd either observe it or go away. I wouldn't even bother to argue it for a large and popular project or for a single-maintainer project, because I would conclude they'd already had the debate and made up their minds.
Maintainers have a right to set conditions for reviewing and accepting patches. If something is FOSS they've already given users the ability to fork off and do something that doesn't fit with the maintainer's vision, schedule, or whatever.
It seems wrong to me to have that freedom and insist that a maintainer compromise their standards because a person doesn't agree with them.
There's always _somebody_ that feels entitled to do whatever the hell they want; so if this was just one-offs it wouldn't bug me. What bugs me is that this seems to be a widely held position.
This bit is basically why I came around to your position:
> Maintainers have a right to set conditions for reviewing and accepting patches. If something is FOSS they've already given users the ability to fork off and do something that doesn't fit with the maintainer's vision, schedule, or whatever.
This is literally how FOSS works. It is an Anarchy. Forks happen all the time for "personal" and "political" reasons, and I think (systemic view at least) this is a good thing
-
R relay@relay.publicsquare.global shared this topic
