Re: RES: What makes software copyrightable anyway?
On 5/21/05, Michael K. Edwards <m.k.edwards@gmail.com> wrote:
> On 5/21/05, Raul Miller <moth.debian@gmail.com> wrote:
> > On 5/21/05, Michael K. Edwards <m.k.edwards@gmail.com> wrote:
> > > Not in any copyright sense whatsoever. And what, every Perl script is
> > > "based on" Perl? Every Lotus 1-2-3 macro is "based on" Lotus? Come
> > > back to Earth, please.
> >
> > It's very clear that "based on" is the essence of what copyright
> > protects in the case of derivative works, and providing
> > supposed counter examples which haven't been heard in
> > court doesn't make that go away.
>
> 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.
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.
> 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
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
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
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?
> > I think there's a lot of ground between "getting bogged down in
> > the little details" and "ignoring the law".
> >
> > (Except, in a sense, "getting bogged down in the little details" can
> > be a way of ignoring the law (when the big important concepts
> > get neglected).)
>
> 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)?
> > > Did you miss the _trademark_ license agreement, unrelated in any way
> > > to the license (the GPL) under which Progress claimed rights to copy,
> > > modify, and distribute MySQL's code?
> >
> > I think you'll agree that the crucial question here is: what license was
> > granted in the agreements between Progress and MySQL?
>
> 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.
> 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.
--
Raul
Reply to: