Re: PROPOSED: interpretive guidelines regarding DFSG 3, modifiability, and invariant text
Initial observations or Brandon's proposal:
1: Please separate the "whereas" from the actual proposal. People
might agree with the proposal, but for different reasons, and might
not want to seem to be signing on to the whereas clauses--and reject
it for that reason alone. I assume you don't care if everyone has the
same reasons for agreeing with you, in which case, please separate the
proposal itself from the reasons you favor it.
2: The 16K limit should be checked against existing packages before we
say that's the number. It being universally agreed that we aren't
upset by the cases we know about, we should check and make sure they
don't run afoul of any new guideline.
3: I would *MUCH* prefer a limit that involved some kind of
proportionality to one that has a fixed size.
4: You are attempting to be "legal" and cover all cases. That's
already outside the spirit of the DFSG. Please resist the
(understandable) temptation to try and define things in such a way
that nobody ever need exercise any judgment or understanding in the
future. Elaborate definitions of like "instruction code for a
computer" are things that are not helpful: we all already know what
that means, and it's a purely internal guideline, so nothing is served
by making it too rigid. We should never create internal guidelines
which have the effect of perhaps blocking us from doing the right
thing at some future date.
5: Your notion of a "work" is unclear. Are we talking about manuals?
Pretty much no manual is "instruction code". Or packages? This is
important if and only if you want to maintain the distinction between
the two sorts of cases, and there is no motivation I can see for doing
that.
6: I am *still* unclear why we need a policy. I would prefer to avoid
making policies until and unless they turn out to be necessary. In
the present case, it would only turn out to be necessary if we
envisioned frequent arguments among developers about whether given
packages should or should not be added. (Having only one argument,
should it happen, is no matter; we had that about KDE and it was not
necessary there to make any formal interpretive policy statement--in
general, we should avoid making formal policy statements, period.)
7: Here is the sort of policy I would happily support, presuming you
can explain why, exactly, we need one at all:
"Some documentation or other matter in Debian packages is sometimes
distributed under licenses that do not permit modification or the
distribution of modified versions. When these portions are small
relative to the size of the package, no harm accrues from distributing
them as part of Debian. However, when it comes to actual programs of
whatever sort, we continue to insist that modification always be
permitted. And, since changes to a program necessitate changes to its
associated documentation, any portion of documentation which might
need to be changed to correctly describe a change in the program must
also permit modification and distribution of modified versions."
That seems to meet all the requirements. Rather than ordering
developers about what consitutes "small", I think we should trust that
developers are reasonable, and only if a problem seems likely to loom
should we go about trying to be more specific.
Thomas
Reply to: