Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

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
> > > > 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.
> > > >         
> > > 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
> > protocol.
> >     
>
> 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.