(iii) to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.
Apple allows 3rd party kernel extensions so naturally you would need to be able to debug the kernel. In my post, I link plenty of official Apple documentation that provide information on how to debug the kernel.
Also, I was careful to not say legal/illegal but allowed/disallowed. I am pretty sure that macOS disables some debugging calls, or at least it used to. What are the limits?
If it's illegal, it's up to Apple to deal with it. Why go out of the way doing free work for them?
- An old call, ptrace(PT_DENY_ATTACH), which prevents the process that calls it from being debugged (with either ptrace or dtrace). iTunes calls this. It's always been rather easy to circumvent, either by attaching before the process has the chance to make the call, or by installing a kext that disables the functionality.
- System Integrity Protection broadly prohibits debugging of system processes, as well as kernel tracing via dtrace. But SIP can be disabled by the user, by design.
Kernel debugging in particular is explicitly supported by Apple in the form of Kernel Debug Kits, which consist of debug symbols for the open source parts of the kernel, as well as variant builds with more debugging stuff enabled at compile time. Peeking at the proprietary parts is presumably against the license agreement but not technically restricted in any way (hard to imagine what such a restriction would look like).
I haven't completely read it (if only because it is 424 pages in multiple languages), but http://images.apple.com/legal/sla/docs/macOS1012.pdf does state:
"M. No Reverse Engineering. You may not, and you agree not to or enable others to, copy (except as expressly permitted by this License or by the Usage Rules if they are applicable to you), decompile, reverse engineer, disassemble, attempt to derive the source code of, decrypt, modify, or create derivative works of the Apple Software or any services provided by the Apple Software or any part thereof (except as and only to the extent any foregoing restriction is prohibited by applicable law or by licensing terms governing use of Open-Sourced Components that may be included with the Apple Software)."
I am not a lawyer, so I don't dare guess at what it really means, but I would guess there are many jurisdictions where most of that doesn't have any implication for persons _buying_ a Mac (a license requires an agreement between parties and cannot be something that one party forces upon another party)
Also, many licenses of open source parts do allow you to do anything with the software, including reverse engineering. I expect that means you are free to debug, say, the Mac OS kernel, once its source has been open sourced.
Source: maintainer of https://github.com/geerlingguy/macos-virtualbox-vm
Instead, Server.app does two things:
1. similar to Xcode, Server.app ships with a POSIX env inside it (nothing chroot/jail-y going on; it just has programs ./configure'd with that env as their --prefix, and some stub programs in the base system that exec their /Applications/Server.app equivalents if they exist);
2. it updates [non-rootless-protected] configuration files, that activate previously-inactive parts of the base system, like opendirectoryd and racoon.
AIUI their profits really come from the hardware sales, so if people try macOS and eventually decide to buy a Mac, Apple wins; if they don't, then Apple didn't really lose either, because those people wouldn't ever buy a Mac anyway.
I played around with Hackintoshing and even writing/porting device drivers to get my install working, and that was somewhat fun, and I even tried out some of the other interesting Mac-only software(z), but in the end I still preferred to use Windows and Linux.
Is it allowed?
Really it is on Apple to attempt to prevent this. Not on the hacker. There isn't many ways an OS vendor and prevent their product from being virtualized. If Apple was smart they'd maybe clean up OSX to have a decent cloud offering.
But alias nope.
And there are plenty of use cases:
* an iOS development offering (as long as iOS development is restricted to Mac OS X)
* security research
* integration with software not available on Linux (e.g. something Photoshoppy)
* hardcore fanboys who can't stomach using anything not ordained by Apple
Fwiw the same is true if you could virtualize iOS.
It's attractive because I can rent it when I need it, versus buying a Mac (or copy of OSX) I'll only use occasionally.