rdesktop: Fascilitating plugins as external processes

[Malcolm Bain]

Hi Ilya

A small note on Iain's comment, and this list on gpl-violations may not 
necessarily be the best place to discuss this (yet again..). 

I may be splitting hairs here, but it is important to note that what a 
technical person may call a "separate" work is not necessarily what a 
judge would consider.... As has been said in many times, the copyright 
law test for derivation/collective works does not necessarily have 
anything to do with "linking" (unfortunately? probably not - there are 
too many ways to "link"). While fork/exec may often draw a "boundary", 
it may not be the test used by the relevant court to define the limit 
between two works and therefore divide what is "GPL" from what "does not 
have to be under the GPL". (The fork/exec bounday is one that is used by 
FSF - I understand - to determine this boundary, as is commented in the 
link given by Iain below.)

If the plug-in can be shown to be a derivative work of (any) GPL code 
(in the legal meaning of "derivative": adaptation, transformation, 
modification... which can vary depending on your jurisdiction) - or, to 
a certain extent, a collective work including parts of (any) GPL code 
(again, a jursidiction specific problem), then it will fall under the 
GPL, whatever its "link" with other (GPL) code is.

So your question seems to (should?) be (from a legal point of view): If 
you want to allow plug-ins to avoid falling under the GPL of the main 
work, does the workaround prevent them from being considered derivative 
works of the GPL code (under the laws of your country, generally 
speaking)? Fork/exec communication may be - strong? - evidence of this, 
but not necessarily conclusive....

Trying to understand your other questions: a few thoughts:
-- There is no difference between platforms and plug-ins from a legal 
point of view - they are all lines of code (instructions) and therefore 
computer programs (at least, as far as EU law goes). A judge would 
normally look to see if B (plug-in) is a derivative work of A (rdesktop) 
- or collective work including A-, regardless of what "type" of programs 
they are.
-- L Torvalds excludes from GPL effect (his interpretation) programs in 
"user space" that use standard system call interfaces - which I don't 
find very helpful either. And when you have a stack (e.g. LAMP), where 
does the platform stop and the program start? Does rdesktop project want 
to make a similar statement about "rdesktop" as a platform (and its GPL 
license) such that "plug-ins using YYY communication method" will not be 
considered (by the rights holders of rdesktop - if you can pull that one 
off) as a derivative work of the main code....
-- One situation I can think of is if both "works" A and B (to avoid the 
work program, library or plug-in) are distributed together "as part of a 
whole" - regardless of whether they can be considered separate programs 
- then it all goes under the GPL (see section 2).... "But when you 
distribute the same sections as part of a whole which is a work based on 
the Program, the distribution of the whole must be on the terms of this 
License, whose permissions for other licensees extend to the entire 
whole, and thus to each and every part regardless of who wrote it." 
(Good luck applying that to your scenario! :-) ). I.e make sure the 
plug-ins are distributed separately...

G'Luck
Malcolm (TINLA, of course)


> -----Original Message-----
> From: legal-bounces at lists.gpl-violations.org
> [mailto:legal-bounces at lists.gpl-violations.org]On Behalf Of Ilya
> Konstantinov
> Sent: Monday, 08 May, 2006 07:10
> To: legal at lists.gpl-violations.org
> Subject: rdesktop: Fascilitating plugins as external processes
>
>
> 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.
>