Re: RES: What makes software copyrightable anyway?
On 5/22/05, Raul Miller <moth.debian@gmail.com> wrote:
> On 5/22/05, Michael K. Edwards <m.k.edwards@gmail.com> 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 <moth.debian@gmail.com> 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
Reply to: