guile-devel
[Top][All Lists]
Advanced

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

Re: ELisp?


From: Ken Raeburn
Subject: Re: ELisp?
Date: Sat, 12 Nov 2011 19:56:31 -0500

On Nov 12, 2011, at 10:00, address@hidden 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


reply via email to

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