Sure, no license key, except for the key used to decrypt protected binaries only on authorized hardware.
There is a license "key", it's the whole computer.
There is a license "key", it's the whole computer.
Sometimes there is freedom in restriction.
Yes, it is. If I pay for a product, it's my prerogative to use it in any way I please. Copyright grants a monopoly on distribution, not on controlling post-purchase usage of the product.
It's one thing to say "we only officially support installation of this product on this list of devices, and can't guarantee it will work on other devices", but inserting artificial restrictions into the product that prevent people from even trying to do officially unsupported things with the product, at their own initiative and at their own risk, is something there really isn't any justification for.
> do I really want the pain of people using it on an Arduino?
What pain? How does it even concern you if people are installing your firmware onto an Arduino, provided that they have legitimate copies of it?
> Opening it up to all the devices dilutes the main thing it has going for it.
Obviously, not installing OSX on other devices is what dilutes the "main thing it has going for it" for those people who have chosen to install OSX on other devices. Are you seriously trying to tell people that their personal preferences are objectively wrong?
> Sometimes there is freedom in restriction.
Straight out of Orwell.
That said, I don't find your arguments compelling; there's a difference between supporting and just not artificially preventing the software from running, and I don't see how doing the latter would make OSX stop "just working" on officially supported machines.
In fact, it's not like they don't anyway, and I don't see how have Hackintoshes diluted the experience of OSX on an Apple machine.
But I'm not saying they should, as I said, I don't really care. I'm just saying that just because they don't want to support other machines, that doesn't mean they have to purposely block them.
I mean, Asus doesn't support Linux on their motherboards either, but they don't have BIOS checks verifying that the OS is supported and refusing to boot if it isn't; they just tell you "you're on your own".
In fact the machines they're selling now almost certainly do have precisely this. It's called 'secure boot', and caused a lot of controversy. The major Linux distributions work because they've managed to get themselves signed with the appropriate key so the BIOS accepts them, but if you want to put a more niche distribution on there, you probably have to disable that check in the BIOS.
And you don't even have to disable the check if you want to use an unsigned distribution: most (all?) implementations allow the user to load her/his own public key to verify the signature against.
While we should worry about its impact - particularly in certain implementations - it's really not even close.
As far as I know, as long as all the hardware is stuff OSX has drivers for (and you generate a DSDT to describe that hardware) then you don't need any special "authorization." You just put in the OSX installer USB/DVD and it works.
> A Mac OS X system which is missing this extension, or a system where the extension has determined it's not running on Apple hardware, will be missing this decryption capability, and as a result will not be able to run the Apple-restricted binaries Dock, Finder, loginwindow, SystemUIServer, mds, ATSServer, backupd, fontd, translate, or translated.
In the old days (10.4), hackintosh systems would patch the protected binaries to remove the page encryption/decryption. Over time kernel extensions were developed to replace the functionality of Don't Steal Mac OS.kext (dsmos.kext or AppleDecrypt.kext) without the hardware checks.
The reason you no longer need either of these extensions is because a kernel extension called FakeSMC.kext was developed, which emulates as much of the functionality of the SMC as possible. This includes thermal and fan monitoring as well as the decryption key storage.
In a modern hackintosh setup, you make use of EFI emulation (inc. DSDT support) included in the bootloader (a boot-132 derivative, most likely Chameleon) and the pre-boot loading of emulator kernel extensions like FakeSMC.kext.
[1]: http://www.osxbook.com/book/bonus/chapter7/binaryprotection/ [2]: http://osxbook.com/book/bonus/chapter7/tpmdrmmyth/