On 5/22/05, Raul Miller <[EMAIL PROTECTED]> wrote: > On 5/22/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote: > > This one's long because it contains excerpts from the cases Raul cited > > along with (hopefully sufficiently polite) rebuttals of his > > interpretations. > > Thanks. > > Also, I should have acknowledged that I'd forgotten about the Louts > v Bourland case until you reminded me. I think my tendency to not > acknowledge points like that is one of my more annoying traits. > Sorry about that.
No worries. I didn't actually make the connection consciously myself at the time that I picked Perl and 1-2-3 as examples. But perhaps we should regroup and identify the things we agree on (see separate thread) and the extent to which other gaps have narrowed. > > On 5/21/05, Raul Miller <[EMAIL PROTECTED]> wrote: > > > 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> > > Ok. > > Allow me to note that in this case, the implementation underneath > that API was entirely replaced. In other words, the API was not > evidence of anything other than itself. That's certainly true of Lotus v. Borland. However, if you look at the cases from video game space, you will see lots of other permutations: game developers using fair means or foul to defeat console makers' efforts to impose onerous contract terms (Sega v. Accolade and Atari v. Nintendo), emulator developers leveraging the availability of games authored for an existing console (Sony v. Connectix and Sony v. Bleem), and one publisher distributing add-ons for another's game (Micro Star v. FormGen). Read together with Lotus v. Borland, MiTek v. ArcE, and Lexmark v. Static Control, I think these decisions add up to a standard by which interoperability requirements trump copyright on APIs. Not entirely without limits; see Atari v. Nintendo, in which Nintendo devised a handshake mechanism that Atari couldn't defeat without going way over the line. But it's hard for me to see how a U. S. federal judge whose attention had been called to this weight of case law could rule that, say, the Net-SNMP source code copies a meaningful amount of copyrightable expression from OpenSSL. > The court didn't make a point of that here, but I think it is > significant. More generally, this ties back to the concept > of "thin" derivative works vs "thick" works. (Which I think > is an important concept when talking about the scope of > coverage by a copyright.) I'm unfamiliar with this concept. What makes a derivative work "thick" or "thin"? And let me remind you that I think, say, OpenSSL itself remains copyrighted and can only be distributed in accordance with its licensing conditions. I am only contending that, say, neither the Net-SNMP source code nor the libsnmp5 shared library infringes the copyright on OpenSSL. > > 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? > > I just wanted a case that covered some of the basics: This was > just to reiterate that it's up to the district court to determine the > facts of the case (such as which elements should be eliminated > from consideration, because they're determined by efficiency > considerations, and which should remain, because they're > creative elements). But if the district court errs as a matter of law, such as by failing to correctly understand and apply the "methods of operation" distinction, then its decision can and will be vacated on appeal. > The "mere aggregation" clause (on the same storage volume but > not a part of the Program or a work based on the Program) seems > to me to contain both elements of IP law and elements of technology. Let's agree that it's a subtle point, and that there's no predicting exactly how a district court would go about construing "mere aggregation", let alone what conclusion it would reach. It's not even clear to me whether an appeals court would go so far as to declare the district court's approach to construing that phrase incorrect as a matter of law even if it was unimpressed by the result. > I certainly wouldn't want to rule out using an expert witness to > declare that downloadable firmware contained in the linux kernel > is simply stored near the kernel and isn't executed as a part of > the program. The court could construe a definition of the phrase "mere aggregation" under IP law and still rely on the assistance of expert witnesses to determine whether that definition fit the facts of the case. That's actually what I would think a judge would be most likely to do, rather than risk reversal on appeal on the grounds that a question of law (standards of contract construction) was improperly delegated by the court. > > 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." > > Certainly. Though it's also worth noting that every case is different, > and a case which includes the original work behind the API is probably > going to have some differences from a work where the only element in > consideration is the API itself. There will be some differences; and now that you mention it, this inspires me to another argument whereby dynamic linking is more likely to survive scrutiny than static linking. Note that a court is likely to decide that releasing a project under any "open source" license has two primary benefits for the copyright holder: 1) access to improvements contributed by licensees, and 2) enhanced personal or corporate reputation. The Planetary Motion v. Techplosion appeals court used exactly this approach to decide that GPL release was "use in commerce". The licensor's odds of reaping these benefits when his or her work is leveraged by another program are much higher if it is conspicuously an independent component available for use from still other programs, and if it's easy to apply a bug fix to all uses of that component in the system. So unless there is a pretty good technical reason for static linking, dynamic linking should be the rule, as part of the evidence that the publisher of the combined work is sincere about securing the benefits of open source release on the component author's behalf. Which is ethically and technically the right answer most of the time anyway. One might be tempted to argue that an author who releases under the GPL is trying to obtain a third benefit: obtaining the release of other authors' work under the GPL. I would expect a US court faced with this argument to rule that it is no more compelling than, say, Sega's interest in dictating the terms on which third-party developers could create and market games for use on Sega's console. US courts don't seem to see that as a legitimate use of the copyright monopoly. Changing their minds about that would, I think, take an act of Congress. [snip some topics on which I have nothing new to say] > > On what basis? What grounds do you have for believing that the judge > > was not talking about the GPL when she said GPL? > > Ok, in the two paragraphs you're referring to, judge Saris makes it > pretty clear that MySQL did not present a convincing argument. > MySQL did not present an argument showing irreparable harm. > Also, there's the question of likelihood of success. > > I believe that the dual-licensing issue is relevant to the likelihood > of success. The contractual agreement between MySQL and > Progress specified that Progress could do some things with MySQL, > this can be seen as a trademark grant and a copyright grant. > > It doesn't seem right that you should be claiming that the GPL should > be considered on a contractual basis and then that a signed contract > between the two parties should be considered irrelevant to that > contractual basis. > > This fundamental inconsistency in your argument bothers me. Perhaps you misunderstand. Both parties acknowledged the existence of two contracts, namely the GPL and the "interim agreement". MySQL appears to have claimed breach of both contracts. The judge ruled for MySQL on breach of the "interim agreement", saying that "Progress violated Paragraph 6 of that agreement by using the MySQL trademark after the termination and by using an unauthorized combination trademark". Her comments on that agreement, and those of the commentator you cited, suggest that it was focused exclusively on remarketing rights and trademark license. The judge then turned to the breach of contract claim with respect to the GPL, analyzed it as we have discussed, and denied it. There is no indication of an overlap in the scope of the two agreements or of the consideration of any copyright license alternate to the GPL. The paragraphs I quoted speak exclusively of the GPL in determining what license Progress did and didn't have to modify and make copies of mysqld. If you think there is a shadow of an indication otherwise in the opinion, please point out exactly where it is in the text. > Note that I'm not at all addressing the irreparable harm issue, here. > I think it should be possible to demonstrate irreparable harm in > some cases, but I'm not sure how that would be possible in a > dual licensing case. [The fundamental arguments I'm thinking of > would be about the value and talent of the developer community > and about how splitting up that community lessens its value. But > when dual licensing is already present that harm seems to already > be present, at the outset.] "Dual licensing" was not at issue in Progress Software v. MySQL. And as for the benefits of having a single developer community, that's an argument that any monopolist can make. Outside the sphere of GPL enthusiasts, I think you will find that most people (and especially most judges) find an ostensibly altruistic monopolist every bit as distasteful as a profit-seeking monopolist. Cheers, - Michael
