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

Re: Inconsistencies in our approach

On Thu, Jul 31, 2003 at 12:13:12PM -0500, John Goerzen wrote:

> I have for some time been lurking during the discussions of the FDL, RFC
> issues, and related matters, and I am getting an increasingly uneasy feeling
> about the consensus that appears to be starting to coalesce around them. 
> You may note that I am a staunch Free Software advocate as you read these
> below.

> Problem #1: DFSG are Guidelines, not a Definition

> This was discussed on -legal a few months back during the discussion with
> the OSI folks.  At the time, Debian people highlighted that DFSG is meant to
> be taken as a document putting forth general guidelines that will be refined
> -- and possibly special-cased (read: overridden) by discussion and precedent
> within the project.

On the contrary, I think the point people were making in that discussion
was that compliance with the letter of the DFSG is a necessary but *not*
sufficient condition for a work's inclusion in Debian main.  I don't
believe that anyone should have the power to override the DFSG except
through a GR on the part of the developers to amend it. [Insert
US-biased separation-of-powers analogy here]

> As the discussion about FDL and the RFCs continues, I have seen various
> people attempt to disect the DFSG, or to redefine "software" in a highly
> loose manner, or to question DFSG's applicability to non-software items.

> *ALL* of these approaches are wrong.  Putting non-software items into the
> same box as a very different beast serves only to cloud the issue.

Indeed!  So why would anyone try to put non-software items in the same
box labeled "Debian GNU/Linux"?

> DFSG represents a set of guidelines for software.  We should be able to look
> at those guidelines, and see how documentation differs from software in
> relevant areas, and consider whether we need to apply them differently to
> documentation.

Perhaps -- but that makes this a matter of interpretation, and
reasonable beings may disagree on how to interpret the guidelines in
such a case.  To remove this ambiguity, a GR would be necessary.

> Problem #2: Double Standards

> We have, and continue to, allow information to be distributed with software
> under even more strict terms than the FDL.  Examples of these things include
> licenses.

Are there other examples of these things?  Licenses are the only ones I
can think of.

Licenses and copyright notices merit special treatment because they
*are* special: they're the one thing that we include in Debian *not*
because of their content value to users, but because they're necessary
legal incantations required by copyright law.  Freedom to modify a
license text does not translate into freedom from distributing the
verbatim text of the license governing the works we distribute; and
while there are parallels here with RFCs (changing the text of the
standard does not change the standard), the key difference is that we
can choose not to distribute the RFCs.  Technically we /can/ choose not
to distribute copyright notices and licenses, but as a pragmatic
concession to copyright law, we opt for a non-empty distro instead. ;)

In short, since no one is advocating the distribution of software
licenses as OS components per se, they are not subject to the same
requirements of content modifiability that govern OS components.  The
interest in RFCs, and other documentation, clearly lies in their utility
as OS components.

> I think this points out to me that a "strict constructionist" approach to
> documentation does not serve us well.  Speaking in a general sense, rather
> than with regard to the particulars of the FDL, it does not prove a
> significant problem for people down the line if portions of a document
> specifically relating to copyright, licensing, and original authorship
> remain immutable, while the "important" parts remain mutable.

Nor does the above prove a significant problem under the DFSG.  The
problem is with licenses which impose requirements beyond what you've
listed above.

> While I share that concern, and agree in principle that they should be
> modifyable providing the modified version does not claim to be an RFC, we
> need to bear in mind that RFCs serve a quite different purpose than software
> documentation.

> RFCs are here to provide specifications, and their usefulness is directly
> derived from the fact that everyone can point to a single unified source for
> a spec.  I, therefore, see the attempt to banish RFCs -- which are not
> software -- as misguided, but would agree that software documentation under
> the same license poses a larger problem.  (The question then is whether to
> banish that.)

As has been discussed here before, there are much better ways to avoid
"identity crises" of works (trademark, libel, slander) that are also
compatible with Free Software.

>  1. Would removing the manual for Emacs, libc, or other important GNU
>     software benefit our users?  Would it benefit Free Software?

Hasn't the FSF itself taken a long-term view on questions of utility vs.
freedom?  Are you arguing that it's beyond the capabilities of the Free
Software community to replace the above documents if they're determined
to be encumbered?

>  2. Would removing the specifications around wich large parts of our
>     system are based benefit our users?  Free Software?

"Perfection is achieved, not when there is nothing more to add, but when
there is nothing left to take away."  Personally, I find the RFC debate
to be much ado about nothing; as a network administrator and as a
programmer who frequently hacks on network software, I frequently refer
back to RFCs, yet I have never used the RFC packages currently provided
by Debian.  Wouldn't our users benefit from efforts to trim down the
distribution by removing unnecessary bloat such as this?

I am playing devil's advocate here; while I don't personally use the RFC
packages, and I do think there's a lot of fat-trimming to be done in the
archive, these packages fare much better than many in the overall
utility analysis.  The point is, it's quite difficult to judge what's
best for our users as a whole -- and again, reasonable beings may
disagree.  Nevertheless, I do think developers who are balking at the
request to remove RFCs from their individual packages are missing the
more important point, namely, that they're including redundant data in
their packages that's provided elsewhere.  If we have copies of common
licenses in our base-files package to cut down on redundancy, why would
we want multiple copies of RFCs that are many times the size of a
typical copyright license?

Steve Langasek
postmodern programmer

Attachment: pgpZWKBJNdnvK.pgp
Description: PGP signature

Reply to: