From: Ken Raeburn <raeburn@raeburn.org>
To: joakim@verona.se
Cc: guile-devel@gnu.org
Subject: Re: ELisp?
Date: Sat, 12 Nov 2011 19:56:31 -0500 [thread overview]
Message-ID: <4D2381E8-435D-4BBB-8D9B-FFD290E1F4E5@raeburn.org> (raw)
In-Reply-To: <m3sjltbd38.fsf@chopper.vpn.verona.se>
On Nov 12, 2011, at 10:00, joakim@verona.se wrote:
>> Hmm... this touches on a political issue I'd been avoiding thinking about. Namely, adding Guile to Emacs, with Guile's new FFI support, would make dynamically loading new executable code into Emacs easy, technically, including non-GPL code written specifically to extend Emacs. There's been a lot of resistance to that in the past. See for example http://lists.gnu.org/archive/html/emacs-devel/2003-07/msg00403.html .
>
> Yes, this seems to have been resolved if the GCC scheme for identifying
> GPL libraries is used. Basically GPL libraries expose a symbol declaring GPL compliance.
The Linux kernel has a method for dealing with this issue too. As I understand it, a module declares its license terms, and if they're not GPL, you get a smaller subset of kernel functionality you can access from the module, though you can still load it.
But the Emacs FFI case is different. Those other modules would have to be written specifically *for* GCC or Linux and licensed appropriately, and with an Emacs FFI we'd want to be able to load, for example, MIT-licensed widget libraries that have other uses not specific to Emacs. We can't expect all other libraries anyone might want to use to tweak their sources to declare GPL compatibility.
Then there's the question of someday doing static compilation of Guile code to machine code. Can I load a .o or .so of my own Lisp code without it being GPL-licensed or at least GPL-compatible?
*sigh* I don't know, I'd rather let RMS and the lawyers worry about it.
>> On the technical side (ignoring the political/legal angles), I wonder if it would be quicker to drop FFI support into Emacs directly, using an interface based on the Guile one, and use that for now, until the Emacs+Guile work is far enough along to merge. I suspect your xwidgets code would be ready for integration much sooner than that. :-)
>
> Quicker, yes, but less interesting. I suppose I'm looking for an excuse
> to do this :)
Ah, that works for me. My excuse was wanting to do things with Emacs while Gnus was collecting data from mail and news servers, using Guile's thread support rather than rewriting all of Gnus to be callback-driven. :-)
Ken
next prev parent reply other threads:[~2011-11-13 0:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-09 1:35 ELisp? Noah Lavine
2011-10-09 13:37 ` ELisp? joakim
2011-10-09 19:22 ` ELisp? Noah Lavine
2011-10-11 10:12 ` ELisp? Ken Raeburn
2011-11-11 9:46 ` ELisp? joakim
2011-11-12 2:13 ` ELisp? Ken Raeburn
2011-11-12 15:00 ` ELisp? joakim
2011-11-13 0:56 ` Ken Raeburn [this message]
2011-11-12 18:03 ` ELisp? Noah Lavine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D2381E8-435D-4BBB-8D9B-FFD290E1F4E5@raeburn.org \
--to=raeburn@raeburn.org \
--cc=guile-devel@gnu.org \
--cc=joakim@verona.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).