Adrian Colomitchi <[email protected]> writes: > On Mon, Jul 22, 2013 at 3:15 PM, Ben Finney < > [email protected]> wrote: > > > Adam Bolte <[email protected]> > > 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 _______________________________________________ Free-software-melb mailing list [email protected] http://lists.softwarefreedom.com.au/cgi-bin/mailman/listinfo/free-software-melb Free Software Melbourne home page: http://www.freesoftware.asn.au/melb/
