Re: Emacs contributions, C and Lisp

[David Kastrup <dak@gnu.org>]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Richard Stallman writes:
>  > [[[ 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. ]]]
>  > 
>  >      > This is because LLVM does not try to defend users' freedom at all.
>  > 
>  >     Of course it does.  It gives them the choice of using excellent free
>  >     software.
>  > 
>  > You have misinterpreted my statement.  LLVM is free software, but it
>  > does not defend users' freedom because only copyleft does that.
>
> That's a nice soundbite, but I'll resist the temptation to disagree
> verbosely.
>
> However, this situation is easily enough changed.  The useful programs
> from the LLVM project can be forked (AFAIK their license is not
> perversely incompatible with the GPL) as GNU projects under the "GPL
> v3 or later" permission schema.
>
> Would you object to that?

I'd object, for basically practical reasons.  You can fork code, but you
cannot fork a community.  A fork of the LLVM codebase under the GPLv3
makes only sense if you actually add nontrivial nonseparable components
under the GPLv3 or the code base can be just swapped out.  If you have
nontrivial nonseparable components, but an actively developed important
upstream, you need to constantly reintegrate the upstream work in order
to keep the edge.

Now if the upstream is a weak license like X11, at some point of time
the developers might say "that fork is annoying, let's relicense what we
have now under BSD with advertising clause and cut off those others".
They'll likely retain the majority of their development community but
hang out the fork under GPLv3 to dry.  That will always be a risk you
work with, and the source of that risk is that the principal work is
made available under a non-copyleft license.

So basically, with an already determined development community, this
sort of licensed fork is a non-starter because of not carrying a
community with it.  Skipping over the problem of _starting_ a new
community, we can take a look at the psychological effects of this kind
of setup by looking at the OpenOffice/LibreOffice fork.  Here we can
glance over the non-starter aspect since the fork happened on an
existing code base, and the permissively licensed "upstream" (with
regard to licensing and thus automatically permitted code flow) got its
licensing change considerable time _after_ the fork.

The relations between both sides of the fork are strained, and a
considerable part of that strain is the asymmetric licensing situation.
This strain clearly keeps the communities from intermingling, meaning
that many constributors identify with one side of the fork.

So an LLVM fork would be a move predictably causing lots of bad blood.
It's not like we haven't paid that sort of price quite a few times.  But
it would also predictably be a move that would lead nowhere.  And that's
self-defeating.

-- 
David Kastrup