On Fri, Aug 22, 2003 at 01:41:55PM -0400, Brian T. Sniffen wrote: > That's an interesting compromise you propose, and it would solve the > problems which affect only some GFDL documents. but I don't think it
I'm well aware of that. > addresses the problems which affect all GFDL documents: the > requirements for transparent formats, and the "anti-DMCA" clause (the > ban on technical access control measures). It also doesn't That doesn't seem to me to be any more non-free than the GPL requiring people that distribute binaries also distribute soures. > well-address the problems with the difficulty of properly applying the > license: what happens when someone says a non-secondary section is > invariant, for example? That is indeed a problem, and we'd probably have to err on the side of caution and consider it invariant. > A few weeks ago, on a Friday, you said that you'd take the weekend to > think about it and try to propose a set of Debian Free Documentation > Guidelines on Monday. I'd be interested to see the output of that > thought process: since I haven't seed a Goerzen FDG, I'd like to know > why you didn't come up with one, and what complexities made it hard -- > or did you just come up with a rephrasing of the DFSG? I didn't post it yet because I'm not yet sure in my own mind what the right guidelines are. Despite the assertions of some, I do not think that just accepting GFDL 100% is the right thing to do here. I see the following scenarios: 1. I'm a Free Software user. I am using Emacs, a large Free system that requires documentation to learn by any means. But that documentation is missing or obsolete because of GFDL. I cannot make use of this Free package. 2. I'm a Free Software developer and want to make a derivative program, but can't because it requires documentation, and I disagree with the GNU manifesto and can't adapt it, and don't have the time to rewrite the manual from scratch. As a developer myself, and a believer in the principles of the free software movement, I'm inclined to conclude that #2 is the larger problem in the long run. I wasn't necessarily so inclined two weeks ago. Regardless, I still maintain that documentation is not software and does need separate guidelines. -- John
