i plan to package openrsync this weekend in alpine as an alternative to rsync (and probably switch the default rsync implementation in future)
-
@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
-
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 @dysfun @AmyZenunim Fedora, yes, that Fedora, the one pushing MCP nonsense and whatever else either held rsync back at the last non-slop version or rolled back
-
i plan to package openrsync this weekend in alpine as an alternative to rsync (and probably switch the default rsync implementation in future)
@ariadne Thank you!
-
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 copyleft didn't predict the creation of software that could trivially launder the functionality of the software through a process judged to be transformative...
...but Marx did!
-
i plan to package openrsync this weekend in alpine as an alternative to rsync (and probably switch the default rsync implementation in future)
@ariadne Oh, I was actually considering packaging openrsync myself in response to the recent release's bug reports (as a fail-safe for pmOS), but nice to see you beat me to it. I don't know enough about openrsync other than it is an OpenBSD version to really make any solid statements other than thanks
-
@ariadne Oh, I was actually considering packaging openrsync myself in response to the recent release's bug reports (as a fail-safe for pmOS), but nice to see you beat me to it. I don't know enough about openrsync other than it is an OpenBSD version to really make any solid statements other than thanks
@ariadne It is also very interesting reading the comments on this post with people explaining the entire ecosystem to you as if you know nothing about it...
-
i plan to package openrsync this weekend in alpine as an alternative to rsync (and probably switch the default rsync implementation in future)
@ariadne I haven't been paying particular attention. What's the problem with rsync? -
@ariadne I haven't been paying particular attention. What's the problem with rsync?
@me its now being coded by Claude and there have been regressions
-
@me its now being coded by Claude and there have been regressions
@ariadne Ugh. I use rsync daily. Thanks for the heads-up. -
i plan to package openrsync this weekend in alpine as an alternative to rsync (and probably switch the default rsync implementation in future)
@ariadne It'd be useful for them to update the "please wait" page with more detail.
It'll be nice having a more heterogenous ecosystem. Thanks in advance for your planned port.
