A concrete proposal
The following is a concrete proposal, but it has two very important
BLANKS in it, with some suggested things that could fill in the
BLANKS. My purpose in giving this is that I think we can all agree
about everything here except the BLANKS themselves. This might help
move us along towards consensus.
It should also be noted that the exact text is not worth worrying
about; this is a thought exercise to focus attention on the BLANKS.
If we reach consensus on them, then we can tighten up the remaining
wording.
Note that BLANKONE is not really that controversial, but I'm unsure
about the best wording, and there are important conceptual issues
behind it.
BLANKTWO is the really important one.
TB's Proposed Guidelines for Invariant Text in Debian Packages
Debian packages usually contain text which is invariant: which all
copiers or modifiers of the software are required to keep intact.
Some of this text consists of copyright notices and associated license
materials. A package may have such text, but not exceeding BLANKONE.
In addition, packages may contain BLANKTWO other invariant text.
All invariant text must be nondocumentary: that it does not need to
be changed in order to keep the documentation an accurate reflection
of the operation of the program, which must itself always be
modifiable.
I envision three fillins for BLANKONE:
BLANKONE OPTION A: "copyright statements, ascriptions of authorial
credit, license texts, and warranty disclaimers."
BLANKONE OPTION B: "copyright statements, licenses, and incidentally
associated material."
BLANKONE OPTION C: "one kilobyte".
(Note that the exact number in BLANKONE OPTION C should be thought
about if people like that option.)
I envision three fillins for BLANKTWO:
BLANKTWO OPTION A: "no".
BLANKTWO OPTION B: "thirty-two kilobytes".
BLANKTWO OPTION C: "one tenth of one percent of the total size of
the documentation".
Note that the numbers in options B and C here should be compared
against historic use; my intention is that they would be tuned such
that presently existing Emacs and GCC manuals be included. (I don't
intend any kind of "permanent" exception for those manuals; Branden is
quite right that such a blank check is uncalled for.) Don't bother
arguing about the exact numbers yet; these are rough examples only.
If you choose BLANKONE OPTION B and BLANKTWO OPTION A, then I am very
hesitant about the workability of the resulting scheme because of the
difficulty in defining "incidentally associated" and the likelihood of
its abuse to avoid the absolute prohibition of BLANKTWO OPTION A.
If I've omitted a fillin for one of the blanks, then please mention
it. I'm not trying to present a fallacy of forced option.
Thomas
Reply to: