Re: Emacs contributions, C and Lisp

[David Kastrup <dak@gnu.org>]

David Engster <deng@randomsample.de> writes:

> Richard Stallman <rms@gnu.org> writes:
>>     Anyway, Stefan gave is OK on libclang usage, 
>>
>> That statement seems to be a misunderstanding.
>
> I don't think so. You and Stefan simply have differing opinions.

The misunderstanding is that outsiders are free to heed just those of
the "differing opinions" they like.  Emacs is copyrighted by the FSF of
which Richard is president.

It's unfortunate that what amounts to an internal disagreement was
carried to this list.  But there is no question about the consequences
while there is no agreement on record.

>> My decision, as head of the GNU Project, is that we will not install
>> anything in Emacs or ELPA that uses clang or LLVM.
>>
>> You can use CEDET, you can use GCC, you can use both, or you can use
>> something else.  But not clang or LLVM.
>>
>> This decision is necessary for achieving more the goal of the GNU
>> Project, which is to give computer users' freedom in their computing
>> in general -- not just in their text editing.
>
> This decision is a mistake. Please reconsider.

That opinion is redundant.  We have already established that this is not
a voting process or shouting match, so do everyone a favor, read up in
the discussion, and contribute something to it once you have figured out
something that has not already been said and that actually applies to a
policy decision.

> If I understand you correctly, you are saying we should not support
> any feature in clang/LLVM unless we can do the same with gcc, because
> although clang/LLVM is free software, it is non-copyleft. At least
> that's what I gathered from your other posts in this thread.
>
> But by the same reasoning you are applying to clang/LLVM, Emacs' must
> not support any feature from Subversion (which is Apache-licensed)
> unless the same feature is present in git, hg, or bzr, or we must
> implement it there first. Likewise, we must not support any feature in
> CMake (which is a BSD-licensed build tool), unless the same feature is
> present in GNU Make, or we must first implement it there as well.

See, you are trying to apply logic here, something like reductio ad
absurdum.  That's fine for, say, speculating about the legal
consequences of license term when viewed by a court trying to follow the
letter of some written law.

But this does not apply to a policy decision.  The whole point of making
an actual decision is that it happens with _deliberation_, not by
applying a fixed set of rules.

If you want to have Richard change a policy decision (which, by the way,
is a rather ambitious undertaking even outside of a mailing list
discussion), you need to convince him that his evaluation of the
perceived benefits and downsides of a decision is skewed to a degree
where the cost of changing the decision is less than that of staying
with it.

> Is that correct? Because if so, you are drawing the line now between
> copyleft and non-copyleft, whereas it used to be between free and
> non-free.

In this case, the line is between using Emacs' leverage for preserving
GCC's importance over betting the horse on a product with an ultimate
fate out of the GNU project's control, and out of its original authors'
and current community's control.

In a similar vein, it was a political decision to move Emacs from CVS to
Bzr as its dedicated version control system, even though there was a set
of other free contenders to choose from.

For GNU projects in general, the GNU maintainer guidelines provide
guidance about how to make decisions and usually do a pretty good job.
In the case of Emacs and GCC (both are copyright-assigned to the FSF
because of their relative importance to the GNU project), Richard can
and does exercise more direct control over the decisions.

So if you want to convince him otherwise (and this discussion has gone
on for too long to have a good chance of finding him attentive still),
you have to convince him of consequences worse than those he has been
able to fathom.  And Richard is not renowned for his optimism.

-- 
David Kastrup