The question I've always had is how enforceable is that really? Obviously the whole point of Apple making macOS freely available is to run it on Apple hardware. They don't give it out for free to run on other hardware but can they really do anything about that other than require you to enter a serial number to download an image? If they really cared, they would just do something like hashing the serial number and current date and time against a secret key (maybe inside a read-only portion of the TPM) and only Apple would be able to verify that the hardware is legit. You would need to somehow expose the TPM to the hypervisor to be able to generate hashes for macOS to verify it's license. Clearly this is not a huge problem for Apple because they would already be doing this if it was an issue.
I’m omitting a few details for brevity (MS licensing is nuts when you get into the weeds).
With other hosts, it’s kind of an Adobe approach - you either weren’t gonna buy a Mac anyways, or you might be tempted to buy a Mac after using macOS in a VM. Realistically, it’s not worth Apple coming after you unless you’re an enterprise making your money by breaking the EULA.
https://i.imgur.com/fop769Z.jpeg
(too bad they didn't pay such close attention to the power profiles their partners were attaching the intel brand name to...)
Serious stuff!
But this is packaged as a Docker image, and Docker is Linux-specific. Linux is not officially supported by Apple on their hardware, and is certainly not prevalent on it. I doubt that the intended target audience of this project is limited to Asahi Linux.
I guess that part of the license is meant to automatically disqualify an apple branded computer running a linux distro as host OS from running MacOS in a VM: "on each Apple-branded computer you own or control that is already running the Apple Software"
Some smart ass might argue that "already running the Apple software" doesn't mean at the exact same time but more like "I am still running it sometimes as dual boot" but I am not sure this would pass the court test.
And since I believe docker on MacOS runs on linux VM, so this would be running qemu on top of a linux vm on top of MacOS.
I can't see any legit use of this. Anyone who would need automatized and disposable environments for CI/CD would simply use UTM on mac minis: https://docs.getutm.app/scripting/scripting/
> that is already running the Apple Software
Running Linux on Apple hardware would not follow that part of the EULA.
""" "Corporate Headquarters has commanded," continued the magician, "that everyone use this workstation as a platform for new programs. Do you agree to this?"
"Certainly," replied the master, "I will have it transported to the data center immediately!" And the magician returned to his tower, well pleased.
Several days later, a novice wandered into the office of the master programmer and said, "I cannot find the listing for my new program. Do you know where it might be?"
"Yes," replied the master, "the listings are stacked on the platform in the data center." """
Serial ports were slow, grep wasn't really a thing, so having a printout (or "listing") of your program was a more efficient way (or only way!)to debug your program after the fact. https://www.youtube.com/watch?v=tJGrie7k97c
Back in the 90's, I had some programming classes in high school where there were 30 chairs, but 15 computers (around the edge)... bring your own 360kb floppy disk! So you had a real incentive (and a strict teacher) who insisted that you wrote out your program ahead of time, show it to her for a first-pass/feedback, and _then_ you'd get to go type it on the computer and see if it worked. Submissions were via printouts (of the program, aka "listing", along with the output) which she then took home and graded.
The whole document IMHO is worth a read, but is definitely a product of it's time (70's/80's/90's). https://en.wikipedia.org/wiki/The_Tao_of_Programming
Stick tongue firmly in cheek, empty your cup, and enjoy the ride!
Edit: ...and the relationship to the cantankerous original comment who "couldn't figure why they'd want to run OSX?", this is the zen-koan sarcastic response of: "use it as a platform for development" (ie: stack your papers on top if it)
It could be in a VM.
For people who want an open-source CLI solution rather than a commercial product which for larger businesses requires payment, there's also colima which does roughly the same thing.
So, lots of people very successfully use Docker on macOS, including on Apple hardware.
This particular software would need nested virtualization to be highly performant, but at least on M3 or newer Macs running macOS 15 or newer, this is now supported by Apple's virtualization framework:
https://developer.apple.com/documentation/virtualization/vzg...
So, if that's not easy to do in a useful and performant way now, it will absolutely be possible in the foreseeable future. I'm sure that the longtime macOS virtualization product Parallels Desktop will add support for nested virtualization quite soon if they haven't already, in addition to whatever Docker Desktop and colima do.
(Tangent: Asahi Linux apparently supports nested virtualization on M2 chips even though macOS doesn't.)
The same result can be achieved by running macOS right in the VM. This can be extra efficient since both the host OS and the guest OS are macOS, and the VM could use this fact.
It may make sense to run macOS in an emulator like QEMU under macOS, if the host version us ARM and the guest version is x64 (or vice versa). But I don't see where Linux and Docker would be useful in this case.
One such case, however, is when the user is already managing Linux Docker containers for other parts of their development or testing workflow and wants to manage macOS containers with the same tooling. That’s legitimate enough, especially when it ends up supporting nested virtualization of the same architecture and not true emulation, to keep the performance penalty modest enough.