The vast majority of questions I get about combining GPL and proprietary software concern embedded systems, since Linux is a component of so many consumer products these days. It's impressive, for instance, to look at Sony's web site where they fulfill their GPL obligation, and see the dozens of TV models and many other products that contain Linux. So, this discussion concerns primarily embedded systems.
(Desktop and server applications really only have one path to keeping Open Source and proprietary products separate: make them physically separate programs, each with its own license. Fortunately, most of the libraries on a Linux system are under licenses that allow them to be combined with a proprietary program without trouble.)
Linux is a natural for embedded systems. That's why it's popping up in more cell phones, often without the customer even realizing it's there. But cell phone manufacturers, and the broader sector of embedded systems, must cope with the problem of how to combine the GPL Linux kernel, and software that isn't Open Source. How does one do that legally?
Most of the publicity over suits to enforce the GPL concerns embedded systems: set-top boxes, cable modems, the list goes on. The suits are caused by just one thing: engineers and their managers combining software from different sources, without going to their company's own lawyers for help in understanding the software licenses. They're used to just clicking yes with no regard to what they're committing themselves and their company to.
The very worst offenders sell their designs to other, much larger, companies without conveying what the licenses are and what obligations the big company must fulfill and then the big company gets sued. This problem isn't specific to Open Source: violation of proprietary software licenses, with their higher stakes, is rife in the embedded systems industry.
Fortunately, it is possible to combine different sorts of software legally, if your team puts some thought into it. The first thing you'll need to do is to build a partnership of your legal organization and engineering. This requires giving engineers sufficient training so that they'll recognize a copyright issue when they encounter it, and will know to call in legal for help rather than attempting to solve the problem alone.
On the legal side, they must be aware that engineering is scored by fulfilling goals on time, and that when they call for legal advice, that advice has to come quickly enough that the engineer isn't put off schedule. Often, an engineer who has been delayed too long will simply go ahead without legal advice, due to the need to fulfill his schedule. And that can cost you big bucks later.
Legal-engineering reviews of how software is combined need to happen early in the design process, when the cost of making a change is low. Finding an issue of license non-compliance or copyright infringement when you're two weeks from shipping the product is much more expensive.
It's important for management to completely understand why you need to hold some software close, while other software should be open. There are really only two good business reasons for keeping software proprietary: that the software provides a business differentiator, making your product visibly better in the customer's eyes, or that the software component doesn't belong to your company, and thus you're not the one who decides whether it's open or closed.
Surprisingly, all of the cellular telephone handset manufacturers I've talked to designate one product as the software that they must hold close at all costs: the GSM stack. This is the software that actually links your telephone with the rest of the cellular network.