Re: RES: What makes software copyrightable anyway?
On 5/20/05, Michael K. Edwards <m.k.edwards@gmail.com> wrote:
> On 5/19/05, Raul Miller <moth.debian@gmail.com> wrote:
> > But the ambiguities have to be valid ambiguities.
> >
> > That's where we seem to differ on this issue.
>
> I think there is little question that the "work based on the Program"
> definition + erroneous paraphrase in Section 0 is either: 1) a "valid
> ambiguity" (to be construed against the offeror on the licensee's
> request), or 2) unambiguously readable only as "derivative work under
> copyright law", because the paraphrase is so weakly attached as to be
> an implausible candidate for a definition even if the licensee wanted
> it that way. Perhaps you would now agree to this "either/or", without
> any implications for whether my reading of the phrase "derivative work
> under copyright law" is correct?
I'm going to tackle this in two pieces. First I'm going to critique
your presentation, then I'm going to try to tackle the issues I
think you're raising. Be warned that I may have misunderstood
you.
Presentation: Logically, you seem to have assumed that the clause
in question is erroneous, and you draw conclusions from this
assumption. In other words, but your conclusions seem to be
don't seem to add much to your initial assumption.
Issues: As near as I can tell, section 0 of the GPL establishes what
is being licensed by the GPL. To my knowledge, no works which are
not explicitly recognized in section 0 are being licensed. Section 0
also seems to establish the scope of the license -- which is something
you've expressed strong interest in. Other sections which grant
permissions explicitly do so "under the terms of this license" which
includes section 0, or under the terms of section 1 (which refers
to "the Program" of section 0), or of section 2 (which must be
under the terms of section 1).
More simply, "the Program" and a "work based on the Program"
are the things that are being licensed. Construing them narrowly
does not seem to be an argument in favor of the licensee except
for the case where the thing being considered does not need to
be licensed under the GPL.
If the only cases you're talking about is a case where the GPL
doesn't eed to license the work in question, I have no dispute
with you on this issue.
> is in dispute. Let's go with, "whatever the cause of action under
> discussion, a claim of (non-exclusive) license to a copyright is
> always viewed through the lens of contract law, and construed
> accordingly." OK?
I think you're still overstating that. For example, consider
statutory license, such as that granted by 17 USC 117.
I agree that you should expect to deal with contract issues in
a copyright dispute, but I'm not comfortable agreeing that the
scope of this issue is as broad as you've asserted.
> > But this seems rather irrelevant in the case of the GPL.
> >
> > Either there's a breach -- in which case there is nothing within
> > the scope of the license (which is the default state under
> > copyright law) -- or there hasn't been, in which case the
> > GPL has granted you some rights, and there's little or
> > no problem.
>
> Can we focus on this question of what "scope of license" means for a
> bit? I am _not_ talking about what happens once a court rules that a
> license has been terminated for breach of contract. I am talking
> about a situation where the contract wouldn't authorize the
> defendant's conduct irrespective of whether it had been breached. In
> this situation -- and only in this situation -- can the court skip the
> rest of the contract analysis.
Ok...
The GPL's scope is fairly broad:
Activities other than copying, distribution and modification are not covered
by this License; they are outside its scope.
Simplifying: the GPL grants most individuals (everyone whose license
has not been terminated) permission to copy, distribute and modify, with
the permissions granted in the context of modification being
narrow. All other rights (if there are any) are reserved.
> That's the question on which the Sun v. Microsoft appellate decision
> hinged -- the district court couldn't rule correctly on a copyright
> infringement claim until it had evaluated the scope of the license.
> And on remand, it correctly (IMHO, IANAL) concluded that the scope of
> the TLDA included the conduct that Sun had alleged constituted
> infringement, and denied Sun's copyright infringement claims.
Given the differences between the license granted in the TLDA and
those granted in the GPL, I'm not sure that this is a fruitful line of
discussion, but at the moment I have no reason to quibble about this.
> > > > In the context of the GPL, the remedy contained in the
> > > > agreement is that the license terminates.
> > >
> > > Funny how that's not how it worked in Progress Software v. MySQL, isn't it?
> >
> > I think that's because MySQL didn't properly charge
> > that Progress Software had violated the GPL.
> >
> > I certainly didn't see any discussion by the judge of
> > the issues which I would have thought were pertinent.
> > This implies to me that those issues weren't raised.
> > Or, if they were raised, that they weren't backed up
> > with facts.
>
> A claim of "GPL violation" was raised, all right. But as Judge Saris
> explained, the facts of the case didn't begin to match _any_ of the
> criteria for a preliminary injunction, let alone all of them. And
> (just to harp on this a little more) she very consciously used
> contract law standards, not the "automatic presumption of irreparable
> harm" applicable to copyright infringement claims.
Note that the facts of the case are those facts which were
presented to the court.
Note also that Judge Saris did not provide any discussion about
whether MySQL+Gemini constituted a protected work.
This implies, to me, that MySQL did not raise that issue. Or, if
they did raise it that they didn't provide any supporting facts.
There are also some arguments that might have been presented
which might show that Gemini itself was a derived work and not
an independent work. I'm assuming that MySQL tried to present
those and that those arguments are the arguments Saris had
a problem with.
> If a copyright infringement claim had been advanced by MySQL, it might
> have been wise on the judge's part to go through an explicit "scope of
> license" construction in the text of her opinion, just to avoid having
> it remanded to her on that technicality. (I don't think it could
> possibly have affected the outcome, but judges prefer to avoid being
> justly criticized on appeal.) But it doesn't actually seem that MySQL
> claimed that Progress Software's conduct was in this sense not within
> the "scope of license" granted by the GPL.
I think we're in violent agreement, here.
> As far as I can tell from the opinion (I have not yet obtained a copy
> of the full docket), MySQL's claims with regard to the GPL were
> entirely stated in terms of breach of contract. (Compare Eben
> Moglen's affidavit, which was not given in his capacity as an attorney
> at law but as an "expert witness".) Evidently MySQL's lawyer cared a
> little bit more about his credibility in the long run than Eben Moglen
> seems to; though again, that judgment is outside my qualifications.
Eben's affidavit does seem to me to be primarily focused on the
"release of source code" which Saris had also ruled on.
I could also speculate that MySQL's dual licensing of their db
resulted in a broader scope than that which would be the case
had it only been available under the GPL.
> I don't begin to have the legal background to construct a complete
> list of what remedies may be available for breach of contract in an
> arbitrary jurisdiction. But the above list is ample for most
> purposes, I should think.
Ok, I think I'm happy with that list.
Thanks.
[skipping on to "derivative works" vs. "collective works"]:
> How about: "X+Y+... is sometimes an uncopyrightable collection
> containing Y and sometimes a collective work containing Y; but neither
> case adds one whit of support to a claim that X, X+Y, or X+Y+..., is a
> derivative work of Y." As long as you are OK with that, I will
> happily concede that X+Y+... might also wind up being described by a
> court as a "derivative work" of (the
> selection-and-arrangement-creative-expression in) some other
> collective work, or might be a derivative work of Y by some other
> theory (such as mise en scene).
>
> I reserve the right to argue differently in a courtroom if I think
> better of it later. :-)
I have some of these reservations myself.
>From my point of view, the legal definitions attempt to be inclusive, with
alternate definitions provided to mop up cases which might be
missed otherwise.
The point you seem to be focusing on seems to be slanted
differently -- and I'll grant that there could indeed be (and probably are)
cases where a collective work is ruled to be not a derivative work.
So... I think we're agreeing here. In a sort of tentative fashion, but
that's probably good enough.
> > [2] Whether the GPL is a valid license for any software where
> > section 0 of the GPL does not apply.
>
> It's also a valid license to create at least some "collections"
> containing the "work based on the Program". Whether construed from
> the "mere aggregation" clause, from industry practice with respect to
> software in general, or from 17 USC 117 and the simple fact that you
> can't do much with it without creating some "collective work" (distro
> CD, hard drive contents, whatever), a GPL licensee is given the right
> to create various collections, copyrightable and otherwise.
I'll agree here. We might have some disagreement on the particulars,
but I think this counts as broad agreement on the form of this issue.
> There's simply no basis in the GPL text for defining some magical
> boundary at exec()/fork() or between interpreter and bytecode. If it
> weren't for the "mere aggregation" clause, it might get punted out to
> some computer industry expert witness, and who knows what they might
> declare to be standard practice -- the FSF's strong-arm tactics have
> helped establish a status quo in which people keep GPL code at arm's
> length. (I suspect that of being a big part of their agenda in
> maintaining the fictions in the FSF FAQ.) I think (IANAL) that 17 USC
> 117 protects dynamic linkers at the minimum, but an expert witness
> could conceivably convince a judge otherwise, and there's the rest of
> the world to consider.
I'll agree that the exec()/fork() thing is merely a heuristic, and that
legal decisions might differ from that heuristic in either direction.
Thanks,
--
Raul
Reply to: