On Tue, Dec 04, 2001 at 05:42:12PM +0100, Henning Makholm wrote: > 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.
Belive it or not, I agree. The reason "size matters" -- or appears to -- so much in this discussion is that people are pounding the hell out of clause 3) of my proposal, and paying relatively little attention to clauses 1) and 2). > 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. Well, while I find the above personally offensive and without much in the way of merit, I personally am a pretty radical advocate of free speech rights. Outlaw hate speech today and they may decide tomorrow that, say, machine code isn't worthy of protection under the First Amendment. Hey, wait, that already happened. It's the same kind of backsliding that I'm worried about when it comes to permitting invariant text into main. To date, license texts and copyright notices are pretty well-defined documents with discrete boundaries. The GNU GPL takes some liberties with the notion of a license, including a fair amount of text that isn't really terms or conditions, but it's still easy to deal with because it's well-known, widely used, easy to tell where it begins and ends, and is unlikely to swell to dizzying proportions in the future. I'm not sure the same arguments can be made for material which "could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them." > (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). I agree, and it was never my contention that nothing that got in under the ~32 thousand byte limit couldn't be nasty. Hence the provision for "exclusive exceptions" as well as "inclusive ones". In other words, we can reject a package as DFSG-unfree even if it comes in under the limit, just as we can accept a package as DFSG-free even if it goes over. The number is intended as a tool, a rule-of-thumb, not a straightjacket, and anyone who implies the latter is misrepresenting the text of my proposal and everything I've said about it. > 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. Agree. RMS agreed that Debian should not be making special cases for the FSF, just as they do not for us. > 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. I'm sorry, I don't see that as necessarily following. I do agree that it's a risk. I think we should try it out, and if people start suspending judgement in favor of just applying the rule, I'd be quick to call for its repeal. A good way to measure this would be to chart the inclusive exceptions vs. the exclusive ones. If we reject a lot of packages for an excess of invariant text even though there's less than 32kB of it, we're probably exercising judgement; if we don't grant exclusive exceptions much but do grant a lot of inclusive ones, then either the limit is too low or people are abusing it. If we grant very few exceptions either way, then either the limit is exquisitely tuned (which I doubt), or people just aren't exercising judgement. If we just keep track of these things I think we *will* be able to tell whether my proposal works or not in practice. All this anticipatory hand-wringing is a poor substitute for practical experience. > So if we are to have guidelines, I'd prefer them to look like case law > rather than income tax formulas. Heh, some case law looks a lot like tax formulas. Read Roe v. Wade sometime. :) Applying different standards to different trimesters of a preganancy is nothing if not arbitrary. Whether you think such a standard makes anyway or not depends a lot on your beliefs and I *really* don't want to go there. > 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. Amen. I completely and strongly agree. > 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. Yes. That is absolutely the sort of thing I'm trying to inaugurate. > 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. To me this sounds like a good argument for scrapping clause 3 altogether and modifying clause 2 to include the entire license text. This way, *any* invariant text that was not a copyright notice or license text applied to the work would have to pass a vetting process. I would point out, however, that we'd have to put the GNU CC and GNU Emacs Manuals under immediate review under such a policy. Also, given the language of the GNU FDL, I think it's reasonable to export more, not fewer GNU Manuals with lots of Invariant Sections in the future. I hope we have the courage to not write the FSF a blank check, just as we wouldn't write anyone else one. -- G. Branden Robinson | Debian GNU/Linux | It tastes good. [EMAIL PROTECTED] | -- Bill Clinton http://people.debian.org/~branden/ |
pgpnUtQ6zkyab.pgp
Description: PGP signature
