Adrian Colomitchi <>

> On Mon, Jul 22, 2013 at 3:15 PM, Ben Finney <
>> wrote:
> > Adam Bolte <>
> > writes:
> >
> > > Once again, your definition conflicts with what the legal Free
> > > Dictionary appears to be (linked above). A PDF is generally a product
> > > of a computer program - not a computer program itself.
> >
> > You're aware that PDF data is an executable program in (a limited subset
> > of) the PostScript programming language? Every PDF document is rendered
> > by *running the program* in an interpreter. Every PDF is both a document
> > and a program.
> >
> > > I suppose that next you're going to say that this e-mail is an
> > > executable program as well?
> >
> > No, because it is not normally executed in order to render it. A PDF
> > *must* be executed to render it. Every PDF is both a program and a
> > document.
> >
> Yes, it is. Reading an email (or any text) is conceptually in no way
> different than reading a PDF. (that is: unless you chose to read it
> straight from the storage media).

Rendering a PDF involves executing the program written in the PDF
programming language (a PostScript subset). Rendering an email message
does not involve executing the message.

A PDF embodies a program. An email message does not.

> Take for instance an "HTML mail" - isn't there need to be an "HTML
> interpreter" to read the email?

Yes. HTML is not a programming language (though it can contain and/or
reference programs in the ECMAScript language, this is distinct from
HTML). Rendering an HTML document does not entail executing the document
as a program.

> Mind you: while PS/PDF is "formatted" as "scripts in an imperative
> programming language" (a Forth derivative), it doesn't make any
> "scripts in a descriptive programming language" a "non-program" (that
> is: data only).

Righht. A PostScript document or a PDF document is always a data stream
*and* a program *and* a document. It's futile to pretend one can say it
is exactly one of those and thereby exclude it from the other

> I argue that, in essence, the read an ASCII text on the display, there
> need to be an "ASCII interpreter" to transform the ASCII/ANSI bytes of
> the text in the groups of lit pixels which make the sense to you (a
> human) as "readable glyphs".

Not all interpreters are interpreting executable programs as input. Your
“ASCII interpreter” is not treating the input document as a program. It
is parsing the document's structure and content, but not executing the
result as a program. A plain-text email message is data, and is a
document, but is not a program.

This is distinct from a PDF renderer, which takes the input document and
parses its structure and content, but then must go further and execute
the result as a program in order to render to output. A PDF data stream
is data, and is a document, but is not a program.

Your argument attempts to erase the distinction between program and
non-program. I don't accept that; “program” has a useful definition, and
some data streams are not normally programs while others are.

> Where does it let the FDL issue at hand? I don't know... but my point
> is: probably one need to abandon the track of "what you technically
> need to consume those bytes" and substitute it with (or, at least,
> supplement it with) considerations based on the "nature of the
> intended consumption" to deal with the "documentation vs application"
> differences.

Whose intention? Does the intent of the recipient count? I argue so. If
so, the copyright holder is not justified in unilaterally foreclosing
some interpretations of the work.

 \       “Crime is contagious… if the government becomes a lawbreaker, |
  `\          it breeds contempt for the law.” —Justice Louis Brandeis |
_o__)                                                                  |
Ben Finney

Free-software-melb mailing list

Free Software Melbourne home page:

Reply via email to