[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "object code" in the GPL and printed copies

Frank Küster wrote:
"Pedro A.D.Rezende" <prezende@unb.br> wrote:

Alexander Terekhov wrote:

Object code is a well established term. GNUspeak is irrelevant.
The Copyright Act defines a computer program as"a set of
statements or instructions to be used directly or indirectly in
a computer in order to bring about a certain result. " 17 U.S.C.
§ 101.

The copyright act is WRONG.

A computer program can NEVER be "a SET of statements or
instructions...", a computer program has to understood as "a SEQUENCE
of statements or instructions...".

I wouldn't be too sure that "set" doesn't have a different meaning to
lawyers than it has to mathematicians or computer scientists.

Anyway, I doubt whether sequence is correct, too - unless you redefine
sequence to include conditional execution and loops.

Apologizing in advance for the length of this reply, I may say I'm
afraid this thread is only getting noisier.

Lawyers and lawmakers ought not pretend to be writing words for which
meanings have been settled for millenia ( SET, SEQUENCE), to mean differently in their writings just when their incompentence to use them gets exposure.

About the above doubt, please consider:

An instruction, whether jumpable (such as 'goto', 'if', 'loop') or non-jumpable (such as 'move_data', 'add_integers'), is an element from a finite set of instructions defined by a model of hardware or by a lower level language. That is, defined by objects that give expression to a computer program in their corresponding object code. Such a set of instructions is defined by rules on how instructions can be coded by bits (syntactic rules), and rules on how instructions cause the object (in case of low level language, an interpreter program) to behave while interpreting instances of these instructions (semantic rules).

The syntax for a jumpable instruction is just like the syntax for any
other instruction: it says that an instance of the instruction is to be formed by a certain sequence of bits, the identity and lengtht of which can be determined from inspection. An object code is formed by the finite set of instructions (sequence of bits) obeying the object's syntactic rules, plus the semantic rules. The semantic rules are those rules which tell how instances of such instructions shall be interpreted by one such object.

An instruction is determined to jump, or not to jump, only at the semantic level, by semantic rules. If a semantic rule dermines that some instance of a jumpable instruction, while being interpreted, is not to jump, the next instructon to be interpreted shall be, like with non-jumpable instructions, the following instruction. The concept of 'following instruction' comes as a feature of the von-Neumann architecture, used to build the commodity hardware in use since the begining of digital programmable computers.

Thus, for the purpose of this discussion (author's right to distributable software), the rules of an object code assume that a program is formed by a SEQUENCE of instructions. Since the semantic rules for jumpable instructions have to refer to positions where they are to jump if the instance's context so determines, this can only be achieved by references to marks or distances (in bytes) over the sequence of instructions. Therefore, in the formation of an object code, adherence to syntactic rules, which determine those marks and distances through the sequence, have to precede the interpretation of semantic rules, which refer to them.

Therefore, in the von-Neumann architecture (today's commodity computers) the sequencing of instructions can not be extricated from the concept of 'computer program', a fact that can be tested as follows: what happens if I show you a bag filled with bits (a lawyer's definition of 'SET of instructions'?), and tell you "this is a program in object code", and ask you "show me the jumps!". What can you do? Without knowing what object that code is for, you (or anyone else, for that matter), nothing.

You can not tell which instances of instructions in that bag may cause, or not cause, the execution of the program to jump when intepreted. In fact, you can neither tell if an instruction is jumpable or non-jumpable. Actually, you can not even tell where an instance of instruction begins or ends. You, or any object, can only hope to do any of these things if the bag's content is first parsed into a sequence of instances of well-formed instructions, if the object is a commodity hardware or computer language used at large since the begining of digital programmable computers.

Thus, in such a context, any object code pressuposes, at a minimum, that a program written to be interpreted by its objects shall be construed as a (finite) sequence of instances of instructions, from the (finite) set of syntactically well-formed instrucions. Refering to computer programs by its form or expression, that is, as sequences of instances of instructions from some object code, yelds a syntactical definiton of computer program. This syntactical definition, in turn, allows for a semantical definition of computer program, the part of the definition that tells what computer programs are for.

Thus, at least for the purpose of describing what is "out there", a proper definition of computer program shall start with a syntactical definition, which pressuposes sequences of instructions in some code, irrespective of whether or how the semantics of any instruction under such code establishes how instances of it may jump, during the execution of the program. Furthermore, the syntactical part of the definition has to precede the semantical part, for the latter is built upon the former.

As a consequence, with more than two levels of languages 'source code' becomes merely a cardinal direction of reference for interpretation, in layered forms of expression for computer programs (the 'object code' in one level is the 'source code' in the next lower level). This is why we can download computer programs, either in source or executable form, over a copper wire ;=). Or why, in the definition quoted from the copyright act, the syntactical definition (where the word 'set' was misused) precedes the semantical definition, in the sentence defining computer programs.

You seem to be confusing the syntactical definition of computer program
(the program's EXPRESSION, the program in aristotelian category
'form', the part we were discussing in this thread), with the semantic
definition of program (the program's BEHAVIOUR, the program in
aristotelian category 'substance', the part we were NOT discussing).

In other words, one can safely say that a computer program is, or is expressable as, a sequence of instances of instructions in some code. This is irrespective of the fact that programs which include jumpable isntructions may, while executing, have these instances interpreted in a sequence which does not match the program's sequence. In other words, the execution sequence (behaviour) may differ from the programming sequence (form) if the program contains any jumpable instructions.

The correctness of the definition given in the copyright act can not be feigned by pretending that the first part of the definitional sentence is to mean what the second part is construed to mean (by choice of verbs), or that lawyers and lawmakers would know how to better use technical terms, and thus they so used some, in law to mean differently than what they have always meant, without bothering to tell anyone else.

Another sign of the quoted definition's incorrectness and of its drafter's incompetence, is that such definition trivializes any attempt to establish a method for telling programs apart, if the word SET is read as in any english dictionary (I dont find it in any legalese dictionary).

Any program that make use of instances of the same subset of instructions would be the same, their 'sets of instructions' being the same, for the semantic part of the definition, as given, can not do the job. The semantic definition could not do it because, according to Gôdel's answer to the halting problem, there is no, and there can be no method to generally distinguish two programs' functionality, in the sense of generally determining what a program's 'result' will certainly be. Neither in advance, by another program (ran on computer or by human hand), nor 'on the fly', by runing two programs side by side.

If such determination was not a theoretical impossibility, dictated by the nature of the realm of symbols, computer security, for one thing, would be a much less dounting enterprise and a much more precise scientific field.

For those who can not phatom what has been said, I can only suggest to
go write a compiler.

Prof. Pedro Antonio Dourado de Rezende  /\
Ciencia da Computacao (61)3072702-212  /  \
Universidade de Brasilia, DF, Brasil  /____\

Reply to: