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 <[EMAIL PROTECTED]> wrote: > On 5/21/05, Michael K. Edwards <[EMAIL PROTECTED]> 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
