Adrian Colomitchi <acolomitchi@gmail.com> writes:
On Mon, Jul 22, 2013 at 3:15 PM, Ben Finney < ben+freesoftware@benfinney.id.au> wrote:
Adam Bolte <abolte@systemsaviour.com> 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 categories.
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