emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs contributions, C and Lisp


From: Jacob Bachmeyer
Subject: Re: Emacs contributions, C and Lisp
Date: Fri, 16 Jan 2015 19:26:32 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0

Richard Stallman wrote:
[[[ 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 illuminates the central question at hand: if an Emacs plugin is > GPL, and provides access to internals of GCC, which is also GPL, can > nonfree software use that Emacs plugin?

"Use" is too broad a word; such a broad question has no answer.
Nonfree software can't be _combined_ with GPL'd code, which includes
that plug-in (what the plug-in _does_ is beside the point).  If a
program A "uses" a program B, does this mean the two are combined?
That depends on details (and there may be a gray area; also, we can't
be sure where courts will say the border is).

Plugins of this type are DSOs, so "use" means "dynamically link at runtime" and "call functions the plugin implements". I think that the GPL FAQ answers this in <URL:http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF>. Since using a GPL plugin in a non-free program requires additional permission on the part of the plugin, which GCC would _not_ provide, non-free software could not dynamically link the plugin.

What I am pretty sure of is that if the plug-in generates the AST as
text, a GPL-covered program could write it into a file, and some
separate proprietary program could read the file, and this would not
be considered combining the two programs.  It would be lawful, and
could be quite harmful.

This is why I am proposing a two-faced (one face for GCC, one for Emacs) link plugin that gets the AST from GCC via some (currently unspecified, but using ptrace(2) is not out of the question) host-platform-specific binary means and presents it to Emacs as some kind of in-memory data structure. Although, after it was pointed out, I now see the possible problem that someone could write Emacs Lisp code to dump that structure as text.

But all this is sounding more and more like we could not stop someone who really wanted the AST in any case. If a developer of non-free software could use any facility we develop to import an AST from GCC into Emacs, what stops that same developer from simply writing their own AST export plugin for GCC and making just the AST dumper GPL?

This is why there is danger in generating the AST as text.

This is why I do not propose exporting a text AST.




reply via email to

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