i plan to package openrsync this weekend in alpine as an alternative to rsync (and probably switch the default rsync implementation in future)
-
@ariadne majority-AI code cannot be copyrighted. it immediately becomes public domain, basically.
@AmyZenunim that wasn't the question.
let me break it down:
1. alpine is interested in a reliable rsync implementation.
2. we presently use rsync, which is GPL, and now vibe-coded.
3. openrsync is an alternative rsync implementation, which is maintained by the OpenBSD project, and thus ISC licensed.
4. if we repeat this cycle over and over, to avoid other regressions from other unreliable vibecoded software, then the pool of influential GPL software wanes over time.
-
sidebar: given that there is interest in alternatives to GPL software that is now being vibecoded, and these alternatives largely tend to not be copyleft...
will vibe coding mean the death of copyleft?
@ariadne I think we will be seeing before-LLM and after-LLM repositories showing-up.
It's only fair.
-
i honestly do not know how i feel entirely about vibe coding? i think it is cool that people can theoretically get any program they want at any time.
but that's theory.
in practice, the code the tools generate has a tendency to be unreliable and frequently also has security issues.
and rsync is being vibecoded by just tridge without any supervision.
@ariadne in theory i do think it's really cool that a nonprogrammer could make a program without going through a lengthy process of learning how to code. however, the history of low code and no code (and prior synonyms and related ideas) makes me wonder if that's something many people really want and whether it will be undermined by increasing complexity (or even existing complexity).
-
@ariadne majority-AI code cannot be copyrighted. it immediately becomes public domain, basically.
@ariadne @AmyZenunim If that's the case, doesn't that mean components of rsync that were LLM-generated aren't under the GPL?
(This is a response to only the comment I'm replying to, not OP.)
-
sidebar: given that there is interest in alternatives to GPL software that is now being vibecoded, and these alternatives largely tend to not be copyleft...
will vibe coding mean the death of copyleft?
@ariadne I kinda think so and I wrote up some thoughts awhile ago: https://www.quippd.com/writing/2026/04/08/ai-code-is-hollowing-out-open-source-and-maintainers-are-looking-the-other-way.html
-
yes, this is because our entire infrastructure is built on rsync, which is now being vibe coded, and that seems like a problem
@ariadne especially for a tool known to be both powerful and dangerous when used uncarefully, and one buried in a zillion automated systems....

-
@ariadne @AmyZenunim If that's the case, doesn't that mean components of rsync that were LLM-generated aren't under the GPL?
(This is a response to only the comment I'm replying to, not OP.)
it's not relevant, or at least, the maintainer's choice to publicly document his decision to shoot himself in the foot regarding intellectual property rights is not relevant to distributions, because the overall package remains GPL regardless of the presence of uncopyrightable code.
-
i honestly do not know how i feel entirely about vibe coding? i think it is cool that people can theoretically get any program they want at any time.
but that's theory.
in practice, the code the tools generate has a tendency to be unreliable and frequently also has security issues.
and rsync is being vibecoded by just tridge without any supervision.
@ariadne My work experience has been interesting. I do catch the LLMs introducing some things that if a human did them I would describe as very poor judgement (I'm not ascribing judgement of any sort to the LLMs). On the other hand, I've had them catch subtle downstream impacts that I missed, including avoiding introducing bugs that would have been a pain to track down. On balance they are improving, I think.
But I also don't count myself as a second reviewer and the LLM as the author; I am the author using the tool, and I still want real third party human review. Confirmation bias is there — I asked the agent to build something, so I'm clearly predisposed, even when consciously trying to read its plan and its code skeptically, to accept it at a light reading.
I'm not sure this is much different in practice from trusting people who have learned how to project confidence in their writing. The machine is statistically likely to produce writing that is at first glance like a person confident in their own analysis. I think it's a difference in degree, since the machines create so much more of it. But I recognize the same temptation to accept specious confidence.
-
it's not relevant, or at least, the maintainer's choice to publicly document his decision to shoot himself in the foot regarding intellectual property rights is not relevant to distributions, because the overall package remains GPL regardless of the presence of uncopyrightable code.
@ariadne @AmyZenunim I just wonder what would happen if non-copyleft software is discovered with the specific components that were generated by LLMs. (Not really relevant to OP; just a thought exercise.) -
@AmyZenunim that wasn't the question.
let me break it down:
1. alpine is interested in a reliable rsync implementation.
2. we presently use rsync, which is GPL, and now vibe-coded.
3. openrsync is an alternative rsync implementation, which is maintained by the OpenBSD project, and thus ISC licensed.
4. if we repeat this cycle over and over, to avoid other regressions from other unreliable vibecoded software, then the pool of influential GPL software wanes over time.
@ariadne @AmyZenunim other distributions won't have the same standards as alpine. debian already declared they don't give a fuck.
-
@ariadne @AmyZenunim other distributions won't have the same standards as alpine. debian already declared they don't give a fuck.
that is also not relevant, but i am not sure that your assertion is true anyway, as at least one debian developer has suggested that the regressions are bad enough to revert back to the last non-LLM version.
-
@ariadne I kinda think so and I wrote up some thoughts awhile ago: https://www.quippd.com/writing/2026/04/08/ai-code-is-hollowing-out-open-source-and-maintainers-are-looking-the-other-way.html
@ariadne I will admit that some of my thinking is probably incorrect here, including the idea that passing copyrighted material through an LLM strips copyright protection; I think what is more defensible is the idea that while the copyrighted code remains copyrighted, since modifications are generated by a machine, the derivative works are ineligible for copyright protection; the original material remains copyrighted.
-
i honestly do not know how i feel entirely about vibe coding? i think it is cool that people can theoretically get any program they want at any time.
but that's theory.
in practice, the code the tools generate has a tendency to be unreliable and frequently also has security issues.
and rsync is being vibecoded by just tridge without any supervision.
@ariadne Actually rsync sometimes regresses. Security update sometimes breaks things. rsync's codebase is indeed complex.
Previously:
https://bugs.debian.org/1093052
https://bugs.debian.org/1093089
https://lists.debian.org/debian-security-announce/2025/msg00006.htmlNot sure whether to blame vibe coding this time..
-
sidebar: given that there is interest in alternatives to GPL software that is now being vibecoded, and these alternatives largely tend to not be copyleft...
will vibe coding mean the death of copyleft?
@ariadne Quite the opposite I think. I think it leads to a resurgence in interest in copyleft, since these are largely the projects not embracing slopware and the fraudulent "non-copyleft" "rewrites" are pandering to techbro asshats and the corporate AI-slop program.
-
@AmyZenunim that wasn't the question.
let me break it down:
1. alpine is interested in a reliable rsync implementation.
2. we presently use rsync, which is GPL, and now vibe-coded.
3. openrsync is an alternative rsync implementation, which is maintained by the OpenBSD project, and thus ISC licensed.
4. if we repeat this cycle over and over, to avoid other regressions from other unreliable vibecoded software, then the pool of influential GPL software wanes over time.
@ariadne @AmyZenunim Except in most cases it's the other way around. rsync is rather unique here. For example it's LLVM embracing slop and GCC rejecting it. Usually because these lines match up with "corporate techbro open source" vs "free software as a social program".
-
sidebar: given that there is interest in alternatives to GPL software that is now being vibecoded, and these alternatives largely tend to not be copyleft...
will vibe coding mean the death of copyleft?
@ariadne Possibly, there seems to be problems from multiple sides; with some vibecoded re-implementations and LLM-generated code effectively licence-washing GPL'd code,
while other GPL'd projects voluntarily drown themselves in slop code.Though, there's also GPL projects taking more restrictive stances about how or if LLMs can be used, to avoid the latter problem,
and hopefully new copyleft projects starting (though, The Industry
seems to favour permissive licenses like MIT lately?) -
@ariadne Quite the opposite I think. I think it leads to a resurgence in interest in copyleft, since these are largely the projects not embracing slopware and the fraudulent "non-copyleft" "rewrites" are pandering to techbro asshats and the corporate AI-slop program.
@dalias @ariadne I said different, but I suppose I assumed that the GPL projects @ariadne was thinking about are those that have given into slop coding; GPL code that isn't GPL, essentially.
I think if people are the ones developing the codebase, we are still stuck with the problem of derivative works not complying with the GPL (as the slop coded projects are derivatives of the GPL projects that have been trained on).
Copyleft becomes less of a cudgel - I don't think it is anything but weaker.
-
sidebar: given that there is interest in alternatives to GPL software that is now being vibecoded, and these alternatives largely tend to not be copyleft...
will vibe coding mean the death of copyleft?
@ariadne That's definitely a concern of mine. AI might be the greatest enclosure act in history.
-
@dalias @ariadne I said different, but I suppose I assumed that the GPL projects @ariadne was thinking about are those that have given into slop coding; GPL code that isn't GPL, essentially.
I think if people are the ones developing the codebase, we are still stuck with the problem of derivative works not complying with the GPL (as the slop coded projects are derivatives of the GPL projects that have been trained on).
Copyleft becomes less of a cudgel - I don't think it is anything but weaker.
@yoasif @ariadne The derivative works are going to have wildly unclear infringement status that varies by jurisdiction and perhaps by short-term political winds. That is an incredibly precarious thing for anyone to be depending on. We need to be amplifying this narrative to make potential users terrified of legal consequences that might befall them in unexpected locations even when they think they have certain countries' legal systems under their thumbs.
-
that is also not relevant, but i am not sure that your assertion is true anyway, as at least one debian developer has suggested that the regressions are bad enough to revert back to the last non-LLM version.
@ariadne @AmyZenunim LOL, LMAO