Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Brian Thomas Sniffen <bts@evenmere.org>]

Henning Makholm <henning@makholm.net> writes:

>> I'm more concerned with pushing the ocaml.el discussion to a
>> conclusion.
>
> One step on the way to a conclusion is to figure out whether the .el
> files are derived from Emacs solely by virtue of using Emacs's APIs.

I've thought about this some more and come to two conclusions.

First, Emacs doesn't really have APIs.  It has LISP code, but there's
no encapsulation or privacy there: everything is exposed and available
to the user at run-time.  gnus-article-wash-html is as much a part of
the user interface as M-q.  Skilled operators of Emacs make use of
these functions all the time.  Such methods of operation are not
copyrightable.

Second, this pretty clearly fits the definition of a derived work
under the FSF's idea of the law, so we're stuck with that.  Some more
digging into Moglen's writing comes up with the following idea:
dynamic linking is *not* enough to get the FSF to decide something's a
derived work.  Rather, they require the combination to be essentially
one program.  His text is, "If the program dynamically links plug-ins,
and they make function calls to each other and share data structures,
we believe they form a single program."  In this case, it's not Emacs'
copyright license which matters, but the copyright licenses (almost
all GPL) for other libraries of elisp code.  Data structures and
callbacks happen among those, making the ocaml mode part of a single
program.  It must be distributed under the terms of the GPL.

Sorry to have let the matter lie for so long.

-Brian

-- 
Brian Sniffen                                       bts@alum.mit.edu