Re: RES: What makes software copyrightable anyway?
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.
> 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.
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.)
> > 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?
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).
> > 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.
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.
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.
> 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.
> > 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:
...
> 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.
The GPL says "Activities other than copying, distribution and modification
are not covered by this License; they are outside its scope. ". This
means that use is not within the scope of the license. Instead, the GPL
grants unlimited rights to make verbatim copies and considerable
(though limited) rights to make modified copies.
And given the structure of copyright law, that's all the rights you
really need to use the software.
It does give the rigth to exclude certain jurisdictions if use is
limited within those jurisdictions, but leaves that up to the
person holding copyright on some other part of a work.
I don't see anywhere in the GPL that reads the way you've
declared it to read.
> > 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.
If That case is restricted (I'm ambivalent on this issue, currently),
it's because the work Quagga was written to contain libsnmp and
libssl.
In other words, talking about these other components as if they were
added after the fact pretty much ignores how the program was
constructed.
> > 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 don't think that's clear.
> > 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?
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.
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.]
Anyways, I have to run.
Later,
--
Raul
Reply to: