Re: Release plans

["Stephen J. Turnbull" <stephen@xemacs.org>]

Alan Mackenzie writes:
 > Hello, Stephen!
 > 
 > On Fri, Aug 15, 2008 at 03:00:56AM +0900, Stephen J. Turnbull wrote:
 > > Alan Mackenzie writes:
 > 
 > >  > The loadability of modules into the kernel has effects on the whole
 > >  > free software community.
 > 
 > > Yeah, it forces free people to make free choices.  This is a good
 > > thing.
 > 
 > A bit like the availability of guns in a community does.

A bit, yes, but the prevalance of that kind of exaggeration in this
community is precisely why I no longer think of myself as a "free
software advocate", though I do advocate software freedom.

 > >  > The facility you want would allow people, in effect, to make
 > >  > proprietary extensions to Emacs.
 > 
 > > That's FUD.  According to the FSF legal staff, it is illegal to
 > > distribute non-GPLv3 modules intended for linking to Emacs.
 > 
 > Are you sure?  OK, yes you are.

Actually, no.  I misspoke.  It is a violation of the GPL to distribute
something, like a Makefile, that is intended to cause a non-GPLvX-
compatible module to be to be linked to a GPLvX module.  I strongly
believe that would include a module being loaded by an Emacs-specific
dynamic loader, such as one that won't load if you don't call
hey_emacs_i_am_gpl_v(X).

I do believe that the FSF would maintain the original position above
(where "intended" is the key word and "-compatible needs to be
inserted appropriately), but I am not terribly sure of that.  In any
case, the restatement is what I need here.

 > Any chance of a reference?

For the restatement:

FSF vs. XEmacs.  We sought and received guidance from Richard on the
question of whether a Qt XEmacs could be distributed.  His answer was
yes on X11 platforms, no on Windows platforms, and provided that we
made it impossible to link Qt in the Cygwin and native NT builds.
(Unless the user patched our code, of course.)  It's in the XEmacs
archives, but you'd have to ask me as they're currently offline due to
a severe space crunch on our host.

FSF vs. Aladdin (Ghostscript).  It's in the ghostscript mailing list
archives, from several years back.  Searching for readline and
ghostscript probably will bring it up.  The FSF intimidated Aladdin
into removing two lines from its Makefile, on the grounds that they
showed the intention to link Aladdin Ghostscript to GNU readline, thus
making Aladdin Ghostscript a derivative of GNU readline.  Aladdin did
remove the code, under protest that there was no license violation
since they did not distribute GNU readline.

 > Are you also sure this applies to external libraries interacting
 > over a clean thin narrow openly specified interface, as contrasted
 > to Elisp libraries which burrow into the heart of Emacs?

First, that's not an "extension" in the usual sense of the word; to
really extend Emacs you need DEFUN.  But that's wordplay.

Show me the interface, and I'll tell you whether I think it applies.
If you mean something like the interface of libpng, sure, you could do
that and it wouldn't apply.  But any platform that provides a
proprietary version of libpng (for example) can already link it
statically.  This is not a distinction between dynamic and static
linking; if one prohibition can be enforced, so can the other.  Cost
will differ, that's all.

I don't think Emacs itself has any such "specified interfaces", and
all the modules I know of either call Emacs buffer functions or use
the DEFUN macro.

 > Hey, just because I'm mistaken (if I am) doesn't make me a fudder.

No offense intended; I say if it is a mistake it is FUD, but I'm
talking about the statement, not the speaker.  Just because a mistake
is FUD doesn't make one a fudder.  But fudders can pick it up and cite
it as the authority, so one should avoid it.

 > Sincere topologies.  Offense wasn't intended, it was just an ill
 > considered throw away comparison.

Your open sets are accepted, and in private mail David Kastrup
contributed somthing like "It's all parallel anyway; that's the point
of hyperbole."  (Which I failed to get until he explained it.<sigh>)
And I would not believe without strong evidence that you ever intended
offense.

 > > The module-loading facility has long been available for both Emacs (as
 > > 3rd party patches, sorry, no URL offhand; maybe from the same source as
 > > XEmacs/CHISE at Kyoto U?) and XEmacs (standard since 21.4).
 > 
 > I didn't know that either.  I looked in the two canonical places on my
 > XEmacs 21.4.17, but didn't find it.  Any chance of a hint to type at C-h
 > f?

It's probably not quite that standard; I believe you need to configure
--with-modules.  Look in M-x describe-installation for module
capability, and if it's there, C-h f load-module.  If not, you can see
the few that we've got in the modules/ directory of the source.