Re: New maintainer

[Stephen J. Turnbull]

David Kastrup writes:
 > "Stephen J. Turnbull" <address@hidden> writes:

 > > LLVM?  "This, too, will pass."
 > 
 > To put more precision to it: usually the point of time where the
 > strategy changes is when it has become pointless.

I don't think that's true.  First of all, all of the examples I
mentioned were considered pointless when first implemented, except to
satisfy Richard's extreme risk aversion.  Nobody else could see any
danger to compare to the gain.  Second, history says otherwise.

- TRAMP: added when free SSHv2 became available.  (Today, lsh is a
  logical operator, not a secure shell.)

- Bazaar: abandoned when it became clear that not only was it GNU in
  name only, it was a project in name only, and annoying (admittedly,
  not crippling) bugs continued to surface and not be fixed.
  Unfamiliarity with it and distaste for its opinionated approach to
  VC were genuine barriers to new contributors (not terribly high, but
  more real than any danger cited in support of these policies).

- DSOs: permitted when the leagle eagles OK'ed the strategy
  (ironically, originated by the Linux kernel IIRC) of requiring a
  call to a "I am licensed under GPL" API before enabling a module for
  GCC, and Richard judged that the same arguments applied to Emacs.

 > Since LLVM already outputs annotated syntax trees, blocking GCC
 > from that kind of interoperation is not going to achieve a useful
 > purpose for the GNU project at the current point of time.

I agree, as I'm sure you already guessed, but here Richard isn't
concerned with useful purposes, he worries that part of GCC itself can
be suborned by a proprietary system.  Currently RTL and the like are
*internal* formats that can be saved to disk, but they are not "data"
that is output to be consumed by *arbitrary* other Works (in the
copyright sense), and therefore exempt from the GPL, which (as a bare
license) can make no restriction on how you use the data output from a
program.  They're internal data structures, subject to copyright even
though produced by a program, that happen to reside on disk rather
than in memory.  IIUC, this principle was tested in the NeXT (Apple?) 
Objective C case and found dependable (enough).

So GCC is is directly constrained, but this has a knock-on effect on
Emacs because support for this feature provided by LLVM would give
LLVM-based development a competitive advantage over GCC-based
development, so support is (for now) prohibited.

 > So I don't expect that restriction to stick around for all that
 > much longer in the current form: after all, we don't have anything
 > to gain from people putting LLVM into their applications rather
 > than GCC even if we had preferred such applications to fall under
 > the GPL because of tight integration with GCC.

That was true when Richard announced that he was putting this idea on
hold while he studied the technical and legal aspects of outputting
CAST[1] so that Emacs can use it but even GCC's own backend can't
consume it.  I think you misunderstand the strength of his
determination not to yield a nanometer to proprietary software.

I believe that, from John's point of view, the risk is real that
Richard will indeed insist on CAST, which will hamper attempts to
extend use of compiler-generated ASTs from completion (or whatever the
initial application is) to refactoring and so on, miring them in
further discussions of the kind that happened earlier for every
extension.

I do, however, want to emphasize that this kind of prior restraint on
Emacs development is *extremely* rare.

Footnotes: 
[1]  Crippled Annotated Syntax Trees.