Inconsistencies in our approach
Hello,
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. In other words, a starting point, and a place from
which to build. By ontrast, OSD is a definition that is intended to be
completely authoratitive on its own.
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.
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.
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.
All of the arguments being made about freeness of documentation -- that
somebody may want to develop a document based on the original -- would also
apply to licenses (perhaps I wish to develop a license based on the GPL).
Yet we are ignoring the problem with the licenses.
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.
Problem #3: Separability of Problems
Concern has rightly been expressed about the ability to modify software
documentation, especially since Free Software is out there to be modified.
Concern has also been expressed about the ability to modify RFCs.
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.)
Problem #4: The Big Picture
We have stated that our priorities are our users and Free Software. We need
to be thinking about whether the actions we take are advancing those goals.
I would say that removing FDL-licensed documents from GNU probably neither
helps our users nor Free Software. And I would say that the same holds true
for RFCs.
Consider these things:
1. Would removing the manual for Emacs, libc, or other important GNU
software benefit our users? Would it benefit Free Software?
2. Would removing the specifications around wich large parts of our
system are based benefit our users? Free Software?
Conclusion
----------
I am all for being completely strict regarding what kinds of software
licenses are allowed into Debian. I am also completely in favor of having
excellent documentation accompanying these programs, and making sure that
people can modify that documentation as appropriate. I think that we may be
on the verge of going overboard in that we are saying "but that's not enough
ability to modify for something that's Free!" when it really is.
Thoughts and critiques are welcome. Flames may be sent to
president@whitehouse.gov, who deserves a good yelling more than I :-)
-- John
Reply to: