Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:
 > Evening, Stephen!
 > 
 > On Tue, Aug 19, 2008 at 02:58:16AM +0900, Stephen J. Turnbull wrote:
 > 
 > > Faulty analogy, until you provide a neutrino's weight of evidence that
 > > any user's freedom to stop using the module is impaired.
 > 
 > I do not accept, as a criterion for freedom, that it is permissible to
 > consider a person's actions divorced from the effect on his neighbours.

That's a very strange philosophy of freedom.  Freedom *means* that you
may do something without concern for interference from your government
or your neighbors.  That doesn't mean it's ethically right to do, of
course.  But you have to argue from a different ethical principle than
freedom.

 > That's just my philosophy and my politics.  If you're going to
 > challenge my arguments, you're going to have to accept, even if
 > only for the sake of argument, these principles.

But Alan, I have accepted your principles, except the one that says
anything you can imagine is probable enough to worry about.

And unfortunately, I can't challenge your arguments because you
haven't posted one (except that fallacious argument from the authority
of Richard Stallman).  You have only posted assertions.  I grant the
conceptual possibility that you assert, but I deny its importance.  I
claim it is both extremely unlikely to come to pass, and that we can
deal with the process of it arising in other ways.  And I've supported
both claims with concrete technical details and policy proposals.

 > This is where we differ.  A plane crash hurts not just the people on
 > board, but the people the wreckage falls on.  Think of Lockerbie in 1988.

I guess I should deduce that you are in favor of closing airports so
that planes will stop falling out of the sky on innocent people?  The
analogy is quite exact, you see.

 > The fallout will hit you.  That proprietary module will gunge up
 > Emacs development, damage Emacs's reputation, cause sysadmins to
 > hate it (they must field the rage from hackers) just as that
 > aeroplane devastated a street in Lockerbie.

I really don't see it.  Emacs developers won't touch the module,
requests for support will be directed to the vendor, and surely
vandalism/netrage by hackers is not to be attributed to Emacs but
rather to the hackers themselves.

What damage to Emacs's reputation do you envision?

 > Again, I'm thinking about the Community's freedom, not just yours as an
 > isolated individual.

I object to your implication that I care only about myself.

 > I think I've made it clear that my "nightmares", as you call them, are
 > not positions I'm defending.  I put them forward only as a counter
 > (mainly) to Tom and to you, to show that bad things are possible, even if
 > not probable.

Bad things are possible.  Stipulated.  As with closing airports to
prevent mid-flight crashes, some policies to ameliorate the possible
bad things are stupid; there are better ways to deal with them.  I
think GNU's refusal to allow dynamic loading in Emacs is such a stupid
policy, because there are better ways to address potential problems.

 > The analysis from you and Tom falls short of mathematical perfection.
 > Unless I'm mistaken, it focusses purely on the effects it would have on
 > knowledgeable automous hackers.

I don't speak for Tom, but my analysis falls short of perfection.  As
I say, you should apply such standard to yourself, as well.

And you are mistaken.  My analysis focusses purely on the *lack* of
freedom-destroying effects for *anybody*.  Once we have some effects
to talk about, I'll worry about whose ox is getting gored.

 > I think we differ because our axioms differ.

I think we differ because I've gone beyond axioms to offer concrete
analysis, and you haven't.

 > You and T regard only the freedom of the informed automous hacker
 > as important.

I am very offended.  I could not have imagined that you would stoop so
low.

 > I (and possibly RMS) see freedom for the entire community as
 > important.  I think my hypothetical bad case ("microsoft8.dll")
 > from last night made that clear.  That such could be imposed on
 > others is a bad thing for me.

I claim it cannot be imposed.  Please rebut.

 > Should a non-free Emacs become widely installed ("established"), say GNU
 > Emacs hobbled by the "microsoft8.dll" I pictured last night, a newer
 > version of Emacs is unlikely to cause the number of installations of that
 > un-free version to fall rapidly to near zero (i.e., become
 > "disestablished").

Depends on what you mean by "rapidly".  Overnight?  No.  In two or
three years?  Yes, I think that can be done, and that's fast enough.

 > For the third time, our basic axioms seem to differ.

They do.  However, for the sake of this discussion, I've adopted
yours.  Except for the axiom that "dynamic loading leads to unfree
Emacs", which I consider a proposition to be proved or disproved.

 > I don't think you see the point I'm making, and your analysis is
 > oblivious to that point, so I disregard it.  Maybe.

No.  I understand your point.  "Introducing a module loader could
cause Emacs to become non-free."  That's scary.

In the light of day, though, I don't believe it's going to happen.
Just like I don't believe there's a mass murderer waiting in the rear
seat of my car.  Possible, yes, and people have been killed by such.
But very very rare, and much better dealt with by locking the car than
by selling it.

OTOH, I do know that benefits (so far of modest size) will certainly
happen.  For example, you're the same Alan Mackenzie who's been
annoyed by the Emacs build process recently, right?  Wouldn't it be
nice if you could just disable the broken feature you don't like, or
even just not build that module and use yesterday's build of the
module with today's core?  How about if you are developing new C code,
and can change and reinitialize it in your running Emacs with a
turnaround of about 5 seconds on a reasonable machine?

Of course those conveniences don't stand up against the nightmarish
scenario of microsoft.dll.  Except that they are *certain*, based on
my personal experience with the feature, whereas IMO the scenario of
microsoft.dll becoming popular has *vanishing* probability, and even
if it does occur, I believe that it is nearly certain that we can
disestablish microsoft.dll.

 > > You haven't even described what a "non-free Emacs" would look like.
 > 
 > That's unwarranted and manifestly false.

I'm sorry, but what is "warranted" for me to say is *my* call, and
"manifestly false" would imply that you provided a description that a
reasonably intelligent person would see as plausible and something
that can be responded to in a reasonable way.  You haven't provided
any such thing, yet.  I discuss below why "microsoft8.dll" is
technically implausible, and I've provided a number of reasons to
believe it's managerially implausible, too.

 > In my post last night, I drew a picture of Emacs running on a
 > future MS OS, where in order to get access to its file system, you
 > had to install the proprietary library "microsoft8.dll".  This
 > would have the side-effect, on the pretext of "security", of
 > disabling `defun'

I can't find anything about disabling `defun', and that's not
plausible anyway.  All defun really does is establish a value for the
function cell (the primitive is defalias), and add some properties
like the documentation string.  You'd have to also disable funcall,
apply, and eval.  Really you'd probably have to replace both the Lisp
interpreter and the byte-code engine, and since there is no documented
API and semantics for those, the FSF would have no problem getting a
subpoena for Microsoft's source code if it was at all compatible.

 > and only allowing signed (by MS) Lisp libraries to be loaded.

Again, the technical difficulties of accomplishing this in GNU Emacs
are enormous.  Remember, GNU Emacs's security features were designed
by the guy who posted his password for somebody else's system in a
public place.

And who do you think would use such a thing?  Word users are used to
such restriction, but they'd piss their pants at the threat of being
saddled with Emacs.  I'd bet a majority of Emacs users, including all
gurus would refuse to use it, so there goes internal suppport.  Making
such a thing popular would require enormous resources put into support.

How could that be imposed?

 > This scenario would be essentially impossible without Emacs linking
 > into external binaries.

False.  It would be possible, and possibly cheaper, simply to build
such an Emacs-alike from scratch, as Richard himself did. This would
have the benefit that *all* of such an Emacs could be proprietary, too.

 > Tom, in his reply, simply failed to address this central issue of
 > my post.  An apology, please.

I'm not in a position to apologize on behalf of Tom.  I offer you my
apology, but it's not clear to me for what. I still don't see a
description of a (feasible) non-free Emacs nor one that can't be
achieved without a dynamic loader.  All you have is your assertion
that this is a real danger, and all I've done is point out
(repeatedly) that you are simply making bare assertions.

 > > I mean for starters, the GPL guarantees that Emacs remains free.  So
 > > people can just say no and keep their personal freedom.
 > 
 > Oh, so GPL's "guarantees" mean that everything's fine, and so we don't
 > need to worry about anything.

What do you think "for starters" means?  It's not a complete argument,
but you really do have to answer it since you have claimed that Emacs
itself would become non-free.  In the case of microsoft8.dll, the user
still has the source, they still have the right to redistribute Emacs,
etc.  So how has Emacs become non-free?

Even if the DLL is loaded in site-start, you can disable that.  (Well,
I can, in XEmacs.)

 > For the fourth time, I reject your axiom that the measure of freedom is
 > solely that of individual informed autonomous hackers.

It's not my axiom.  Please provide a quote of me asserting that axiom.

 > > And what is the difference between an Emacs that calls non-free code
 > > via a binary module, and an Emacs that accesses files via TRAMP and
 > > non-free SSH?
 > 
 > The ability of a binary module to disable `defun'

No need for a binary module: (fmakunbound 'defun).

 > and prevent all but digitally signed code from being loaded.

I don't know how to do this without taking over eval and the bytecode
engine.  That's going to be very difficult, even without worrying
about the fact that the only documentation of the semantics at that
level is the source, and thus the author of microsoft8.dll is very
vulnerable to a copyright infringement suit.

 > > Should we remove process support from Emacs?
 > 
 > No.  My question to you: what can an intimately linked binary module
 > achieve that calling something as a separate process couldn't?

Reload a patched C object into a running Emacs.

Manipulate Emacs data structures, and provide new ones.

Very little that a separate process can't, but it can do everything a
lot faster.

 > Linking to external binaries has been in XEmacs for some while.
 > What have people done with it?  Could they have done the same by
 > calling an external program via an OS call?

Look in the modules directory of XEmacs.  In the case of the Canna
module, no such command exists, so you need to link to Canna.
Although there's also a network protocol so you could use just Lisp.

 > Up to now, you and Tom have been asserting that calling external binaries
 > is critically important and very useful.

No, I haven't.  I've simply said I don't see enough risk, even given
the nightmarish consequences you envision, to outweigh the benefits I
see.