Re: RES: What makes software copyrightable anyway?

["Michael K. Edwards" <m.k.edwards@gmail.com>]

This one's long because it contains excerpts from the cases Raul cited
along with (hopefully sufficiently polite) rebuttals of his
interpretations.

On 5/21/05, Raul Miller <moth.debian@gmail.com> wrote:
> On 5/21/05, Michael K. Edwards <m.k.edwards@gmail.com> wrote:
> > Lotus, actually, has been heard in court.  Remember Lotus v. Borland?
> > The macro language in 1-2-3 was held to be uncopyrightable, as was the
> > menu interface with which it was fairly closely interlocked.  (Held at
> > appellate level, affirmed by an evenly divided Court, so no opinion at
> > Supreme Court level.)  A large fraction of the discussion in the
> > Supreme Court oral argument was about users' existing spreadsheets
> > that used the 1-2-3 macro language -- otherwise known as its external
> > API -- and how Lotus ought not to permitted to leverage the copyright
> > monopoly in order to lock those users into its implementation of that
> > API, whether or not they originated it.  If it were correct to call
> > all of those spreadsheets "derivative works" of 1-2-3, then they
> > certainly would have that leverage.
> 
> The court decision isn't really phrased that way.
> 
> As I read it, it's saying "unoriginal elements can't be copyrighted", and
> that the system in question was unoriginal.

That's certainly not how I read it.  Here's the quote that best
summarizes the logic behind the appeals court's ruling:

<quote>
We also note that in most contexts, there is no need to "build" upon
other people's expression, for the ideas conveyed by that expression
can be conveyed by someone else without copying the first author's
expression.  In the context of methods of operation, however,
"building" requires the use of the precise method of operation already
employed; otherwise, "building" would require dismantling, too. 
Original developers are not the only people entitled to build on the
methods of operation they create; anyone can.  Thus, Borland may build
on the method of operation that Lotus designed and may use the Lotus
menu command hierarchy in doing so.
</quote>

See also other quotes from this decision below.  (The oral arguments
at Supreme Court level are interesting but not valid precedents; and
in any case, I can't see where you got that reading from either
source.)

> http://caselaw.lp.findlaw.com/cgi-bin/getcase.pl?court=11th&navby=case&no=945262opa
> 
> This doesn't say that all computer languages are unoriginal -- though
> clearly it does say that some of them are.

What, exactly, did you have in mind in this citation to MiTek v. ArcE,
in which the appeals court affirmed the district court's use of
various standards to reject MiTek's claims of copyright infringement? 
Since you don't quote any text from this decision, I'll give it a
shot:

<quote>
Unlike the Lotus court, we need not decide today whether a main menu
and submenu command tree structure is uncopyrightable as a matter of
law.  We agree with the conclusion reached by the district court that
the ACES menu and submenu command tree structure is uncopyrightable
under 17 U.S.C. § 102(b).
</quote>

What that means is that the MiTek court, in affirming the district
court's decision, did not have to go as far out on a limb as the Lotus
court did in reversing the lower court.  Remember that under common
law (and especially in the US, per the Seventh Amendment) an appeals
court cannot re-examine a question of fact settled by a lower court. 
Thus, in order to reverse, the Lotus court had to declare that the
district court had erred as a matter of law -- that, not just under
the factual circumstances of Lotus v. Borland but under all
circumstances, a menu command hierarchy like Lotus 1-2-3's is
uncopyrightable.  This is exactly what the appeals court decided,
based not least on its relationship to the 1-2-3 macro language.

<quote>
That the Lotus menu command hierarchy is a "method of operation"
becomes clearer when one considers program compatibility. Under
Lotus's theory, if a user uses several different programs, he or she
must learn how to perform the same operation in a different way for
each program used. For example, if the user wanted the computer to
print material, then the user would have to learn not just one method
of operating the computer such that it prints, but many different
methods. We find this absurd. The fact that there may be many
different ways to operate a computer program, or even many different
ways to operate a computer program using a set of hierarchically
arranged command terms, does not make the actual method of operation
chosen copyrightable; it still functions as a method for operating the
computer and as such is uncopyrightable.

Consider also that users employ the Lotus menu command hierarchy in
writing macros. Under the district court's holding, if the user wrote
a macro to shorten the time needed to perform a certain operation in
Lotus 1-2-3, the user would be unable to use that macro to shorten the
time needed to perform that same operation in another program. Rather,
the user would have to rewrite his or her macro using that other
program's menu command hierarchy. This is despite the fact that the
macro is clearly the user's own work product. We think that forcing
the user to cause the computer to perform the same operation in a
different way ignores Congress's direction in § 102(b) that "methods
of operation" are not copyrightable. That programs can offer users the
ability to write macros in many different ways does not change the
fact that, once written, the macro allows the user to perform an
operation automatically. As the Lotus menu command hierarchy serves as
the basis for Lotus 1-2-3 macros, the Lotus menu command hierarchy is
a "method of operation."
</quote>

> > You can't just pull some common sense usage of "based on" out of a hat
> > and say that's what consitutes a derivative work.  The vast
> > preponderance of case law is against you here, based on the cases I've
> > read (many of which I've cited).  Have you any counterexamples to
> > offer in which a program was held to be a derivative work of the
> > language in which it was written, an API which it called, or an engine
> > on which it ran -- except via a "mise en scene" doctrine with regard
> > to a story-type work?
> 
> Kohus vs. JVM is a case where "functional means uncopyrightable" was
> insufficient, and where it's up to district court to decide on the
> relevance of expert testimony.
> 
> http://caselaw.lp.findlaw.com/scripts/getcase.pl?navby=search&case=/data2/circs/6th/03a0150p.html

I think you misinterpret this case, and then attempt to apply it
incorrectly to an argument I made elsewhere.  I'll deal with the
latter first; a court of fact is permitted to rely upon expert
testimony with respect to points of fact but not with respect to
points of law.  The question of whether "mere aggregation" should be
construed with reference to IP law usage (as it seems clear to me it
should) or by recourse to a computer industry expert witness is, I
believe, a point of law, and hence something on which an appeals court
is free to reverse a district court if they get it wrong.  On the
other hand, if the appeals court concludes that it was not
unreasonable as a matter of law for the court or fact to consult an
expert witness on that point, then it cannot change the conclusion the
court reached based on that witness's testimony.

As for "functional means uncopyrightable" being insufficient, you will
observe that this decision makes no reference to "methods of
operation", as indeed it would have no occasion to -- the copyrighted
works under discussion are drawings of safety latches.  The court
explains how to apply the "doctrine of merger" (of idea and
expression) to decide which parts of the expression are inseparable
from the ideas contained.  This paragraph concludes:  "In the present
case expert testimony will likely be required to establish what
elements, if any, are necessary to the function of any latch designed
for the upper arm of a collapsible playyard."

I agree that, if it weren't for the "methods of operation" test,
computer languages would be copyrightable.  This test is not mentioned
in Kohus v. Mariol, but that doesn't mean that the Sixth Circuit
doesn't apply it when it is relevant; after all, it's in 17 USC
102(b).  As used in modern jurisprudence, this test does not concern
itself with whether other forms of expression were available to the
original author, but rather with the advantage that accrues to the
public when later authors build interoperable systems.  Indeed, the
Lotus court sought authority from the very Supreme Court ruling that
Congress drew upon in writing that clause into the copyright statute:

<quote>
Our holding that ``methods of operation'' are not limited to mere
abstractions is bolstered by Baker v. Selden. In Baker, the Supreme
Court explained that

"the teachings of science and the rules and methods of useful art have
their final end in application and use; and this application and use
are what the public derive from the publication of a book which
teaches them. . . . The description of the art in a book, though
entitled to the benefit of copyright, lays no foundation for an
exclusive claim to the art itself. The object of the one is
explanation; the object of the other is use. The former may be secured
by copyright. The latter can only be secured, if it can be secured at
all, by letters-patent."

Baker v. Selden, 101 U.S. at 104-05. Lotus wrote its menu command
hierarchy so that people could learn it and use it. Accordingly, it
falls squarely within the prohibition on copyright protection
established in Baker v. Selden and codified by Congress in § 102(b).
</quote>

> DSC v Pulse seems to indicate that when there are significant limitations
> encumbering some work that 17 USC 117 and 17 USC 109 might not
> apply.  (Granted: whether this would be applicable to the GPL has
> not yet been granted -- but it could be argued that possession of
> a copy of a GPLed program does not constitute ownership.  Sections
> 4 and 6 of the GPL are examples of clauses which would reinforce
> this point of view.)  (Granted, libssl does not impose this kind of
> restriction, and thus works based on it are not protected in this
> fashion.)
> 
> http://caselaw.lp.findlaw.com/scripts/printer_friendly.pl?page=fed/981024.html

First off, I think you misunderstand the court's references to 17 USC
109.  The opinion cites section 109 as evidence of what constitutes
"ownership" of a copy of a copyrighted work, and compares the rights
of an "owner" against those granted under the plaintiff DSC's
contracts with its RBOC customers:

<quote>
Each of the DSC-RBOC agreements limits the contracting RBOC's right to
transfer copies of the POTS-DI software or to disclose the details of
the software to third parties. For example, the DSC-Ameritech
agreement provides that Ameritech shall "not provide, disclose or make
the Software or any portions or aspects thereof available to any
person except its employees on a `need to know' basis without the
prior written consent of [DSC] . . . ." Such a restriction is plainly
at odds with the section 109 right to transfer owned copies of
software to third parties. The agreements also prohibit the RBOCs from
using the software on hardware other than that provided by DSC. If the
RBOCs were "owners of copies" of the software, section 117 would allow
them to use the software on any hardware, regardless of origin.
Because the DSC-RBOC agreements substantially limit the rights of the
RBOCs compared to the rights they would enjoy as "owners of copies" of
the POTS-DI software under the Copyright Act, the contents of the
agreements support the characterization of the RBOCs as non-owners of
the copies of the POTS-DI software.
</quote>

The GPL goes out of its way to disclaim any limitations on the use of
the Program, focusing exclusively on rights to copy, modify, etc.
under copyright law.  The rights granted to a licensee are also amply
broad to encompass the transfer of owned copies to third parties. 
Hence the analytical approach taken by the Federal Circuit in DSC v.
Pulse seems to me to be overwhelmingly likely to conclude that GPL
licensees are "owners of copies" for the purposes of 17 USC 117.

> ADA vs. Delta Dental seems to indicate that a work doesn't have to be
> very original to receive protection, even (perhaps especially) in the
> case of computer programs
> 
> http://caselaw.lp.findlaw.com/scripts/printer_friendly.pl?page=7th/964140.html

I haven't troubled to look closely at this case because I have no
difficulty with your assertion.  Unless, of course, you are trying to
say that there is adequate creative expression in the "selection and
arrangement" of compiled copies of Quagga, Net-SNMP, and libssl to
form a collective work.  ADA v. Delta Dental (addressing the literal
copying, and unauthorized modification, of an entire taxonomy of
dental procedures) doesn't support that conclusion.  But while I'm at
it, I might as well point out that it supports my arguments that APIs
are uncopyrightable:

<quote>
So far as the ADA is concerned, any dentist, any insurer, anyone at
all, may devise and use forms into which the Code's descriptions may
be entered. The ADA encourages this use; standardization of language
promotes interchange among professionals. (The fact that Delta used
most of the Code but made modifications is the reason ADA objects, for
variations salted through a convention impede communication.) Section
102(b) precludes the ADA from suing, for copyright infringement, a
dentist whose office files record treatments using the Code's
nomenclature. No field of practice has been or can be monopolized,
given this constraint. Section 102(b) permits Delta Dental to
disseminate forms inviting dentists to use the ADA's Code when
submitting bills to insurers. But it does not permit Delta to copy the
Code itself, or make and distribute a derivative work based on the
Code, any more than Baker could copy Selden's book.

Whether there are other obstacles to the relief the ADA seeks is a
subject best left to the district court in the first instance. The
judgment is vacated, and the case is remanded for further proceedings
consistent with this opinion.
</quote>

> Is that enough to entertain the possibility that a computer programming
> language might be subject to copyright protection, and that this might
> be a significant issue in the context of the GPL?

Quite the opposite -- the implementation is copyrightable, but the
language is not, if it is offered for the purpose of use by third
parties on terms that amount more or less to publication.  If it's
entirely internal to some other program and can't be accessed without
creating (without authorization) a derivative work, or if it's
unpublished and only offered under a contract which preserves its
trade secret status, that's another story.  But I think it's clear
that, under US law, even taking someone else's GPL work and exposing
functionality as an API or an application language -- as long as the
result is genuinely published and attracts third-party users --
produces an uncopyrightable method of operation that can legitimately
be used by non-GPL code.  IANAL, TINLA, etc.

> > I am not feeling particularly bogged down, myself.  The truth is in
> > the details, along with the devil; and the law, especially in
> > common-law countries, is composed almost entirely of details.  In this
> > discussion, the differences between breach of contract and copyright
> > infringement, between "scope of license" and the complete agreement,
> > and especially between derivative and collective works matter a great
> > deal.  They are, in fact, the "big important concepts".
> 
> Ok... does that mean we need to go into issues like the use of civil
> law instead of common law (given that you've raised common law
> as important at some point along the line)?

Yes, generally we do, if we're trying to reach conclusions that are
globally valid.  That's what happens when you leave the "choice of
law" clause out of an offer of contract that is exercised
internationally.  Perhaps it would be nice if the Berne Convention
created a basis for internationally uniform non-contract copyright
licenses; but it doesn't.

> > I hope you'll read Progress Software v. MySQL again and agree that the
> > crucial fact is that the claims with respect to the trademark license
> > and with respect to the GPL were considered quite separately, and
> > injunction granted on the former and denied on the latter.  No
> > consideration of any feature of the NuSphere/MySQL relationship, other
> > than the GPL and the handling of source code and binaries, entered
> > into the two paragraphs in which the GPL claims were considered and
> > rejected as grounds for injunction.
> 
> I agree that copyright was treated separately from trademark.
> 
> I do not agree that this means that that commercial agreement
> could not be read as granting copyright license.

On what basis?  What grounds do you have for believing that the judge
was not talking about the GPL when she said GPL?

> > It seems clear to me from the judge's opinion that the "remarketing
> > rights" your commentator mentions were focused exclusively on
> > trademark issues, and the copyright license necessary to make copies
> > of the software for distribution was offered solely through the GPL.
> > (Note, by the way, that both parties had issued press releases at the
> > time the remarketing agreement was originally inked, in which they
> > spoke of Progress / Nusphere as having "funded" the relicensing of
> > MySQL under the GPL, in lieu of its previous licensing terms.)  We'll
> > see for certain once someone gets hold of the full docket, if that's
> > still possible.
> 
> As you've been pointing out, there's two issues here: scope of
> license and whether the associated contract is in breach.
> 
> Anyways, I'm of the opinion that Eben Moglen was correct that
> the software was dual licensed, and that the judge was aware of
> this when constructing her opinion.  If you disagree, I'd like to
> ask you provide something at least as compelling as Moglen's
> affidavit which indicates that this could not have been the
> case.

Let's quote those two paragraphs from Judge Saris's opinion again:

<court-opinion>
With respect to the General Public License ("GPL"), MySQL has not
demonstrated a substantial likelihood of success on the merits or
irreparable harm. Affidavits submitted by the parties' experts raise a
factual dispute concerning whether the Gemini program is a derivative
or an independent and separate work under GPL P 2. After hearing,
MySQL seems to have the better argument here, but the matter is one of
fair dispute. Moreover, I am not persuaded based on this record that
the release of the Gemini source code in July 2001 didn't cure the
breach.

In any event, even if MySQL has shown a likelihood of success on these
points, it has not demonstrated that it will suffer any irreparable
harm during the pendency of the suit, particularly in light of the
sworn statement that all source code for Gemini has been disclosed and
the stipulation, given by [NuSphere parent] Progress during the
hearing, that the end use license for commercial users will be
withdrawn. Finally, because the product line using MySQL is a
significant portion of NuSphere's business, Progress has demonstrated
that the balance of harms tips in its favor regarding the use of the
MySQL program under the GPL.
</court-opinion>

Cheers,
- Michael