On Thu, 31 Jul 2003 12:13:12 -0500 John Goerzen <jgoerzen@complete.org> wrote: > 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. I will assume that the rest of your argument is not predicated on the paragraph immediately preceeding this one. If you're going to say "we aren't allowed to say that the DFSG applies to documentation too", you can't say in the next breath that it only applies to software. Speaking of double standards... :) > 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 agree wholeheartedly. The project as a whole seems to have decided that it's okay for license text to be non-Free. That's fine. But don't assume that because the concensus is that non-Free license texts are okay that all non-programming text that's non-Free is acceptable. > 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. As a "strict constructionist", why is it okay for documentation to be partially immutable but not okay for parts of software to be immutable? Consider extremely obnoxious advertisements in software. They're certainly not important as far as functioning of the program is concerned, but would you consider the software "Free enough" if such advertisements legally couldn't be removed? (Please note that I'm drawing an analogy here, not trying to open up the debate about whether documentation is software or not.) > 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. I don't believe much serious concern was expressed about the ability to modify RFCs. In some cases the licenses forbade it, and nobody I know really had a problem with that. They go into non-free/, but who cares? They're still there. This is the license they've chosen, and there's nothing wrong with that. > 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.) Yes. See above. > 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? The "good for our users" point can AND HAS been twisted both ways, so please refrain from using that approach. It's not constructive. I will refrain myself, for instance. > 2. Would removing the specifications around wich large parts of our > system are based benefit our users? Free Software? See above. > 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 :-) I'd like to ask you to read the GFDL carefully, especially section 2. Regardless of whether or not the license is Free, it may very well be the case that we can't legally distribute anything covered by this license. I'm in the process of discussing the issue (and others) with some lawyers who have volounteered to help with FOSS. When everything's worked out I will publish an analysis of the GFDL. It will be in two parts; a short, general overview of the "problems", both ethical and legal, and a long explanation of the first part.
Attachment:
pgpbEjGazIYDM.pgp
Description: PGP signature