From: bhayden@teal.csn.org (Bruce Hayden)
Subject: Re: Out of print material and copyright law
Organization: Colorado SuperNet, Inc.
Date: Thu, 21 Jan 1993 05:56:26 GMT

leonard@qiclab.scn.rain.com (Leonard Erickson) writes:

>>I think that blanket statement is extreme. What you have to look at
>>is the level of detail in the algorithm, not at whether there is
>>an algorithm being copied. 

>Let me re-phrase that. The *program* was copyrighted, not the
>algorithm. And at the level of detail that is going to be copied,
>you'd have a hard time proving that it was derived from the original!

Well, if at some level of abstration, the two programs are not
substantially similar, then you probably do not have copying.
But what you are going to be looking at is not which registers
get loaded in which order (though if you had copying there, the
case would be easy). Instead, the plaintiff will invariably try
to substantial similarity or actual copying of some level of
abstration. 

>>I believe that it is not unconceivable that you could essentially
>>translate one assembler into another and have infringing copying.
>>If (as it appears here) you have access, you use the substantial
>>similarity test. Remember, Whalen (despite all of its faults)
>>was a translation from one language to another. This is little
>>different from translating from English to French, which is
>>clearly considered infringement.

>You *could* do such a translation. I've done so in porting from one 
>processor to another. The only problem is that the translated code
>*won't work*. The new machine rarely handles *any* hardware function
>the same. Different rules for video addressing, different port addresses,
>different basic I/O setups. So unless the program is *very* simple,
>you are actually ahead if you take a *flow chart* (or similarly
>high level representation) and work from that. 

Well, define what level of flowchart you are talkling about. Just 
using a flowchart won't get you off the hook, since
flowcharts are also literary works. Technically, if you write a
program based on a flowchart, the program is a derivitive work.
Actually, if you can find the intermediate flowchart, and can
prove that the original flowchart was based on the original 
program - you may not need to prove substantial similarity.

What you have to look at is whether the various modules end up being
implemented in the same order. You have to look at both the static
and the dynamic behaviour (see Randy Davis testimony in CA v. Altai).
Remember - module order, and function in a program is potentially
protectable expression. 

>>>Higher level languages are more portable, but even there, it's a tossup
>>>as to whether you are porting *code* or porting *algorithms*. 

>>Are you saying then that you can port algorithms, and not code?
>>I think the question is the level of detail (or abstration) that
>>you port.

>I'm saying that the copyright for "Space Invaders" covers the code,
>not the "rows of thingie marching down the screen and getting zapped
>from behine shields that can get blasted away". 

Agreed, the literary work copyright doesn't cover the way that the 
things get zapped (unless you accept look and feel). But - an 
audio-visual C/R might. So - as long as you design the new program
from the external operation of the program, you probably won't 
infringe the literary work copyright (unless you are being sued 
by Lotus). The story may change if you get the programs to do the
same thing by copying some of the logic. 

>And that anything *besides the "thingies" description that can be 
>found in a program is likely to either be not movable to another
>assembler (or dialect in the case of a high level language), or if
>portable is likely to not be something sufficiently "original" to
>be covered. The exceptions are likely to be alogorithms, not code,
>and as such only the *expression* of the alogirthm is covered, not
>the algorithm itself. 

See below. Just because you are moving algorithms, you are not off
the hook. First, you have to make sure that you are not copying
any of the expression in copying the algorithms. And this is not
necessarily that eassy. Often you are predisposed to a certain
expression of one because that is the only way you have ever seen it.

What you have to keep in mind is that the arrangement of algorithms,
and modules is potentially protectable expression. Likewise, just
because something is not sufficiently original in itself, the way
it is included in the program again may be protectable.

As an analogy, most literary works covered under the U.S. copyright
act is written in English. The individual words are almost entirely
in the public domain. But the arrangement of the words can easily
result in protectable expression, despite the fact that the lower
level the protectable expression is based upon is in the P.D.

>For example, if I copyright a program, and in it I use a novel
>new algorithm (say a new sort), then unless the program's primary use
>is for sorting things, then if I write another program using that
>sort, it *isn't* going to qualify as a derivative work because of
>that sort!

But you are talking about a single algorithm in isolation. That is
not what you usually have. What you usually find is that the 
arrangement of algorigthms is critical. And that is expression
.
>>>Basicly, it's the old argument about whether or not you can copyright a
>>>*plot*. 

>>Well - doesn't that depend on the level of detail in the plot. 
>>In other words - Learned Hand's levels of abstrations.
>>At one level, you clearly have protected expression.
>>At a much higher level you don't. So you have to define
>>the level of abstration or detail before you can determine
>>whether or not the plot is protected.

>Well, I'd say that a "psuedocode" description, such that it could
>be implemented on any platform in any language (subject to things 
>like not being able to code Empire on a 1k machine, or fancy 
>graphics on a character only display) is a sufficiently "high level"
>that it is *not* covered by a copyright of a program that matches
>it. 

>So if I can reduce a copyrighted program to such a description, 
>without the copyrighted *source* and without running a disassembler
>on it, then I'm not infringing. And the *lack* of suits over games
>produced in such a manner seems to uphold this.

>I could copyright the psuedocode, but that wouldn't affect the game.
>And it probably wouldn't stop folks from writing programs that
>matched my psuedocode as long as they hadn't used it to make them.
>(in essence, we are talking about the standard "clean room team"
>method of cloning software, only a level *higher* in abstraction)

Agreed - it is generally accepted in C/R law that if two people
come up with the same expression without copying, then there is
no infringement. This is exactly the opposite of patent law.

Bruce E. Hayden
(303) 758-8400
bhayden@csn.org

Newsgroups: misc.legal.computing