Hacker News Reader

Comment by implying | Hacker News Reader

Took a little while to find the magic words in there: https://github.com/wimpysworld/quickemu/blob/af26f41440d63a0...

I always wondered how is it stealing if you (1) own a copy and, (2) Apple effectively stopped charging money for macOS.

It's hardly stealing if the original owners still have a copy. It's more of a breach of terms of service, or unlicensed access to intellectual property.

The "theft" spin on copyright violation is the result of years of lobbying by the media industry because they foresaw a drop in sales when people didn't need to buy the same thing over and over again.

Property is about who has the right to control something, not about scarcity. Although its original application was to a physical object, it's not limited to physical objects. So, "stealing" can be considered in both a narrow context and a broader context. The narrow meaning refers to literally taking a physical object away from someone else and giving it to yourself. But the broader meaning is wresting exclusive control of the property from the lawful owner. So, in that sense, copyright infringement and license violations can be legally thought of as theft.

No one but Apple owns a copy of macOS. They own a license to use it according to the terms of that license.

Which is another argument against using the term "stealing". At no point does the user deprive Apple of the ownership of macOS.

Control is a part of ownership. If you don't control how something is used and by whom, you don't really own it. So either using it in unauthorized ways is in a manner theft, or Apple's "ownership" is not real ownership. I'm not sure what the solution is, but IP is a tricky concept no matter your position.

It sounds like Apple don’t even own it then if they can’t prevent people from pirating it.

I can’t prevent someone from robbing me, just make it harder for them to do so and have legal recourse if they do it anyway.

This still counts as “having control”.

It has nothing to do with actually preventing all infringement, but instead seeking enforcement in at least some cases. If a copyright owner is aware of substantial infringement and chooses not to pursue (or license) they may lose their copyright through genericization or other means.

(Caveat: I’m not a lawyer, but I learned broadly the above from an IP lawyer.)

Sure, and I didn’t argue for or against the use of that term. The legal definition of theft varies by jurisdiction, but is not necessarily limited to physical objects (e.g. services). I have no idea whether it’s appropriate in this case (I’m not a lawyer), but feels more like copyright infringement.

Not according to German law.

Do tell more (genuinely curious).

As with all information, society as a whole "owns" macOS - Apple only has been granted a temporary monopoly of this information in order to encourage them to create more.

Practically, what’s the difference until their copyright expires?

Innumerable court cases have turned on what are often negligible practical differences. Apple is said, legally, to "hold" copyright. Saying they "own" it would mean they have all sorts of rights and powers around it that we as a society choose not to grant to them.

That is not to say that numerous judges have not, on their own initiative, elected to grant holders many such powers. Judges can be just as confused as anyone, and more than some, and so exceed their statutory authority. Congress, moreso. But there is still a difference.

Actually I own several dvds that contain legitimate copies of Mac OS X (back when it came on dvds)

You may own the physical disc, but to use the software on it you need to accept the license terms.

Because to do that, I have to make another copy into the memory of my computer.

You're technically correct, but its debatable whether all parts of EULAs are legally binding/enforceable.

I think that the illegal (ish) part comes from Apple making macOS free if you're installing it on Apple hardware. They don't publicly license it for use on non-Apple hardware, although, I would guess that VMWare if not others has a license to run it on random x64 servers to test ESXi with because setting up a different testing environment of Mac Minis to test every change to their hypervisor on instead of using their normal testing infrastructure would be dumb.

(or they just do it anyway and don't tell Tim.)

> I think that the illegal (ish) part comes from Apple making macOS free if you're installing it on Apple hardware.

I don't think it's true since the phrase in question was present also in Mac OS X when we had to purchase each version. Apart from that, this part of the license is not valid in several European countries. When you think of it, it's quite reasonable: how could anyone dictate how you are using something you purchased? It makes no any sense.

> ...this part of the license is not valid in several European countries.

Do you have a link maybe? My quick search found nothing...

Ignoring the legal and accounting details, the basic idea is that macOS is something that Apple includes with each Mac computer that they sell.

If you don't own a Mac, you don't own macOS. If you own a Mac and some other computer(s), you own macOS for the Mac, but not for the computer(s). You might've purchased an upgrade to a newer version of macOS, but if you don't already own a Mac, you don't have something to upgrade, so the upgrade doesn't grant you ownership of macOS.

Now, from a legal point of view, it's a good deal different from (and more complicated than) that, but that's the basic idea. So don't make the mistake of thinking that because Apple gives macOS away for free to Mac owners, and don't use elaborate and onerous copy protection or license-tracking nonsense, that you're entitled to install it on something other than a Mac.

apple's eula allows you to run macos on apple hardware.

Just install proxmox on a mac mini or old mac pro and run macos VMs

What is this?

ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc

Bonus points if you also know these ones (without searching for them):

K4HVD...

09 F9 11 02 9D...

I don't know them but I'm going to venture a guess that at least 1 of them is the DVD decryption key.

The first looks like a Windows VLK (maybe XP?)

No thats FCKGW

I can't believe I remembered that.

It's odd the things we remember. I memorized a 25-digit Windows 98 Key because of how many times I reinstalled it. I don't remember why I had to reinstall it so many times, but I sure remember the key!

Ha! Internet high five :)

I guess you're just missing the Adobe CS Keys that didn't need the license server after they shut them down.

Won't someone take pity on Apple Computer?

In fact the company changed its name to just "Apple" back in 2007. So maybe this doesn't even count.

It's a Rot13-encoded string: "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc". It seems to be the string that is supposed to make MacOS only run on certified systems, but it's obviously been reverse engineered and now it needs to be added to any Mac emulators to work.

VirtualBox supports two methods of operation:

(1) You supply this value in the "DeviceKey" config parameter

(2) Ensure the "GetKeyFromRealSMC" boolean config parameter is enabled (not sure if it is turned on by default or not). When enabled, VirtualBox retrieves the value from the SMC of your Mac.

Obviously method (2) only works if your host is a Mac. Apple doesn't supply a public API to retrieve this value, so VirtualBox has some code which runs inside a macOS kernel extension, and directly uses the SMC hardware registers to request it. [EDIT: Actually, turns out macOS does have an undocumented API for this – talk to AppleSMC using IOServiceGetMatchingService, IOConnectCallStructMethod, etc – and they use it, but they still fall back to direct hardware access if the API call fails, or if Windows/Linux/etc is the host OS and Apple hardware is detected.] VirtualBox already has a bunch of kexts needed to provide various features, and so this is just a bit more code in one of those kexts.

Option (2) is a lot of extra complexity compared to option (1), but has the advantage of being legally much cleaner. Option (2) only works on Apple hardware, and so by using option (2) Apple's license condition, of only virtualising macOS on Apple hardware, is automatically enforced.

Considering that VirtualBox is from Oracle, and as well as open source, they also sell it as a commercial product, you can understand why Oracle's lawyers want option (2).

I don't see why someone would opt for option 2 when virtualizing macOS on an Apple machine.

So my understanding – if you run VirtualBox on macOS, and you choose macOS as Guest OS type when creating your VM, it automatically turns GetKeyFromRealSMC on. That means you are using option (2) by default. You can always switch to option (1) instead if you want to, but if you are virtualising macOS-on-macOS, there is little reason to.

From reading the VirtualBox source code [0] – it also automatically enables GetKeyFromRealSMC if it detects Apple hardware, even if the host OS isn't macOS. So, if you install Windows on your Mac, and then create a macOS VM in VirtualBox, it will automatically select option (2) as well. (I think, they actually include the code to talk to the Apple SMC in their Windows and Linux kernel drivers too.)

(Note I haven't actually tried doing this myself, this is just what I gather from the source.)

[0] https://github.com/mdaniel/virtualbox-org-svn-vbox-trunk/blo...

> but if you are virtualising macOS-on-macOS, there is little reason to.

Not needing to run a kext just to retrieve a known hardcoded string seems like a very good reason.

You don't need to use a kext. You can instead use IOKit to talk to the AppleSMC driver over a Mach port. Works even without root: https://gist.github.com/vagelim/dd5be2802ecb097b81cf07711f6a...

VirtualBox has code to do the above. But it also has code in one of its kexts to do it by talking directly to the hardware, in case (for whatever reason) this API doesn't work; it tries IOKit first and then calls the kext as a fallback. And, the kext doesn't solely exist to talk to the SMC, it does a bunch of other things too. I'm not sure whether VirtualBox works without its kexts, but if it doesn't, it isn't because of this reason.

(When I wrote my original comment above, I didn't know you could do this through the IOKit API, although I've since edited that comment to mention it.)

Can't the emulator just patch out the code that checks for that string?

That would likely need to be built for every version of MacOS that's ever been made, it's easier to emulate the hardware and provide the key it's looking for. That part alone shouldn't violate any ToS or laws on it's own, as long as the key isn't provided by the emulator/vendor. That will still allow you to still virtualize MacOS on the actual hardware (as is required by the license of the OS) without having a hacky patch in place that could lead to crashes or failures to boot whenever an update is applied to the guest.

disclaimer: I am not a lawyer, this is not legal advice, etc.

It is illegal under the DMCA to circumvent an effective copy protection measure, or to traffic in devices intended primarily for such circumvention. The law sets a very, very low bar for what counts as "effective". Basically, if you get around any obstacle to unauthorized copying or use, or show others how to get around it, you have committed a felony. Everyone who has repeated the device key here has committed a felony.

I assume the `tr` is to avoid detection, there's a tiny bit more info here: https://www.nicksherlock.com/2021/06/installing-macos-12-mon... (grep for 'OSK')

Seems people really avoid saying the value, ('don't be surprised it doesn't look like a random string') maybe there's some history of Apple requesting people cease & desist wherever they find it, I don't know.

It's easy enough to search for "isa-applemsc":

https://github.com/search?q=isa-applesmc&type=code

I'm guessing it's more of a philosophical stance rather than avoiding detection. Like "Apple isn't going to make me put the string 'dontsteal' in my repo".

Fair enough, I just had no idea to search for that. (I searched 'OSK' because that was the variable name and it seemed not specific to quickemu.)

Reply on news.ycombinator.com