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 /____\
?http://www.cic.unb.br/docentes/pedro/sd.htm
--------------------------------------------
Reply to: