[sldev] Re: Plugin architecture

[Jason Giglio]

Tim Shephard wrote:
> Not sure what that means, but in case you're misunderstanding what I mean:
> 
> For those of us who can not afford to write code that doesn't get
> merged in, we generally want to understand what will have a high
> degree of probability of getting merged in before we start work.

We've been over that.  It's not the way open source works.  Hans Reiser 
devoted a large portion of his life to something that might have never 
been merged into Linux.  If he wanted to wait for official sign-offs 
from Linus on code that didn't exist yet, he'd still be waiting.

> 
> So we ask certain questions to the those who can wave the merging
> wand:  do the Linden's care about security?   Is performance
> important?    Are they concerned about the instability that loaded
> DLLs might cause on the client versus an embedded VM that mono could
> provide?
> 

No one is in a position to answer questions about a patch they haven't 
seen yet!  The code *must* come first.

> If we do develop a plugin architecture for Linden Labs, will our code
> be protected by copyright or will we have to open source that as well?
>  Some of us have zero desire to work on a plugin architecture, have
> it merged in, and only to find that we have to release all our plugin
> code under GPL.
> 

That is a valid question.

Assuming there is a tight enough coupling to make a "derived work" 
legally (which is a gray area in copyright law regarding runtime loaded 
modules)...

If you released your plugin as GPL, it wouldn't be compatible with the 
SL client license anyway, GPL+FLOSS exceptions is *not* GPL compatible.

The idea many of us have is that the low level plugins would likely 
mainly expose higher level functionality.  For example SL-Python might 
be a low level plugin, then you can actually write the guts of your 
plugin in Python and be free of license concerns.

In the end though you are asking a legal question no one knows the 
answer to.  No one really knows how tight coupling must be to create a 
derived work.  Most people consider normal dynamic linking to be close 
enough, and the FSF would probably consider even runtime loading close 
enough (as per their views on Java and GPL).  Even if LL says informally 
that it's "OK", that wouldn't change the legality of it without some 
official license exception from LL.

> Perhaps they don't yet know exactly what they want to merge in, which
> is why a dialogue of some sort might want to start up with the
> decision makers on their side.
> 

They can't know until the code is written.  They've said they aren't 
going to buy into anything sight unseen.

> Like any complicated group endeavor in life, a certain amount of
> forethought and dialogue between stakeholders is always a profitable
> thing.   Getting some indications from a leadership level, the
> decision makers, about what they probably want versus what they
> probably do not want can only help the process.

You have a PMI certification, am I right?

-Jason