[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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: