Re: exchange with Richard Stallman

[Bill Mitchell <mitchell@mdd.comm.mot.com>]

I'm not a debian policymaker, but I do have some thoughts on
the points raised in this discussion between Bruce and Richard.

The project has at various times operated on the consensus model,
the loudest-shouter model, the benovelent-dictator model, the
troika model, the office-of-the-CEO (with several persons sharing
CEO responsibilities and consulting behind closed doors) model,
the near-total-anarchy model, and probably a few other models
which I neglect to mention.  I gather that we're now operating
on the CEO (Makes policy, oversees operations, delegates authority
and responsibility -- Bruce) and Chairman (Sets philosophy but
not operating policy, dictates or strongly influences CEO selection
-- Ian M).  I've likely not got that completely correct.

Whatever model we're operating on, I'd hope that input from project
team members would be considered before irrevocable action is taken.

I've rearranged the sequence of some of the requoted material below.
It's not necessarily clear from the indent prefixing whether Bruce
or Richard is speaking, but what's being said by the speaker should
be a good indication.

Bruce Perens <bruce@Pixar.com> said:

>The following is an exchange I've been having with Richard Stallman over
>yesterday and this morning. My conclusion is that what he is asking for
>is not stuff that it's reasonable for us to do, that that Debian can not
>work together with FSF.

and

>To: Richard Stallman <rms@gnu.ai.mit.edu>
>Subject: Re: Can we work together
>
>Richard,
>
>I think the answer is No, we can not work together.

Unless there's more going on than what was presented in the quoted
exchanges, it looks to me like there's likely enough middle ground
for us to go our way while still giving FSF a debian distribution
from which they can pick up the great majority without burdening
them with such a major effort as to make debian look like an
unattractive starting point.  I think requiring them to start over
from sources on all packages qualifies as burdensome.

>>From bruce Fri Mar 22 21:51:22 1996
>
>Richard,
>
>> 1. We need to have packages with unstripped executables.
>
>This point should not be difficult.
>As we approach a multi-architecture release it becomes more important
>that there be a standard way to pass compiler flags into the package
>makefiles. Most of them accept CFLAGS and LDFLAGS passed in, probably
>a number of them need changes to make that work. You'd have to re-build
>all packages with different compiler flags. This should be automatic
>once the initial problems are worked out. I think you would have to
>do a separate build, as I doubt we'd want this option for our main
>release, due to space considerations.

>From: Richard Stallman <rms@gnu.ai.mit.edu>
>
>    I think you would have to
>    do a separate build, as I doubt we'd want this option for our main
>    release, due to space considerations.
>
>What space considerations do you mean?  Don't you have a disk
>available where you could store the unstripped packages alongside the
>stripped ones?
>
>    Do you have evidence that this works as a debugging strategy?
>
>Yes, plenty.

If we take Richard at his word on this, perhaps the following might
be workable for both debian and FSF as a stripped vs. unstripped
approach:

1.  Change the packaging guidelines to require unstripped executables
    in packages (but please keep reading).

2.  Update packages to unstripped executables in the course of normal
    package upgrade uploads.

3.  Advise FSF to survey the debian packages and identify the ones which
    they'd plan to pick up in a debian-based linux distribution release.

4.  Before freezing debian 1.1 for the FSF pickup, require all packages
    on their list to be upgraded to unstripped executables.

5.  Extend dpkg to strip executables as a part of package installation,
    but provide the ability to disable the stripping and leave installed
    executables unstripped as a config option (dpkg config file? environment
    variable?) and/or a dpkg invocation flag.  Do this in such a way that
    FSF could field a distribution which would install unstripped
    executables as the default, and which would allow us to host a
    distribution which would install stripped executables as a default,
    while maintaining the flexibility on both distributions for users
    to change this default on a per-distribution-installation basis,
    and to override this on a per-package basis.

It seems to me as if this wouldn't be an undue burden on us, and would
provide Richard most of what he needs without unduly burdening FSF either.
(Or am I missing something obvious which would make this unworkable?)

Note -- if this is otherwise workable, but the size of downloaded packages
for those desiring stripped executables becomes an issue, it'd be possible
to offer alternate stripped and unstripped distribution trees on the
distribution site.  Packages could be uploaded unstripped, and scripts
on the distribution site could unpack them, strip the executables, and
repackage stripped versions of the packages for the stripped tree.
(I'm tempted to begin a tangential discussion on an additional point
here, but I'll refrain because it's not immediately germain to this
particular issue, and I think this discussion is too important to defocus
with side issues)

>> 2. We need to encourage people to write documentation in Texinfo. [...]
>I think you've had a difficult time marketing Texinfo to the world for
>all of the years it's been available. I don't see that this is going
>to be an easier sell now, with so many people starting to write for
>WWW as their primary medium. I can make HTML work as a common
>denominator. I have not yet come up with any ideas that would make it
>easier to market Texinfo to people who contribute their effort.

Personally, I like texinfo just because I can easily produce a printed
manual from it.  For online docs, I like html better than info, but
don't like either very much.  That's probably because info(1) has such a
miserable user interface and because I'm not webbified enough to have
a html browser handy when I want to look at docs.  Also, I'm one of those
who read better horizontally than vertically, and I'm more likely to have
a stocked-up bookshelf ready to hand than a convenient means of quickly
producing printed docs from whatever is online. 

One upcoming development might change this balance, at least for me.
The next release of Elvis (one of the several vi clones provided in
the debian distribution, and the one I use), has a html display mode.
I'm not sure how well it'd be suited as a general-use html-docs
browser, but it works well for the html-format elvis package docs.
To try it out, install the e2x11-2.0-beta package, start e2x11, and
type ":help".

Speaking as a debian package maintainer, I take the doc format I
get from the upstream maintainer.  For my packages, that's usually
texinfo, sometimes html, and sometimes something else.  Are there any
texinfo<->html cross-conversion tools available?  I've seen mention
of an info->html converter someplace, but can't recall where.  I
gather that both html->texi and texi->html->texi involve nontrivial
issues regarding fonts and graphics.

>> 3. We need simpler installation with clear documentation. [...]
>I'm trying. [...]

'nuff said, for now.  I'm looking forward to the improvements which
Bruce's efforts will produce.

>> 4. We need a complete separation between what we distribute
>> and all non-free software.
>This is another reason for FSF to take Debian and re-build it to their
>specifications when we make a release. I don't think editing the few
>files that mention non-free software and removing some packages is a
>very big job.

It seems reasonable to me for debian to localize the information
which debian provides on contrib and non-free packages to one or two
files, and to clearly identify those files to FSF.

I'm almost tempted to opine that it seems reasonable for debian to
categorize packages into FSF, free (but not FSF), restricted (which
is my current impression of what "contrib" means in debian-speak),
non-commercial, and non-free.

   FSF                  what they pick up
   free                 we consider them free, but FSF doesn't offer them
   non-commercial       free for non-commercial use
   restricted           can't be distributed via commercial channels
   non-free             cost money to use (shareware, fee after trial
                        period, etc.)  (perhaps these need to be subdivided
                        into those which can be freely distributed and those
                        which cannot)

>I think the fundamental issue here is one of philosophical purity.
>We aren't convinced that we can afford not to be heterodox.
>Because you are identified with your philosophy, you can't be anything
>but orthodox. It's going to be difficult to have a meeting of minds
>because of this.

Probably true, on the texinfo vs. html issue.  Possibly less true on
other issues.

mitchell@mdd.comm.mot.com (Bill Mitchell)