Re: Release plans

[Alan Mackenzie]

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.
We are not just individuals, we are each part of a community, in fact of
several communities.  If Joe gets saddled with a non-free Emacs, that
affects James who has a free one, and quite markedly.  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.  I think I made that clear last night, with my image of
lots of hypothetical Microsoft users who'd get saddled with an entirely
non-free Emacs.

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

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.

> Similarly, any damage to my freedom that is threatened by a proprietary
> module can be avoided by not using it.

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.

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

>  > > 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?"

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.

>  > 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!

Well, I don't think I'm calling people nasty names, and I'm not using
derogatory hyperbole/ambiguous terms like "nightmare", "defeatist", and
"untenable" to imply or half imply other people are idiots or incapable,
or to detract from calm factual discussion.

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.  To me, it is thus incomplete, and thus
invalid.  In any case, I think the burden of proof lies on you, as a
proponent of change, not on me.

I think we differ because our axioms differ.  You and T regard only the
freedom of the informed automous hacker as important.  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.  Apparently
it bothers you not at all.

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

<sigh>.  What I meant, and I think this was perfectly obvious, is that
Richard's copious experience of nasty deviousness in the real world, his
contacts with legal experts, his experience of and intuition in such
things, and so on, should incline the rest of us to respect his judgement
and caution.  Is that OK for you now? 

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

Sorry, this is just a pedantic squabble about the exact meaning of words.
"Establish" has more than one syllable, and that should have been a
warning sign for me not to use it.  Here's a clarification:

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

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

I've nothing more to add in this particular bit of the conversation.

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

Assuming that, somehow, they get to find out the feature exists.  If I
didn't know you better, I'd wonder if you weren't being economical with
the truth here.  It's your project, Stephen, so please give me a pointer
to something in XEmacs 21.4.17 which tells me how to link in an external
binary.  I'm interested in what this feature looks like.  And please tell
me how I should have become aware of it.  Or did the feature first appear
in 21.4.x, where x > 17?

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

For the third time, our basic axioms seem to differ.  I don't think you
see the point I'm making, and your analysis is oblivious to that point,
so I disregard it.  Maybe.

> You haven't even described what a "non-free Emacs" would look like.

That's unwarranted and manifestly false.  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' and only allowing signed (by MS) Lisp
libraries to be loaded.  This scenario would be essentially impossible
without Emacs linking into external binaries.  Tom, in his reply, simply
failed to address this central issue of my post.  An apology, please.

> 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.  They are guarantees, after all.  Hmmm.

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

> 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' and prevent all but
digitally signed code from being loaded.

> 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?  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?

Up to now, you and Tom have been asserting that calling external binaries
is critically important and very useful.  I don't recall seeing much
justification.  If I've missed it, a pointer would be appreciated.

-- 
Alan Mackenzie (Nuremberg, Germany).