On Sun, Apr 25, 2004 at 03:57:23PM -0400, Nathanael Nerode wrote: > > There is in fact a much better reason to think of them as programs. There's > not much distinction between having a 'program' run by an 'interpreter' and > having 'data' interpreted by a 'program'. I agree that there is some similarity in certain cases, but cat is not a state machine; it does not move from one state to another based on the input. At best it applies a fixed transform to the input. > We certainly consider programs in interpreted languages like perl or > python to be programs, not just 'data'. It depends on the context. They are programs in the context of a perl interpreter, and data in the context of cat or an editor. A text file containing instructions for a theoretical machine 'foo' cannot be a program until foo exists, because there is no machine that will run it. > But similarly, an ASCII file can be considered a 'program' executed by > the interpreter consisting of 'cat' plus your console. An HTML file > is a 'program' interpreted by a web browser. Et cetera. This is bending the definition of "program" far too much for my tastes. I think the criterion should be "does a state machine which executes this string exist"? If it does not, it is not a program, at least until such a machine springs into existence, on paper or otherwise. > > Is an application not distributable by Debian if it does not include the > Not the difference between 'not distributable by Debian' and 'not > distributable as part of the Debian system'. Something is 'distributable > by Debian' if it can be legally distributed in non-free. That doesn't make > it distributable as 'part of Debian', in 'main'. Yes, I meant in main, obviously. A thinko. A GPL context raises the same set of questions as to whether it is distributable at all though. But the GPL refers to "Software"; DFSG#2 refers to "program". > > source XML of a manual, > I certainly hope that to go in 'main', manuals will have to provide source > (preferred form for modification); otherwise, it's quite annoying to modify > them. Suit yourself; I don't mind hacking nroff or HTML. As I mentioned in another post, "preferred form" is a nebulous, subjective term. > > or the source EPS of an image file, > If it was created and modified in that form. That's a stringent precondition. How about if it was modified after it was transformed from the original EPS, and then placed into Debian? Then, nobody has "source" for the modified image. Since no source for the modified form exists, and it was modified in the transformed format, you could easily say that the preferred form of modification is now the transformed version (at least if you don't want to lose all the changes in the interim). Again, the preferred form is subjective, and is not a solid basis for determining free-ness. > If it was managed and modified as a .wav, the way I would, the .wav would be > the required source, yes. (Some people work directly with .mp3s, despite > the quality loss, for whatever reason.) Same problem, see above. > > etc etc, ad absurdum? Where does the cutoff > Nuthin' absurd yet. I would say that preventing something from going in main simply because it had been transformed from a format preferred by some people, at some prior point in its lifetime, is rather absurd. > > of practicality between software and supporting materials end? > What practicality problem? I give up. Actually, I don't. But this is getting frustrating. Is that how you want to win this debate? > In the *binary* packages, you distribute the preferred form for installation > and general use. In the *source* package, you distribute the preferred > form for modification. People who aren't interested in modification don't > even download the source package. People who are interested do. That sounds like a great scheme. Now, enumerate what the Debian-Approved preferred forms of modification for various types of data shall be, and codify the preferred-form-of-modification requirement into the DFSG, and maybe that last paragraph would hold some weight in an argument. -- Ryan Underwood, <nemesis@icequake.net>
Attachment:
signature.asc
Description: Digital signature