Re: Emacs contributions, C and Lisp

Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

I've been reading this in the list archives and as a long-time GNU/Linux 
user, feel the need to chime in.

Perhaps there is a better option?  I seem to remember efforts to adapt 
Guile to run Emacs Lisp and then to port Emacs to run using Guile 
instead of its own runtime.  I'm not certain of the difficulty, but 
perhaps GCC could be, over time, moved towards an option to build as 
Guile extensions?  I haven't looked far enough into this to know if it 
is feasible, or how much work would be needed, or if I'm completely 
mistaken and it isn't feasible at all.

Obviously, it should still be possible to build "stand-alone GCC", but 
having the compiler be available from Guile could easily solve the issue 
at hand here, especially if the extension presents a Lisp-like API for 
the GCC internal structures.  This would also address the concerns about 
the GCC front-end being abused to feed nonfree backends, since the tree 
would only be present in memory behind a GPL interface.

But this is years away at best and doesn't solve the immediate problem, 
which is that Emacs needs a parse tree "now".  There are three options 
for how to get that:

(1)  Write a C parser in Emacs Lisp.
(2)  Get the AST from GCC.
(3)  Get the AST from Clang.

Option (1) leads to an Emacs C Compiler and fully self-hosting Emacs, 
which is both interesting and an insane duplication of effort.  Option 
(2) has the advantage that it would ensure full support for GNU C, but 
the problem of actually getting the parse tree from GCC without 
weakening GCC's copyleft.  Option (3) has the advantage that no one will 
object to dumping an AST from Clang, but Clang isn't a GNU project and 
has incomplete support for GNU C.

A more useful question is "How can GCC most efficiently provide an AST 
to Emacs?"  Part of the answer is that Emacs already has the complete 
text of every file involved.  Emacs doesn't care what the name of a 
variable is--that's already in the buffer.  Emacs cares what part of the 
buffer corresponds to a variable name.  Dumping an AST that contains 
only annotations to text, referring to positions in the source files 
instead of actually including text in the AST, looks to me like a good 
middle ground.  Such an AST (which I will call a "refAST" because it 
contains only references to program source text) would be a significant 
pain to use as compiler input, since the symbol names are missing, while 
also being exactly the information that an editor needs.  We can make it 
harder to use the refAST to abuse the GCC frontend by the same expedient 
that makes the refAST easier for Emacs to read.  Emacs already has the 
source text, why force it to read duplicates from the AST dump?

Further, the refAST needs to resemble the source text as closely as 
possible.  Most of GCC's value is from the optimizer and code 
generators.  Parsing is relatively simple compared to the rest of GCC.  
If the refAST is dumped after optimization, it will be next to useless 
for editing the source.  So the refAST must be dumped prior to any 
optimization.  My knowledge of GCC internals is lacking, but a glance at 
gccint suggests that Emacs needs a dump of GENERIC, which, incidentally, 
can "also be used in the creation of source browsers, intelligent 
editors, ..." 
(<URL:http://gcc.gnu.org/onlinedocs/gccint/C-and-C_002b_002b-Trees.html>).  
Further reading reveals that for better or for worse, this ship has 
already sailed and GCC has had an option to dump GIMPLE representation, 
which is probably far more useful for abusing the frontend than an AST 
dump, for some time now.

In short, the earlier in the GCC pipeline the parse tree is dumped, the 
more useful the dump is for editing source and the less useful the dump 
is for feeding a nonfree compiler backend.  Dumping references to source 
text, but not the text itself, simultaneously makes reading the dump 
into Emacs easier and feeding the dump into another backend harder.

My proposal:

--Immediate:
    -- GCC option for dumping refAST for editor use
       -- parse tree is dumped as early as is feasible, definitely prior 
to optimization
--Near term:
    -- Emacs Lisp ported to Guile
--Longer term:
    -- GCC buildable as Guile extensions
       -- provides full access to GCC internal structures, but only to 
Free software
    -- Emacs ported to Guile


PS:  There have been questions raised as to the use of a full syntax 
tree.  One feature that I would find useful that would be trivially 
enabled by having the syntax tree would be to make M-C-t next to a 
binary operator swap its operand expressions.  This is a contrived 
example, but shows a simple case:

      a * b +. c * d
C:    a * c +. b * d
Lisp: c * d +. a * b

The dot represents point.  The result labeled "C" is what happens 
currently.  The result labeled "Lisp" is what would happen if Emacs 
actually understood C syntax on the same level as s-expressions.  A 
refAST would enable this as a side-effect of its other uses.

Re: Emacs contributions, C and Lisp

[David Engster]

Jacob Bachmeyer writes:
> Obviously, it should still be possible to build "stand-alone GCC", but
> having the compiler be available from Guile could easily solve the
> issue at hand here, especially if the extension presents a Lisp-like
> API for the GCC internal structures.  This would also address the
> concerns about the GCC front-end being abused to feed nonfree
> backends, since the tree would only be present in memory behind a GPL
> interface.
>
> But this is years away at best

As always, people are needed to actually code that.

> and doesn't solve the immediate problem, which is that Emacs needs a
> parse tree "now".  There are three options for how to get that:
>
> (1)  Write a C parser in Emacs Lisp.

Already done. Works reasonably well for C, is lacking for C++. Improving
it would still be my first option, but no one is interested in helping.

> Dumping an AST that contains only annotations to text, referring to
> positions in the source files instead of actually including text in
> the AST, looks to me like a good middle ground.  Such an AST (which I
> will call a "refAST" because it contains only references to program
> source text) would be a significant pain to use as compiler input,

There's no significant pain in looking up the names from the source
files. Also, I see absolutely no point in somehow obfuscating the AST,
since for feeding things like LLVM, there are much simpler options, like
you have noticed yourself (see below).

> Further, the refAST needs to resemble the source text as closely as
> possible.  Most of GCC's value is from the optimizer and code
> generators.  Parsing is relatively simple compared to the rest of GCC.

I don't think the guys maintaining the C++ frontend would agree...

> If the refAST is dumped after optimization, it will be next to useless
> for editing the source.  So the refAST must be dumped prior to any
> optimization.  My knowledge of GCC internals is lacking, but a glance
> at gccint suggests that Emacs needs a dump of GENERIC, which,
> incidentally, can "also be used in the creation of source browsers,
> intelligent editors, ..."

Yes.

> Further reading reveals that for better or for worse, this ship has
> already sailed and GCC has had an option to dump GIMPLE
> representation, which is probably far more useful for abusing the
> frontend than an AST dump, for some time now.

That's what I said from the beginning, and it's my main point why all
this discussion about somehow obfuscating the AST dump is so completely
absurd. My guess is that DragonEgg does exactly what you
describe. Richard chose to not respond to this fact.

-David

Re: Emacs contributions, C and Lisp

[David Kastrup]

Jacob Bachmeyer <jcb62281@gmail.com> writes:

> I've been reading this in the list archives and as a long-time
> GNU/Linux user, feel the need to chime in.
>
> Perhaps there is a better option?  I seem to remember efforts to adapt
> Guile to run Emacs Lisp and then to port Emacs to run using Guile
> instead of its own runtime.  I'm not certain of the difficulty, but
> perhaps GCC could be, over time, moved towards an option to build as
> Guile extensions?  I haven't looked far enough into this to know if it
> is feasible, or how much work would be needed, or if I'm completely
> mistaken and it isn't feasible at all.

That would be a solution that would favor integration of Emacs and GCC
and make it convenient.  But Lisp/Scheme/Guile is easy to parse, and
easy to interface with other tools.  That's the reason for Emacs'
popularity, and the reason Guile is pitched as GNU's extension language.

Anything that is feasible for combining Emacs with GCC will be feasible
for combining proprietary tools with GCC.

I don't see a way to hack ourselves around that.  Other GNU tools like
Make and Bison have options to dump their complete parse tree and/or
underlying data sets, and there are some applications making use of that
(sometimes just for debugging purposes: try tracing down shift/reduce
and reduce/reduce conflicts without an extensive dump).  Of course, they
are not as "mainstream" as context-sensitive programming editors.

> A more useful question is "How can GCC most efficiently provide an AST
> to Emacs?"  Part of the answer is that Emacs already has the complete
> text of every file involved.  Emacs doesn't care what the name of a
> variable is--that's already in the buffer.  Emacs cares what part of
> the buffer corresponds to a variable name.  Dumping an AST that
> contains only annotations to text, referring to positions in the
> source files instead of actually including text in the AST, looks to
> me like a good middle ground.  Such an AST (which I will call a
> "refAST" because it contains only references to program source text)
> would be a significant pain to use as compiler input, since the symbol
> names are missing, while also being exactly the information that an
> editor needs.  We can make it harder to use the refAST to abuse the
> GCC frontend by the same expedient that makes the refAST easier for
> Emacs to read.  Emacs already has the source text, why force it to
> read duplicates from the AST dump?

That's basically the "make things as convenient for Emacs" road.  But
anything Emacs can do, comparatively simply external programs can do.
We can (and should) favor Emacs, but we won't be locking out non-free
uses of the same data set in that manner.

Technically, what's good for Emacs is good for other tools.  And I don't
see a licensing hack working within copyright law that would give us the
power to discriminate since copyright does not extend to program
interaction and we are working with licensing rather than contracts,
namely giving additional permissions over what copyright allows.

-- 
David Kastrup

Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

David Kastrup wrote:
> Jacob Bachmeyer <jcb62281@gmail.com> writes:
>
>   
>> Perhaps there is a better option?  I seem to remember efforts to adapt
>> Guile to run Emacs Lisp and then to port Emacs to run using Guile
>> instead of its own runtime.  I'm not certain of the difficulty, but
>> perhaps GCC could be, over time, moved towards an option to build as
>> Guile extensions?  I haven't looked far enough into this to know if it
>> is feasible, or how much work would be needed, or if I'm completely
>> mistaken and it isn't feasible at all.
>>     
>
> That would be a solution that would favor integration of Emacs and GCC
> and make it convenient.  But Lisp/Scheme/Guile is easy to parse, and
> easy to interface with other tools.  That's the reason for Emacs'
> popularity, and the reason Guile is pitched as GNU's extension language.
>
> Anything that is feasible for combining Emacs with GCC will be feasible
> for combining proprietary tools with GCC.
>
>   
Not quite in this case.  The GPL would still apply to GCC built as Guile 
extensions and therefore would still apply to any code that calls into 
GCC through Guile, just like Guile's current readline module.  Guile 
puts everything into the same process and isn't "arm's length" at all.  
Emacs is GPL, so it can call into GCC through Guile with no problem.  A 
proprietary tool doing the same gets dropped right into a copyright 
quagmire.

>> A more useful question is "How can GCC most efficiently provide an AST
>> to Emacs?"  Part of the answer is that Emacs already has the complete
>> text of every file involved.  Emacs doesn't care what the name of a
>> variable is--that's already in the buffer.  Emacs cares what part of
>> the buffer corresponds to a variable name.  Dumping an AST that
>> contains only annotations to text, referring to positions in the
>> source files instead of actually including text in the AST, looks to
>> me like a good middle ground.  Such an AST (which I will call a
>> "refAST" because it contains only references to program source text)
>> would be a significant pain to use as compiler input, since the symbol
>> names are missing, while also being exactly the information that an
>> editor needs.  We can make it harder to use the refAST to abuse the
>> GCC frontend by the same expedient that makes the refAST easier for
>> Emacs to read.  Emacs already has the source text, why force it to
>> read duplicates from the AST dump?
>>     
>
> That's basically the "make things as convenient for Emacs" road.  But
> anything Emacs can do, comparatively simply external programs can do.
> We can (and should) favor Emacs, but we won't be locking out non-free
> uses of the same data set in that manner.
>
>   
Correct, an external program could easily enough convert a refAST back 
into a full AST.  The goal is to make things as convenient for Emacs 
(and other editors, particularly Free ones) as possible, while also 
making a proprietary developer's job harder, particularly reading it 
into another compiler.  While convenience for Emacs is more important 
than pain for others, having only locations in the AST dump provides 
both, except for other editors.

> Technically, what's good for Emacs is good for other tools.  And I don't
> see a licensing hack working within copyright law that would give us the
> power to discriminate since copyright does not extend to program
> interaction and we are working with licensing rather than contracts,
> namely giving additional permissions over what copyright allows.
>
>   
The limits of the GPL's reach, as best as I can see, is "arm's length", 
whatever that precisely is.  In any case, the position I've always seen 
taken is that linking, especially when using a novel API, is within the 
scope of "derived work" and thus can be subject to requirements in the GPL.

Which leads to another idea that I think may have been mentioned:  Does 
Emacs have the ability to load C plugins from shared objects?  That 
would open two new options:  (1) a very efficient binary dump format 
that is a huge pain to read, unless you are using the provided (GPL, of 
course) library that would be very efficient, but would have knowledge 
of GCC internals, and (2) a GCC plugin that holds compilation after 
parsing and exposes the AST through some tightly-coupled IPC mechanism 
to a corresponding Emacs-side plugin.  Both of these options require a 
more-or-less stable API presented to Emacs, but work best with a 
platform-specific ball-of-mud link between Emacs and GCC, both ends of 
which should probably come from GCC.  Passing GCC internal structures 
and references thereto over the link should be encouraged, as long as 
the editor side in the end gets a full AST (or at least an interface to 
one) without too much difficulty.  Because the Emacs plugin would need a 
stable API, it could also be used by other Free editors, but because it 
would be GPL, proprietary software would not be permitted to use it.  
This is basically a simpler, "make something quickly" version of the 
longer term Guile/Emacs/GCC combination, which should remain a goal, 
both to get rid of this ridiculous hack I propose here, and to make GCC 
more available to other programs under the GNU system as well.

Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

David Engster wrote:
> Jacob Bachmeyer writes:
>   
>> Dumping an AST that contains only annotations to text, referring to
>> positions in the source files instead of actually including text in
>> the AST, looks to me like a good middle ground.  Such an AST (which I
>> will call a "refAST" because it contains only references to program
>> source text) would be a significant pain to use as compiler input,
>>     
>
> There's no significant pain in looking up the names from the source
> files. Also, I see absolutely no point in somehow obfuscating the AST,
> since for feeding things like LLVM, there are much simpler options, like
> you have noticed yourself (see below).
>
>   
It's not so much intentional obfuscation, as obfuscation as a 
side-effect of optimization.  Admittedly, a refAST is simple to convert 
back into a full AST, but doing so is an effort that should give a hint 
that "you are not supposed to be doing this".

>> Further, the refAST needs to resemble the source text as closely as
>> possible.  Most of GCC's value is from the optimizer and code
>> generators.  Parsing is relatively simple compared to the rest of GCC.
>>     
>
> I don't think the guys maintaining the C++ frontend would agree...
>
>   
Then C++ is even more complex than I had thought.  I last used it for a 
freshman course in college some years ago.

>> Further reading reveals that for better or for worse, this ship has
>> already sailed and GCC has had an option to dump GIMPLE
>> representation, which is probably far more useful for abusing the
>> frontend than an AST dump, for some time now.
>>     
>
> That's what I said from the beginning, and it's my main point why all
> this discussion about somehow obfuscating the AST dump is so completely
> absurd. My guess is that DragonEgg does exactly what you
> describe. Richard chose to not respond to this fact.
>
>   
Not quite.  DragonEgg is actually a GCC plugin, so, rather than reading 
a GIMPLE dump, it gets the data from memory and splices the LLVM backend 
into the GCC compiler process.  It is GPL.  Any parts of LLVM it uses 
have to be licensed compatibly with GPL terms.  So DragonEgg can't 
(directly) use a nonfree backend with GCC, although it can dump LLVM IR 
which could then be fed into a non-free backend, but distributing such a 
system would have the legal uncertainties of whether you really can obey 
that particular letter while flagrantly violating the associated 
spirit.  From what I understand, Apple was considering something like 
that, but decided that developing Clang from scratch was a better idea.

Re: Emacs contributions, C and Lisp

[Perry E. Metzger]

On Mon, 12 Jan 2015 17:21:21 -0600 Jacob Bachmeyer
<jcb62281@gmail.com> wrote:
> >> Parsing is relatively simple compared to the rest
> >> of GCC. 
> >
> > I don't think the guys maintaining the C++ frontend would agree...
>
> Then C++ is even more complex than I had thought.  I last used it
> for a freshman course in college some years ago.

C++ is an amazing mess. Parsing is grotesquely hard for a modern
language -- C++ isn't even remotely LALR -- and on top of
that, we have things like the template language which is Turing
complete. The language is also more and more complicated with every
passing year -- modern C++ is a huge language compared to the C++ of
20 years ago.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Emacs contributions, C and Lisp

[Eli Zaretskii]

> Date: Mon, 12 Jan 2015 17:20:40 -0600
> From: Jacob Bachmeyer <jcb62281@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> Which leads to another idea that I think may have been mentioned:  Does 
> Emacs have the ability to load C plugins from shared objects?

Why would we need that?  We _are_ the Emacs project, so we could
simply make whatever C code is needed part of Emacs.

Re: Emacs contributions, C and Lisp

[Stefan Monnier]

>> Which leads to another idea that I think may have been mentioned:  Does
>> Emacs have the ability to load C plugins from shared objects?

No, not yet, but there's preliminary work for that, and I hope that
preliminary work can get included for 25.1, tho I haven't heard much
news from it in a while.

> Why would we need that?  We _are_ the Emacs project, so we could
> simply make whatever C code is needed part of Emacs.

Because we want Emacs-25.1 to be able to link to libraries which might
not yet have been written when 25.1 is released.


        Stefan

Re: Emacs contributions, C and Lisp

[David Kastrup]

Jacob Bachmeyer <jcb62281@gmail.com> writes:

> David Kastrup wrote:
>> Jacob Bachmeyer <jcb62281@gmail.com> writes:
>>
>>   
>>> Perhaps there is a better option?  I seem to remember efforts to adapt
>>> Guile to run Emacs Lisp and then to port Emacs to run using Guile
>>> instead of its own runtime.  I'm not certain of the difficulty, but
>>> perhaps GCC could be, over time, moved towards an option to build as
>>> Guile extensions?  I haven't looked far enough into this to know if it
>>> is feasible, or how much work would be needed, or if I'm completely
>>> mistaken and it isn't feasible at all.
>>>     
>>
>> That would be a solution that would favor integration of Emacs and GCC
>> and make it convenient.  But Lisp/Scheme/Guile is easy to parse, and
>> easy to interface with other tools.  That's the reason for Emacs'
>> popularity, and the reason Guile is pitched as GNU's extension language.
>>
>> Anything that is feasible for combining Emacs with GCC will be feasible
>> for combining proprietary tools with GCC.
>>
>>   
> Not quite in this case.  The GPL would still apply to GCC built as
> Guile extensions and therefore would still apply to any code that
> calls into GCC through Guile, just like Guile's current readline
> module.  Guile puts everything into the same process and isn't "arm's
> length" at all.

> Emacs is GPL, so it can call into GCC through Guile with no problem.
> A proprietary tool doing the same gets dropped right into a copyright
> quagmire.

Not if it does just the same as Emacs since that means it uses a
generically useful interface.

> Which leads to another idea that I think may have been mentioned: Does
> Emacs have the ability to load C plugins from shared objects?

No, and the reason is again not technical but political: it would make
Emacs generally useful as a component in compound applications not
reached by the GPL.

At one point of time, we'll probably need to rebalance the needs for
being able to rearchitecture and retool against the reach we would like
the GPL to have.

If we limit all our architecting choices to extensions in reach of the
GPL of the original core, we won't be able to interconnect big
independent GPLed applications, like Emacs and GCC are, because that
would also provide the technical means to interconnect with a big
non-GPLed application while keeping it independent.

So the "plugins/AST for GCC" question and "callable modules for Emacs"
question is pretty much tied down for the same reason: any reasonably
powerful connection mechanism between Emacs and GCC will make it
possible to connect Emacs with proprietary tools, and GCC with
proprietary tools.

I think it would be too expensive for us to _not_ pay this price.
Throwing a spanner into modularity and versatility whenever things get
interesting is going to be too expensive.  I would state "we should be
happy copyright can't reach everywhere", but with regard to software
licensing that is not all that convincing since most "licensing" mostly
relies on contractual conditions far exceeding copyright and
consequently has not much control to lose from increased possibilities
of interaction due to a changing technical landscape.

-- 
David Kastrup

Re: Emacs contributions, C and Lisp

[David Kastrup]

"Perry E. Metzger" <perry@piermont.com> writes:

> On Mon, 12 Jan 2015 17:21:21 -0600 Jacob Bachmeyer
> <jcb62281@gmail.com> wrote:
>> >> Parsing is relatively simple compared to the rest
>> >> of GCC. 
>> >
>> > I don't think the guys maintaining the C++ frontend would agree...
>>
>> Then C++ is even more complex than I had thought.  I last used it
>> for a freshman course in college some years ago.
>
> C++ is an amazing mess. Parsing is grotesquely hard for a modern
> language -- C++ isn't even remotely LALR -- and on top of
> that, we have things like the template language which is Turing
> complete. The language is also more and more complicated with every
> passing year -- modern C++ is a huge language compared to the C++ of
> 20 years ago.

To write software well, it's a valid strategy to hack together some
prototype and tweak it until it does the job, then throw it away and
rewrite from scratch.

"Modern C++" has been developed like that.  Except that it missed out on
all the "throw it away" stages.  It's like a reptile with a genetic
defect that kept it from properly molting, so there is lots of old and
patchy and flaky stuff of the original small frame all over the place
and grotesque mounts of flesh squeezing out from the original fossilized
skin.

"Ada's too big.  Let's just patch up C instead."

I actually like Lua because it is sort of the antithesis of C++.
Instead of the "let's see what else we can cram into the language"
approach, they use more of the "let's see what we can do without"
approach.  Also a bit overdone (for example, statements are _optionally_
separated by semicolon but just whitespace is enough), but it leaves
much less of a bad aftertaste.

-- 
David Kastrup

dynamic modules progress (was: Emacs contributions, C and Lisp)

[Ted Zlatanov]

On Mon, 12 Jan 2015 23:56:26 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>> Which leads to another idea that I think may have been mentioned:  Does
>>> Emacs have the ability to load C plugins from shared objects?

SM> No, not yet, but there's preliminary work for that, and I hope that
SM> preliminary work can get included for 25.1, tho I haven't heard much
SM> news from it in a while.

Aurelien asked for more time to deal with some minor issues, but I'm
sure that if anyone was interested in rebasing the branch
dynamic-modules-rc2 and testing it, it would speed things up.  I just
came back from a vacation and am still catching up.

Ted

Re: Emacs contributions, C and Lisp

[Perry E. Metzger]

On Tue, 13 Jan 2015 05:38:11 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Mon, 12 Jan 2015 17:20:40 -0600
> > From: Jacob Bachmeyer <jcb62281@gmail.com>
> > Cc: emacs-devel@gnu.org
> > 
> > Which leads to another idea that I think may have been
> > mentioned:  Does Emacs have the ability to load C plugins from
> > shared objects?
> 
> Why would we need that?  We _are_ the Emacs project, so we could
> simply make whatever C code is needed part of Emacs.
> 

Well, one reason might be to permit extensions to be written that the
Emacs developers didn't think of/aren't part of the main
distribution/etc. One might also want to allow a minority of
users to have large binary add-ons without forcing *all* users
to pay the cost of loading those add-ons in memory.

Perl, python and some other systems allow for libraries with native
binary components. In some sense, Emacs is a language (elisp) with an
editor attached, so the idea isn't *entirely* mad.

That said, I'm not sure the case for it is a slam dunk, either.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

Eli Zaretskii wrote:
>> Date: Mon, 12 Jan 2015 17:20:40 -0600
>> From: Jacob Bachmeyer <jcb62281@gmail.com>
>> Cc: emacs-devel@gnu.org
>>
>> Which leads to another idea that I think may have been mentioned:  Does 
>> Emacs have the ability to load C plugins from shared objects?
>
> Why would we need that?  We _are_ the Emacs project, so we could
> simply make whatever C code is needed part of Emacs.
>
>   
I described my "two plugins" proposal as a "ridiculous hack" with good 
reason:  the only stable API involved is the API by which Emacs calls 
the plugin on its side of the link to GCC.

The Emacs plugin I proposed is essentially a piece of GCC loaded into 
the Emacs process and would be (as much as practical) independent of the 
version of Emacs used and very much dependent on the version of GCC 
used.  A different Emacs plugin would be needed for each version of GCC 
whenever the relevant internal data structures change.  This would, in 
practice, require that the stable API used be defined by Emacs, and a 
plugin (for Emacs) implementing the API be provided by GCC, for each 
version of GCC.  If this API is well-designed, other language 
implementations could also implement plugins to provide ASTs to Emacs.  
Similarly, other Free editors could use the Emacs plugin to load AST 
data from GCC and other language implementations that provide their own 
plugins.  All of this is a temporary measure and the basis for (part of) 
a future GCC Guile module interface (which would not have the IPC part, 
since GCC/Guile would then be in the Emacs/Guile process).  With similar 
(hopefully minor) modifications, other Free editors could likewise embed 
Guile and gain the benefits of access to GCC's AST since the plugins 
would then be obsolete and discontinued.  Due to GCC's license (the 
GPL), nonfree tools would not be able to use any of this.

The interim Emacs plugin either (1) reads a more-or-less binary dump of 
GCC data structures or (2) accesses GCC data structures via some 
tightly-coupled IPC mechanism (shared memory?) either of which would be 
provided by a matching GCC plugin.  The idea was that this would bring 
any user of the Emacs plugin under the GPL's scope with respect to GCC, 
because it's essentially an API into GCC.  This is, of course, no 
problem for Emacs, which is itself GPL.  Nor would it be a problem for 
any other Free editor, which could use the same plugin as Emacs does.  
It would be a problem for nonfree tools, since the Emacs plugin needed 
to access the data would be GPL and deeply intertwined with its matching 
GCC plugin and version of GCC.

Why this sort of ridiculous hack, you ask?  Because I'm trying find a 
way that GCC can export an AST such that the GPL comes with it.  In 
other words, I'm trying to find a solution that makes both Emacs (get 
the AST) and RMS (don't let nonfree software have the GCC AST) happy.  
Having vaguely defensible technical benefits (efficiency, other Free 
software also gets the AST) would be the icing on the cake.  Simply 
running them both in Guile solves this problem nicely, but will be a 
long way off.  The ridiculous hack is something that can be implemented 
"now"-ish, at least in theory, if someone who understands the problem 
space well enough sets out to do it.

Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

David Kastrup wrote:
> Jacob Bachmeyer <jcb62281@gmail.com> writes:
>   
>> Emacs is GPL, so it can call into GCC through Guile with no problem.
>> A proprietary tool doing the same gets dropped right into a copyright
>> quagmire.
>>     
>
> Not if it does just the same as Emacs since that means it uses a
> generically useful interface.
>
>   
It has been a while since I last read through the FSF GPL FAQs on this, 
so maybe copyright has been weakened, but I thought that dynamic linking 
does not avoid the GPL.  Guile bindings for operations on GCC's GENERIC 
tree would be broadly useful, but I thought that they would also be 
indisputably derived from GCC, and any program written to use them would 
likewise be seen as deriving from GCC?  Has this reach of copyright been 
reduced?  Or have I always been mistaken?

>> Which leads to another idea that I think may have been mentioned: Does
>> Emacs have the ability to load C plugins from shared objects?
>>     
>
> No, and the reason is again not technical but political: it would make
> Emacs generally useful as a component in compound applications not
> reached by the GPL.
>
>   
Could Emacs require plugins to state compliance with the GPL in order to 
be loaded, like GCC requires?

Re: Emacs contributions, C and Lisp

[David Kastrup]

Jacob Bachmeyer <jcb62281@gmail.com> writes:

> David Kastrup wrote:
>> Jacob Bachmeyer <jcb62281@gmail.com> writes:
>>   
>>> Emacs is GPL, so it can call into GCC through Guile with no problem.
>>> A proprietary tool doing the same gets dropped right into a copyright
>>> quagmire.
>>>     
>>
>> Not if it does just the same as Emacs since that means it uses a
>> generically useful interface.
>>
>>   
> It has been a while since I last read through the FSF GPL FAQs on
> this, so maybe copyright has been weakened, but I thought that dynamic
> linking does not avoid the GPL.

Exactly.  And neither does it imply "the GPL", namely the deduction that
both programs form an inseparable whole.  We are dynamically linking a
number of image libraries into Emacs, and do so even at runtime on
Windows.  That does not mean that they suddenly are licensed
differently.

> Guile bindings for operations on GCC's GENERIC tree would be broadly
> useful, but I thought that they would also be indisputably derived
> from GCC, and any program written to use them would likewise be seen
> as deriving from GCC?  Has this reach of copyright been reduced?  Or
> have I always been mistaken?

I should think the latter.  That was the reason for the GCC plugin wars.

-- 
David Kastrup

Re: Emacs contributions, C and Lisp

[Richard Stallman]

[[[ 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. ]]]

  > It has been a while since I last read through the FSF GPL FAQs on this, 
  > so maybe copyright has been weakened, but I thought that dynamic linking 
  > does not avoid the GPL.

Our position is that dynamic linking makes a combination covered by
the GPL -- provided the code _as distributed_ is designed for linking
the parts together.

Combinations that the user decides to make, which are not prearranged
by code that gets distributed, are not limited by the GPL.  This is
true regardless of how the parts get linked.

  > Could Emacs require plugins to state compliance with the GPL in order to 
  > be loaded, like GCC requires?

If Emacs supports plug-ins, it should definitely handle this as GCC does.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs contributions, C and Lisp

[David Kastrup]

Richard Stallman <rms@gnu.org> 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. ]]]
>
>   > It has been a while since I last read through the FSF GPL FAQs on this, 
>   > so maybe copyright has been weakened, but I thought that dynamic linking 
>   > does not avoid the GPL.
>
> Our position is that dynamic linking makes a combination covered by
> the GPL -- provided the code _as distributed_ is designed for linking
> the parts together.
>
> Combinations that the user decides to make, which are not prearranged
> by code that gets distributed, are not limited by the GPL.  This is
> true regardless of how the parts get linked.
>
>   > Could Emacs require plugins to state compliance with the GPL in order to 
>   > be loaded, like GCC requires?
>
> If Emacs supports plug-ins, it should definitely handle this as GCC does.

If our only option to combine Emacs and GCC is to implement this in a
manner where neither GCC nor Emacs can be considered a separate
application any more, then we won't be combining Emacs and GCC.

Copyright can be made to cover extensibility.  But it will stop at
interoperability of preexisting applications.

-- 
David Kastrup

Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

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. ]]]
>
>   > It has been a while since I last read through the FSF GPL FAQs on this, 
>   > so maybe copyright has been weakened, but I thought that dynamic linking 
>   > does not avoid the GPL.
>
> Our position is that dynamic linking makes a combination covered by
> the GPL -- provided the code _as distributed_ is designed for linking
> the parts together.
>
> Combinations that the user decides to make, which are not prearranged
> by code that gets distributed, are not limited by the GPL.  This is
> true regardless of how the parts get linked.
>   

Where is the line here?  Does having GPL code define a new API mean that 
programs using that new API can be considered designed for linking to 
that GPL code?  If not, how can the GPL be effective on libraries, such 
as Readline?  I thought that this was how that worked.

More specifically, if a future version of GCC, buildable as a Guile 
extension, offers access to its AST through a Guile API, would nonfree 
programs be able to use the GCC API, or would the GPL protections cover 
GCC's API?  Assume that GCC invents its own API and does not reimplement 
some other API for AST access.  If nonfree programs could use GCC in 
this case, what prevents the same abuse of Readline now?  (I base my 
longer-term proposal for Emacs/Guile/GCC on past positions I have seen 
taken with respect to Readline; perhaps I have misunderstood.)

Re: Emacs contributions, C and Lisp

[Richard Stallman]

[[[ 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. ]]]

  > > If Emacs supports plug-ins, it should definitely handle this as GCC does.

  > If our only option to combine Emacs and GCC is to implement this in a
  > manner where neither GCC nor Emacs can be considered a separate
  > application any more, then we won't be combining Emacs and GCC.

I agree with that statement -- but that seems like a leap from one
topic to a totally unrelated one.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs contributions, C and Lisp

[Richard Stallman]

[[[ 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. ]]]

  > Where is the line here?  Does having GPL code define a new API mean that 
  > programs using that new API can be considered designed for linking to 
  > that GPL code?

Yes, if using that API implies dynamically linking with that
GPL-covered code.

This is nothing new.  It has been our position for decades.

  > More specifically, if a future version of GCC, buildable as a Guile 
  > extension, offers access to its AST through a Guile API, would nonfree 
  > programs be able to use the GCC API, or would the GPL protections cover 
  > GCC's API?

Yes.  And the same is the case with GCC's existing API for plug-ins.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs contributions, C and Lisp

[David Kastrup]

Richard Stallman <rms@gnu.org> 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. ]]]
>
>   > > If Emacs supports plug-ins, it should definitely handle this as
>   > > GCC does.
>
>   > If our only option to combine Emacs and GCC is to implement this in a
>   > manner where neither GCC nor Emacs can be considered a separate
>   > application any more, then we won't be combining Emacs and GCC.
>
> I agree with that statement -- but that seems like a leap from one
> topic to a totally unrelated one.

It's related in that Emacs is a general purpose application independent
from GCC.  Any way we find for combining Emacs with GCC will be usable
as a way for combining GCC with proprietary applications without the
proprietary applications falling under the GPL.

-- 
David Kastrup

Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

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. ]]]
>
>   > More specifically, if a future version of GCC, buildable as a Guile 
>   > extension, offers access to its AST through a Guile API, would nonfree 
>   > programs be able to use the GCC API, or would the GPL protections cover 
>   > GCC's API?
>
> Yes.  And the same is the case with GCC's existing API for plug-ins.

I just realized that my question was very badly worded, with two 
positive alternatives, one good and one bad.  Is that the good "yes, the 
GPL would cover the API" or the bad "yes, sadly, nonfree programs could 
use the API"?  I think that it is the good alternative, since the 
existing GCC plugin API would never have been implemented otherwise, but 
there has been plenty of confusion around this topic already, so I ask 
for clarification.

Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

David Kastrup wrote:
> Any way we find for combining Emacs with GCC will be usable
> as a way for combining GCC with proprietary applications without the
> proprietary applications falling under the GPL.
>   

I do not think that that is necessarily so.  For example, adapting GCC 
to be usable as a library would allow Emacs (and other Free software) to 
use GCC in a way that would remain barred to proprietary applications.  
I am less sure than I initially was about the "two plugins" solution I 
proposed earlier, but I will clarify it here.

The "two plugins" interim solution:

Implement a pair of plugins, one uses the existing GCC plugin interface, 
the other uses a to-be-developed Emacs extension interface.  The 
to-be-developed Emacs extension interface essentially allows subrs to be 
added to a running Emacs.  It is not useful aside from extending an 
Emacs Lisp interpreter.  The pair of plugins is an inseparable whole.  
The need for two plugins is simply an artifact of GCC's current 
architecture, which precludes directly loading GCC into the Emacs process.

The end result is Emacs Lisp bindings to GCC's internal API for its 
internal AST.  Since these internal APIs in GCC are somewhat stable, 
even though the underlying structures may not be stable, Emacs gets 
workable access to the AST.  Since the link plugin (the pair is a 
technical artifact--it is really one plugin using both interfaces and 
IPC to tie the processes together) would be GPL, nonfree software would 
not be able to use it.

Since the plugin would be Emacs Lisp bindings to GCC's internal API, it 
would logically be a part of GCC.  The IPC link within the plugin is a 
technical artifact and the overall function of the plugin is to make 
(part of) GCC available as a library to Emacs.  If the bindings are 
well-designed, the future GCC/Guile may be able to reuse the interface 
with a less-complex implementation that does not need IPC.  This would 
mean less work when porting Emacs to Guile, since only the process of 
loading the API would change.

On a technical note, could a single shared object be both a valid GCC 
plugin and a valid Emacs plugin?  That would eliminate even the 
appearance of separability, which seems to be the concern with this 
approach.  Maybe we need a new GCC extension for runtime binding of 
symbols to allow symbols to be undefined as long as they are not used?  
Or should we just let the plugin code be a mess, with many calls to 
libdl, as a reminder that this is supposed to be a temporary solution?

Re: Emacs contributions, C and Lisp

[David Kastrup]

Jacob Bachmeyer <jcb62281@gmail.com> writes:

> David Kastrup wrote:
>> Any way we find for combining Emacs with GCC will be usable
>> as a way for combining GCC with proprietary applications without the
>> proprietary applications falling under the GPL.
>>   
>
> I do not think that that is necessarily so.  For example, adapting GCC
> to be usable as a library would allow Emacs (and other Free software)
> to use GCC in a way that would remain barred to proprietary
> applications.  I am less sure than I initially was about the "two
> plugins" solution I proposed earlier, but I will clarify it here.
>
> The "two plugins" interim solution:
>
> Implement a pair of plugins, one uses the existing GCC plugin
> interface, the other uses a to-be-developed Emacs extension interface.
> The to-be-developed Emacs extension interface essentially allows subrs
> to be added to a running Emacs.  It is not useful aside from extending
> an Emacs Lisp interpreter.  The pair of plugins is an inseparable
> whole.  The need for two plugins is simply an artifact of GCC's
> current architecture, which precludes directly loading GCC into the
> Emacs process.

If two plugins to Emacs and GCC are made to talk to each other, you can
replace the Emacs plugin with something else doing the same from GCC's
point of view.

GCC and Emacs are independent applications with an independent history
and a necessity to continue working independently.  If you make those
independent applications communicate in any manner, any other
application using this communication is going to remain similarly
independent.

Even if we managed to successfully mess with this basic equivalence, the
consequences of establishing such precedence would be so much worse for
our cause than accepting this limit of copyright's reach could ever be
that we'd be wise to not even try.

-- 
David Kastrup

Re: Emacs contributions, C and Lisp

[Richard Stallman]

[[[ 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. ]]]

  > I just realized that my question was very badly worded, with two 
  > positive alternatives, one good and one bad.  Is that the good "yes, the 
  > GPL would cover the API" or the bad "yes, sadly, nonfree programs could 
  > use the API"?

Sorry.  If I were in less of a hurry, I'd have read the question
carefully and written my answer clearly.

The situation with Emacs will be the same as it is with GCC now:
plug-ins have to be GPL.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

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. ]]]
>
> The situation with Emacs will be the same as it is with GCC now:
> plug-ins have to be GPL.
>   


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?

I think that the answer to this question is "no", and that this provides 
a means to export GCC's AST to Emacs without opening the AST to nonfree 
software.

Re: Emacs contributions, C and Lisp

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

On 01/15/2015 07:47 PM, Jacob Bachmeyer wrote:
> Richard Stallman wrote:
>> The situation with Emacs will be the same as it is with GCC now:
>> plug-ins have to be GPL.
>>   
> 
> 
> 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?
> 
> I think that the answer to this question is "no", and that this provides
> a means to export GCC's AST to Emacs without opening the AST to nonfree
> software.

That doesn't address Richard's concern. I can write some elisp to export
the AST to my proprietary compiler.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Emacs contributions, C and Lisp

[David Kastrup]

Jacob Bachmeyer <jcb62281@gmail.com> writes:

> 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. ]]]
>>
>> The situation with Emacs will be the same as it is with GCC now:
>> plug-ins have to be GPL.
>>   
>
>
> 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?

That's not the central question at hand.  The central question is: if an
Emacs plugin can provide access to internals of GCC, what keeps nonfree
software from using the same mechanism as the Emacs plugin to get access
to internals of GCC?

If you combine Emacs and GCC, there will be one point where Emacs ends
and GCC begins.  And that is the point where you can swap out either for
a nonfree application without getting copyright involved, since GCC and
Emacs are clearly independent applications.

The price for interoperation is interoperation.  And since it is rather
more than less important for free as opposed to proprietary software
that independent teams can create cooperating applications, I don't see
that it makes sense for us not to pay that price.  And the latest point
to which we can delay this is when a concrete application is imminent.

We can't guarantee that such an application will be successful if we
allow it.  But it will definitely fail if we don't.

-- 
David Kastrup

Re: Emacs contributions, C and Lisp

[David Kastrup]

Daniel Colascione <dancol@dancol.org> writes:

> On 01/15/2015 07:47 PM, Jacob Bachmeyer wrote:
>> Richard Stallman wrote:
>>> The situation with Emacs will be the same as it is with GCC now:
>>> plug-ins have to be GPL.
>>>   
>> 
>> 
>> 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?
>> 
>> I think that the answer to this question is "no", and that this provides
>> a means to export GCC's AST to Emacs without opening the AST to nonfree
>> software.
>
> That doesn't address Richard's concern. I can write some elisp to export
> the AST to my proprietary compiler.

And the reason is that Emacs is the ultimate glue for independent
applications and _designed_ for that.  Putting Emacs on a GUILE basis
will "acerbate" its flexibility.  That's the whole point of making Emacs
a central pillar of the GNU system.

-- 
David Kastrup

Re: Emacs contributions, C and Lisp

[Richard Stallman]

[[[ 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).

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 there is danger in generating the AST as text.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

David Kastrup wrote:
> Jacob Bachmeyer <jcb62281@gmail.com> writes:
>   
>> 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. ]]]
>>>
>>> The situation with Emacs will be the same as it is with GCC now:
>>> plug-ins have to be GPL.
>>>   
>>>       
>> 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?
>>     
>
> That's not the central question at hand.  The central question is: if an
> Emacs plugin can provide access to internals of GCC, what keeps nonfree
> software from using the same mechanism as the Emacs plugin to get access
> to internals of GCC?

What 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.

> If you combine Emacs and GCC, there will be one point where Emacs ends
> and GCC begins.  And that is the point where you can swap out either for
> a nonfree application without getting copyright involved, since GCC and
> Emacs are clearly independent applications.  

The point where Emacs ends and GCC begins in my interim proposal is the 
function calls into the Emacs plugin I propose that GCC would provide.  
Emacs would be, in effect, dynamically loading GCC as a library.  That 
that library is implemented using RPC to another process is an 
implementation detail.

> The price for interoperation is interoperation.  And since it is rather
> more than less important for free as opposed to proprietary software
> that independent teams can create cooperating applications, I don't see
> that it makes sense for us not to pay that price.  And the latest point
> to which we can delay this is when a concrete application is imminent.
>
> We can't guarantee that such an application will be successful if we
> allow it.  But it will definitely fail if we don't.

You are right, which is why I am seeking a workable solution that all 
can be happy with.

Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

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.

Re: Emacs contributions, C and Lisp

[David Kastrup]

Jacob Bachmeyer <jcb62281@gmail.com> writes:

> David Kastrup wrote:
>> Jacob Bachmeyer <jcb62281@gmail.com> writes:
>>   
>>> 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. ]]]
>>>>
>>>> The situation with Emacs will be the same as it is with GCC now:
>>>> plug-ins have to be GPL.
>>>>         
>>> 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?
>>>     
>>
>> That's not the central question at hand.  The central question is: if an
>> Emacs plugin can provide access to internals of GCC, what keeps nonfree
>> software from using the same mechanism as the Emacs plugin to get access
>> to internals of GCC?
>
> What 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.

So gdb has to be licensed identically with any program you debug using
it because it is accessing the respective program's memory?

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.

>> The price for interoperation is interoperation.  And since it is
>> rather more than less important for free as opposed to proprietary
>> software that independent teams can create cooperating applications,
>> I don't see that it makes sense for us not to pay that price.  And
>> the latest point to which we can delay this is when a concrete
>> application is imminent.
>>
>> We can't guarantee that such an application will be successful if we
>> allow it.  But it will definitely fail if we don't.
>
> You are right, which is why I am seeking a workable solution that all
> can be happy with.

It sounds to me like we are looking for a snakeoil bottle label text
that will placate Richard and/or ourselves for some while so that we
might carry on a bit.  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.

And our limited and distributed resources and skills as free software
developers mean that our success depends on interoperation within free
software.  We can't afford this process every time we want something to
work together.

-- 
David Kastrup

Re: Emacs contributions, C and Lisp

[David Kastrup]

Jacob Bachmeyer <jcb62281@gmail.com> writes:

> 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.

Using Emacs as an AST dumper would be an inconvenience.  Not more, not
less.  Emacs can be used as a batch script engine, and in today's
inflated resource needs, it would not even consume noticeably more
memory than calling some Java program.  At any rate, if Emacs is fast
enough to work for working with the AST in Emacs, it will be fast enough
to export it.

> 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?

That too, if it is a general purpose export plugin.  But at least they'd
have to do it themselves.  Which is a pretty small threshold.

>> This is why there is danger in generating the AST as text.
>
> This is why I do not propose exporting a text AST.

Transforming data is not much of a problem if it is designed to be not
much of a problem for at least _some_ use case.  And it would be
pointless to make it a problem for ourselves.

The most we can hope to do is tilt the table: export as Lisp data.
Still easy to parse, but easier still for us.  And make Emacs really
useful for manipulating the data.  The more GNU and GPLed components fit
together like a jigsaw puzzle, the more annoying it becomes for
programmers to refit a a non-free component into this universe.  Even
when they are legally allowed to do it.

It's not a large hurdle, sure.  But at least it is not a hurdle for
ourselves.

-- 
David Kastrup

Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

David Kastrup wrote:
> Jacob Bachmeyer <jcb62281@gmail.com> writes
>> David Kastrup wrote:
>>     
>>> Jacob Bachmeyer <jcb62281@gmail.com> writes:
>>>       
>>>> 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. ]]]
>>>>>
>>>>> The situation with Emacs will be the same as it is with GCC now:
>>>>> plug-ins have to be GPL.
>>>>>
>>>>>           
>>>> 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?
>>>>
>>>>         
>>> That's not the central question at hand.  The central question is: if an
>>> Emacs plugin can provide access to internals of GCC, what keeps nonfree
>>> software from using the same mechanism as the Emacs plugin to get access
>>> to internals of GCC?
>>>
>>>       
>> What 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.
>>
>>     
> So gdb has to be licensed identically with any program you debug using
> it because it is accessing the respective program's memory?  

No, because GDB is not, itself, communicating with the target using 
complex data structures.  A program that uses GDB to inspect some GPL 
target and interprets complex data structures from that target might 
bring the GPL into the picture, but GDB itself is merely a conduit in 
this picture.  The OS kernel that implements ptrace does not have to be 
licensed identically to the program being debugged, either.

> 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.  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.

>>> The price for interoperation is interoperation.  And since it is
>>> rather more than less important for free as opposed to proprietary
>>> software that independent teams can create cooperating applications,
>>> I don't see that it makes sense for us not to pay that price.  And
>>> the latest point to which we can delay this is when a concrete
>>> application is imminent.
>>>
>>> We can't guarantee that such an application will be successful if we
>>> allow it.  But it will definitely fail if we don't.
>>>
>>>       
>> You are right, which is why I am seeking a workable solution that all
>> can be happy with.
>>
>>     
> It sounds to me like we are looking for a snakeoil bottle label text
> that will placate Richard and/or ourselves for some while so that we
> might carry on a bit.  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.
>
> And our limited and distributed resources and skills as free software
> developers mean that our success depends on interoperation within free
> software.  We can't afford this process every time we want something to
> work together.
>   

We are at a point where continued inaction will eventually make GNU 
irrelevant, the right action will put GNU far ahead of all the others 
for the foreseeable future, and the wrong action will... well, extending 
the metaphor about the defensive wall around our city that RMS has used, 
the wrong action could destroy our defensive wall entirely.

It is very important that we find and carry out the right action.

Re: Emacs contributions, C and Lisp

[chad]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]


> On 16 Jan 2015, at 15:21, Richard Stallman <rms@gnu.org> wrote:
> 
> 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.

Isn’t this what dragonegg does (or did before it was abandoned for lack of interest)? 

	http://dragonegg.llvm.org <http://dragonegg.llvm.org/>

~Chad

[-- Attachment #2: Type: text/html, Size: 1117 bytes --]

Re: Emacs contributions, C and Lisp

[David Kastrup]

Jacob Bachmeyer <jcb62281@gmail.com> writes:

> David Kastrup wrote:
>> Jacob Bachmeyer <jcb62281@gmail.com> writes
>>>
>>> What 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.

We are shooting ourselves much more in the foot that way than anybody
else.

> 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?

>> And our limited and distributed resources and skills as free software
>> developers mean that our success depends on interoperation within
>> free software.  We can't afford this process every time we want
>> something to work together.
>>   
>
> We are at a point where continued inaction will eventually make GNU
> irrelevant, the right action will put GNU far ahead of all the others
> for the foreseeable future,

Reality check: with regard to interoperation we will not be "far ahead
of all the others" period.  And that has never been much of a focus for
the GNU project anyway.  If we ever wanted to get "far ahead" in that
category, talking about interfaces that are not robust or generic enough
to be considered an interface (because once there is a proper interface,
it can be used by non-free applications) is like discussing what plate
armor is best for ballet dancing.

> and the wrong action will... well, extending the metaphor about the
> defensive wall around our city that RMS has used, the wrong action
> could destroy our defensive wall entirely.

At the current point, we have a defensive wall around our armory and
can't get in.

> It is very important that we find and carry out the right action.

I think we missed the point of time where that would have been very
important.  We dropped the ball quite thoroughly already.  But since
this is a principal problem, it will come up again.  And again.  And the
real danger is that we continue to fumble and drop every time.

It is my personal conviction that in the area of interfacing, the kind
of micromanaging that would be required to manage GCC/Emacs plugins let
alone an integration will not work.  If we need to have this kind of
discussion everytime some GNU components want to operate closer, this
cannot work.  GNU is designed and intended to work as one, and if we
need to micromanage every step where it does that, we will not be
getting anywhere.

This issue and the associated decisions will not disappear overnight.
There is no urgency for action: both damage and benefits of a particular
decision will be accumulative for a long time.

But what we need is a long-term strategy here.  We can't muddle through
like that forever, pissing everyone off in the process.

Richard needs to come to a basic yes/no decision regarding whether he
wants to see independent GNU applications to be combined in new manners
without micromanaging each instance (and I am very unconvinced that this
is even possible, for legal, technical, and social reasons) or not.  A
"yes" will very likely imply that this kind of combination cannot be
barred from being done with non-free independent components.  A "no"
will mean that the GNU universe as a whole will permanently be
disadvantaged regarding regarding interoperation compared to a more
permissively managed infrastructure.

Having certainty about that will make it possible for people to choose
which projects under which guidance to participate in without wasting
their time and emotions on things they are powerless to change.

We need a strategic decision, and that's Richard's responsibility.  For
the issue at hand, smart completion and possibly refactoring tools based
on a combination of Emacs and Gcc, it may come too late to make much of
a difference any more, at least regarding those people who wanted to
volunteer this time.  That's possibly a waste and a shame but it may be
that the pieces of clockwork are now too broken to pick them up.

But there is no point in having that kind of waste occur again and again
and again.  The strategy "wait until the issue occurs next time and then
repeat what we did last time until it goes away" is undignified.

-- 
David Kastrup

Re: Emacs contributions, C and Lisp

[Richard Stallman]

[[[ 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 and
distribute the resulting binary, since they are both available under
GPLv3.  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.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs contributions, C and Lisp

[David Kastrup]

Richard Stallman <rms@gnu.org> 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
applications.

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

Re: Emacs contributions, C and Lisp

[Perry E. Metzger]

On Sun, 18 Jan 2015 04:50:25 -0500 chad <yandros@gmail.com> wrote:
> 
> > On 16 Jan 2015, at 15:21, Richard Stallman <rms@gnu.org> wrote:
> > 
> > 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.
> 
> Isn’t this what dragonegg does (or did before it was abandoned for
> lack of interest)? 
> 
> 	http://dragonegg.llvm.org <http://dragonegg.llvm.org/>

dragonegg did indeed use the GCC front end together with the LLVM
back end. Interest in the code waned when LLVM's own C/C++ front end
became sufficiently robust.

-- 
Perry E. Metzger		perry@piermont.com

Re: Emacs contributions, C and Lisp

[Richard Stallman]

[[[ 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. ]]]

The GCC developers told me Dragon Egg is not practical for real use.
But it is indeed an example of the danger that concerns me.

I am not sure how Dragon Egg affects the issue at hand.  To read all
the mail that people sent about this, and think about it, I need a
block of time.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

David Kastrup wrote:
> Richard Stallman <rms@gnu.org> 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. ]]
>> 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.
>   


What we are looking for is essentially a way for Emacs to use GCC as a 
library.  That makes GCC _act_ as a plugin for Emacs, even though it 
remains a separate program.  The reason we want this is that simply 
dumping the AST might weaken GCC's copyleft in practice, but making GCC 
usable as a library will not.

Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

David Kastrup wrote:
> Jacob Bachmeyer <jcb62281@gmail.com> writes:
>   
>> David Kastrup wrote:
>>     
>>> Jacob Bachmeyer <jcb62281@gmail.com> writes
>>>       
>>>> What 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.

Re: Emacs contributions, C and Lisp

[Richard Stallman]

[[[ 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. ]]]

  > 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
  > applications.

I have not had time to read that long discussion.  I did have time to
correct a simple, self-contaied, but incorrect, statement about the
requirements of the GPL and plugins.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs contributions, C and Lisp

[Richard Stallman]

[[[ 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. ]]]

  > What we are looking for is essentially a way for Emacs to use GCC as a 
  > library.

That, as such, should be straightforward.  What may be problematical
is giving GCC new interfaces for calling it as a library.  They may or
may not be problematical -- it depends on what those interfaces do.

I have not had time to read the big discussion about that.  Maybe
there is a solution along these lines.

Please don't post more about this now.  Please give me time
to catch up and then read that discussion.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs contributions, C and Lisp

[Perry E. Metzger]

On Sun, 18 Jan 2015 23:35:26 -0500 Richard Stallman <rms@gnu.org>
wrote:
> The GCC developers told me Dragon Egg is not practical for real use.

It is no longer practical for real use because of bitrot. It was the
preferred C++ front end for LLVM before Clang matured and was quite
usable at that time.

> But it is indeed an example of the danger that concerns me.

Your concern about people mixing and matching parts of software is
not crazy. As many of us have acknowledged in the course of these
discussions, that can indeed happen. The question is whether it is
worth making lots of important things impossible to do in the FSF's
free software ecosystem in order to prevent bad things from
happening here and there. (There are also those like me who argue
that, because of LLVM, it is already more or less no longer possible
to prevent the bad things from happening anyway.)

> To read all the mail that people sent about this, and think about
> it, I need a block of time.

That is understandable. I think the only concern is that it would be
better that this not be put off indefinitely.


Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Emacs contributions, C and Lisp

[David Kastrup]

"Perry E. Metzger" <perry@piermont.com> writes:

> On Sun, 18 Jan 2015 23:35:26 -0500 Richard Stallman <rms@gnu.org>
> wrote:
>> The GCC developers told me Dragon Egg is not practical for real use.
>
> It is no longer practical for real use because of bitrot. It was the
> preferred C++ front end for LLVM before Clang matured and was quite
> usable at that time.
>
>> But it is indeed an example of the danger that concerns me.
>
> Your concern about people mixing and matching parts of software is
> not crazy. As many of us have acknowledged in the course of these
> discussions, that can indeed happen. The question is whether it is
> worth making lots of important things impossible to do in the FSF's
> free software ecosystem in order to prevent bad things from
> happening here and there. (There are also those like me who argue
> that, because of LLVM, it is already more or less no longer possible
> to prevent the bad things from happening anyway.)

I think it is worth pointing out that DragonEgg was basically the
full-extent danger that the strategies concerning GCC plugin
philosophies was supposed to avoid.

It is both important to note that the restrictions placed on plugin
development were not successful in blocking DragonEgg, and that
DragonEgg nevertheless did not manage to be of permanent relevance.

Now part of the reason is that the active driving forces behind LLVM
object to the GPL for both practical as well as philosophical reasons
and consider the requirement to use GPLed components a blemish rather
than a convenience.  We cannot rely on the creators of proprietary
(rather than permissively licensed) software solutions being driven by
the same motivations that caused DragonEgg to fizzle.

But at least those large companies which can easily be classified as
mostly adverse to free software tend to avoid touching GPLed software,
particularly GPLv3.  So we have to worry more about the business friends
of the GPL (like the Android universe) than the enemies.  And those tend
to prefer developing their own replacements over getting bad press.

While the overall situation leading to DragonEgg's demise is not
guaranteed to stay the same forever, it is one relevant data point.

>> To read all the mail that people sent about this, and think about
>> it, I need a block of time.
>
> That is understandable. I think the only concern is that it would be
> better that this not be put off indefinitely.

Indeed.

-- 
David Kastrup

Re: Emacs contributions, C and Lisp

[Richard Stallman]

[[[ 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. ]]]

Please don't try to tell me what the issue is
or what is important.  I know what I think about that.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.