Savannah rejects a project because it uses GPL

[Frank Heckenbach]

Alfred M. Szmidt wrote:

> I wouldn't call troff/latex files for `program source.  They all spit
> out a static file, one could compare it to a file with values in it,
> that you give to a program, which then spits out a fractal image.  Is
> the file with the values, just numbers, source code? Or even a
> program?  Of course not.

It's not obvious at all. If the program that you give the file to is
an interpreter (compiler / byte code machine / emulator), and the
values are source code in the interpreted language (source code in
the compiled language or intermediate code produced by a previous
compilation step / byte code / machine code of the emulated
machine), if necessary encoded in some numeric form (just to satisfy
your "just numbers" condition, which is rather meaningless as
everything on a digital computer can be written as numbers), then
yes, the file is a program. -- To most of us, who include source
code in the definition of programs, in all of the cases, and to you
who only seem consider machine code as programs, at least in the
case of an emulated machine. Or do you claim that whether the
content of a file *is* a program depends on whether it's being run
on a native machine or on an emulator? (If so, what is it while it's
not being run?)

> A LaTeX/groff file is more akin to a very
> long parameter list (this is stretching it a bit, but that is what it
> kinda is)

I don't know groff very well, but for (La)TeX this isn't true.
(La)TeX provides a Turing-complete language, so (La)TeX files can be
programs. Probably the majority of existing (La)TeX files are not
"really" programs (or rather, trivial programs, comparable to a C
program consisting only of a series of printf's) if you don't count
the included packages, but it's certainly possible to write programs
in (La)TeX. The same holds for PostScript, unlike PDF, BTW.

A rather easy way to find out (for practical purposes -- the formal
definition can be found in the literature) is to ask the question
whether you can, e.g., compute digits of pi or some well-known
fractal in a language, *without* writing down the result. (An
indication is, if you keep increasing the number of digits or the
resolution of the fractal, does the "program" size grow or remain
the same.) E.g., in non-programmable languages such as HTML (without
JavaScript or other extensions) the only ways to "display" a fractal
are things like including it as an external image, or ASCII art, or
use of tables -- all of which have to grow to display larger
versions.

In contrast, in (La)TeX and PostScript you can implement the fractal
algorithms, so you can output the fractal at higher resolutions by
just changing a parameter. (FWIW, I programmed some fractals in PS
myself. The PS files are very small -- below 1 KB for several
fractals, independent of output resolution. When I converted them to
PDF for fun, the PDF size exploded as I increased resolution --
quickly approaching 100 MB before I stopped. That's because PDF is
basically PS minus the programming language -- the primitives
(graphics etc.) are mostly the same, so the difference is quite
clearly shown in this comparison.)

Simo wrote:

> To me what differentiate a program from a document is that a program can
> handle inputs, while, generally, documents should not.

I don't think this distinction is very useful. On the one hand, as
you say:

> Said that I know
> there a re documents that can change and take inputs, so it really does
> not make any sense to draw a clear line, the line moves on a case per
> case base.

(Even serial letters take inputs.)

On the other hand, programs do not have to take inputs. Though you
could say that a program without input always gives the same result
(if you exclude randomness, by defining it as some kind of input,
which seems reasonable), I don't agree to equating a program with
its output.

As an example, consider a program that repeatedly inputs a natural
number n and outputs the n'th digit of pi. It takes input, so it
would be a program, according to that definition. Now if you replace
the input statement by a statement counting up n, so the program
outputs all digits of pi in succession (until aborted), it wouldn't
be a program anymore -- though the actual code is the same, except
for a trivial modification!?

Or even more extreme, what about an automated test suite (say for a
compiler, so the individual tests are written in the compiler's
source language, and there is some kind of test framework). As it
takes no input (given a fixed compiler version), and always outputs
"OK", neither part of it would be a program according to that
definition. No, I don't think that's a useful definition. The
established definitions in CS of computability, Turing completeness
etc. seem more useful.

Though actually this all misses the point. When someone claims that
programs and non-programs need different kinds of freedoms, then
it's up to him to support this claim. From such an argument it could
be seen show which properties of programs are actually relevant to
the argument. Up to now, we've only seen that "it's functional" is
not the relevant property (as documentation is functional, even
according to the FDL), so the rest seems to be pointless arguing
about irrelevant definitions so far.

Frank

-- 
Frank Heckenbach, frank at g-n-u.de
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)