Scripsit Branden Robinson <[EMAIL PROTECTED]>
> To that end, I'm willing to bend a bit to accomodate the GNU folks on a
> utilitarian basis. However, such accomodation naturally requires
> artifices. One would be to say the FSF can do whatever it wants and
> we'll call it Free. Another is to set a limit on the amount of
> non-modifiable text and permit packages into main with less than that
> amount. This limit could be non-relative (my proposal), proportional
> (Thomas Bushnell), or vary per package and depend on the package
> maintainer's discretion (Anthony Towns, I think).
FWIW, I don't think it is wise to make a set of guidelines that center
on *size* of the invariant text as the main parameter for the
decision. Sure, the size is *one* parameter, but I think there are at
least some other that are at least as important:
1. What is the actual content and purpose of the invariant section?
2. How much does it relate to the technical contents of the docs?
3. How much does Debian really *want* to dristribute the technical
docs (let's be honest; we cannot just shove this one under the
carpet).
The less "benign" the contents of the invariant section is, the less
of it should be acceptet. Of course some kinds of contents should not
be accepted at all - for example
A derived version of this manual must reproduce this notice
verbatim: "ALL NIGGERS MUST DIE".
where, I'm sure most of us can agree, the 160 bits of invariant
text here is 160 bits too much. (This example is extreme in order
to fit into the discussion. But one can surely imagine ways, if
there's tens of KBs available, to say things that are, as a whole,
just as objectionable but still keep them snugly under whatever
numerical limit we set, as well as cleverly buried in
seemingly-relevant stuff).
On the other hand, only some very special kinds of text justfy having
as much space as the GNU Manifesto takes up in the Emacs Manual. I
think that simply setting up a size test that says "the GNU Manifesto
is okay, because there's not very much of it" is one of the *worst*
ways to retroactively justify the presence of the Emacs Manual in
Debian. If will be one of the kind of policies that continually
invite abuse.
In principle I agree with Branden that some sort of guidelines would
be better than having the ftpmasters do their judgements completly
in the blind. But such a guideline must be compatible with the
necessary fact that the need for human judgement will be the rule,
not the exception. Any kind of arithmetic criterion, however stuffed
with disclaimers saying that "good judgement must be exercised", will
surely give the wrong impression.
So if we are to have guidelines, I'd prefer them to look like case law
rather than income tax formulas. We might set up a collection of prior
cases, saying, this thing was let in because of such-and-such and
despite such-and-such - and that thing was left out because of
such-and-such. Take the necessary flamewars as actual casese arise,
and try to synthesize some statements of "properties that are usually
considered when making the judgement" as the available material grows
big enough to show patterns.
I'd even be happy to suggest the first synthetic statement:
0. In general we're not happy about invariant parts of documentation.
It's a complete showstopper if they contain technical information,
but even if they don't we'd rather not have them at all. Sometimes
they're let in anyway, but only because there are specific reasons
that count more than our dislike for invariance. "There's no
acceptable, more free, documentation available" is usually a
necessary but not sufficient part of such specific reasons.
--
Henning Makholm "Manden med det store pindsvin er
kommet vel ombord i den grønne dobbeltdækker."
