Re: Release plans

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

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.

 > 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.  This
restriction on dynamic loading doesn't change the legal status; it
just makes it cheaper for the FSF to fight would-be violators and wake
up those people who just don't bother to think about whether their
distributions are violations.

As Richard says, it's appropriate that the defenders of freedom pay an
extra cost to show they value freedom.  Emacs should get dynamically
loadable modules.  The kernel's strategy for require'ing GPL would
work here, too.

 > We could end up with a firm like Linspire saying "our version of
 > Emacs is superior because it can access files over the <proprietary
 > X> protocol,

It might cost the FSF to fight that, but they'd win.  Don't defend
freedom with FUD.  If they can't win, then you could distribute Emacs
as a .o with appropriate modules and have the user do the linking to
the same effect.  If the proprietary module is that attractive, you
can bet people would do it.

 > There are other choices.  You could, for example, write a module-loading
 > facility yourself, and thus distribute your own Emacs fork.  You'ld not
 > make yourself popular though, any more than the Lucid Emacs crowd did a
 > long time ago.

I resemble that remark, although I wasn't there at the time.  Is it
really worth offending those of us who choose to work on XEmacs when
the cases are not parallel at all?

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