Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:
 > Morning, Stephen!
 > 
 > On Mon, Aug 18, 2008 at 09:01:54AM +0900, Stephen J. Turnbull wrote:
 > > Alan Mackenzie writes:
 > 
 > >  > I wasn't talking about a scientific process for which evidence can
 > >  > be weighed up.
 > 
 > > Shouldn't you be?  Surely you know it is possible to quantify risk,
 > > and analyze it scientifically?
 > 
 > OK, but it is like the blowing up of a nuclear reactor, not a plane
 > crash.

Faulty analogy, until you provide a neutrino's weight of evidence that
any user's freedom to stop using the module is impaired.  The
difference between the nuke and the plane is that we know a nuke
accident endangers millions of people.  A plane crash can be avoided
by not getting on.  Similarly, any damage to my freedom that is
threatened by a proprietary module can be avoided by not using it.
Sneaking it in a distribution of Emacs is clearly a GPL violation.

 > > Why do you ask that we on your nightmares, or Richard's, to guide
 > > policy?
 > 
 > I don't ask anyone to we on my nightmares.  ;-)  I think you missed a
 > word out.

"Why do you ask that we *depend* on your nightmares, or Richard's, to
guide policy?"

 > > Are you beginning to see how untenable your position is?
 > 
 > No.  It may well be that, after more rigorous analysis, loadable binaries
 > in Emacs might not be a problem.  But being wrong is a long way from
 > being untenable.

Sigh.  All the analysis so far has been provided by me and Tom,
principally, with similar comments from others on the pro-DSO side.
You just repeat your assertions, and Stallman compliments your for
your clear statement of the issues.  Humbug!

 > > In fact the only thing it has going for it is
 > 
 > >  > Richard is a master of nasty deviousness, so the fact that he sees a
 > >  > problem is reason in itself to take it seriously.  ;-)
 > 
 > > but that's genuinely ad hominem.
 > 
 > Yes, but it's not an a.h. attack.  It's an a.h. compliment.

Attacks are often valid logically.  Ad hominem is a logical *fallacy*,
inadmissible in reasoned discouse.

 > >  > The essential point is that if an un-free Emacs became established
 > >  > through the mechanism of loading binary libraries, we could not
 > >  > easily reverse it.
 > 
 > > Huh?  All you have to do is write the patch and announce a release.
 > > Richard has done that before (the security patch a couple years ago).
 > 
 > "Huh?"?  Such a patch would do nothing to disestablish an established
 > un-free version.

Of course it does.  The old version was an unfree *GNU* Emacs.  The
new state of affairs is a free GNU Emacs, and an unfree *fork*.  If
you don't think that causes disestablishment, consider that no major
GNU/Linux distributor would be likely to continue to distribute the
fork as GNU Emacs; they'd make a separate package.  Users would get
their butts kicked as this addictive non-free app stops working with a
bizarre error message about `function load-module not found' as soon
as they upgraded Emacs.  And Richard would do what he did to the
Lucid people (what *they* did then is not relevant; I'll bet you none
of them would be willing to go through that again, is the point).

If that doesn't disestablish the fork pretty quick, Emacs is at least
as far behind the fork as Emacs 18.59 was behind Lucid 19.1.  Pretty
unlikely.

The above is what *analysis* looks like.  Are you beginning to see how
untenable your position is yet?

 > Those two sentences seem to contradict eachother.  I can't find any
 > documentation for it in either of the manuals (XEmacs 21.4.17) or NEWS.
 > I even know it exists, and I've even got a solid search term ("loader"),
 > but I still can't find it.  That's hardly encouragement.

OK, so we don't *encourage* it, and we have some documentation bugs.
"Would you like to work on the bugs?"  It's still a standard feature,
supported and easily configured for those interested in it.

Alan, why don't you apply these picky-picky standards to your *own*
non-arguments?  You complain about how we try to avoid the issues,
although I don't see that we do.  I've explained, Tom has explained,
why we don't believe a "non-free Emacs" can become established.  But
you have a monster in the closet that simply disappears every time we
open the door.  Not one dirty footprint, no fur settling to the floor,
nothing.

You haven't even described what a "non-free Emacs" would look like.  I
mean for starters, the GPL guarantees that Emacs remains free.  So
people can just say no and keep their personal freedom.

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?  Should we remove process support from Emacs?

 > I've just had a look at the SXEmacs home page, having not previously been
 > aware of it.  I can't really see any reason for SXEmacs's existence.

Freedom.  Steve on the one side and me and Ben on the other had
different ideas about how to run a project, and what quality of code
and design should be allowed in.  ("Quality" here includes style etc,
it's not necessarily better or worse.)