home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / misc / legal / computin / 2515 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  7.2 KB

  1. Xref: sparky misc.legal.computing:2515 misc.legal:22991
  2. Newsgroups: misc.legal.computing,misc.legal
  3. Path: sparky!uunet!cs.utexas.edu!asuvax!ncar!csn!teal!bhayden
  4. From: bhayden@teal.csn.org (Bruce Hayden)
  5. Subject: Re: Out of print material and copyright law
  6. Message-ID: <bhayden.727595786@teal>
  7. Sender: news@csn.org (news)
  8. Nntp-Posting-Host: teal.csn.org
  9. Organization: Colorado SuperNet, Inc.
  10. 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>
  11. Date: Thu, 21 Jan 1993 05:56:26 GMT
  12. Lines: 138
  13.  
  14. leonard@qiclab.scn.rain.com (Leonard Erickson) writes:
  15.  
  16. >>I think that blanket statement is extreme. What you have to look at
  17. >>is the level of detail in the algorithm, not at whether there is
  18. >>an algorithm being copied. 
  19.  
  20. >Let me re-phrase that. The *program* was copyrighted, not the
  21. >algorithm. And at the level of detail that is going to be copied,
  22. >you'd have a hard time proving that it was derived from the original!
  23.  
  24. Well, if at some level of abstration, the two programs are not
  25. substantially similar, then you probably do not have copying.
  26. But what you are going to be looking at is not which registers
  27. get loaded in which order (though if you had copying there, the
  28. case would be easy). Instead, the plaintiff will invariably try
  29. to substantial similarity or actual copying of some level of
  30. abstration. 
  31.  
  32. >>I believe that it is not unconceivable that you could essentially
  33. >>translate one assembler into another and have infringing copying.
  34. >>If (as it appears here) you have access, you use the substantial
  35. >>similarity test. Remember, Whalen (despite all of its faults)
  36. >>was a translation from one language to another. This is little
  37. >>different from translating from English to French, which is
  38. >>clearly considered infringement.
  39.  
  40. >You *could* do such a translation. I've done so in porting from one 
  41. >processor to another. The only problem is that the translated code
  42. >*won't work*. The new machine rarely handles *any* hardware function
  43. >the same. Different rules for video addressing, different port addresses,
  44. >different basic I/O setups. So unless the program is *very* simple,
  45. >you are actually ahead if you take a *flow chart* (or similarly
  46. >high level representation) and work from that. 
  47.  
  48. Well, define what level of flowchart you are talkling about. Just 
  49. using a flowchart won't get you off the hook, since
  50. flowcharts are also literary works. Technically, if you write a
  51. program based on a flowchart, the program is a derivitive work.
  52. Actually, if you can find the intermediate flowchart, and can
  53. prove that the original flowchart was based on the original 
  54. program - you may not need to prove substantial similarity.
  55.  
  56. What you have to look at is whether the various modules end up being
  57. implemented in the same order. You have to look at both the static
  58. and the dynamic behaviour (see Randy Davis testimony in CA v. Altai).
  59. Remember - module order, and function in a program is potentially
  60. protectable expression. 
  61.  
  62. >>>Higher level languages are more portable, but even there, it's a tossup
  63. >>>as to whether you are porting *code* or porting *algorithms*. 
  64.  
  65. >>Are you saying then that you can port algorithms, and not code?
  66. >>I think the question is the level of detail (or abstration) that
  67. >>you port.
  68.  
  69. >I'm saying that the copyright for "Space Invaders" covers the code,
  70. >not the "rows of thingie marching down the screen and getting zapped
  71. >from behine shields that can get blasted away". 
  72.  
  73. Agreed, the literary work copyright doesn't cover the way that the 
  74. things get zapped (unless you accept look and feel). But - an 
  75. audio-visual C/R might. So - as long as you design the new program
  76. from the external operation of the program, you probably won't 
  77. infringe the literary work copyright (unless you are being sued 
  78. by Lotus). The story may change if you get the programs to do the
  79. same thing by copying some of the logic. 
  80.  
  81. >And that anything *besides the "thingies" description that can be 
  82. >found in a program is likely to either be not movable to another
  83. >assembler (or dialect in the case of a high level language), or if
  84. >portable is likely to not be something sufficiently "original" to
  85. >be covered. The exceptions are likely to be alogorithms, not code,
  86. >and as such only the *expression* of the alogirthm is covered, not
  87. >the algorithm itself. 
  88.  
  89. See below. Just because you are moving algorithms, you are not off
  90. the hook. First, you have to make sure that you are not copying
  91. any of the expression in copying the algorithms. And this is not
  92. necessarily that eassy. Often you are predisposed to a certain
  93. expression of one because that is the only way you have ever seen it.
  94.  
  95. What you have to keep in mind is that the arrangement of algorithms,
  96. and modules is potentially protectable expression. Likewise, just
  97. because something is not sufficiently original in itself, the way
  98. it is included in the program again may be protectable.
  99.  
  100. As an analogy, most literary works covered under the U.S. copyright
  101. act is written in English. The individual words are almost entirely
  102. in the public domain. But the arrangement of the words can easily
  103. result in protectable expression, despite the fact that the lower
  104. level the protectable expression is based upon is in the P.D.
  105.  
  106. >For example, if I copyright a program, and in it I use a novel
  107. >new algorithm (say a new sort), then unless the program's primary use
  108. >is for sorting things, then if I write another program using that
  109. >sort, it *isn't* going to qualify as a derivative work because of
  110. >that sort!
  111.  
  112. But you are talking about a single algorithm in isolation. That is
  113. not what you usually have. What you usually find is that the 
  114. arrangement of algorigthms is critical. And that is expression
  115. .
  116. >>>Basicly, it's the old argument about whether or not you can copyright a
  117. >>>*plot*. 
  118.  
  119. >>Well - doesn't that depend on the level of detail in the plot. 
  120. >>In other words - Learned Hand's levels of abstrations.
  121. >>At one level, you clearly have protected expression.
  122. >>At a much higher level you don't. So you have to define
  123. >>the level of abstration or detail before you can determine
  124. >>whether or not the plot is protected.
  125.  
  126. >Well, I'd say that a "psuedocode" description, such that it could
  127. >be implemented on any platform in any language (subject to things 
  128. >like not being able to code Empire on a 1k machine, or fancy 
  129. >graphics on a character only display) is a sufficiently "high level"
  130. >that it is *not* covered by a copyright of a program that matches
  131. >it. 
  132.  
  133. >So if I can reduce a copyrighted program to such a description, 
  134. >without the copyrighted *source* and without running a disassembler
  135. >on it, then I'm not infringing. And the *lack* of suits over games
  136. >produced in such a manner seems to uphold this.
  137.  
  138. >I could copyright the psuedocode, but that wouldn't affect the game.
  139. >And it probably wouldn't stop folks from writing programs that
  140. >matched my psuedocode as long as they hadn't used it to make them.
  141. >(in essence, we are talking about the standard "clean room team"
  142. >method of cloning software, only a level *higher* in abstraction)
  143.  
  144. Agreed - it is generally accepted in C/R law that if two people
  145. come up with the same expression without copying, then there is
  146. no infringement. This is exactly the opposite of patent law.
  147.  
  148. Bruce E. Hayden
  149. (303) 758-8400
  150. bhayden@csn.org
  151.  
  152.