Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

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.