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. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
