On Mon, Jul 22, 2013 at 04:50:51PM +1000, Adrian Colomitchi wrote:
> 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.

Those are good points, and I feel that your conclusion is quite
reasonable. However, making assumptions about the nature of the
intended consumption is one of the fundamental disagreements Ben seems
to have with the FDL.

Attachment: signature.asc
Description: Digital signature

Free-software-melb mailing list

Free Software Melbourne home page: http://www.freesoftware.asn.au/melb/

Reply via email to