[Top][All Lists]

[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: Sun, 18 Jan 2015 16:34:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Richard Stallman <address@hidden> 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. ]]]
>   >   But I don't think we can terminally avoid dealing
>   > with the fact that we cannot achieve interoperation between separate
>   > free software applications without enabling interoperation with separate
>   > nonfree software that does not trigger copyright.
> That is not valid as a general principle.
> Here's one very clear example to show that.
> It is perfectly legal to staticly link GCC and GNU Emacs

"between separate free software applications".

> and distribute the resulting binary, since they are both available
> under GPLv3.

I expect symbol conflicts.

At any rate, this is a strawman argument.  I did not claim that we
cannot _merge_ separate free software applications without the danger of
this enabling _merging_ them with non-free software.

The topic was _interoperation_ between _separate_ free software

Sure, _merging_ them into a single executable does not cause a conundrum
for us.  It is merely utterly useless.

Emacs excels at interoperation with independent tools.  Requiring a
_merge_ with anything you'd seriously like to use would render it so
much less useful that it's not even theoretically interesting.

> However, linking with nonfree software in that same way would be a
> violation.
> The issues about plug-ins are more complicated and more specipic than
> that putative principle would suggest.

Because I was not talking about plugins.  I was talking about making GCC
and Emacs interoperate.  That turns neither into a plugin of the other.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]