Theocacao: Darwin Kernel Source vs Piracy

Darwin Kernel Source vs Piracy

An article on Daemon News gives a personal perspective on working with the Darwin source base, specifically what it's like interacting with Apple engineers and the workflow. The end of the article points out that kernel source isn't provided for Darwin x86:

With the release of Mac OS X for x86 processors, Apple has chosen to not release source to key components of the OS, such as the kernel and all drivers. This means Darwin/x86 is dead in the water;

It seems that this is because releasing the source for these things would help hackers pirate Mac OS X. There are certainly a wide variety of opinions on these issues, but the basic mechanics are pretty simple at the end of the day.

The Darwin project only exists due to an unspoken contract: free source code is provided with the understanding that Apple needs to use it in a commercial product. Darwin is funded by Mac OS X. If the open source project makes it hard to sell the product in the intended way, what is Apple to do?

It may be that the need to switch to another processor architecture and the accompanying threat of piracy has changed the rules. A pirated copy of Mac OS X which is installed on a generic x86 box is a much bigger deal for Apple than a pirated copy of Windows XP is for Microsoft. In fact, Apple has never made too big of a deal about piracy on PPC, presumably because the user must already own a Mac.

The article continues:

One has to wonder why Apple even bothers to release non-GPL'd source at all, if it is unwilling to cooperate with external developers to increase their return on investment and accept external bug fixes and features. Even worse, one has to wonder why people would want to donate their time to such a fruitless and pointless cause.

This is actually a fair question to ask. Darwin exists in something of a misty, grey landscape where absolute rights and wrongs are scarce. The project is a delicate compromise between community benefits and the very real point that Apple can't turn its entire business on its side for the sake of Darwin.

Certainly some have argued that Apple should open source all of Mac OS X, but these suggestions rarely come with any sort of explanation of how to make the big picture work. At the end of the day, Apple is in the business of creating computers, not economies. To get right down to it, the engineers need to be paid so that they can feed their families.

Some have suggested that Apple should pursue the "free software, pay for support" approach. This may work for the geek-centric Linux culture, but it just doesn't fit with Apple. People buy Macs so they can minimize their interactions with support. This would, by definition, be a losing business proposition.

Hopefully we'll see all these issues shake out as Apple's x86 platform matures.

Darwin Kernel Source vs Piracy
Posted Feb 23, 2006 — 17 comments below

Ian — Feb 24, 06 828

Of course, this assumes that Apple has decided not to release Darwin/x86 at all. The referenced article presents no proof that this is the case. Apple has made no public statements to this effect at all. Just a few days ago, people were assuming that Apple was going to release only those parts of Darwin that were under the GPL, and yesterday Apple released far more than that. In the absence of any sort of public statement, this sort of speculation seems a bit premature.

Preston — Feb 24, 06 829

According to what I've heard, the source files are now posted, and it was a simple mistake on Apple's part.

Guido — Feb 24, 06 830

Only a part of the sources have been posted: the xnu kernel and the drivers are still missing.

lone — Feb 24, 06 831

The kernel checks on boot that Darwin is running on an Intel Mac by asking the onboard Fritz ("Palladium") chip. The chip contains a key that the kernel checks for autenticity.
Publishing the kernel source means that Apple must either publish its private keys, or make a version of the kernel without the keys inside. Either way, an enterprising hacker can pick up kernel sources and recompile it after commenting out the chip check, making it available to all x86 PCs.
Me? I'd have stayed with PowerPC :D

Scott Stevenson — Feb 24, 06 832

The kernel checks on boot that Darwin is running on an Intel Mac by asking the onboard Fritz ("Palladium") chip. The chip contains a key that the kernel checks for autenticity.

I haven't looked into this stuff at all, so I'm curious -- how do the hacks circumvent the startup check? I don't want the code, just curious on theoretical level how this is possible.

Johannes — Feb 24, 06 836

The silly thing about this is, of course, that the intel version of OS X has already been hacked, without the help of Apple-published kernel code.
Holding it back has accomplished nothing (except, of course, angering all those who need the kernel code, as documentation, as a starting point for own developments, or just as a fun thing to read).
As someone who falls in the last category (yes, I do like to read source code) I just hope that they'll just waiting to clean up the xnu code, to then release it.

Scott Stevenson — Feb 24, 06 837

The silly thing about this is, of course, that the intel version of OS X has already been hacked, without the help of Apple-published kernel code.

Hmmm, I guess don't quite see the logic here. The current versions have been hacked but not future versions. If something is added to the kernel to protect the OS in a different way, then releasing future versions of the kernel as source would likely help pirates.

Anon — Feb 25, 06 838

OK - how about this: just move the hardware check to something not in darwin - like, say, the window server (no genuine apple hardware - no GUI for you!)

lone — Feb 25, 06 841

That would be the logical conclusion, but it seems Apple wants to have the check in the kernel rather than in userspace...

PO'd developer — Feb 25, 06 847

This stinks! I'm a new ADC Select Developer, and I'm going to try to write kernel drivers for x86... How on earth am I going to do this if I cant look at existing drivers or the kernel source code?

Scott Stevenson — Feb 25, 06 849

Kernel drivers? You mean IOKit drivers? I believe there's documentation and examples for this. In any case, your code shouldn't dig into the kernel internals since that could break from release to release. You should be using the IOKit interfaces.

Or am missing your point?

Jonathan — Feb 27, 06 850

In a relating note, I noticed that with release 8.5 of Darwin Apple has switched to the older version of their open source licence (APSL 2 -> APSL 1.1). Do you think this was done to fight piracy or for some other reasons?

Kai Cherry — Mar 10, 06 927

I know this is "old" but is is still a *very real problem*...in fact we are writing software to get around this boneheadedness on Apple's part.

Essentially, it is harder to write x86 drivers, because you cannot debug them on a PPC via kdp, the kernel debugger.

You can't do this, because there is an endian bug. We know how to fix it. We can't.

So, we have had to result in writing a proxy that sits "in the middle" to do this work, when it would have taken 10x less time at this point to fix it in the kernel.

sat — Mar 13, 06 929

Kai Cherry - could you post your kdp proxy somewhere for use?

This is already a problem with some other projects.

KAD — Apr 20, 06 1115

I was truly interested in buying a Mac.
After having several friends that switched and were not very happy I thought I would do some additional research.
These forums have been very helpful.
I'm sticking to Debian Linux.

Scott Stevenson — Apr 21, 06 1116

I'm sticking to Debian Linux

Hmmmm, well I guess if kernel source is important to you. In any case, I heard somebody mention that 10.4.6's kernel source is now available, so maybe you can look into that.

Anyome — May 17, 06 1259

The x86 kernel source is there, you just have to look inside it and you'll notice folders in saying i386 and ppc ;)

Comments Feed

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.