Re: Emacs contributions, C and Lisp
[Posted January 13, 2015 by jake]
| From: |
| Richard Stallman <rms-AT-gnu.org> |
| To: |
| David Engster <deng-AT-randomsample.de> |
| Subject: |
| Re: Emacs contributions, C and Lisp |
| Date: |
| Wed, 07 Jan 2015 21:46:30 -0500 |
| Message-ID: |
| <E1Y937G-0004pS-SP@fencepost.gnu.org> |
| Cc: |
| monnier-AT-iro.umontreal.ca, emacs-devel-AT-gnu.org |
[[[ 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. ]]]
> We do that by excluding such output from the definition of Target
> Code. Because of this, even if someone writes a plugin that saves
> this information to disk, any programs that change the structures
> before GCC writes out Target Code will be involved in the
> Compilation Process. If that program is proprietary, the exception
> will not be available to any software compiled with it; the object
> code that GCC ultimately creates will have to be distributed under
> the terms of the GPL.
> Now I'm even more confused why you'd have a problem with exporting the
> AST.
These conditions on libgcc will be effective if a plug-in is used,
provided compilation continues thru the GCC back end, because the GCC
back end makes code that depends on libgcc.
But if the plug-in writes the whole program as an AST and compilation
uses some other back-end, it probably won't use libgcc, so those
conditions on libgcc won't apply at all.
I am very concerned lest the GCC back ends to be replaced with LLVM,
which permits proprietary changes and proprietary back ends.
--
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.