I don't think the prior poster is suggesting that you would have to sign existing software.

I believe that they are suggesting that Apple would be required to let you sign your own software if you do choose and give owners the right to opt to have their os trust software they OR Apple signed.

There is something that was addressed in the gpl community called tivoization.

Tivos dvrs were Linux boxes wherein they shared their source technically complying with the letter of the gpl but in fact locking them down so users couldn't modify the devices violating to many peoples mind the spirit and clearly expressed intent of the license.

This is if I understand correctly dealt with in gpl 3 which is what I think the poster is talking about.

Apple ios devices are non free in the same fashion as Tivos which is incompatible with gpl3

This only seems to be an issue for iOS and its derivatives. You can replace /bin/bash on macOS if you turn SIP off.

I don't understand why GPLv3 would be a problem on macOS.

On macOS, you can run anything out of the box (depending on security/gatekeeper settings) and you can replace or modify system executables (such as /bin/bash) if you turn off SIP (which is slightly tricky to do but can be done from recovery mode.)

Running your own customized /usr/local/bin/bash is easy of course, and package managers like MacPorts or Brew make it simple to install various shells including the latest bash.

On iOS, however, there might be an issue, as you have to sign executables with XCode, but unfortunately Apple reduced free developer provisioning profiles from one year down to two weeks in order to block third-party app stores and malware, and to get more people to sign up for the paid developer program. Moreover, there is also no Apple-sanctioned way to modify system executables that I am aware of.

Did you notice how many qualifiers you had there? The trend on macOS is clear: harder and harder to run/do anything that isn't blessed by Apple.

SIP and Gatekeeper and one-time commands. I find disabling SIP to be much less painful than enabling unsigned drivers in Windows.

I wouldn't even classify turning off SIP as "slightly tricky". You boot into recovery mode, open the terminal, type in two words, and press enter.

Besides, this is separate from the GPLv3 question. You can absolutely recompile bash and replace macOS's version with your own, so I don't understand why this is a problem for Apple.

It's not a problem, yet. But I would argue that it's quite clear from Apple's actions the last ~5 years that they really want to make Mac OS behave as iOS as much as possible, including making it impossible for regular users to run arbitrary non app store software.

I know it sounds crazy, but they have for years now been taking steps - like this - which nobody seems to find a rational cause for, but which step by step seem to remove obstacles of technically, legal, or user expectations in line with making OS X an app store only platform, and if possible completely replace OS X with iOS.

You can't think of a single rational cause for requiring code signing by default other than them wanting to lock down the system? It's a huge security gain for normal users, and helps application developers by encouraging normal users to trust third-party applications rather than being terrified they'll get malware if they install any non-apple software.

It's certainly possible that Apple has intentions other than to make the platform better and a discussion can be had on if the tradeoffs are worth it, but it's ridiculous to claim that there are zero benefits to anyone but Apple.

I can't think of a single (non-malicious) rational cause for requiring code signing by default and making the requirement impossible for the user to disable.

We're talking about what Apple could be planning that would violate the GPLv3. As long as the signing can be disabled by the user, there shouldn't be a GPLv3 violation.

If there were a simple checkbox in the OS to disable SIP, I would expect zillions of ‘nice’ add-ons would ship with instructions on how to disable it.

I also expect zillions of helpful nieces/nephews would flip that checkbox for their uncles/aunts, and, accidentally or on purpose, leave it that way.

Even if that isn’t true, making it harder for malware to flip that flag already is a rational reason to implement it this way.

I have zero issues with how SIP is currently implemented. It's just hard enough to turn off to protect people, without being overly annoying.

I do worry very much about SIP becoming impossible to disable some day. Don't ban knives because people might cut themselves.

The obvious "rational" security benefits to users are:

1) Gatekeeper makes it harder to run malware; unsigned executables don't run by default, and signed malware can have its developer keys revoked by Apple.

2) SIP makes it harder for malware to modify system files.

The obvious "rational" business benefit to Apple is that:

3) Gatekeeper makes it harder to sell Mac apps without Apple getting a 30% cut

The "You must release changes"-clause and anti-tivoization clause might be not be enough individually to switch to MIT zsh but probably were together good enough reasons for Apple to switch.

Why? How does this affect them on macOS at all?

If Bash were also being used on iOS that would be different, but I'm quite confident that will never happen.

Again, perhaps it is because Apple is planning for a future where SIP and Gatekeeper cannot be turned off. A future where macOS is basically reduced/merged to iPadOS. Time will tell.

I expect Macs in enterprise/education are locked down so that Gatekeeper and SIP can't be turned off by normal users.

But preventing ALL Macs from turning off Gatekeeper and SIP? I think that would be unpopular.

A company or school can already do this easily, by the way, by setting a boot-loader password and restricting admin access. Notably, this are normal macOS functions, you don't need a fancy mtm setup.

That would violate GPLv3, wouldn't it?

IANAL, but I really don't think so. On a company laptop, the company owns the laptop, and the company can lock it down as much or as little as they want.