[sldev] Media Rendering Plugin Framework Interaction

[Argent Stonecutter]

On 2009-11-12, at 09:04, Lawson English wrote:
> Argent Stonecutter wrote:
>> If the plugin links to a GPLed program then it has to be covered  
>> by  the GPL. A plugin using an arms-length scheme like the proxy  
>> scheme I  proposed some time back wouldn't be a problem, but I  
>> can't see how you  could implement a plugin that does something  
>> like rendering content  onto a prim with that kind of interface.

> The media plugin uses shared memory + a socket stream for discrete  
> events like raw mouse/keyboard i/o.

> Reading and writing into the same address shouldn't count as  
> "linking" else any app that used hardware mapped memory would be  
> verbotten. E.g. anything using a graphics card or a print buffer.

That depends on the interpretation of "derived work". That's what  
counts, not how the potential avenue of derivation is implemented. The  
FSF has in the past argued that simply using an API that only has a  
GPL implementation counts as a derived work, and this was taken  
seriously enough to lead to a couple of token BSD-licensed projects  
implementing the same API as a GPL-licensed project just to shortcut  
that. The only cases I know of where such an argument haven't been  
made is when the connection is through an actual honest-to-Internet  
network socket (and closing that "loophole" was one of the original  
goals of the GPL3, in drafts at least).

In this case it would be Linden Lab's interpretation of where the  
distinction lies that matters. Have they stated explicitly that this  
specific API is "arms length" enough that a plugin wouldn't count as a  
derived work? If not, they need to.

For things like graphic cards and print buffers, the "OS API"  
exception covers them.