home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky misc.legal.computing:2515 misc.legal:22991
- Newsgroups: misc.legal.computing,misc.legal
- Path: sparky!uunet!cs.utexas.edu!asuvax!ncar!csn!teal!bhayden
- From: bhayden@teal.csn.org (Bruce Hayden)
- Subject: Re: Out of print material and copyright law
- Message-ID: <bhayden.727595786@teal>
- Sender: news@csn.org (news)
- Nntp-Posting-Host: teal.csn.org
- Organization: Colorado SuperNet, Inc.
- References: <1ikgsaINNnbu@shelley.u.washington.edu> <2dOp02HI31EB01@JUTS.ccc.amdahl.com> <1993Jan11.065525.17032@qiclab.scn.rain.com> <bhayden.726826461@teal> <1993Jan20.111319.21520@qiclab.scn.rain.com>
- Date: Thu, 21 Jan 1993 05:56:26 GMT
- Lines: 138
-
- 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
-
-