Ik bedoel met wijzigingen niet het aanpassen van de kernel, maar het niet meer gebruiken van de code die onder een non-APSL licentie en opnieuw schrijven wat je onder een andere licentie wil hebben om daarmee eventuele beperkingen die een licentie oplegt om een andere licentie te gebruiken te omzeilen.
XNU is verder as-is te downloaden, te compileren en daarna te gebruiken met een willekeurige OS X installatie. Er is ergens zelfs in een boek uit 2002 een complete handleiding voor mensen die niet weten hoe dat moet of het nog nooit gedaan hebben en een stappen overzicht willen.
http://docstore.mik.ua/orelly/unix3/mac/ch07_01.htm
Hackintosh installaties die op niet ondersteunde CPU's gingen draaien gebruikten vaak aangepaste kernels (bijvoorbeeld de ToH kernel voor ondersteuning met CPU's die bepaalde instructies niet hadden, voornamelijk oude P4's en AMD's). Die hebben daar dus gretig gebruik van gemaakt. Tegenwoordig is dat de moeite niet waard om dat de standaard kernel ook prima draait zolang je maar geen antieke hardware gebruikt
Wat AirPlay betreft: AirPlay is niet een speciale uitvinding van Apple, het is RTP/RTSP met AES encryptie en extra control kanalen (als we het even bij Audio houden). Die AES was dus een eis van MPAA & consorten, het lijkt me niet dat Apple dacht dat het een leuk idee was om geld weg te gooien om AES in een bestaand streaming protocol te implementeren als het niet nodig was

Verder is het niet te vergelijken met A2DP: ten eerste niet om dat het qua functionaliteit niet hetzelfde is (A2DP is point to point bluetooth audio van op z'n best matige kwaliteit) en om dat het nog niet bestond toen AirPlay (de eerste versie uit 2004 die toen nog AirTunes heette) maar gebruikte al RAOP, Remote Audio Output Protocol, om zowel digitaal als analoog muziek over TCP/IP te versturen met gebruik van mDNS autodiscovery. De AirPort Express heeft dan ook een gecombineerde 3.5 mm audio jack en toslink optische audio uitgang die je aan je DAC kan hangen om zo rechtstreeks hoge kwaliteit (in elk geval voor het jaar waarin het uitgebracht werd

iets van 16 bit & 44.1Khz) te streamen van je computer naar luidsprekers die ergens anders staan, en als je wil dus meerdere luidsprekers tegelijk wat je in feite een multi-room geluidssysteem geeft. Je kan dus vanaf meerdere computers naar meerdere luidsprekers streamen en vanaf je computer het volume regelen (en de volume regeling wordt dus ook op de client gedaan, alleen de control commando's verlaten je computer, hij stuurt niet een 'zachter' signaal). Apple heeft eigenlijk geen moeite genomen om het 'geheim' te houden, en licenties om AirPlay in third party apparatuur in te bouwen zijn er al sinds het bestaan van AirPlay. Heeft dus niks met anderen buiten sluiten te maken. Als je met players software players op andere platformen om audio te 'sturen' bedoelt: ja, dat wordt natuurlijk als verkoopfeature voor Apple producten zo gehouden, ze gaan natuurlijk niet iets ontwikkelen als ze er niet zelf rijker van kunnen worden

maar de RSA pubkey was al vrij vroeg beschikbaar en is niet veranderd, wat het implementeren in andere players vrij triviaal maakt, en dat al best lang. AirFoil gebruikt daar een third party library voor die in principe dus door allerlei andere software gebruikt kan worden voor integratie.
Dat HFS+ in de Linux tree niet bepaald op niveau is klopt, maar dat ligt vooral aan het gebrek aan behoefte. Behalve een HFS(+) schijf lezen en APM lezen is er ook weinig nut voor HFS+ op Linux, het is technisch misschien beter dan bijvoorbeeld FAT, exFAT of NTFS, maar biedt dan weer niks t.o.v. ext4, BTRFS of ZFS. Dat ze Apple's sources niet gebruiken is om dat de basis van de HFS driver op hele oude code gebaseerd is, nog van voor het OS X tijdperk, waardoor er op dat moment dus nog helemaal niks was om vanaf te werken. Dat omzetten gaat nu niemand meer doen gezien het eigenlijk niet nodig is. In bijna alle gevallen kan je een file sharing protocol gebruiken of een ander common filesystem gebruiken. Dat file haren is ook de reden dat Netatalk bijvoorbeeld wel flink bijgehouden werd/wordt, om dat het best goed werkt, erg snel is (sneller dan SMB), en vanuit een POSIX perspectief vanaf versie 2.2 vrij praktisch is als je het over TCP/IP gebruikt (en niet AppleTalk als iemand dat nog aan het doen zou zijn).
Dat ZFS alleen als read-only driver eindigde is inderdaad jammer, maar door Oracle's licentiewoede had Apple niet veel keuze. Nu ZFS ook een open source fork heeft is er kans op een ander bedrijf die een implementatie maakt en die in een commercieel product stopt, wat een precedent kan veroorzaken zodat het juridisch haalbaar is voor Apple om het nog een keer te proberen. De vraag is dan natuurlijk wat voor precedent dat dan zou scheppen, want als Oracle er een zaak van maakt en wint hebben we allemaal een probleem
Wat deze alinea betreft:
Apple is niet alleen maar gesloten, maar zoals de meeste commerciele partijen zijn ze verre van open. Mijn statement was ook niet dat Apple beter/slechter was dan de rest. Alleen dat commerciele partijen vaak andere beweegredenen hebben om delen te open-sourcen dan een Free Software Foundation (die doen het vanuit een overtuiging).
Ja en nee. Natuurlijk is het bestaansrecht van commerciële bedrijven geldverdienen en als je beursgenoteerd bent ook nog eens winstmaximalisatie bij de wet. Maar het kan allemaal een stuk erger dan het nu is. Qua sources liggen Google en Apple bijvoorbeeld mijlen ver voor als je het met Microsoft vergelijkt. Maar als je die drie met Canonical vergelijkt lopen ze weer lichtjaren achter. Maar als je die drie niet met Canonical vergelijkt maar met Oracle dan valt het allemaal wel weer mee (vooral voor Microsoft).
Als we ons beperken tot een MS vs. Apple vergelijking denk ik niet dat Microsoft enige kans heeft. De magere releases tot zo ver zijn prachtig, maar slaan nog geen deuk in het pakje boter dat de closed source wereld van Windows nu is. Apple daarentegen heeft erg veel software gewoon FOSS gemaakt, en andere software waarvan het verplicht was door de licentie ook gewoon weer gedeeld met hun eigen patches. Daarnaast zijn er integrale componenten daadwerkelijk publiekelijk toegankelijk en kan je PR's inschieten (en dan doel ik op MacOS Forge). Hoewel het er niet denderend veel zijn is het toch op z'n minst interessant te noemen dat zo'n gigantische multinational toch nog componenten FOSS kan maken na dat de juristen er hun plasje overheen gedaan hebben en alle grote bazen even flink aan hun grijze hoofden gekrabd hebben. En dan doel ik dus op code die van nul af opgebouwd is. En eigenlijk helemaal niet gepubliceerd had hoeven worden.
Uiteindelijk maakt het natuurlijk niet dat je opeens je eigen OS X en iOS kan gaan compileren, en als je het wat groter trekt: het is erg onwaarschijnlijk dat we met de manier waarop Amerika op "Intellectual Property Patents" draait ooit commerciële software van de giganten gaan zien die je 100% van sources zelf kan compileren. Maar dat er componenten of misschien later zelfs grote componenten wel vrij en vrij te compileren zijn is toch wel een flinke stap in de goede richting voor developers die meer willen dan een black box.