Re: REVISED PROPOSAL regarding DFSG 3 and 4, licenses, and modifiable text

[Henning Makholm <henning@makholm.net>]

Scripsit Branden Robinson <branden@debian.org>

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

I'm not out to outlaw hate speech - I'm just suggesting that Debian
should choose not to participate in it, and not to regard technical
documentation as free if the freedom is contigent on people
participating in hate speech.

There's an important line between my right to speak whatever I want,
and my right to try to force others to speak what I want them to.

> I agree, and it was never my contention that nothing that got in under
> the ~32 thousand byte limit couldn't be nasty.

I'm aware that such wasn't your intention. But whether or not you want
it, that's how people *will* read such guidelines. And that's why I
think that concrete size limits shouldn't even be in the guidelines.

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

My point is that I think the `admissibility' of some invariant section
correlates only weakly with its size - weakly enough that I think that
the exceptions (in either direction) will need to be so frequent
(among those already few cases that wouldn't be settled by sheer
common sense long before anyone bothers to look up the guidelines)
that it would be better not to have the rule to except from in the
first place.

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

I'm not implicating anything about your *intention* - in fact you have
made your intention perfectly clear in this debate. I'm saying that
it's just not going to *work* that way.

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

Since judgement must always be exercised, why have a rule (of thumb or
of steel) at all? It seems to me that no matter where we put the magic
number, the rule is going to be wrong in a sizeable portion of those
cases where judgement *needs* help at all.

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

True in principle, but it's the only tool we have in deciding whether
the experiment should be made or not. Knowing how hard it is to change
these things once they get any kind of historical momentum, I'd say
that the dangers outweigh the perceived gain.

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

Then we agree about basic issues - but we don't agree about whether we
have basis for making a general statement of numerical nature just now.

> 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 suppose that is more or less what I'm arguing for.

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

I would feel uncomfortable with guidelines that *didn't* call for
explicit judgement and explicit good reasons for material of the
kind and quantity that is piggybacked onto those two manuals.

I suspect the most likely outcome of such review would end up with
something like "GCC and GNU Emacs are currently such an essential part
of a free OS that Debian would be a bad joke if they weren't included
and documented. So the manuals are in". But that wouldn't mean that
the FSF would automatically get away with doing the same with less
critical components - say, if the FSF decided that they wanted their
own implementation of cron and shipped a manual with the same
invariant sections, I'm not sure Debian would want that manual.

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

And I hope each of those will be given individual scrutiny.

-- 
Henning Makholm                            "I, madam, am the Archchancellor!
                                       And I happen to run this University!"