|
From: | Jacob Bachmeyer |
Subject: | Re: Emacs contributions, C and Lisp |
Date: | Mon, 19 Jan 2015 16:45:46 -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 |
David Kastrup wrote:
Jacob Bachmeyer <address@hidden> writes:David Kastrup wrote:Jacob Bachmeyer <address@hidden> writesWhat stops nonfree software from doing that is that the mechanism used to get access to internals of GCC is very low-level (using ptrace(2) to directly access GCC's memory would not be out of the question) and transfers GCC internal structures over the link, which are interpreted within the Emacs process. According to the GPL FAQ: "Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking."(<URL:http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins>) I expect that GCC's internal trees qualify as "complex data structures". There is certainly not a nice, readable, text AST dump involved at any point.At any rate, does not sound like an interface one could keep steady across different GCC versions. To make that the case, you need something describing the internals' meaning, akin to how debug information describes memory layout. Once you have that kind of "my raw memory means $x" description, this constitutes an interface. Possibly an awkward interface, but that's not legally significant.That's the point--the interface between the underlying processes is not stable across GCC versions and the "description" of the internals' meaning comes in the form of a C DSO that Emacs can load to get Emacs Lisp bindings to GCC's own API for accessing these structures. The "description" is a program component that must be combined with any program that uses it.So what? You do that with a minimal program you license under the GPL and then dump the AST in a generically useful form. Then you get a sanely usable dump of generally useful information you and other proprietary programs can use conveniently while any program from the GNU project has to go through a binary mess by decree.
This comes back to writing Emacs Lisp code to dump the AST. I argue that no reputable proprietary vendor would choose jumping through those particular flaming hoops over writing their own frontend, especially when jumping through flaming hoops to abuse GCC would make their own license terms reek of hypocrisy, which could look bad in court if they ever needed to sue. Less-than-reputable vendors (likely in foreign countries where enforcing copyright is difficult) would simply violate the GPL outright (probably by copy-paste-edit from GCC) and ignore demands for compliance, just like they violate proprietary licenses. This is probably happening now and we just don't know about it yet due to language barriers.
Reverse engineering one version of the interface would allow non-free software to use that version of GCC, yes, but doing that repeatedly as GCC changes, without it ever becoming a derived work, would quickly become more expensive than simply writing a new parser. Especially since the two halves of the link plugin are only required to talk to each other, and are built together, so they can change easily. The link protocol could even be made polymorphic in some way, so that every pair of binaries built would have a subtly different link protocol.So any version of Emacs will work only with a particular version of GCC? Remind me: whose life were we trying to make harder?
No. GCC would provide the link plugin, and it would be updated with GCC. That is why this proposal requires that Emacs be able to dynamically load C plugins.
[Prev in Thread] | Current Thread | [Next in Thread] |