Re: Dynamic loading progress

[David Kastrup]

"Stephen J. Turnbull" <address@hidden> writes:

> Daniel Colascione writes:
>  > On 09/14/2015 07:56 PM, Stephen J. Turnbull wrote:
>
>  > The rest of the discussion aside: Python's current license is
>  > GPLv3-compatible, isn't it? gnu.org and Python's documentation both
>  > claim it is.
>
> AFAIK IANAL TINLA.  That's not the issue I have in mind.
>
> Pragmatically speaking, even if it's not possible to legally prohibit
> you from distributing such a module, I think Richard would veto
> incorporation of such a module in Emacs, because it would make it
> possible to silently link Emacs to proprietary code via a Python
> plugin.

Well, regarding the "proprietary plugin" issue it would seem most
expedient to have the plugins run in the Emacs GC and exception model
and, where third-party independently developed libraries are to be
integrated, to have to compile/byte-compile/assemble some
library-specific wrapper encapsulating/mapping the exceptions/callbacks
to the Emacs model.

I have no idea regarding the technical feasibility of various different
approaches.  But regarding the "circumvent GPLv3" angle, having a
default model of completely separate exception/memory handling and FFI
that allows a drop-in direct binary use of libraries not specifically
developed for use with Emacs, while certainly offering the maximum of
convenience in one regard, forms a reasonably clearly defined license
barrier for "application as a whole" forming a clear stop for the reach
of the GPLv3.

So having our binary interfaces and calling conventions and
memory/exception handling default to "like Emacs does" is not just
Lisp-friendly but is also keeping our license enforcement options more
conservative.  While my personal opinion is that licensing
considerations should not justify complications amounting to
uselessness, I see nothing wrong with letting them serve as tie-breaker.

-- 
David Kastrup