[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs contributions, C and Lisp

From: Jacob Bachmeyer
Subject: Re: Emacs contributions, C and Lisp
Date: Fri, 16 Jan 2015 19:26:24 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

David Kastrup wrote:
Jacob Bachmeyer <address@hidden> writes:
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The situation with Emacs will be the same as it is with GCC now:
plug-ins have to be GPL.
This illuminates the central question at hand:  if an Emacs plugin is
GPL, and provides access to internals of GCC, which is also GPL, can
nonfree software use that Emacs plugin?

That's not the central question at hand.  The central question is: if an
Emacs plugin can provide access to internals of GCC, what keeps nonfree
software from using the same mechanism as the Emacs plugin to get access
to internals of GCC?

What stops nonfree software from doing that is that the mechanism used to get access to internals of GCC is very low-level (using ptrace(2) to directly access GCC's memory would not be out of the question) and transfers GCC internal structures over the link, which are interpreted within the Emacs process. According to the GPL FAQ: "Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking."(<URL:http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins>) I expect that GCC's internal trees qualify as "complex data structures". There is certainly not a nice, readable, text AST dump involved at any point.

If you combine Emacs and GCC, there will be one point where Emacs ends
and GCC begins.  And that is the point where you can swap out either for
a nonfree application without getting copyright involved, since GCC and
Emacs are clearly independent applications.

The point where Emacs ends and GCC begins in my interim proposal is the function calls into the Emacs plugin I propose that GCC would provide. Emacs would be, in effect, dynamically loading GCC as a library. That that library is implemented using RPC to another process is an implementation detail.

The price for interoperation is interoperation.  And since it is rather
more than less important for free as opposed to proprietary software
that independent teams can create cooperating applications, I don't see
that it makes sense for us not to pay that price.  And the latest point
to which we can delay this is when a concrete application is imminent.

We can't guarantee that such an application will be successful if we
allow it.  But it will definitely fail if we don't.

You are right, which is why I am seeking a workable solution that all can be happy with.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]