On Mon, Jul 22, 2013 at 3:15 PM, Ben Finney < ben+freesoftw...@benfinney.id.au> wrote:
> Adam Bolte <abo...@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). Take for instance an "HTML mail" - isn't there need to be an "HTML interpreter" to read the email? (well, of course you call it "renderer" or "formatter", but in essence this is what the "HTML formatter" will do: it will "interpret" the HTML of your email body to render your "human readable" image of the email). 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). 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". BTW, I argue the same is valid in reverse: the source-code of an application is nothing but data, unless you choose to "launch it into execution" - without he help of the OS (and potentially the "build tools"), the source-code is in no way different than a "piece of literature". For example, if one chooses so, one may write a "C to music-score transpiler<https://en.wikipedia.org/wiki/Source-to-source_compiler>" and interpret that source code as music (and consider the source code as "interpretative art"). 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. Adrian _______________________________________________ Free-software-melb mailing list Free-software-melb@lists.softwarefreedom.com.au http://lists.softwarefreedom.com.au/cgi-bin/mailman/listinfo/free-software-melb Free Software Melbourne home page: http://www.freesoftware.asn.au/melb/
