[Top][All Lists]

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

Re: Emacs contributions, C and Lisp

From: David Kastrup
Subject: Re: Emacs contributions, C and Lisp
Date: Thu, 15 Jan 2015 23:29:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Jacob Bachmeyer <address@hidden> writes:

> David Kastrup wrote:
>> Any way we find for combining Emacs with GCC will be usable
>> as a way for combining GCC with proprietary applications without the
>> proprietary applications falling under the GPL.
> I do not think that that is necessarily so.  For example, adapting GCC
> to be usable as a library would allow Emacs (and other Free software)
> to use GCC in a way that would remain barred to proprietary
> applications.  I am less sure than I initially was about the "two
> plugins" solution I proposed earlier, but I will clarify it here.
> The "two plugins" interim solution:
> Implement a pair of plugins, one uses the existing GCC plugin
> interface, the other uses a to-be-developed Emacs extension interface.
> The to-be-developed Emacs extension interface essentially allows subrs
> to be added to a running Emacs.  It is not useful aside from extending
> an Emacs Lisp interpreter.  The pair of plugins is an inseparable
> whole.  The need for two plugins is simply an artifact of GCC's
> current architecture, which precludes directly loading GCC into the
> Emacs process.

If two plugins to Emacs and GCC are made to talk to each other, you can
replace the Emacs plugin with something else doing the same from GCC's
point of view.

GCC and Emacs are independent applications with an independent history
and a necessity to continue working independently.  If you make those
independent applications communicate in any manner, any other
application using this communication is going to remain similarly

Even if we managed to successfully mess with this basic equivalence, the
consequences of establishing such precedence would be so much worse for
our cause than accepting this limit of copyright's reach could ever be
that we'd be wise to not even try.

David Kastrup

reply via email to

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