On 8/28/98, Patrice A. Lyons <plyons/0003432266[_at_]mcimail.com> wrote:
>
> Appreciate Rod's reply from a computer science point of view. It has
> also been my understanding that there is no principled distinction in
> practice between program and so-called "data." The U.S. copyright law
> has proven flexible in this regard. I recall in this context the
> Copyright Office regulations re computerized typeface designs, as
> amended to reflect advances in computer program technology.
Patrice is correct that there is is no principled distinction between program and data. One of the dominant styles of programming is "data driven programming" -- in which all manner of aspects of the functioning of the program are parameterized and stored externally to the program. Depending on the parameters, a program might display text in French or English, save data to a disk drive or output it to a printer, hyphenate words using one or another algorithm, accept suspicious-looking data as valid or not, etc. It is not just the display info that is stored in the data -- much of the logic of the program can be stored that way too. The decision rules in an expert system can be externalized and applied on a case by case basis by reading data from tables. Or the rules can be coded into the system in a huge logic tree. Is one case "data" and the other case "code"?
One example in which many software architects will lay out an intensely data driven structure for a given program is the situation in which the underlying logic will change depending on circumstances external to the program. For example, if the program would function differently in a French version than an English than a German than a Japanese one, then all of the opportunities for variation are dealt with in data files that can be replaced without having to recompile and relink the program. Similarly, to the extent that different computers that run the program will be significantly differently configured, there is an advantage to encapsulating all of the device I/O and making it easy for the program to recognize and cope with new devices as they come along. Even the selection of the algorithm of choice to do basic mathematical functions might be externalized, with decision rules saved in tables, depending on the underlying precision of the processor chip found on this computer.
This e-mail communication should not be interpreted as legal advice or a legal opinion. The transmission of this e-mail communication does not create an attorney-client relationship between me and you. Do not act or rely upon law-related information in this communication without seeking the advice of an attorney. Finally, nothing in this message should be interpreted as a "digital signature" or "electronic signature" that can create binding commercial transactions. Received on Sat Aug 29 1998 - 21:32:24 GMT
This archive was generated by hypermail 2.2.0 : Mon Mar 26 2007 - 00:35:31 GMT