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 >programs.
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 >for documentation.
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
Massa
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]