Hacker News Reader

Comment by chasil | Hacker News Reader

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."

View on HN

> 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

Jeremy Alliston (assuming that my memory serves me) is the foremost to decide if this should be done.

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.

The only option should not to be to take away user freedoms. BSD licenses are popular with proprietary software writers because they can use it without any of the restrictions that seek to preserve the rights of the end user. Instead you get proprietary software stacks like Apple and Android that seek to lock the users out of anything not granted by the company.

The correct way to stop this is to file bugs against the software for not matching the de-facto standard of the copied software.

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?

Limits on the length of path and file names in the archive.

Edit: I see that they switched from ustar to pax as the default format in OpenBSD 7.6, so I guess this isn't true any longer.

> The only way to stop this is for the original author(s) to release this under a BSD license.

That is likely not possible even if they wanted to - unless all contributors have signed over rights to their contributions.

Even then if the new project is specifically wanting to simplify things, and/or a change in language is important, reimplementation might still be preferable for them.

Exactly.

> 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.

> The only way to stop this is for the original author(s) to release this under a BSD license

No, then you get proprietary forks of the BSD codebase.

Apple doesn't like GPLv3, but this is by choice.

Sometimes, inventions by OpenBSD team (often using Open as prefix) become standard, such as OpenSSH and PF.

Reply on news.ycombinator.com