Re: Release plans

[Alan Mackenzie]

Hi, Stephen,

On Tue, Aug 19, 2008 at 06:46:22PM +0900, Stephen J. Turnbull wrote:

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

What, exactly, are we getting so worked up about, then?

> .... (except that fallacious argument from the authority of Richard
> Stallman).

That's a mischaracterisation of what I've said.  I respect his opinion
not because of his "authority", but because of his experience of the
murky place where legality, politics, and software meet, and my own near
total lack of it.

> You have only posted assertions.  I grant the conceptual possibility
> that you assert, but I deny its importance.

OK, thanks!

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

Now who's drawing wild conclusions?

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

In a nice rational world that might be the case.  In the world we know,
it'd be "Emacs = hassle = problems, let's just ditch it."

> What damage to Emacs's reputation do you envision?

It's reputation for being a highly effective reliable working program
which causes trouble neither for its users nor sysadmins.

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

OK.  I got this notion from what you have written in your posts, see
below.

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

Right.  So do you agree the present issue is a matter of analysis and
judgement, weighing up risks and benefits?  For example, it is (or used
to be) sensible to close airports during thick fog.

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

That is clear.

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

A little while ago, I opined that it is more important to be free than to
be aware of that freedom.  I don't think your analysis has covered those
Emacs users who are free by virtue of that use, but are unaware of it.
They could lose freedom, possibly without realising it, if any of the Bad
Things we're talking about happen.

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

That wasn't intended to offend, and I'm sorry it did.  I was trying to
get some sort of handle on why two highly intelligent, normally genial,
hackers, are having such a bad tempered exchange.  Please consider this
extract from your email in this thread:
    
    Message-ID: <address@hidden>
    Date: Sun, 17 Aug 2008 01:29:53 +0900

    Richard M. Stallman writes:

     >     How does not providing dynamic loading maximize what users can
     >     do while remaining free?
     >
     > It protects against the danger of non-free C-level add-ons to
     > Emacs.

Stephen: All a freedom-lover has to do to avoid those non-free add-ons is ...
     avoid them.

Further, in your post before your last one, you wrote:

Stephen: I mean for starters, the GPL guarantees that Emacs remains free.
     So people can just say no and keep their personal freedom.


That sentence "All a freedom-lover has to do ...." suggested to me that
you only considered the effect on "freedom-lovers" (what I called
"informed autonomous hackers") important.  The sentence "So people can
just say no and keep their personal freedom." reinforces this impression,
in that it disregards those who can't just say no.  I think Richard was
concerned about protecting users who would be less able to avoid non-free
add-ons, for whatever reason.

These sentences of yours still suggest to me that you don't regard the
freedom of the non-informed, or non-autonomous hacker with very much
importance.  Please comment on this.

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

I can't, at least, not at the level I think you want.  It would need more
expertise on and more interest in things like licensing, copyright, ...
than I've got.  Anyhow, I'm not the person that needs to be persuaded.

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

I don't think it could.

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

The bit I think you're neglecting is the free "for whom?".

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

Again, non-free "for whom?".  If you'ld've made specific reference to
people who couldn't or wouldn't take action against non-free add ons
themselves, I'd accept you'd understood my point.

> In the light of day, though, I don't believe it's going to happen.

I don't think it would happen either, for what it's worth.  

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

Yes, it would indeed be nice.  If Emacs had been structured more
modularly, this would be easy.

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

The sentence fragment ".... only allowing digitally signed LISP or binary
libraries to be COMPILED or loaded."  But that's not important.  The fact
is, a loaded binary module could disable any part of the Lisp
infrastructure.  It's a mere technical problem, not even that difficult.

> ..... the FSF would have no problem getting a subpoena for Microsoft's
> source code if it was at all compatible.

Maybe, maybe not.  Who wants to go there?  What would happen to Emacs in
the years the court case would drag over?

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

> Again, the technical difficulties of accomplishing this in GNU Emacs
> are enormous.

Really?  A few defadvices in the right (wrong?) place would do the trick.

> Remember, GNU Emacs's security features were designed by the guy who
> posted his password for somebody else's system in a public place.

What was somebody saying about ad hominem attacks not all that long ago?

> How could that be imposed?

I don't think the module I depicted, microsoft8.dll, could be imposed.
It is just too extreme, too blatant.  A more subtle, insidious spoiler
module might be imposable.

>  > > 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 a colloquial expression which means, anywhere I've lived, something
like "I have a number points I could make, any one of which will refute
your point, so I am going mention just one of them, in the hope you'll
not be so abstruse as to carry on a long fruitless argument which you'd
lose anyway.".

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

Without the mischief module they can't access their files, since the OS
puts some sort of lock on the file system.  That module prevents any Lisp
code other than the standard distribution libraries from being compiled
or loaded, and will itself only run in an unmodified Emacs.  Emacs has
now become non-free for those users on that system.

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

Sure, assuming that the --no-site-start flag isn't removed from Emacs
(which anyone is free to do).

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

OK.  I think the benefits are moderate rather than profound.  David K.
mentioned the Lilypond info pages having images, and how it would be
helpful dynamically to load image libraries for them.

-- 
Alan Mackenzie (Nuremberg, Germany).