[kmeisthax]

Well, GPLv3's installation instructions requirement more or less is targeted squarely at consumer electronics companies and that includes Apple. If Apple were to include GPLv3 software in iOS, the only way to comply with the license would be to significantly alter their security model to include an owner override. While there are ways that Apple could still use GPLv3 software, not change their security model, and remain in compliance[0]; I imagine they decided it would be easier to just ban new GPL software in their OS entirely rather than deal with the compliance headaches.

Apple in particular never shipped any GPLv3 software in their OS and stopped updating even v2 software. They used to be very heavy GCC users, but wrote their own permissively-licensed compiler that outdoes it in almost every way. In their defense, they actually wanted LLVM to be an upstream FSF project; but RMS famously lost the e-mail because he daily-drives barely functional ancient laptops. In a sense, that too is enterprise-hostility; albeit not owing to choice of license. I imagine that if the FSF had agreed to refactor GCC the way Apple wanted, Apple would have gone through the time and effort of GPLv3 compliance.

I'd also argue that GPLv3 didn't actually fix the TiVo loophole. It can't - not unless we're going to pull an SSPL and start writing copylefts that trip on software that merely runs alongside Linux. The way TiVo got around the GPLv2 installation instructions requirement was to make their own proprietary app enforce the kernel lockout rather than the bootloader, and prohibiting that would be very draconian.

That being said, you also should take into account the historical context of GPLv3's announcement and development. The FSF had some pretty crazy ideas, like rolling the Affero clause into GPLv3, that probably scared people into dropping their upgrade clauses even if it never actually made it into an actual FSF license document. The end document we actually got is relatively tame, but the message the FSF sent was that they were willing to ship whatever license language they felt met their personal definition of software freedom. If you didn't like any new restrictions they added to your own code, tough.

[0] Stuff that runs in a sandbox container and doesn't use private entitlements probably isn't violating GPLv3, because Apple hands out free dev accounts that let you compile and run whatever, albeit with some annoying requirements to renew the app's signature every week.

[no_time]

>the only way to comply with the license would be to significantly alter their security model to include an owner override.

Damn imagine the horror.

[kmeisthax]

In Apple's defense, it's not a trivial ask. They have security features like activation lock that would be defeated by a badly-implemented owner override[0]. Right now, if someone steals your iPhone, it becomes e-waste because you can't reset it unless you login to iCloud. But if there's an owner override that anyone can use, then they can install a version of iOS with the activation lock patched out.

That's not to say it can't be made reasonably secure. In fact, Apple actually did it on M1 Macs[1]. The secure boot policy there includes a device-generated key that only the first admin account - the Owner account - gets, which can be used to sign new kernels for that machine only. Ergo, if you want to install Linux, you have to be logged into that Owner account. You can't steal someone's Mac, wipe it, and defeat the activation lock by installing Linux. But to get there required a lot of additional engineering work[2] - the easy path is "only our software runs on our hardware".

[0] AFAIK Android has similar security features, so they face the same threats that iOS does.

[1] T2 has a similar but less elaborate scheme. It doesn't have per-volume security guarantees - if you want to dual-boot Mac and Linux, then you have to turn off the signature check on the macOS side.

[2] Engineering work, BTW, that I'm genuinely surprised Apple put in. I imagine there were some very heated internal debates over whether or not the Mac should even have an owner override. Especially given that Apple did their darnedest to ensure that the owner override can't touch anything even remotely related to iOS. If you launch an owner-signed kernel, iOS app support turns itself off; and the Apple-signed versions of macOS actually have the same sideloading restrictions on iOS apps that iOS does. Which is particularly silly, because you can get around that by just compiling for Catalyst.

[no_time]

Yeah I agree it's a very nontrivial task but there is a difference between not doing it because it's hard or explicitly saying "fuck you, know your place"

>If you launch an owner-signed kernel, iOS app support turns itself off; and the Apple-signed versions of macOS actually have the same sideloading restrictions on iOS apps that iOS does.

Has there been an attempt to patch this out? if the supposed owner override is actually real then technically the only thing separating you from a non treacherous ios subsystem is a few conditional jumps right?

[sbuk]

Interestingly, this[0] was posted a day after the article. It looks like Apple initially contributed a lot to BASH for instance

>We had a lot of gratitude in the Open Source community — particular for our fixes to make bash pass the tests.

The GNU projects showed their appreciation by re-licensing under the GPLv3.

[0]https://news.ycombinator.com/item?id=29984016