[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: PROPOSED: interpretive guidelines regarding DFSG 3, modifiability, and invariant text

On Sun, Nov 25, 2001 at 07:17:05PM -0800, Thomas Bushnell, BSG wrote:
> Initial observations or Brandon's proposal:

Bzzzt.  You lose points for forgetting how to spell my name despite the
fact that we've communicated dozens of times before.

> 1: Please separate the "whereas" from the actual proposal.  People

The "whereas" is already separated, natch.  It's there to bring the many
people who won't bother to read the background material (somewhat) up to
speed.  If any proposal is adopted, it should contain only the proposed
interpretive rules.

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

I agree.  I wanted to kick this out of the nest, though, since I'd been
sitting on it for a couple of weeks.

> 3: I would *MUCH* prefer a limit that involved some kind of
> proportionality to one that has a fixed size.

You've got it.  See the subsequent section.  The GNU FDL is intended for
documentation.  If people stick to that, they already have the 5%
proportionality exception.  If somebody tries to license something that
isn't documentation under the GNU FDL, they may have problems.

I see that as a feature, not a bug.

> 4: You are attempting to be "legal" and cover all cases.  That's
> already outside the spirit of the DFSG.

Hence why this is not proposed as an amendment to 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.

If you have specific objections, I welcome edits, but I reject the above
assertion as justification for torpedoing this entire endeavor.

We need something better than arbitrary decrees.  People look to the
DFSG, and to Debian's interpretation of it, for guidance in selecting
their licenses.  We need to acknowledge this leadership role, and behave
responsibly, not capriciously.  It's easier to do this if we have
interpretive guidelines.

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

Feel free to propose edits.

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

The FSF sees the need to distinguish the two (code vs. documentation).
I myself was pretty happy with the simple old license that was on the
FSF manuals.  But the GNU FDL is here now and people want to use it, so
I'm attempting to roll with the development instead of pretending it
doesn't exist.  RMS said he'd be unhappy if Debian had to reject stuff
licensed under the GNU FDL.  I'm trying to provide an avenue for us to
prevent that without throwing wide the doors for abuse by people who
violate the intent of the GNU FDL.

> 6: I am *still* unclear why we need a policy.

I don't trust everyone in the world to live up to the standard set by
the FSF.  The FSF put out a license called the GNU FDL and is asking the
world to use it.  That's great.  The license contains no internal checks
on abuse of Invariant Sections.  I think that's not so great.  I want an
established rule that makes it clear that not everything licensed under
the GNU FDL is rubberstamped "DFSG-free", since this could lead to
violation of our Social Contract.  Moreover, I want to reduce the amount
of ad hockery that goes on with respect to license checking.  If you'll
ask around I think you'll find this is a goal of the FSF as well.

More generally, Debian is and should remain the final arbiter of what
the DFSG means, and how it should be applied.  I think it is
inappropriate for Debian to permit Richard Stallman, Eric Raymond, or
Bruce Perens, among others, to fire off a mail to debian-legal and
unilaterally tell Debian what it will and will not accept.  To be fair,
only one of the above people has done so.  Another has his own
organization, whose judgment he expects the entire world to accept, and
one has, apparently, applied to become a Debian developer, and is
willing to engage in reasoned discussion even with people like me[1].

> I would prefer to avoid making policies until and unless they turn out
> to be necessary.

And I'd rather pre-empt some flamewars.

All I'm trying to say is, "you can't piggyback anything you want on the
precedent that Debian allows non-modifiable texts like that of the GPL
into packages in main".  We need boundaries.

> 7: Here is the sort of policy I would happily support, presuming you
> can explain why, exactly, we need one at all:

I'm rapidly reaching the conclusion that there is no explanation I can
offer that you will accept.  You want Debian to finesse these issues.  I

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

You are asking us to allow a lot more non-modifiable, and thus non-Free,
material into Debian than we currently do.  I find this stance

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

An ounce of prevention is worth a pound of cure.  Nothing about my
proposed interpretive guideline is binding.  It's not part of the Debian
Policy Manual, the Social Contract, the DFSG, the Debian Constitution,
or any other formal document.  It can be amended freely at any time.
I'm asking that we reach consensus on SOME policy (small p) because
there are clearly issues of confusion.  Sunnavind raised a valid
concern; he asked a reasonable question that we can expect other people
to ask in the future.  The text DFSG provides no obvious answer.  Your
proposed paragraph above certainly does not follow from the DFSG in any
obvious way (that doesn't mean it's bad, it means the issue is
insufficiently specified by the DFSG).  I'm trying to address this.  What
kind of crisis do you require to justify action in your opinion?  The
threat of a lawsuit?  Charges that the Debian team are hypocrites
because we'll let the GNU Emacs Manual (under the GNU FDL) into main,
but not some other manual?  What sort of strife will convince you of the
need for even the feeblest of gestures, such as the one I have made?

[1] You too, can play along at home!  Match the name to the tactic!
Depending on which web tabloids you read, the actual facts may surprise

G. Branden Robinson                |     Communism is just one step on the
Debian GNU/Linux                   |     long road from capitalism to
branden@debian.org                 |     capitalism.
http://people.debian.org/~branden/ |     -- Russian saying

Attachment: pgpnZFAAHrNL7.pgp
Description: PGP signature

Reply to: