I've been using openrsync here and there since it was announced and it's definitely improved over time. I'm looking forward to when I can use it exclusively.
The one place in my usage where it doesn't match Samba rsync is with the following:
> I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/services/services.
As someone who has also suffered uncountable years of abuse from rsync, I understand the impulse, but I think it makes a lot more sense (and is a safer default) to create a second ”services”.
If we have a chance to change rsync defaults to something less insane and save future generations from this mess I think we should.
We don't, since we're not implementing a UI from scratch, we're matching something else.
Of the two possible worlds where in one this reimplementation matches what some see as annoyances in the interface or in another they mostly match the interface except for a few cases where the purposefully diverge (for no good technical reason), IMO the latter is far worse and causes more enexpected behavior.
At most, add a special flag to opt into different default behavior so nobody is surprised by running the same command on different systems and getting different behavior.
> Was there already a /tmp/services directory on the dest?
No. And just to make sure, I ran a quick 'rm -rf /tmp/services' on the remote host, then re-ran openrsync on the client. Same result. This is OpenBSD 7.9 on both sides.
Was it 15.0? I seem to recall it coming in one of the minor point releases in the 15.x line - and I remember it breaking some scripts mysteriously.
EDIT: ah, fun: they did include it in 15.0, but they decided to save the breaking change that removed backwards compatibility for 15.4. https://apple.stackexchange.com/a/479297
The problem with this fragmentation of rsync is that Apple and Android will prefer it, but the Linux and greater GPL world will adhere to the original implantation due to inertia. Power users will just have to know the quirks of each version.
The only way to stop this is for the original author(s) to release this under a BSD license.
Edit: For those assuming equivalent/identical behavior, study these words carefully: "accepts only a subset of rsync's command-line arguments."
It's really no different than every other BSD utility (and SysV utility, if you're running one of those) being different than the GNU ones. We've coped with it for fifty years at this point.
My thought upon reading this is why would Apple or Android bother including rsync? I've noticed that I've needed to install it manually on fresh installs of Debian, FreeBSD...
But then, I just checked a recent Mac that I don't use much and haven't put much on, and it's installed.
Basically like GNU Tar/CPIO and BSD Tar/CPIO. I've largely standardised towards using the bsd variant everywhere (especially since now even Windows ships it and it handles lots of other archive formats using the `tar` command) but it's always a pain to install it everywhere
The actual work of porting is matching the security features provided by OpenBSD's pledge(2) and unveil(2). These are critical elements to the functionality of the system. Without them, your system accepts arbitrary data from the public network.
I am not seeing pledge on Alpine Linux in edge. Have people been testing Pledge on Linux? Did I perhaps misunderstand the risk of using Openrsync without pledge? Or is this article just for OpenBSD users?
Linux has no such features as pledge or unveil, nor capsicum. it has cgroups, namespaces and a mess ofnother things u need to combine to try and do similar things. (it was built iteratively as many systems interacting and being combined to form 'sandboxing' or isolation/limiting of capabilities rather than specific isolation as an entire concept with specific system calls and kernel paths to enable it).
there might be newer stuff in linux land now i see comments about landlock but i assume those will build on the linux primitives rather than whole new ones. - total assumption there but it would seem logical to reuse rather than make new.
part of likely what they mean by 'mess' is that its all over the place. many different ways to try and lock things down. hard to pick what is best etc. without thoroughly diving into the different subsystems entirely. (as opposed to just have 1 or 2 relatively simple system calls)
that quote seems to be a bit of an oversimplification to the point of being completely wrong.
> Without them, your system accepts arbitrary data from the public network.
Neither of these features change if you are accepting arbitrary data from the public network. They limit what an exploited process can do. It's explained properly in the 'Security' section, so I'm not sure where this came from.
This attempt to avoid things that use AI is increasingly looking like some weird kind of reverse whack-a-mole where each targeted hole becomes radioactive after. Just grabbing some popcorn to watch.
It took me quite some time to realize what an utterly presumptuous product name Claude Code actually is, but only because Shannon is rarely mentioned with his first name. It's golden calf levels of hubris, even more so if you consider how incapable it was on release. It's like renaming calc.exe Einstein. Incredibly poor taste, but entirely in line with AI tech bro mentality.
That linkage never occurred to me, or, I suspect, them. Claude use to be a reasonably common name. I have an uncle Claude. Why do you believe they named it after Shannon in particular?
Hmm, Claude Shannon was an American (the model is ostensibly named after him), so maybe how he pronounced it would be the correct pronunciation.
That said, every language on earth will adapt foreign words into its phonology. The alternative would be to adopt the phonology of every language that loaned a word into your language.
rsync has specific running modes for the super-user. It also pumps arbitrary data from the network onto your file-system. openrsync is about 10 000 lines of C code: do you trust me not to make mistakes?
No, but that's why almost nobody runs it outside of strict trust boundaries. This security section would make more sense if rsync was like curl, which routinely deals with hostile counterparties. If the other side of your rsync is hostile, you probably have bigger problems!
(I'm not an rpki person so I don't know if there's some part of that problem domain that changes this equation. I'm not dunking on the project, just saying this snagged me in the README).
No, but that's why almost nobody runs it outside of strict trust boundaries. This security section would make more sense if rsync was like curl, which routinely deals with hostile counterparties. If the other side of your rsync is hostile, you probably have bigger problems!
I disagree. While rsync is most often used to transfer data between "friendly" systems, it's inherently crossing a security boundary. It's important to make sure that an attacker can't leverage it to transform the breach of one system into the breach of multiple systems.
> almost nobody runs it outside of strict trust boundaries.
I guess you can define "strict" however you want, but from what I saw ~10 years ago, most linux distros handled mirroring with rsync. That's a lot of usage in a pretty core part of the foundational open source ecosystem.
+1 to this. Other than people's reflexive anger or fear about AI coming for their code, I don't see anything to suggest that these are bugs that are due to the inclusion of AI vs bugs in a program with a bunch of complex interop with the filesystem and network.
In any case, it's important to identify projects that are beginning to actively vibecode and clearly express position on this issue on various platforms so that authors and maintainers receive feedback.
Even if this particular bug was not written by LLM in this particular case, it's not a fact that the release does not include other regressions and that subsequent vibecoded versions will not include them & new ones.
> it's not a fact that the release does not include other regressions and [...]
Are you listening to yourself? The same exact thing also has applied, applies and will continue to apply to manually written code, in perpetuity. There's nothing new under the sun here; regressions happen when there's change, and the only way to mitigate is to have healthy feedback loops.
Do not going harassing developers because you think they are doing it wrong. If you can do better and don't want to actually contribute to the upstream you are always free to fork it.
No. It's not important. It's actually pretty shitty to go around looking for projects and then telling the maintainers you disagree with how they develop.
Friendly reminder that volunteer maintainers owe you literally not a single goddamn thing. I absolutely want no AI slop in my commercial products that I pay money for, but your feedback is not important to people you are not paying to develop software for you. They gave away not only their software but the source code for free; if you have a problem with it, fork it. Which is something you can do with their generous allowance, and that is an allowance any maintainer can instead choose to not bother themselves with if publishing their code for free leads themselves to dealing with entitled internet commenters harassing them with complaints.
Somewhat ironic Postfix has a record of no root/RCE in the default install, where opensmptd hasn't (CVE-2020-7247). Time will tell if it stays that way.
Exclude is very commonly used in automation jobs to avoid duplicating big git repos and other big files. I think that would be a show stopper for a number of people.
What's the deal with the name? Openrsync implies to me that it's an open source alternative to a closed source program. But the original Rsync is GPL? Is this just the pushover license making it "more open"?
And GNU folks would say the GPL is actually the more open choice because it forces the project to stay open.
Two different ways of thinking about it I guess... it's nice to have choices and I don't think one is more or less "correct", more a matter of opinion/taste I guess.
I don't think the FSF would say that. They prefer the GPL, because it prevents someone from making a closed derivative, but I haven't seen them ever claim it is more open than "permissive" licenses.
It kind of reminds me of the equality of opportunity people versus the equality of outcome people. One sets the starting conditions for developers, the other the ending conditions for users.
A true morality must be based on consent, not coercion. Humanity may not be there yet, and therein lies the argument for force (and thus copyleft); but the ultimate goal should always be to reduce its necessity.
It’s not coercion. You’re free to not use it, or alternatively do what these folks did, write your own. Coercion would be forcing people to use it through some mechanism, which clearly isn’t possible with GPL.
I see this, and the spiritual example that immediately comes to mind is that which is labeled as "crime". Would it be more moral that a murderer must first consent to being judged and sentenced, or that there is a system which automatically comes into play to hopefully deter but also punish it when it happens?
The paradox clears itself up if you look at what tolerance actually is. It's simply not interfering with people's agency over themselves. Given that your right to self-agency doesn't entitle you to restrict others' self-agency, behavior that does try restricting others' agency is automatically not included in "tolerance."
The BSD license is why we have Valkey and not a purely closed-source Redis. It would have been much easier to perform the rugpull if Redis had initially been GPLed.
On top of badreligion42’s point, that both licenses allow forking just as easily - don’t you have the rugpull part backwards?
Afaik BSD licensed stuff can be re-licensed under any more closed licenses at any time, where as to re-license GPL, you need consent from every single contributor.
But i’m not familiar with the redis-valkey story so, maybe there is some nuance i am missing?
Redis started off as Free Software, but was switched to a source available license in version 7.4. The community promptly forked to Valkey, which is still under the BSD license. Since then, Redis shifted to AGPL 3, with contributor agreements, to try to ensure that they're the only ones who can attempt to commercialize Redis.
AGPL makes commercializing harder only for people who fear the AGPL because they want to keep stuff for themselves. there is no problem commercializing it if you don't mind sharing all your connected code. the only benefit redis has is that they can integrate non-free code in their hosting service, while the rest of us could not. since it is their work, i think it is reasonable that they have an advantage. it does not reduce my freedom as a user. it only hinders AWS and other big players from crushing redis.
And how exactly did the BSD license make creating Valkey easier? GPL and BSD licenses both have the source in the open. Anyone creating a fork, can easily do so for either BSD or GPL licensed projects. Since Redis is a database, which the user won't be using a binary of, even using a fork of a supposedly GPL-licensed Redis would not require you to share your modifications with your user, same as BSD.
The BSD license made forking Valkey easier because it ensures that everyone has equal footing. The GPL, especially with contributor license agreements and the like, makes it much more easy for a single party to control the direction of the product. For another example of this happening, look at MongoDB. It started out under the AGPL, but was rugpulled to a non-free license.
Mongo was already a centralized project. Technically open source agpl but I don’t remember it having a large developer community or really many contributions from outside mongo. When the rug pull happened I think simply most people didn’t care or moved on to equal (or better) alternatives. It’s not beloved software like Redis is.
OpenSSH was a 'reaction' to the original SSH(.com) code getting closed source:
> OpenSSH originated in 1999 as a fork of Björn Grönvall's OSSH, which derived from Tatu Ylönen's original SSH 1.2.12 release, the last version distributed under a license permitting open-source redistribution before Ylönen's subsequent software became proprietary under SSH Communications Security.[4]
It was probably the second thing with the Open— prefix by this group of developers, OpenBSD itself being the first. They simply ran with the naming convention. OpenBGP/OSPF were developed as alternatives to Quagga (GPL).
> Is rsync going closed source? If not, how is that the same thing?
Not closed source, but with rsync 3.0 it changed its license to GPL3, which a lot of folks don't like: BSD/MIT licenses have zero limitations on use and distribution, GPL2 (rsync 1.x, 2.x) forces one to release code, GPL3 (rsync ≥3.x) adds further restrictions.
Some folks want to distribute code with as few restrictions as possible. Other folks have a great good/goal in mind (e.g., 'all software is open source') and so add 'local restrictions' to hopefully achieve greater non-restrictions.
No. The name only means it’s made by the OpenBSD team, nothing more. If they made their own Python port, it’d be called OpenPython, even though the original is FOSS.
So is OpenSUSE made by the BSD team? OpenOffice? OpenShift? OpenCV? OpenAI?
It is not reasonable to claim this prefix unambiguously refers to the OpenBSD team. I do not understand why so many in this thread are pretending this isn't a confusing choice.
The person I replied to said the "open" prefix means it's made by the OpenBSD team and I am responding to that.
Do not invent arguments that I did not make. I have only said that naming it openrsync when rsync already exists and is "open" in the general sense is confusing.
I find the negative reactions to this observation very confusing, especially yours, but I see that you're an OpenBSD developer so that explains your bias.
> The person I replied to said the "open" prefix means it's made by the OpenBSD team and I am responding to that.
What was said is that the OpenBSD operating system folks chose to use the Open— prefix for all their other projects ("They simply ran with the naming convention."). What was not said was that all Open— prefixed projects were from them.
You’re inventing an argument I didn’t make. OpenBSD doesn’t own “open”. Literally no one is saying that. What I did say is that openrsync is named that because the OpenBSD team names their projects that way. The “open” in this project means that it came from OpenBSD, not that that it’s in contrast to rsync being proprietary (which it isn’t).
I've been using openrsync here and there since it was announced and it's definitely improved over time. I'm looking forward to when I can use it exclusively.
The one place in my usage where it doesn't match Samba rsync is with the following:
openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services
I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/services/services.
Normal directory mirroring as in -av -e ssh /path/to/src/ example.com:/path/to/dst/ works as it does with Samba rsync.
> I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/services/services.
As someone who has also suffered uncountable years of abuse from rsync, I understand the impulse, but I think it makes a lot more sense (and is a safer default) to create a second ”services”.
If we have a chance to change rsync defaults to something less insane and save future generations from this mess I think we should.
We don't, since we're not implementing a UI from scratch, we're matching something else.
Of the two possible worlds where in one this reimplementation matches what some see as annoyances in the interface or in another they mostly match the interface except for a few cases where the purposefully diverge (for no good technical reason), IMO the latter is far worse and causes more enexpected behavior.
At most, add a special flag to opt into different default behavior so nobody is surprised by running the same command on different systems and getting different behavior.
Was there already a /tmp/services directory on the dest?
One of the biggest points of confusion with rsync is how directories and trailing slashes are handled.
> Was there already a /tmp/services directory on the dest?
No. And just to make sure, I ran a quick 'rm -rf /tmp/services' on the remote host, then re-ran openrsync on the client. Same result. This is OpenBSD 7.9 on both sides.
And I 100% agree about trailing slashes.
There's also a Go implementation by Michael Stapelberg / the Gokrazy team: https://github.com/gokrazy/rsync
For those needing context for the development of this package; this project is presently being developed as part of a RPKI validator.
https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-va...
This is the version used in macOS since 15.0.
Was it 15.0? I seem to recall it coming in one of the minor point releases in the 15.x line - and I remember it breaking some scripts mysteriously.
EDIT: ah, fun: they did include it in 15.0, but they decided to save the breaking change that removed backwards compatibility for 15.4. https://apple.stackexchange.com/a/479297
I'm going to ask a question. I could ask chatgpt. I could Google it. I am asking a question because it is human to do so.
Ubuntu's packaged rsync, is it Samba rsync? Why reimplement it?
There is also a (stub) web page:
https://www.openrsync.org/
The problem with this fragmentation of rsync is that Apple and Android will prefer it, but the Linux and greater GPL world will adhere to the original implantation due to inertia. Power users will just have to know the quirks of each version.
The only way to stop this is for the original author(s) to release this under a BSD license.
Edit: For those assuming equivalent/identical behavior, study these words carefully: "accepts only a subset of rsync's command-line arguments."
> The only way to stop this is for the original author(s) to release this under a BSD license.
Would that stop it? My understanding was that at least OpenBSD tended do redo things for technical reasons, not just licensing
It's really no different than every other BSD utility (and SysV utility, if you're running one of those) being different than the GNU ones. We've coped with it for fifty years at this point.
> Apple and Android will prefer it,
My thought upon reading this is why would Apple or Android bother including rsync? I've noticed that I've needed to install it manually on fresh installs of Debian, FreeBSD...
But then, I just checked a recent Mac that I don't use much and haven't put much on, and it's installed.
Basically like GNU Tar/CPIO and BSD Tar/CPIO. I've largely standardised towards using the bsd variant everywhere (especially since now even Windows ships it and it handles lots of other archive formats using the `tar` command) but it's always a pain to install it everywhere
Yeah, I'm leaning towards strongly preferring bsdtar since it's happy to work on e.g. zip files:) Does it have any real downsides?
The actual work of porting is matching the security features provided by OpenBSD's pledge(2) and unveil(2). These are critical elements to the functionality of the system. Without them, your system accepts arbitrary data from the public network.
https://justine.lol/pledge/
I am not seeing pledge on Alpine Linux in edge. Have people been testing Pledge on Linux? Did I perhaps misunderstand the risk of using Openrsync without pledge? Or is this article just for OpenBSD users?
Linux has no such features as pledge or unveil, nor capsicum. it has cgroups, namespaces and a mess ofnother things u need to combine to try and do similar things. (it was built iteratively as many systems interacting and being combined to form 'sandboxing' or isolation/limiting of capabilities rather than specific isolation as an entire concept with specific system calls and kernel paths to enable it).
there might be newer stuff in linux land now i see comments about landlock but i assume those will build on the linux primitives rather than whole new ones. - total assumption there but it would seem logical to reuse rather than make new.
part of likely what they mean by 'mess' is that its all over the place. many different ways to try and lock things down. hard to pick what is best etc. without thoroughly diving into the different subsystems entirely. (as opposed to just have 1 or 2 relatively simple system calls)
No, landlock is a separate thing. It's the first of its kind on Linux that doesn't completely suck, like seccomp does (https://blog.habets.se/2022/03/seccomp-unsafe-at-any-speed.h...).
From above your quote:
> The only officially-supported operating system is OpenBSD, as this has considerable security features.
And below your quote:
> This is possible (I think?) with FreeBSD's Capsicum, but Linux's security facilities are a mess, and will take an expert hand to properly secure.
It is portable in the sense that it compiles and runs, not in the sense that it has the same security features.
I'd love to see pledge/unveil on (upstream) Linux - but I'm not holding my breath.
> I'd love to see pledge/unveil on (upstream) Linux - but I'm not holding my breath
There is Landlock now, I believe it would be possible to implement unveil and pledge on top of that.
Ok that makes more sense, thankyou.
that quote seems to be a bit of an oversimplification to the point of being completely wrong.
> Without them, your system accepts arbitrary data from the public network.
Neither of these features change if you are accepting arbitrary data from the public network. They limit what an exploited process can do. It's explained properly in the 'Security' section, so I'm not sure where this came from.
that quote seems to be a bit of an oversimplification to the point of being completely wrong.
Under Portability [1] I don't have access to update that repo. I deleted my accounts when Microsoft took over.
[1] - https://github.com/kristapsdz/openrsync
This attempt to avoid things that use AI is increasingly looking like some weird kind of reverse whack-a-mole where each targeted hole becomes radioactive after. Just grabbing some popcorn to watch.
Thanks for the heads-up! I wasn't aware that Tridge is using Claude. I shall use Openrsync from now on.
I feel bad for people with the real name Claude.
I think it would be funny to have a grad student named Claude for the hilarious ambiguity it would create.
Yeah, and we thought the most unlucky people were the ones named Alexa.
Or those named Karen...
Rajesh here
It took me quite some time to realize what an utterly presumptuous product name Claude Code actually is, but only because Shannon is rarely mentioned with his first name. It's golden calf levels of hubris, even more so if you consider how incapable it was on release. It's like renaming calc.exe Einstein. Incredibly poor taste, but entirely in line with AI tech bro mentality.
That linkage never occurred to me, or, I suspect, them. Claude use to be a reasonably common name. I have an uncle Claude. Why do you believe they named it after Shannon in particular?
It seems to be a widely repeated "fact" which can't be traced to anything particularly authoritative:
https://archive.is/pt5fQ
https://britannica.com/topic/Claude-AI
Looks like the 2023 NYT article started it, and it uses this as reference:
> depending on which employee you ask, was either a nerdy tribute to the 20th-century mathematician Claude Shannon
Personally I always associated it with the silent protagonist from GTA3.
https://gta.fandom.com/wiki/Claude
Yeah, especially since most Americans don't know how to properly pronounce Claude.
Hmm, Claude Shannon was an American (the model is ostensibly named after him), so maybe how he pronounced it would be the correct pronunciation.
That said, every language on earth will adapt foreign words into its phonology. The alternative would be to adopt the phonology of every language that loaned a word into your language.
rsync has specific running modes for the super-user. It also pumps arbitrary data from the network onto your file-system. openrsync is about 10 000 lines of C code: do you trust me not to make mistakes?
No, but that's why almost nobody runs it outside of strict trust boundaries. This security section would make more sense if rsync was like curl, which routinely deals with hostile counterparties. If the other side of your rsync is hostile, you probably have bigger problems!
(I'm not an rpki person so I don't know if there's some part of that problem domain that changes this equation. I'm not dunking on the project, just saying this snagged me in the README).
No, but that's why almost nobody runs it outside of strict trust boundaries. This security section would make more sense if rsync was like curl, which routinely deals with hostile counterparties. If the other side of your rsync is hostile, you probably have bigger problems!
I disagree. While rsync is most often used to transfer data between "friendly" systems, it's inherently crossing a security boundary. It's important to make sure that an attacker can't leverage it to transform the breach of one system into the breach of multiple systems.
> almost nobody runs it outside of strict trust boundaries.
I guess you can define "strict" however you want, but from what I saw ~10 years ago, most linux distros handled mirroring with rsync. That's a lot of usage in a pretty core part of the foundational open source ecosystem.
OK, I agree, that's bad.
Many distros use rsync for that but also support unencrypted HTTP.
They’re layering on checksums and signing such that they mostly don’t think about the trustworthiness of mirrors or the networks between them.
No-slop version for the sane of us
Context: https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
https://social.treehouse.systems/@thesamesam/116662824873341...
+1 to this. Other than people's reflexive anger or fear about AI coming for their code, I don't see anything to suggest that these are bugs that are due to the inclusion of AI vs bugs in a program with a bunch of complex interop with the filesystem and network.
In any case, it's important to identify projects that are beginning to actively vibecode and clearly express position on this issue on various platforms so that authors and maintainers receive feedback. Even if this particular bug was not written by LLM in this particular case, it's not a fact that the release does not include other regressions and that subsequent vibecoded versions will not include them & new ones.
> it's not a fact that the release does not include other regressions and [...]
Are you listening to yourself? The same exact thing also has applied, applies and will continue to apply to manually written code, in perpetuity. There's nothing new under the sun here; regressions happen when there's change, and the only way to mitigate is to have healthy feedback loops.
Do not going harassing developers because you think they are doing it wrong. If you can do better and don't want to actually contribute to the upstream you are always free to fork it.
That's literally what this thread is about.
Openrsync is a project that’s existed for a long time and is a great example of people building what they want.
This thread has people suggesting it’s good or important to go tell open source devs they’re using bad tools.
The former is great. The latter is not.
No. It's not important. It's actually pretty shitty to go around looking for projects and then telling the maintainers you disagree with how they develop.
Friendly reminder that volunteer maintainers owe you literally not a single goddamn thing. I absolutely want no AI slop in my commercial products that I pay money for, but your feedback is not important to people you are not paying to develop software for you. They gave away not only their software but the source code for free; if you have a problem with it, fork it. Which is something you can do with their generous allowance, and that is an allowance any maintainer can instead choose to not bother themselves with if publishing their code for free leads themselves to dealing with entitled internet commenters harassing them with complaints.
> Friendly reminder that volunteer maintainers owe you literally not a single goddamn thing.
Technically true. However, I also do not owe them my silence.
I have not checked with OpenBSD 7.9, but as of 7.8 it did not support --exclude or -z. But outside of that openrsync works great.
(EDIT: --exclude is now supported on 7.9. Not sure when that was added, nice!)
But seems avoiding "slop" is getting very hard. I saw postfix now has a bit of AI code in it.
https://mastodon.sdf.org/@mrmasterkeyboard@mastodon.social/1...
Somewhat ironic Postfix has a record of no root/RCE in the default install, where opensmptd hasn't (CVE-2020-7247). Time will tell if it stays that way.
Where do you see that about Postfix? I followed the links and the only thing I see is that AI is being used to find bugs, not write code.
>Claude assisted code found in external/ibm-public/postfix/dist...
That is from the original post in the thread. Is that really due to LLM ? I do not know since I avoid AI as much as I can.
But the person also posted this link too:
https://github.com/NetBSD/src/commit/f764ddf4062e855f73fe2e3...
Right, I read all that and I didn't see anything to indicate that AI is being used to write code - just one person's unsubstantiated claim.
I did not look at details until I saw your post, but I tend to agree with you on this point.
But that is the odd thing, how to tell for sure if a LLM was used :)
Exclude is very commonly used in automation jobs to avoid duplicating big git repos and other big files. I think that would be a show stopper for a number of people.
I just tried openrsync(1) on OpenBSD 7.9, --exclude now works.
I have not tried using exclude in openrsync in a while, but I can see it now works on OpenBSD 7.9!
What's the deal with the name? Openrsync implies to me that it's an open source alternative to a closed source program. But the original Rsync is GPL? Is this just the pushover license making it "more open"?
OpenBSD folks would consider the GPL to be less open due to the requirement to apply the GPL to any derivative works.
And GNU folks would say the GPL is actually the more open choice because it forces the project to stay open.
Two different ways of thinking about it I guess... it's nice to have choices and I don't think one is more or less "correct", more a matter of opinion/taste I guess.
I don't think the FSF would say that. They prefer the GPL, because it prevents someone from making a closed derivative, but I haven't seen them ever claim it is more open than "permissive" licenses.
It kind of reminds me of the equality of opportunity people versus the equality of outcome people. One sets the starting conditions for developers, the other the ending conditions for users.
Since developers are a subset of users, it's actually possible to calculate which is more open.
> more open choice because it forces the project
A true morality must be based on consent, not coercion. Humanity may not be there yet, and therein lies the argument for force (and thus copyleft); but the ultimate goal should always be to reduce its necessity.
It’s not coercion. You’re free to not use it, or alternatively do what these folks did, write your own. Coercion would be forcing people to use it through some mechanism, which clearly isn’t possible with GPL.
I see this, and the spiritual example that immediately comes to mind is that which is labeled as "crime". Would it be more moral that a murderer must first consent to being judged and sentenced, or that there is a system which automatically comes into play to hopefully deter but also punish it when it happens?
Allowing closed-source to exist is always the less moral choice for many reasons (one example being ecological sustainability)
Is this not the paradox of tolerance restated in different terms?
BSD license is unrestricted, it tolerates taking open source and closing it, thus always being at risk of things closing down.
GPL license doesn’t tolerate taking from open source and closing it, thus ensuring things stay open.
The paradox clears itself up if you look at what tolerance actually is. It's simply not interfering with people's agency over themselves. Given that your right to self-agency doesn't entitle you to restrict others' self-agency, behavior that does try restricting others' agency is automatically not included in "tolerance."
The BSD license is why we have Valkey and not a purely closed-source Redis. It would have been much easier to perform the rugpull if Redis had initially been GPLed.
On top of badreligion42’s point, that both licenses allow forking just as easily - don’t you have the rugpull part backwards?
Afaik BSD licensed stuff can be re-licensed under any more closed licenses at any time, where as to re-license GPL, you need consent from every single contributor.
But i’m not familiar with the redis-valkey story so, maybe there is some nuance i am missing?
Redis started off as Free Software, but was switched to a source available license in version 7.4. The community promptly forked to Valkey, which is still under the BSD license. Since then, Redis shifted to AGPL 3, with contributor agreements, to try to ensure that they're the only ones who can attempt to commercialize Redis.
AGPL makes commercializing harder only for people who fear the AGPL because they want to keep stuff for themselves. there is no problem commercializing it if you don't mind sharing all your connected code. the only benefit redis has is that they can integrate non-free code in their hosting service, while the rest of us could not. since it is their work, i think it is reasonable that they have an advantage. it does not reduce my freedom as a user. it only hinders AWS and other big players from crushing redis.
And how exactly did the BSD license make creating Valkey easier? GPL and BSD licenses both have the source in the open. Anyone creating a fork, can easily do so for either BSD or GPL licensed projects. Since Redis is a database, which the user won't be using a binary of, even using a fork of a supposedly GPL-licensed Redis would not require you to share your modifications with your user, same as BSD.
The BSD license made forking Valkey easier because it ensures that everyone has equal footing. The GPL, especially with contributor license agreements and the like, makes it much more easy for a single party to control the direction of the product. For another example of this happening, look at MongoDB. It started out under the AGPL, but was rugpulled to a non-free license.
It feels like your actual beef here is with CLAs, which often are designed to allow the current maintainers to relicense.
CLAs are not an attribute of the GPL. They're an agreement that can be applied to contributions to any codebase with any license.
Mongo was already a centralized project. Technically open source agpl but I don’t remember it having a large developer community or really many contributions from outside mongo. When the rug pull happened I think simply most people didn’t care or moved on to equal (or better) alternatives. It’s not beloved software like Redis is.
The BSD license made forking Valkey easier because it ensures that everyone has equal footing
equal footing on the license is what allowed AWS to crush the original creators of the products they host.
it's a trade off.
the AGPL does not prevent a hosting service. it only prevents creating non-free addons. i see no problem with that. see also my other comment
Many projects closely associated with OpenBSD start with "open"... openssh, openbgpd, openntpd, opensmtpd etc.
Notable exception, OpenSSL already had the Open prefix so the OpenBSD project is called LibreSSL.
Not many are reimplementations of existing, much more popular, already open source projects.
OpenSSH was a 'reaction' to the original SSH(.com) code getting closed source:
> OpenSSH originated in 1999 as a fork of Björn Grönvall's OSSH, which derived from Tatu Ylönen's original SSH 1.2.12 release, the last version distributed under a license permitting open-source redistribution before Ylönen's subsequent software became proprietary under SSH Communications Security.[4]
* https://en.wikipedia.org/wiki/OpenSSH
It was probably the second thing with the Open— prefix by this group of developers, OpenBSD itself being the first. They simply ran with the naming convention. OpenBGP/OSPF were developed as alternatives to Quagga (GPL).
Is rsync going closed source? If not, how is that the same thing?
> Is rsync going closed source? If not, how is that the same thing?
Not closed source, but with rsync 3.0 it changed its license to GPL3, which a lot of folks don't like: BSD/MIT licenses have zero limitations on use and distribution, GPL2 (rsync 1.x, 2.x) forces one to release code, GPL3 (rsync ≥3.x) adds further restrictions.
Some folks want to distribute code with as few restrictions as possible. Other folks have a great good/goal in mind (e.g., 'all software is open source') and so add 'local restrictions' to hopefully achieve greater non-restrictions.
No. The name only means it’s made by the OpenBSD team, nothing more. If they made their own Python port, it’d be called OpenPython, even though the original is FOSS.
So is OpenSUSE made by the BSD team? OpenOffice? OpenShift? OpenCV? OpenAI?
It is not reasonable to claim this prefix unambiguously refers to the OpenBSD team. I do not understand why so many in this thread are pretending this isn't a confusing choice.
Nobody ever claimed that “Open” is a prefix used unambiguously by only one group of people ever.
In fact, your insistence that “Open” can only be used by projects that are replacing proprietary software is itself very odd.
OpenBSD itself has had its name for thirty years, and is not named for being an “open source” implementation of a proprietary OS.
The person I replied to said the "open" prefix means it's made by the OpenBSD team and I am responding to that.
Do not invent arguments that I did not make. I have only said that naming it openrsync when rsync already exists and is "open" in the general sense is confusing.
I find the negative reactions to this observation very confusing, especially yours, but I see that you're an OpenBSD developer so that explains your bias.
> The person I replied to said the "open" prefix means it's made by the OpenBSD team and I am responding to that.
What was said is that the OpenBSD operating system folks chose to use the Open— prefix for all their other projects ("They simply ran with the naming convention."). What was not said was that all Open— prefixed projects were from them.
You’re inventing an argument I didn’t make. OpenBSD doesn’t own “open”. Literally no one is saying that. What I did say is that openrsync is named that because the OpenBSD team names their projects that way. The “open” in this project means that it came from OpenBSD, not that that it’s in contrast to rsync being proprietary (which it isn’t).
OpenBSD didn’t get its name from NetBSD going closed source.
Historically speaking, it may have meant open to poorly socialized developers.
Which aren't? It seems all (or most) are.