The smaller processor runs a compact real-time operating system or no operating system at all. The PDA-like functions live in the larger processor, which runs a more powerful operating system based on the Linux kernel, Windows CE, Symbian. The smaller processor listens for phone calls continuously, while the larger one sleeps to save battery power when the user isn't interacting with it.
With two processors, it's clear that the programs in one are separate from those in the other processor. As I've described this, it already keeps the GSM stack in its own space. Other software that must be locked away from the world like a DRM system can live there too.
With this sort of organization, it is possible to change all of the software in the larger chip, and the software in the smaller chip continues to do its appointed tasks properly. Properly handled, this organization can even be used to host software under the newer GPL3 license alongside of software that is locked down and provides DRM, things GPL3 eschews.
Although the Linux kernel is under the GPL, applications that run on top of it do not themselves need to be under the GPL, and they can be under any license. User-mode programs are where most of your business-differentiating software belongs, since they interact with the user. The only programs you might not want to put here are ones that need to be very thoroughly locked down, that need to provide real-time services or that handle hardware interrupts directly.
Kernel under a Kernel
Just as Linux does not insist that applications on top of it have the GPL, a kernel running under Linux, in a separate hardware address space, can be used to insulate proprietary software from Linux. Recently, virtualization systems have been used for this task, although they are probably too large for embedded applications.
What not to do
Don't assume that you can put proprietary kernel drivers in a run-time loadable kernel module. The legality of such a practice is dubious, and there have not been sufficient cases to say reliably what would happen if you were to get sued.
Also, don't look for, and use loopholes in the Open Source licenses. Nothing makes your company look worse than taking unfair advantage of people who provided their work to you without charge, expecting in good faith that you'd honor their license. It also tends to make Open Source folks reluctant to cooperate with your company, the next time you need help with their software. And it looks bad to judges, too.
Don't try to do what I've discussed without legal counsel to advise and review your actions.
Bruce Perens is one of the founders of the Open Source movement in software, and today is a strategic consultant to companies large and small on issues of Open Source, Open Standards, and technology. He spends a lot of time explaining software engineering to lawyers, and law to software engineers and their managers. He can be reached via firstname.lastname@example.org, or 510-984-1055.