Caution: because I am talking about code
libraries, this discussion will be technical – a combination of the worst of geek and lawyer-speak.  Sorry.

I had a discussion with a colleague yesterday about Apple’s choice of licenses used for open-sourcing of its
Grand Central Dispatch (GCD)
concurrency framework, which is a piece of software Apple credits with driving great Mac OS X performance improvements.  GCD comprises both a
library component, called “libdispatch”, licensed under Apache 2.0, and a C
language extension, called “blocks”, a runtime distributed under the LLVM
license
, a BSD derivative (someone has already begun porting blocks to iPhone and older versions of OS X, distributed
under the MIT license). 

Where I had speculated that Apple had chosen the license mix
that it had to facilitate incorporation into GCC (and avoid the problems Apple
experienced with developing Objective C as a series of libraries and a
front-end that was a derivative of gpl-licensed GCC code), it looks like in
reality Apple is trying to wean itself from GCC entirely, by its support for,
and use of LLVM (a compiler runtime that is an alternative to GCC’s runtime)
and a compiler front end called clang.  The LLVM runtime still supports
the goal of portability because of its availability on linux (some
distributions use a GCC-llvm compilation method for the kernel).  David Chisnall, in a thoughtful article, claims that Apple's transition to LLVM (away from GCC) presents a perfect example of the principle that "you don't necessarily get good results from forcing people to do things."

Apple’s support for LLVM may not be entirely due to the
licensing issue, because LLVM is considered to have significant performance
improvements
, and a reason for Snow Leopard’s improved performance
The performance improvement, however, can be due to Apple’s development support
for LLVM, which may be due to the licensing issue.  So we may have a
chicken and egg issue.  I do think that Apple started supporting LLVM
before it got really good
(and most likely in order to be free from GCC), and
then the performance improvements followed (with help from a large open-source
community that arose to support the project).
  John Siracusa at ars technica says:  “By committing to a Clang/LLVM-powered
future, Apple has finally taken complete control of its development
platform.” 

So what do the respective licenses  and distribution
methods get Apple?

GCD and libdispatch – Apache 2.0.  As we
have discussed, one distinguishing feature of Apache 2.0 is that it provides
for automatic license termination if the licensee instigates patent litigation
regarding the work (in clause 3).  This provides Apple with control over its own patents
regarding the work, and is similar to how Apple released Mini DisplayPort, a
standard that has been incorporated into VESA's DisplayPort standard.  
Apache 2.0 also allows for “viral” licensing, although it is not “copyleft” per
se; in clause 4, redistribution allows either source and/or code redistribution
and derivatives as long as the distribution is also licensed under Apache
2.0.  For that reason, the FSF considers Apache 2.0 licensed code to be
“one-way” compatible with GPLv3, meaning that a GPLv3 project can include
Apache 2.0 code
, but not the other way around.  

The Apache 2.0  license is not compatible with GPL2,
because of the automatic patent license termination, but that does not
automatically mean that the linux kernel project cannot use the new libdispatch
library.  Ryan Paul at ars technica believes that the license incompatibility does prevent adoption by linux.  Remember that the linux kernel today will allow linkage to fully
proprietary driver libraries, let alone alternatively licensed open-sourced
libraries.  See http://blogs.techrepublic.com.com/opensource/?p=276&tag=rbxccnbtr1
for a discussion of the debate about allowing linkage to proprietary
drivers.  So Apple can get adoption or use of libdispatch by linux, if
that is its goal. 

Apple is promoting use of GCD as a standard by also
releasing OpenCL, a standard it has been developing with nVidia, incorporating
a set of libraries to take OpenGL a step further and provide parallel
processing on graphics cards and core processors.  OpenCL has been set up
under the “stewardship” of the Khronos group that controls OpenGL, but John Siracusa says to "make no mistake, OpenCL is Apple's baby."  OpenCL builds on GCD, (and LLVM, but does not
incorporate blocks) and provides a higher level programming API, just as OpenGL
did, as well as language extensions.  
Just as OpenGL has been implemented on linux, there is no reason to believe
that OpenCL will not also be implemented on linux, by nVidia, if no one else.

Blocks – released under LLVM license (a BSD
derivative) and as part of LLVM project.  It may have just made sense to
release blocks as part of the existing LLVM project and under the license
already adopted for that project.   This license is compatible with
the GPL Because it is a BSD derivative, it can be used in GPL projects; the
llvm-gcc compiler front end is released under GPLv2, (no update since GPLv3),
but there is a GCC link time optimizer released under GPLv3. .

Because blocks are a c language extension, and not just a
library feature, there is extra benefit to Apple by encouraging adoption
(language extensions that developers do not adopt are useless).  Of
course, by inclusion in Apple development environments, there will be some
level of adoption, but there are network effects in having more developers use
this construct.  Ars technica explains that “It's Apple intention to
submit blocks as an official extension to one or more of the C-based languages,
though it's not yet clear which standards bodies are receptive to the
proposal,” (further noting that blocks are supported by all of Apple’s compilers
(including Apple’s GCC distribution).

Apple has many very smart IP lawyers guiding its choice in open source licenses; the fact that neither Grand Central Dispatch nor Blocks were released under the GPL is not an accident.  Ultimately, I don't agree that Apple's choice of a non-GPL license will prevent its adoption by anyone other than GPL evangelists, and I believe that Apple would not have open-sourced this work if its only alternative was to use the GPL.  I think Apple's example shows how careful companies need to be in open sourcing code, especially if such code is part of a larger whole.