site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) Thanks for listening, Peter _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Hi, Some of you may recognize me as having started a similarly themed thread <http://lists.apple.com/archives/Darwin-dev/2005/Jun/msg00136.html> a year ago. Well, today, I was looking for the source code to the 10.4.x linker on Intel. So I went to the <http://darwinsource.opendarwin.org> website, fully expecting to look at the cctools sources and see what differences in behavior to expect between Intel and ppc. I expected the linker sources to be available, because they have always been available, and because cctools contains the assembler which is based on GNU as, and thus under the terms of the GPL. I was amazed to find that the gas sources had been split out of cctools, so they could be provided in accordance with the GPL, but no other part of cctools was made available. So I never did get an answer to my question. I assume that the idea is to limit the source code availability to those who are attempting to steal Mac OS X and use it on systems not built or approved by Apple. I can understand and applaud the goal, but not the methods. By limiting published source code to that which is "infected" by the GPL, Apple is, in my honest opinion, scoring an own goal. Let me give some examples. Without cctools source code, Shantonu Sen's wonderful odcctools project will die. Nobody will be able to build a to darwin gcc cross compiler anymore. <http://www.opendarwin.org/projects/odcctools> dlcompat could never have been written, as it uses "internal" APIs from dyld <http://darwinsource.opendarwin.org/10.3.9/cctools-573.1/dyld/dyld_libfuncs.c> <http://www.opendarwin.org/projects/dlcompat> Were it not for Apple publishing their changes to the perl project, perl upstream would never have known about Apple's changes to perl for tiger. <http://www.mail-archive.com/perl5-porters@perl.org/msg86873.html> Now, those are only things that I know about/can remember right now, I'm sure that there are many other examples. I guess that kext developers will now have a significantly harder time when something makes them say "wtf!" there will be no sources to check. It's not only very sad, it is quite unnecessary to have such a blanket ban on publishing source code. Userland sources that come from *BSD should be published, as should projects like perl, python that have relaxed licensing, but in no way affect anyones ability to run Mac OS X on their Dell. If possible, I'd advocate publishing obfuscated kernel sources too. According to <http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology_Overview/index.html>, consists of Core OS, Core Services, Application Services, Graphics & Multimedia, Application Environments, and, User Experience. Of these, Core OS has previously had the source code published on each release of the operating system. This means that the source code that Apple used to publish and allow people to browse, in the main, comes from opensource projects. While many project's licences do not require that changes be sent back or source code published, I think it only fair play. This email sent to site_archiver@lists.apple.com