Scope of Copyright (Was RE: Collecting Smalltalk idioms)

Russell Allen russell.allen at
Wed Aug 11 01:29:54 UTC 1999

>> This forces me to ask a question that has been bothering me > for a long
>>time: What is the extent of copyright?
>> > Is
>> > new
>> 	^super new initialize
>> > copyrighted?
>> > If not, is a method that is widely used (for example > calculation of
>>the area of a rectangle or some form of > enumeration) but can be
>>reasonably implemented in only one > way copyrightable?
>Though I am an attorney, the following is not legal advice.  Legal advice
>often requires a more detailed application of law to particular facts, and
>cases can go either way depending upon the subtlest factual detail.
>Accordingly, when working through an actual legal problem, rely only on
>advice of counsel who has throughly examined your particular case and
>ignore this posting, which provides only an incomplete and cursory survey
>of the area.

Hi all,

Another problem with asking generic questions like this is that the answer
will vary depending on where you ask it.  Although copyright laws are some
of the most internationally unified areas of law (thanks to a large body of
international agreements) there are still differences between
jurisdictions; which could be the "subtlest detail" which Andrew mentioned.

For example, although the general principles of copyright are the same in
America and Australia, (we too have the idea/expression dichotomy), we
don't use the same merger test (which, after all, was set out by a US judge
in a US court).

To take another example, in some common law countries such as Australia and
Britain, a piece of code may possibly not be covered by copyright simply by
virtue of the fact that it is too small and lacks meaning in itself - as
Exxon found out when claiming that the made-up word "Exxon" was copyrighted
(once again, citation on request).

I'm not going to bother setting out what our test for merger is; because
knowing the law in Australia won't really help much :)  However, don't
assume that what is legal/illegal in America is legal/illegal in Europe etc.



>A threshold question for any infringement case is whether copying or
>derivation had occurred.  If the alllegedly infringed program was written
>without reference to the allegedly infringing program (and the defendant
>can prove that fact), there can be no claim for copyright infringement.
>The next threshold question is whether the claimed subject matter is
>protectible at all under the Copyright Act.  The scope of copyright is
>statutorily limited to expression of an idea, and not to ideas themselves.
>Unfortunately, this distinction is not as meaningful as it may first
>sound, but it motivates the first general policy issue: Merger.  Where an
>expression of an idea is so intertwined with the idea itself that it
>cannot reasonably be expressed otherwise, the expression is not protected.
>Very short snippets of code that accomplish just one thing are likely to
>merge with their ideas.  (in languages other than Perl, perhaps, where
>there are by design 1000 different ways to express the shortest piece of
>code :-))
>So, ideas, and expressions merged with ideas are not protectible, at least
>in theory.  As you can expect, the merger test is fairly strict, so most
>cases go beyond these two stages to the step of comparing two programs for
>infringement.  To do so, we need to consider a special analysis the Courts
>use when comparing two different computer software programs that "do the
>same thing" to determine if they are "substantially similar" for Copyright
>purposes.  The so-called AFC test was laid out in a landmark Second
>Circuit case, Altai v. Computer Associates, Inc. (citation available upon
>There are three stages to the AFC test: Abstraction, Filtration and
>Comparison.  Abstraction takes the two codes and tries to abstract the
>code to a level where the abstractions from each are identical.  If it
>requires "too high" a level of abstraction, then we can find either that
>there has been a merger of expression and ideas, or that the protection
>sought is purely for the idea itself.  Otherwise, having abstracted to the
>lowest level at which the programs are identical, we then proceed with
>During the Filtration stage, all non-protectible elements are removed.
>Thus, purely merged expression or non-original content in the abstraction
>are removed, as are so-called "scenes-a-faire."  A "scene-a-faire" is an
>idiom that is inherent in the media of the expression, such as a scene at
>the end of a Western with the good guy wearing a white hat riding off into
>the sunset.  In the computer context, this might include a GUI event loop
>or other idioms and coding techniques that are dictated or conventional
>for programs of the particular kind.  There are a zillion other sorts of
>things that can be filtered, but a detailed list of same is beyond the
>scope of this message.
>Finally, during Comparison, the filtered abstractions are compared to
>determine how much of the "meat" has been taken, that is, whether the
>balance are substantially similar enough to a sufficient extent to justify
>an award against the defendant.  This is typically the simplest portion of
>the analysis, and is in the end a judgment call for the fact-finder.  As
>before, there are a zillion factors to guide the analysis, well beyond the
>scope of this message, but I note that the focus is more properly on how
>much is similar, rather than how much is different.
>At the end of the day if a bunch has been taken, the defendant loses.
>Otherwise, the Plaintiff loses.  (Given the cost and energies expended in
>these matters, I'm not sure where anybody ever "wins.")
>I regret that I do not have the time now to write this more briefly and
>clearly, but I hope this was at least helpful.  As you might imagine, the
>answer to the questions posed above whether those snippets would be
>protectible and infringed appears to be: Probably not, as the meaningful
>content would likely be either unprotectible subject matter or filtered
>out during AFC as "scenes a faire," but it will always depend on the rest
>of the details.

Russell Allen

russell.allen at


More information about the Squeak-dev mailing list