Re: Emacs contributions, C and Lisp

[David Kastrup]

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

> David Kastrup writes:
>  > "Stephen J. Turnbull" <address@hidden> writes:
>  > > David Kastrup writes:
>
>  > >  > It only weakens the GPL if you start creating situations where
>  > >  > it cannot be taken seriously and/or enforced.
>  > >
>  > > I see.  So the widespread use of GPL in projects that don't collect
>  > > assignments is another excuse to declare a piece of software an enemy
>  > > of the movement.
>  > >
>  > > Seriously, I disagree.
>  > 
>  > Since I cannot even figure out what your strawman is supposed to
>  > refer to, I am not sure what you disagree with.
>
> The argument for the FSF assignment policy is that it makes the
> license much easier to enforce.

No, that it makes the license enforceable at all.  Only the copyright
holder can enforce the license for a piece of code.

> Ie, it is the position of the FSF that failing to collect assignments
> creates "situations where [the GPL] cannot be taken seriously and/or
> enforced."

Wrong.  The GPL can _always_ be enforced by the copyright holder.
Collecting the assignments makes sure that the FSF has the full ability
to enforce any violation of the whole code base even when a non-trivial
part of the code's history can be traceable to someone affiliated with
the defendant.

The problem is not that the GPL would or would not be taken seriously,
but rather the ability of the FSF to act as copyright holder.  Since the
FSF is not directly responsible for the majority of the code it has
copyrights on, acting as a warden without assignments would be
difficult.

> If the GPL can't be enforced,

The GPL can be enforced.  The problem would rather be that the choice
whether to enforce it or not would not lie with the FSF.  If you take a
look at the enforcement situation with the Linux kernel, a large ratio
of enforcement cases is done by Harald Welte over the Netfilter code.
Throw out the network filtering (and isn't it currently being replaced
anyway?), and you have a good chance to use the Linux kernel in
proprietary settings without anybody bothering to sue.

That's underwhelming.

> the software can be proprietized -- and so such projects, like LLVM,
> are "failing to defend software freedom".  So Emacs shouldn't provide
> modes to support their unique features according to RMS's logic AIUI.

> But I don't see how it can weaken the GPL.

It doesn't weaken the GPL.  It weakens GCC, and with it, the GNU
project.  Part of the strength of the GNU project lies with GCC setting
language and performance standards, and it's bad if the most thorough
modes we make available with Emacs are not able to support the GCC
dialects.

The Linux ecosystem (for a lack of a better work) is tightly connected
to GNU, not just because of the general GNU flavor of the user space
(including glibc and the core utilities) but also because the kernel is
compiled using GCC, both for feature and performance reasons.  And I
think that it may by now be possible to compile the Linux kernel with
Clang (which got implementions of all of the extensions including
assembler templates that the kernel used).  So in this case GCC and the
GNU project were in the situation of creating a de facto standard.  Once
Emacs supports what Clang provides rather than what GCC provides, not
even Emacs will support any new features of GCC.

There is a rather tenuous hold based on licenses, technical
dependencies, public perception (including "coolness") and so on over
where semi-open systems like "Android" go, choose to go, and are able to
go.  GCC plays a central role in where people place their focus, their
loyalties, and their goals.  It's one of the actually active ties to the
GNU project that the Linux kernel has.

So we want to have GCC stay technically competitive in order to retain a
non-licensing based connection into those kind of projects and, not
least of all, the Linux kernel.  On the other hand, staying technically
competitive is not self-serving but it serves to have a wider audience
for our non-technical goals.  Giving up the latter in order to have a
stronger stand for the former is sort of pointless.  Sort of what one
calls a "dying throw" or "parting shot".

When put to the choice, we'd rather give up on Android than GNU.  And us
having to take that choice at some point of time is what Clang/LLVM are
working towards.

Once Clang/LLVM become the compiler for Android, it is a matter of time
and hipness before it becomes the default compiler for the Linux kernel.

Once the kernel is bootstrapped using Clang/LLVM, it is a matter of time
before the userland of big distributions is compiled using Clang/LLVM as
well, with GCC becoming optional.

At some point of time, it will become harder to compile the Linux kernel
with GCC out of the box, and bootstrapping a full GNU system will mean
that we need to revert to the HURD, mostly relying on using Linux
drivers.  At least until someone sues us for combining GPLv2 drivers
with a GPLv3+ kernel.

All of this has nothing to do with "the GPL being weakened".  It's the
weakening of GCC as a vital part of the GNU-derived software universe
that's the issue.

And if you are saying "that's too pessimistic.  All of this _could_
happen, but that's by no means sure.": the whole point of being behind
GCC is to do what is in our power to push against this happening.  Our
power may be small compared to those of the universe, but that has not
kept us from making a difference by applying it aimedly and timely
enough.

"We can still patch up our roof if and when a storm comes" does not
work.  And "oh, it's on the horizon, but maybe it'll pass.  Let's see if
it does, then we don't need to patch the roof." is, well...

-- 
David Kastrup