Re: A possible GFDL compromise
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
Reply to: