Re: Documentation is/is not software [was: NEW ...]
Matthew Palmer wrote:
>On Tue, Mar 22, 2005 at 12:32:30PM +0000, Matthew Wilcox wrote:
>>On Tue, Mar 22, 2005 at 09:06:19AM -0300, Humberto Massa wrote:
>>>And I believe that the Vancouver proposal, if implemented as intended
>>>up to now, will not only affect what Debian really *is*, but in some
>>>ways will *destroy* what Debian is.
>>Debian has already decided to destroy what it is by giving in to the
>>crackpots who insist that everything is software.
>Way to set the tone for a productive debate.
Yeah, we are seeing a lot of this lately.
>At any rate, the problem with trying to treat different types of
>bitstreams differently is to classify them, and identify a different
>set of freedoms which are appropriate -- and, more pretinently, why
>those different set of freedoms is important. The "crackpots" won more
>or less by default, because nobody was able to come up with either of
>these two pre-requisites. This suggests to me that either (a) it can't
>actually be done, in which case the "crackpots" are, after all, right;
>or (b) Debian is so filled with "crackpots" that there is nobody who
>actually wants to see documentation treated differently to executable
IMHO the problem is that there is not a clear distinction. Period. Why?
Because source code *is* documentation. The set of freedoms we want to
Free Software (AFAICT) is: freedom to study, modify... for all this we
need access to the documentation, part of which is the source code.
>I used to sit in the "documentation requires different freedoms" camp,
>but eventually just couldn't support my feelings with logical argument.
>But there are significantly more powerful minds than mine out there; I
>look forward to hearing their arguments in favour of different freedoms
The problem with hearing arguments in favour of different freedoms for
documentation is that people will have to define what is -- and what is
not -- documentation. And I don't really think this is possible.
One example: are Debian-changelogs documentation? They contain
instructions on what version of a package is to be built, and which
debbugs should be closed...
>If someone can come up with a bright-line test for differentiating
>executable materials and documentation, or executable materials and say
>firmware, and can produce a "DFDocumentationG" or "DFFirmwareG" with
>effective reasoning, I will be most impressed, and will most likely
>support their position. Until then, however, I am firmly in the "all
>things we ship are software, and the DFSG applies to all of that" camp.
>- Matt crackpot and proud