documentation x executable code
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
Reply to: