Current versions of macOS use a signed system volume [1], much like iOS - under a standard system configuration, the user can't replace system executables or other files, even as root. Unlike iOS, the user can disable SSV, but I'm not certain that's sufficient for GPLv3 - and I can't imagine Apple feels comfortable with that ambiguity.
By the GNU website it would be sufficient. The website says:
> GPLv3 stops tivoization by requiring the distributor to provide you with whatever information or data is necessary to install modified software on the device
By my reading of this, there is not a requirement that the operating system is unlocked, but the device. Being able to install an alternate operating system should meet the requirement to "install modified software on the device."
> This may be as simple as a set of instructions, or it may include special data such as cryptographic keys or information about how to bypass an integrity check in the hardware.
As you've mentioned with disabling SSV, and as Asahi Linux has shown, Apple Silicon hardware can run 3rd party operating systems without any problems.
The hardware might be open for now but you can imagine Apple would like to keep the possibility of closing it off on the table, thus the allergy to gplv3.
Edit: "without any problems" is definitely a stretch.
I feel like there is a wide gap between "hand holding" and holding the specs locked up in Cupertino never to see the light of day. A M-generation Mac is not the same kind of set up to allow running software as say, any x86 machine.
I also imagine that quite simply saying "look you can compile this binary as an alternative and run it on the machine" would fit the requirements, even if it doesn't entirely capture the spirit of anti-tivoisation
Sure, though there's little point in replacing executables such as rsync when you can install your own version (perhaps through a package manager and package repository / database such as Homebrew [1] or MacPorts [2]) and use the PATH environment variable to decide which version of the executable you'd like to use in which context.
This might be true for the most part as an end user, but from a licensing perspective regarding the original binaries, this is irrelevant.
You must be able to modify and change the code, not merely append to the PATH:
> Tivoization: Some companies have created various different kinds of devices that run GPLed software, and then rigged the hardware so that they can change the software that's running, but you cannot.
My claim is entirely from the end user perspective. We should not really care which tool Apple includes for their licensing purposes. If we have a dependency on a particular tool then we have the ability to install and use it ourselves. The signed system volume does not interfere with our ability to do that.
I'd advise looking at the actual language of the GPL, not the FSF's (non-binding) statements about what they intended it to mean. The relevant text is at the end of section 6 of https://www.gnu.org/licenses/gpl-3.0.txt - search for the words "Installation Information". I am not a lawyer, but my reading of the text suggests that:
1) The so-called anti-Tivoization clauses are scoped to "consumer products". Don't ask me why, but the language is very deliberately constructed to limit these terms to products "which are normally used for personal, family, or household purposes" - if you're building hardware for commercial or industrial use, none of this applies.
2) These clauses are also scoped to object code which is conveyed "as part of a transaction" in which the user purchases or rents a consumer product which the code is intended for use with. The intent was to limit this to software which was incorporated in the device; however, it accidentally ends up applying to any consumer transaction where the user purchases (e.g.) both a computer and a piece of software which includes GPLv3 code - regardless of who's selling them. So, in practice, this actually applies to any GPLv3 software, regardless of whether it's part of a device's firmware or not.
3) The end result of these clauses is to require that any software distributed under these conditions (which is to say, any GPLv3 software) be distributed with "Installation Information". It's somewhat ambiguous what precisely this encompasses, but it's quite possible that, if Apple distributed GPLv3 software, some of their internal software signing keys and/or build processes would be considered part of that Installation Information.
> Current versions of macOS use a signed system volume
Sometimes I feel like I'm deluding myself with the small inconveniences I put myself through only using Linux, but finding out about stuff like this wipes that away.
[1]: https://support.apple.com/guide/security/signed-system-volum...