rdesktop: Fascilitating plugins as external processes

[Ilya Konstantinov]

Hi,

Recently we've been having a legal discussion in the rdesktop (client to
Microsoft Remote Desktop) project and I was hoping for the input of this
group.

Technical background:
In the Microsoft Remote Desktop protocol, there's support for third
party vendors channeling their specific data over the remote desktop
channel ("Virtual Channels"), e.g. Smell-o-vision Ltd. can write a
plugin that'll sit in Microsoft's Remote Desktop client and receive
smell data via a special channel in the Remote Desktop connection.

One contributor has introduced a patch which allows such vendors to
write such plugins for rdesktop:
https://sourceforge.net/tracker/?func=detail&atid=381349&aid=1472969&group_id=24366

Naturally, since rdesktop is GPL, the issue of the plugins being 
non-free was risen. (Yes, the original contributor is employed by such a 
vendor, but that's a minor detail.)

A workaround was proposed, whereas the plugins won't be shared libraries 
but forked processes communicating through a well-defined protocol.

Though it's clear to me that, in principle, non-free software is not in 
my best interests, I'm wondering about the legal side of it.

Questions:
1. Is fork-exec really a workaround for shared libraries? Isn't that 
just a technical detail? If so, wouldn't that be a huge loophole in the GPL?
2. Whether external process or shared library, is this even illegal 
under the GPL? Is this case "rdesktop is a platform and the plugin is a 
program", in which case the GPL will allow it?
Or is similar to as if rdesktop is an "SSL library" and the non-free 
plugin is the "HTTP server", where the HTTP server has to be free to use 
a GPL'd SSL library?

I'll appreciate any feedback.