Re: Emacs contributions, C and Lisp

[David Kastrup]

Richard Stallman <address@hidden> writes:

>     > Actually yes they were (though not with those words).  Someone
>     > cited my decision against having GCC write a complete syntax
>     > tree.  That output would make it easy to use GCC as a front end
>     > for nonfree back-ends.  That would be tantamount to making
>     > nonfree versions of GCC.
>
>     I disagree.
>
> Disagree if you like, but I think it is true in this case.

Well, I think "complete syntax tree" is probably mostly a red herring
not worth the fight we have been seeing over it.  It is most likely
rather version- and language-specific and likely quite bound into GCC's
internals whenever one wants to be serious about "complete".

It would appear (from a separate reply) that the information written by
-fdump-xref is basically the info that any completion server/daemon
would have to provide access to (if one does not just parse it in Elisp
itself), and that in the context of the Ada backend there has already
been written a tool that reads it and provides the respective
information for Ada, C, and C++.

So it would appear that these eggs have not just been laid but already
hatched and most of the emotions invested into this discussion are moot
anyway.

> * When I say "nonfree versions of GCC", what I mean is the use of
> parts of GCC as part of a nonfree compiler.  There are various ways
> that could be implemented, but the harm is the same.

Well, GCC consists of multiple executables implementing multiple passes.
One could always replace the second executable, but I suppose that this
would be enough of a mess that calling the combination a "mere
aggregation" would, in spite of separate address spaces, be ridiculous
enough that nobody would consider that a valid defense.

I think similar restraint would apply for most operations resulting in
an actual full compiler.

Things are different with plugging GCC into a fully proprietary IDE.  I
don't really see that any interfaces we concoct in order to use GCC as a
more-than-just compiler component of an Emacs-based workflow could be
kept from getting used for integrating GCC for the same purpose into a
proprietary IDE without causing a combined work to be covered by the
"software as a whole rather than mere aggregation" clause.

So I'm not sure that much to really fight over remains once we are
delving into concrete applications we want to implement based on GCC in
an environment such as Emacs.  Either everybody gets it or nobody.

What _is_ satisfying, however, is that once big companies with a patent
portfolio use and distribute GCC for getting more value out of
proprietary offerings from them, we more or less get patent
indemnification for doing the same feature inside of Emacs as an IDE:
that's a nice benefit of GPLv3.

Which makes me suspect that we won't see large-scale misuse of GCC.
None of the big players want to risk effectively foregoing any of their
patents all of which, no matter how ridiculous, are potentially worth
millions or even billions of dollars.

GPLv3 was accompanied by enough of a predictable backlash that it seems
wasteful not to amend our strategies where we consciously paid the price
for changing the battlefield to our advantage.

We lost ground with LLVM, and we gained ground with GPLv3.  We should
take both into account.

-- 
David Kastrup