4 ms·
> unless they provided the OS-level signing keys on request All they need is to provide a bypass which permits executing a modified binary, which they already
by wahern 7y ago
> unless they provided the OS-level signing keys on request
All they need is to provide a bypass which permits executing a modified binary, which they already do otherwise projects like Homebrew and MacPorts wouldn't be possible, not to mention the fact that development on macOS would become a nightmare.
From a technical and legal perspective there's no reason to avoid the GPLv3 for a program like GNU Make. Apple's lawyers are just lazy and instituted a blanket, company-wide prohibition against GPLv3. A GPLv3'd Bash might plausibly create some headaches given the system integration, but they could have always used ksh like every other BSD, or zsh as they're now doing, as the default system shell and shipped a modern, updated Bash as a convenience for user scripts. iOS also poses additional headaches, but that's a separate issue--Apple already deprecated system(3) and in general you can't (and don't) rely on shell programs in iOS.
TL;DR: Apple's lawyers are lazy and needlessly hostile, even given an expansive, unrealistic interpretation of the GPLv3 anti-circumvention clause.
- nrclark 7y agoAgreed with this. There's one extra dimension though - the toolchain. The catch with MacPorts and Homebrew is that both of them use the XCode toolchain for compilation and linking. And Apple encumbers the heck out of XCode with EULAs, App-store accounts, etc. My interpretation of GPLv3's "Installation Information" section is that Apple wouldn't be able to force you to do any of that junk if they were shipping GPLv3 components. I hate that Apple does all of that bullshit. But somebody at Apple seems to think there's value in all that EULA protection and control, which is probably why GPLv3 software got the boot.