Usually, the litmus test is: Does the software work at all without the GPL'd parts? If not, it doesn't matter how segregated you think it is, because it's still dependent on that GPL'd code.
As an example, consider a video player with a codec plugin system. The player ships with a noop plugin, a proprietary plugin for MPEG-1 video, and a general plugin that leverages GPL code. It is my understanding that the video player can still be non-GPL, but that wrapper to the GPL code must be GPL
This seems exactly analogous to the CLISP/libreadline example I just linked in another comment, where it was agreed that CLISP needs to be under the GPL.
The situation is, probably, a bit different if the video player authors have no intention of using GPL code and just develop an interface, and someone else unrelated comes along and writes a GPL plugin. But if the app's authors ship the GPL plugin or worse write it, they're on shaky ground.
(This gets you into some slightly silly situations where author A writes GPL software A linking software B, software B can make use of a GPL-incompatible library C, all of A, B, and C can legally redistribute their software on their own, but Debian has to make sure A doesn't link C because they're shipping the whole thing.)
If you're distributing them all together, all of it would have to be under the GPL. If you're distributing them separately, otoh, only the GPLed bits would have to be under the GPL.
