[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: more evil firmwares found

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

Reply to: