3 ms·

I don't disagree either, but the whole GPLv3 situation is still not solved after all this years. Will they completely remove bash, rsync, eventually?

pininja 5y ago
I seem to remember they just switch default shell to zsh, which is MIT [0] [0] https://github.com/zsh-users/zsh/blob/master/LICENCE https://github.com/zsh-users/zsh/blob/master/LICENCE
- salamanderman 5y ago
  And if you change your default back to bash, every new terminal you open complains that you should switch to zsh
  - sigjuice 5y ago
    export BASH_SILENCE_DEPRECATION_WARNING=1
  - Klonoar 5y ago
    Not if you install a modern bash, unless I’ve missed something all these years.
    - salamanderman 5y ago
      What I see when I open a terminal is this: The default interactive shell is now zsh. To update your account to use zsh, please run `chsh -s /bin/zsh`. For more details, please visit https://support.apple.com/kb/HT208050 https://support.apple.com/kb/HT208050. I believe I switched from the default zsh to the bash that also came with the operating system. I don't think I installed a new bash. I was just trying to add on to/respond to the question "Will they completely remove bash, rsync, eventually?" . My answer was too short and I didn't actually make it clear what I was saying. I think the answer to the question "Will they completely remove bash, rsync, eventually?" is yes, at least for bash, I think they will remove it. My evidence for thinking they'll remove it is if you switch from the default zsh to the bash that comes with the operating system, they'll kindly ask you to switch back to zsh every time you open the terminal. Yes, you can change the default from nagging you with BASH_SILENCE_DEPRECATION_WARNING, which is great to know.
  - tobylane 5y ago
    If someone does that, I hope they find a newer version of bash. The old (3.27?) GPL2 bash should give a warning like that.
- tambourine_man 5y ago
  Sure, but that doesn’t solve the issue of shipping ancient software forever. It’s not default but it’s there, like Python 2 was
JimDabell 5y ago
> Will they completely remove bash, rsync, eventually? Removing bash is a pretty safe bet. They’ve been making move after move in recent years preparing for it. https://scriptingosx.com/2019/06/moving-to-zsh/ https://scriptingosx.com/2019/06/moving-to-zsh/
tombert 5y ago
I don't really see the problem with this though; people who are familiar with what bash and rsync are will probably understand computers well enough to install them with Homebrew or Macports or something.
- acdha 5y ago
  > people who are familiar with what bash and rsync are will probably understand computers well enough to install them with Homebrew or Macports or something. This is probably somewhat optimistic: there are a lot of people who are not developers who still use those tools — I've supported scientists, librarians, analysts, etc. who had a few scripts using tools like that but weren't really comfortable making changes. That doesn't mean it's _hard_ to install Homebrew but it's something which they'll need a little pointer and possibly institutional approval to do.
  - tombert 5y ago
    That's fair, I guess it has a potential to affect non-geek users at some level if they're using geek-supplied scripts. I guess I just feel like the net good would be to de-bundle these non-compliant tools and get them to install upstream versions from Homebrew or MacPorts or something. It's annoying, and I'm not one of those people that tends to be the "OMG JUST RTFM IT'S NOT THAT HARD!!", since if people are struggling with it then it is "that hard", but I feel like there isn't a solution that can satisfy all parties with this. It seems that we either break the workflow, which makes a few of the aforementioned parties for a bit, keep bundling the old versions of these tools and leave potential security problems in there, or somehow forcing Apple to change their OS to be GPL3 compliant. For better or worse (probably worse), that last one isn't going to happen, so it feels like the lesser of the two evils is to stop bundling software that won't be getting future support.
  - filmgirlcw 5y ago
    I agree that plenty of people who are not developers use those tools but I also don’t think the lift of installing homebrew or macports is going to be too much for people who are already smart enough to run those scripts in the first place. Like you said, it just requires a little pointer, which hopefully people will be happy to provide. The approval thing is valid, but I feel like that is likely going to be an issue that becomes more and more common as Apple moves to move more and more tools and utilities to the Xcode tools download anyway. Support/approval teams are just going to need to adjust to that reality, even if it’s an annoyance because I don’t see things shifting back, at least with Apple. But issues of approval aside, I honestly think back of myself as a teenager, installing fink and Macports and figuring it all out as I went along and I wouldn’t have called myself a developer then. I was just a girl who wanted to tinker with stuff. I think we (and I’m not talking about you specifically but the more general “we” as in the types of people that frequent HN) often underestimate the abilities of our non-dev brethren. We overestimate how much users know too, of course, but I do think we often slot people who have shown that they have the capabilities and desire to solve a problem into a “lesser” box just because they don’t carry the title of developer. And that affects those users too, who then assume they can’t do something when their own track record proves otherwise.
kmeisthax 5y ago
I'm pretty sure they eventually will. Personally, I'd like to know why Apple decided to ban GPLv3 software in macOS. It's not locked down enough to trip the TiVo clause[0]. My ongoing guess has been "just in case we need this in iOS", but these tools are all things that Apple would never ship in iOS anyway - the whole point of that OS is that you don't get access to any of those tools[1]. Alternatively, they might have just taken the Linus Torvalds tact of "this changes the deal", even if that change is minor. But that's not so much a license compatibility problem as much as it is a difference of opinion. Which is something that might never actually be resolved. Thanks to the v3 split, "GPL" now means two different licenses based on RMS's personal opinions on what restrictions best preserved software freedom at that time[2]. Even a hypothetical GPLv4 that dropped the TiVo clause for the sake of appeasing Linus and Apple would be changing the deal for people who wrote v3 programs expecting them to be a bulwark against locked-down devices. In either case, it does not make sense for Apple to ship decades-old utilities that it refuses to update for legal or moral reasons. At best, they're dead weight - it is very much common practice for people developing on macOS to install the newer versions of those utilities themselves. At worst, they are an actual security hazard, as they aren't sandboxed in any way. Bugs in those utilities would be very much exploitable on macOS. So if we've decided "we're not going to update this ever", then we might as well get rid of it and replace it with something else. [0] The TiVo clause in GPLv3 is actually not that strong, BTW. It requires that, if you ship the software as part of some hardware, that you provide a way for the owner of that hardware to modify the GPLv3 bits and have the hardware still work. The only thing that would remotely trip the clause on macOS would be SIP, and that's also owner-overridable. You will lose iOS app support in the process on M1 Macs, but the TiVo clause doesn't cover that scenario - which is ironic because that's exactly how TiVo worked around similar language in GPLv2. [1] Apps like iSH or a-shell do exist, but they run x86 or WASM binaries within the App Store sandbox. They also don't trip the GPLv3 TiVo clause. [2] At one point, RMS was seriously open to the idea of just rolling the Affero clause directly into GPL, which probably spooked people way more
- tombert 5y ago
  I wonder if it has something to do with the Busybox lawsuit. I think that it might be more to do with "we don't want to rock the boat with licensing...GPL2 has worked for us, and we don't want to be forced into a corner like Linksys was with Busybox". This is entirely speculation on my end, IANAL and I didn't work in that part of Apple.

pininja 5y ago

I seem to remember they just switch default shell to zsh, which is MIT [0] [0] https://github.com/zsh-users/zsh/blob/master/LICENCE https://github.com/zsh-users/zsh/blob/master/LICENCE

salamanderman 5y ago
And if you change your default back to bash, every new terminal you open complains that you should switch to zsh
- sigjuice 5y ago
  export BASH_SILENCE_DEPRECATION_WARNING=1
- Klonoar 5y ago
  Not if you install a modern bash, unless I’ve missed something all these years.
  - salamanderman 5y ago
    What I see when I open a terminal is this: The default interactive shell is now zsh. To update your account to use zsh, please run `chsh -s /bin/zsh`. For more details, please visit https://support.apple.com/kb/HT208050 https://support.apple.com/kb/HT208050. I believe I switched from the default zsh to the bash that also came with the operating system. I don't think I installed a new bash. I was just trying to add on to/respond to the question "Will they completely remove bash, rsync, eventually?" . My answer was too short and I didn't actually make it clear what I was saying. I think the answer to the question "Will they completely remove bash, rsync, eventually?" is yes, at least for bash, I think they will remove it. My evidence for thinking they'll remove it is if you switch from the default zsh to the bash that comes with the operating system, they'll kindly ask you to switch back to zsh every time you open the terminal. Yes, you can change the default from nagging you with BASH_SILENCE_DEPRECATION_WARNING, which is great to know.
- tobylane 5y ago
  If someone does that, I hope they find a newer version of bash. The old (3.27?) GPL2 bash should give a warning like that.
tambourine_man 5y ago
Sure, but that doesn’t solve the issue of shipping ancient software forever. It’s not default but it’s there, like Python 2 was

JimDabell 5y ago

> Will they completely remove bash, rsync, eventually? Removing bash is a pretty safe bet. They’ve been making move after move in recent years preparing for it. https://scriptingosx.com/2019/06/moving-to-zsh/ https://scriptingosx.com/2019/06/moving-to-zsh/

tombert 5y ago

I don't really see the problem with this though; people who are familiar with what bash and rsync are will probably understand computers well enough to install them with Homebrew or Macports or something.

acdha 5y ago
> people who are familiar with what bash and rsync are will probably understand computers well enough to install them with Homebrew or Macports or something. This is probably somewhat optimistic: there are a lot of people who are not developers who still use those tools — I've supported scientists, librarians, analysts, etc. who had a few scripts using tools like that but weren't really comfortable making changes. That doesn't mean it's _hard_ to install Homebrew but it's something which they'll need a little pointer and possibly institutional approval to do.
- tombert 5y ago
  That's fair, I guess it has a potential to affect non-geek users at some level if they're using geek-supplied scripts. I guess I just feel like the net good would be to de-bundle these non-compliant tools and get them to install upstream versions from Homebrew or MacPorts or something. It's annoying, and I'm not one of those people that tends to be the "OMG JUST RTFM IT'S NOT THAT HARD!!", since if people are struggling with it then it is "that hard", but I feel like there isn't a solution that can satisfy all parties with this. It seems that we either break the workflow, which makes a few of the aforementioned parties for a bit, keep bundling the old versions of these tools and leave potential security problems in there, or somehow forcing Apple to change their OS to be GPL3 compliant. For better or worse (probably worse), that last one isn't going to happen, so it feels like the lesser of the two evils is to stop bundling software that won't be getting future support.
- filmgirlcw 5y ago
  I agree that plenty of people who are not developers use those tools but I also don’t think the lift of installing homebrew or macports is going to be too much for people who are already smart enough to run those scripts in the first place. Like you said, it just requires a little pointer, which hopefully people will be happy to provide. The approval thing is valid, but I feel like that is likely going to be an issue that becomes more and more common as Apple moves to move more and more tools and utilities to the Xcode tools download anyway. Support/approval teams are just going to need to adjust to that reality, even if it’s an annoyance because I don’t see things shifting back, at least with Apple. But issues of approval aside, I honestly think back of myself as a teenager, installing fink and Macports and figuring it all out as I went along and I wouldn’t have called myself a developer then. I was just a girl who wanted to tinker with stuff. I think we (and I’m not talking about you specifically but the more general “we” as in the types of people that frequent HN) often underestimate the abilities of our non-dev brethren. We overestimate how much users know too, of course, but I do think we often slot people who have shown that they have the capabilities and desire to solve a problem into a “lesser” box just because they don’t carry the title of developer. And that affects those users too, who then assume they can’t do something when their own track record proves otherwise.

kmeisthax 5y ago

I'm pretty sure they eventually will. Personally, I'd like to know why Apple decided to ban GPLv3 software in macOS. It's not locked down enough to trip the TiVo clause[0]. My ongoing guess has been "just in case we need this in iOS", but these tools are all things that Apple would never ship in iOS anyway - the whole point of that OS is that you don't get access to any of those tools[1]. Alternatively, they might have just taken the Linus Torvalds tact of "this changes the deal", even if that change is minor. But that's not so much a license compatibility problem as much as it is a difference of opinion. Which is something that might never actually be resolved. Thanks to the v3 split, "GPL" now means two different licenses based on RMS's personal opinions on what restrictions best preserved software freedom at that time[2]. Even a hypothetical GPLv4 that dropped the TiVo clause for the sake of appeasing Linus and Apple would be changing the deal for people who wrote v3 programs expecting them to be a bulwark against locked-down devices. In either case, it does not make sense for Apple to ship decades-old utilities that it refuses to update for legal or moral reasons. At best, they're dead weight - it is very much common practice for people developing on macOS to install the newer versions of those utilities themselves. At worst, they are an actual security hazard, as they aren't sandboxed in any way. Bugs in those utilities would be very much exploitable on macOS. So if we've decided "we're not going to update this ever", then we might as well get rid of it and replace it with something else. [0] The TiVo clause in GPLv3 is actually not that strong, BTW. It requires that, if you ship the software as part of some hardware, that you provide a way for the owner of that hardware to modify the GPLv3 bits and have the hardware still work. The only thing that would remotely trip the clause on macOS would be SIP, and that's also owner-overridable. You will lose iOS app support in the process on M1 Macs, but the TiVo clause doesn't cover that scenario - which is ironic because that's exactly how TiVo worked around similar language in GPLv2. [1] Apps like iSH or a-shell do exist, but they run x86 or WASM binaries within the App Store sandbox. They also don't trip the GPLv3 TiVo clause. [2] At one point, RMS was seriously open to the idea of just rolling the Affero clause directly into GPL, which probably spooked people way more

tombert 5y ago
I wonder if it has something to do with the Busybox lawsuit. I think that it might be more to do with "we don't want to rock the boat with licensing...GPL2 has worked for us, and we don't want to be forced into a corner like Linksys was with Busybox". This is entirely speculation on my end, IANAL and I didn't work in that part of Apple.