[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs contributions, C and Lisp
From: |
David Kastrup |
Subject: |
Re: Emacs contributions, C and Lisp |
Date: |
Fri, 28 Feb 2014 10:31:59 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
"Stephen J. Turnbull" <address@hidden> 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
- Re: Emacs contributions, C and Lisp, (continued)
- Re: Emacs contributions, C and Lisp, Glenn Morris, 2014/02/19
- Re: Emacs contributions, C and Lisp (was: Re: /srv/bzr/emacs/trunk r101338: ...), Jorgen Schaefer, 2014/02/19
- Re: Emacs contributions, C and Lisp (was: Re: /srv/bzr/emacs/trunk r101338: ...), Eli Zaretskii, 2014/02/19
- Re: Emacs contributions, C and Lisp, Andreas Röhler, 2014/02/24
- Re: Emacs contributions, C and Lisp, Richard Stallman, 2014/02/25
- Re: Emacs contributions, C and Lisp, Stephen J. Turnbull, 2014/02/26
- Re: Emacs contributions, C and Lisp, Richard Stallman, 2014/02/27
- Re: Emacs contributions, C and Lisp, Stephen J. Turnbull, 2014/02/27
- Re: Emacs contributions, C and Lisp,
David Kastrup <=
- Re: Emacs contributions, C and Lisp, Richard Stallman, 2014/02/28
- Re: Emacs contributions, C and Lisp, Stefan Monnier, 2014/02/17
- Re: Emacs contributions, C and Lisp, Jorgen Schaefer, 2014/02/19
- Re: Emacs contributions, C and Lisp, Phillip Lord, 2014/02/18
- Re: Emacs contributions, C and Lisp, Stefan Monnier, 2014/02/16
- Re: Emacs contributions, C and Lisp, Richard Stallman, 2014/02/17
- Re: Emacs contributions, C and Lisp, Stefan Monnier, 2014/02/17
- Re: Emacs contributions, C and Lisp, Richard Stallman, 2014/02/18
- Re: Emacs contributions, C and Lisp, Dmitry Gutov, 2014/02/18
- Re: Emacs contributions, C and Lisp, Richard Stallman, 2014/02/20