[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: Mon, 19 Jan 2015 16:45:46 -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:
David Kastrup wrote:
Jacob Bachmeyer <address@hidden> writes
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
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.
At any rate, does not sound like an interface one could keep steady
across different GCC versions.  To make that the case, you need
something describing the internals' meaning, akin to how debug
information describes memory layout.  Once you have that kind of "my raw
memory means $x" description, this constitutes an interface.  Possibly
an awkward interface, but that's not legally significant.
That's the point--the interface between the underlying processes is
not stable across GCC versions and the "description" of the internals'
meaning comes in the form of a C DSO that Emacs can load to get Emacs
Lisp bindings to GCC's own API for accessing these structures.  The
"description" is a program component that must be combined with any
program that uses it.

So what?  You do that with a minimal program you license under the GPL
and then dump the AST in a generically useful form.  Then you get a
sanely usable dump of generally useful information you and other
proprietary programs can use conveniently while any program from the GNU
project has to go through a binary mess by decree.

This comes back to writing Emacs Lisp code to dump the AST. I argue that no reputable proprietary vendor would choose jumping through those particular flaming hoops over writing their own frontend, especially when jumping through flaming hoops to abuse GCC would make their own license terms reek of hypocrisy, which could look bad in court if they ever needed to sue. Less-than-reputable vendors (likely in foreign countries where enforcing copyright is difficult) would simply violate the GPL outright (probably by copy-paste-edit from GCC) and ignore demands for compliance, just like they violate proprietary licenses. This is probably happening now and we just don't know about it yet due to language barriers.

Reverse engineering one version of the interface would allow non-free
software to use that version of GCC, yes, but doing that repeatedly as
GCC changes, without it ever becoming a derived work, would quickly
become more expensive than simply writing a new parser.  Especially
since the two halves of the link plugin are only required to talk to
each other, and are built together, so they can change easily.  The
link protocol could even be made polymorphic in some way, so that
every pair of binaries built would have a subtly different link

So any version of Emacs will work only with a particular version of GCC?
Remind me: whose life were we trying to make harder?

No. GCC would provide the link plugin, and it would be updated with GCC. That is why this proposal requires that Emacs be able to dynamically load C plugins.

reply via email to

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