Re: Emacs Lisp's future

[Stephen J. Turnbull]

Nic Ferrier writes:

 > I am torn between a much more open and distributed Emacs (which I
 > suspect rms won't like)

What's not open or distributed about Emacs?  Maintaining legal
paperwork is a cost and an inconvenience, but the GPL itself legally
guarantees openness and in practice Emacs development is highly
distributed.  ELPA is only going to provide more cases where people
want to "sign papers", or to gather "papers" from their coauthors.  I
can't see this as a problem -- Emacs will acquire more copyrights than
it would have otherwise.

I suppose it's theoretically possible that the body of unassigned and
perhaps unassignable Emacs Lisp will grow faster than the body of
assigned Emacs Lisp, but I doubt it.  Even if it does, most people do
obey the rules, and the body of free software will increase.

 > and having Emacs stay guaranteed free 

There are no guarantees.  It is certainly possible that an SCO-like
attack could be made on Emacs, especially via submarine patent.  The
FSF legal policy merely makes it less likely to succeed, and provides
the FSF the option of shifting costs onto contributors if it fails to
defend the copyrights they claimed to assign.

 > But that's what we did when we introduced packages. How else did
 > people think it would end?

Huh?  Packages simply are a way of making long-standing practices
(development and distribution by satellite projects) more convenient
for end users, permitting multiple development cycles for "core"
modules if desired by the core developers, and to some extent blurring
the line between core-developer and end-user convenience.

As long as GNU ELPA exists, there is no reason to believe that Emacs
is at any more legal risk than ever.  The only legal "danger" to Emacs
created by third-party packages is that, because of the greater
convenience, people who otherwise would not have used them at all may
be exposed to "buccaneer" packages from folks who play fast and loose
with the GPL.  As long as everybody is aware that GNU ELPA protects
them from that, it's their choice.  You may not like knowing some will
make the "wrong" choice, and I know RMS doesn't like it, but what do
you propose as the alternative that is safer?  The package system
itself doesn't favor or enable GPL violations and other unfree
practices, except possibly as a side effect of more free software
being available to violate (unlike "permissive" licensing, which does
enable unfree distribution and intentionally does so).

The practical problem created by packages is (to some eyes) a blessing
in disguise.  By enabling convenient separate development and
distribution of many more Lisp packages than would otherwise exist,
separate from Emacs core, it "exports" many APIs that would otherwise
be considered internal.  Developers wishing to change these "exported"
APIs will encounter a lot more resistance, especially from package
maintainers whose development cycles differ from the core's.  But many
projects have found such discipline to be useful in encouraging
development of a community of library modules and applications.

Consider-the-source-ly y'rs,


Steve