On Tue, 04 Jan 2005, Matthew Garrett wrote: > So far, I have not seen a single convincing argument as to why > documentation needs different freedoms to executable code. The existence > of this thread is a good opportunity to try to find some.
Well, let's rename the thread then (did that). Here's what *I* think about it, so that you all know my position from day one: 1. The kama sutra is documentation (really :-) ) 2. The emacs manual is documentation 3. The autoconf info manual is documentation 4. The autobook and cvsbook books are documentation 5. The W3C recommendations, RFCs and POSIX standards are documentation BUT 1. The kama sutra is not software, because it is not part of anything containing executable code *and* it was *not* created with the intent of ever being such. 2. The emacs manual is software, because it is an *essential* part of the whole emacs suite. It was created with the clear intent to be distributed along with the emacs executable. 3. The autoconf info manual is also software, due to the same reasoning on (2). It also contains examples that are supposed to be used and are executable code. Upstream is fixing that little problem. 4. The autobook and cvsbook are NOT software. Even in sgml format + stylesheets, or in PostScript format (and PostScript *is* executable code). It is all on the *intent*. They are not *essential* documentation (otherwise they would have been part of the original CVS and autotools packages -- that the essential documentation was not good enough to preclude the two books being written is not an issue). 5. While RFCs and other standards are often *essential* documentation of something (e.g. when a RFC is the sole document of an API), they predate the executable AND they where NOT written to be the companion of any executable, but rather to define how all executables in a certain class should behave. Again, it is on the intent. So, I would not say they are software). That would mean that, if I take into consideration the whole reason WHY we have the DFSG freedoms as they are, and in order to protect the idea behind them IMHO 1, 4 and 5 would be eligible for a DFDG rule. 2 and 3 would NOT be, and I do consider a very hard blow on my trust on the FSF that such documents are being distributed in a more restrictive license than the executables. I have since understood why one might want the GFDL for stuff like 4 and 5 (even if I do not like the GFDL), but I do think that it has absolutely no place anywhere near software (and thus, anywhere near the essential documentation of the executables in a software package). I would not have too much trouble with GFDL documentation that is not software in Debian, the same way that I certainly would like to have the RFCs and other standards in Debian. In fact, I'd quite happly welcome such documentation in Debian as long as that means we'd turn all guns to make sure the *software* that is currently under the GFDL is properly relicensed to be free software again. That's where the fight worth fighting is, IMHO. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh