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