Proper license for plugins

Sun Jan 16 22:35:16 UTC 2005

On Sun, 2005-01-16 at 08:35, Michael R. Bernstein wrote:
> On Sun, 2005-01-16 at 04:43, Benjamin Rossen wrote:

> > Yes. Emacs is GPL. You must make the source code available, you may not 
> > prevent anyone else from adding to your work and making new derivatives, and 
> > you are not permitted to use any other license form.
> 
> While I think this is true for Emacs, I don't think this is necessarily
> correct generally.
Yes emacs would be more of an interpretor either of lisp directly or of
a byte-code IIRC. There are some areas concerning modules or plugins
that may be grey-areas and there is legitimate argument over IMHO.

> If the plugin is a derivative of GPL code (whether another plugin, or
> the host software), the new plugin must clearly be GPL.
Yes that is absolutely true and also one should remember that the intent
of the GPL is also to control some "Collection Works" as well.

> The plugin and host software do form a combined work that in-toto should
> be covered under the GPL if distributed.
If distributed together in the same package then it all needs to be GPL.
If they are separately packaged and distributed then it *might* not be
needed for it all to be GPLed. For instance if a website had had the
parts available as separate downloads then that could be viewed as being
separate. Or if you had two CDs or two DVDs even if the could all fit on
one -- the faq does say that merely having files on the same hard-drive
or cd is mere aggregation. However I think that having them on
completely different installation media and making it clearly optional
is a good choice because it high-lights the independent and separate
status. CYA

> But the plugin itself, if not derived from GPL code, and if distributed
> separately, does not necessarily have to be licensed under the GPL. I'm
> going to be wishy-washy here, because IANAL, but it strongly depends on
> *how* the plugin interfaces with the host software, and also whether the
> plugin can be considered an independent work also useful on it's own.
True and what I think is super tricky here is what constitutes
*independent* and what is dependent? I think the "useful on it's own" is
an excellent test, but not an exclusive one. The GPL faq mentions a few
other things like:
is it fork()/exec() or is it mmap() and jump/call?
Is it native-machine code or byte-code or otherwise interpreted?
Is an interpreter extended to provide "bindings" to other facilities
like libraries or is it self-contained?
Do they share data-structures or make calls into each other?
What is the mechanism of communication (exec, pipes, rpc, function calls
within a shared address space, etc.)?
What are the semantics of the communication (what kinds of information
are interchanged)?

The Linux kernel also has an interesting approach; It can export a
symbol generically to all modules or restricted to GPL-only modules.
This is seen only as a guideline you might still step over the line even
if you only use the generically available module interfaces and symbols.

> In many cases, the plugin license would at least have to be
> GPL-compatible.
> 
> This is pretty dodgy though, and 'useful on it's own' is a pretty hard
> standard to meet for most plugins.
I don't think it is the *only* test that may apply. In fact strictly
speaking it may be impossible for most systems that we are referring to
in this discussion: A kernel usually needs at least a init, userspace
needs a kernel. So we must qualify what we intend.

If a plugin can be made to work with X, Y, or Z then is it dependent on
any one of them? I don't think so.
However if a plugin or program is only useful when combined with a
specific GPLed application, program, or infrastructure then it's claims
of independence can be seen as clearly weakened. It is further weakened
if it requires a narrow range of specific versions as well.

So I think that if a utilized component is a commodity and substitutable
then its commoditized usage should be seen as not nullifying the
independent status of the utilizing component. I think that in those
cases one should endeavor to stick to the lowest common denominator and
to standardized documented behavior and interfaces. The usage of
interfaces or behavior specific to a particular GPLed implementation may
nullify an independent status.

For instance the mysql people has said that if you have an application
that uses their DB then you should either be GPLed application or get a
special license. However if your application can be shown to run with
postgresql, interbase, or whatever as well then you are not dependent
IMHO.

Also how much does say the compilation process outputting binaries for
specific target architectures and the like effect dependency in the
legal sense? The definition of "dependent" includes influenced,
controlled, determined by something else, contingent, relying on support
or aid, connected or related.
If the program and it's plugins both use a native machine code then at
least the choice of which native code for the plugin you had compiler
produce is strongly *influenced* and determined by being the same as the
program.

So I think that incidental or mutually shared dependencies on
third-party constraints are not to be taken as nullifying an independent
status.

However I think a key guideline might be that to be considered
independent it should be able to function *alone*(to an extend that
makes sense in today's Operating Systems environments) or be very
flexible in what it can and will work with.

> Your safest bet, if you want to use the GPL for the host software but to
> allow proprietary plugins, is to simply grant an exception for plugins,
> however you define them.
> 
> Another option would be to use the LGPL for your application instead.
Both are very workable. YMMV and it depends on your situation and
desires.

> This is tricky territory, though, and you *will* want to get the advice
> of a lawyer.
Well IANAL but I think that if you do enough study and don't try
anything fancy/tricky that you shouldn't have to run see a lawyer over
every little thing.
BTW some of the things I said in this email are not universal agreed
with, so if you are doing something fancy then please don't construe
this email as containing any legal advice; I intended only to be
informative, and a helpful pointer to your further research.

-- 
http://dmoz.org/profiles/pollei.html
http://sourceforge.net/users/stephen_pollei/
http://www.orkut.com/Profile.aspx?uid=2455954990164098214
http://stephen_pollei.home.comcast.net/
GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1  3C01 910F 6BB5 4A7D 9677
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20050116/3b91334d/attachment.sig>