Re: Questions about legal theory behind (L)GPL
[routed back to debian-legal; I accidentally replied directly to Raul]
On Mon, 17 Jan 2005 17:04:02 -0500, Raul Miller <moth@debian.org> wrote:
> > > > > The GPL is a license document, and "automatically receives" is a
> > > > > license grant. The GPL doesn't need to be law to grant license --
> > > > > granting license is what copyright licenses do.
>
> > > On Sun, Jan 16, 2005 at 10:48:55PM -0800, Michael K. Edwards wrote:
> > > > "The GPL isn't law" was in response to "the GPL doesn't say this is an
> > > > authorization to sublicense". Under US law as I understand it,
> > > > there's no other way to implement the purported license grant
> > > > indicated by "automatically receives" other than the sublicensing
> > > > paraphrase that I gave.
>
> > On Mon, 17 Jan 2005 13:48:23 -0500, Raul Miller <moth@debian.org> wrote:
> > > Why would direct licensing not work?
>
> On Mon, Jan 17, 2005 at 12:55:47PM -0800, Michael K. Edwards wrote:
> > As I understand it, generally speaking, a contract has two parties --
> > offeror and offeree.
>
> Ok. However, it's worth noting that these parties are distinct each
> time the [implied] contract is executed.
That's one reason why I think the sublicensing interpretation is more natural.
> > To the extent that it binds other persons or entities, it does so
> > through the doctrine of agency -- either party A declares that non-party
> > B will fulfill some of A's obligations as an agent of A, or A agrees,
> > acting as an authorized agent of B, to commit to conduct on B's behalf.
>
> Until you've established that the GPL binds third parties through any
> means other than direct execution of the [implied] contract, this is
> begging the question.
This statement was about the general reach of contracts purporting to
bind third parties, not about the GPL text.
> > The GPL appears to me to fall under the latter, authorizing the licensee
> > to offer a sub-license to all copyrights in the incoming GPL work.
>
> I disagree.
>
> The GPL states
>
> Each time you redistribute the Program (or any work based on the
> Program), the recipient automatically receives a license from the
> original licensor to ...
>
> This is very clearly a license from the original licensor (whoever that
> is) to the licensee.
>
> Of course a Program might have multiple copyrights, but the GPL has
> required (under section 2) that the people who have added such material
> have made it available under the GPL terms.
>
> In other words, I see multiple implied contracts, but each contract
> is between the original copyright holder and the recipient. I don't
> see any grounds for thinking that there's any sublicensing.
>
> For that matter, sublicensing might be seen as an attempt to circumvent
> the requirement that the original licensor grant the license to the
> recipient.
There's some reason to this, especially in light of GPL section 4.
But that would result in potential jeopardy for breach of contract
between each licensee and every copyright holder. That has nasty
consequences, which I wrote out in the draft I lost (don't use Google
Search in the same tab as your GMail session!) but will summarize as
"both sides become vulnerable to expensive to defend, quasi-frivolous
lawsuits in inappropriate jurisdictions". The doctrine of agency was
created to avoid this kind of nastiness and make complex business
relationships possible without an endless web of implied contracts.
> > To get the same effect with "direct licensing", you'd have to read
> > separate offers of contract from each copyright holder to the recipient
> > into the single act of passing her a modified work, which is a little
> > far-fetched.
>
> The way I read it, those offers of contract from each copyright holder
> to the recipient are made each time the program is redistributed.
>
> I don't see why this is "far-fetched", and I don't see any reason to
> pretend that that's not what the license mandates.
A mandate without an implementation is subject to construction.
Construing agency to issue sublicenses leaves the contract between
distributor and immediate recipient where it belongs, with subject
matter being the entire contents of the offered blob of software. I
think that's much cleaner as a basis for findings of fact than the
"contracts upon contracts" construction, and does a better job of
reaching the parties' intent, which is what judicial construction is
supposed to do.
> ...
> > > I imagine that (where two copyright holders differ from one another in
> > > their interpretation) the judge would look at the history of how these two
> > > copyright holders have acted. If one has recently changed their intent
> > > then the judge would need to consider their previously expressed intent.
> ...
>
> > On the question of sub-licensing, I doubt that you would be able to
> > find evidence of either copyright holder's stance in advance, and it
> > wouldn't matter much anyway, since as a matter of law (in the US)
> > ambiguities in contracts must be construed against the offeror and
> > there's no way to demonstrate the licensee's intent in a
> > non-negotiated, "standard form" contract. (That isn't necessarily
> > true if there's a history of correspondence between the parties and it
> > can be demonstrated that both interpreted the contract in the same
> > way.)
>
> I'm thinking that there will typically have been a history of
> correspondence between the parties. Most likely: an email archive,
> the changelog, release announcements, etc.
>
> And the basic question is: why was the material contributed in the
> first place?
>
> As a general rule, if someone had an objection to their content being
> distributed, they would speak up shortly after they find out about
> the issue. If some extended period of time has passed (for example:
> the time between Debian Stable releases), there's a very real question
> as to why the issue wasn't raised earlier.
>
> This issue, in concert with testimony about informal communication
> between the parties, should be sufficient in most if not all cases of
> "some free software developer decides to litigate about some old code".
Facts like these could support defenses of equitable estoppel, implied
license, and fair use. But they hardly settle the question a priori.
> Of course, if the code has just recently been added, then the right thing
> to do when someone complains is remove the code. However, if someone
> is pulling an SCO, the right thing to do is document what really happened.
ACK.
> > My guess (IANAL) is that a court would find that, when A offers
> > Project X under the GPL, B modifies and distributes it, and C accepts
> > license in the modified version, B and C have formed a contract and
> > A's participation is limited to the agency for sub-licensing purposes
> > implicit in the contract that it offered B. This is especially likely
> > to hold in a situation where B is Debian, since most users deal
> > directly with Debian for updates, bug reporting, etc., and can
> > reasonably claim that as far as they are concerned their license came
> > from Debian and the rest is between Debian and the upstream(s).
>
> I don't think a court case where this issue is relevant is likely.
Suppose the FSF had gone beyond complaining and threatening when KDE
used Qt under the QPL and proceeded to sue, say, IBM for bundling
RedHat with some of their servers. Don't you think it would be
relevant whether IBM could claim reliance on RedHat as the FSF's
agent?
> I think that, if there were such a court case, that the court would
> rule that C has a license from A (because the GPL says that C has such
> a license).
>
> However, it's never wise to think that you know how a judge will decide,
> so I will admit that there is some small chance that a judge would rule
> the way you've outlined.
I agree that there's some chance either way, unless someone can cite a
precedent more definitive that what I've found.
> > > Most likely, the judge would say that Ms X doesn't have standing.
> >
> > How could that be? Factually, her copyright has been infringed unless
> > Debian (reachable through SPI and/or as a list of named defendants
> > plus a stack of Does and Roes) can demonstrate that it acted under
> > license.
Let me be a little clearer here. I'm positing that a copyrightable
quantum of expression has been accepted from material offered by Ms. X
under the GPL into the Kaffe code base. I'm further positing that
Kaffe is in main and that the amount of material copied exceeds a "de
minimis" portion, at which point "copying" has been demonstrated. In
the absence of a successful legal or equitable defense (such as a
valid license or "fair use"), that's infringement.
Presuming that the GPL is a valid offer of contract and it can be
demonstrated that Ms. X offered and someone accepted these terms as
agent-in-fact of the Debian Project, the court then has to determine
whether the scope of the license grant covers Debian's conduct and
whether there are grounds for rescission of the license. None of this
has anything to do with whether Ms. X has "standing" -- that became
undeniable once copyrightability, copyright ownership, and "copying"
were demonstrated.
> I already answere that:
>
> > > Eclipse is not a module of Kaffe.
>
> > I don't understand what legal significance you expect this to have in
> > this situation.
>
> Eclipse doesn't hae a GPL notice on it.
>
> Kaffe does.
ACK.
> However, the GPL states that mere aggregation is not restricted
> by the GPL.
>
> So for Kaffe's license to matter for Eclipse, you'd have to have some
> other reason for thinking that the GPL would restrict this case. That
> leaves us with:
>
> Maybe Eclipse contains code from Kaffe. [But that's not the case, as far
> as I can see -- they are related at runtime. If Kaffe was used to build
> the Eclipse byte code, there might be some questions about classpath,
> but there's already an explicit exception for that, and you did not
> specify that Ms. X contributed specifically to classpath.]
>
> Maybe Eclipse falls under the following requirement for Kaffe:
>
> For an executable work, complete source code means all the source code
> for all modules it contains, plus any associated interface definition
> files, plus the scripts used to control compilation and installation
> of the executable.
>
> But Eclipse is not a module of Kaffe. Eclipse is not an associated
> interface definition file for Kaffe. Eclipse is not a script used to
> control compilation and installation of Kaffe.
OK, now I get the context of "Eclipse is not a module of Kaffe".
> Instead, Eclipse is merely aggregated with Kaffe, and one of the ways
> of running Kaffe runs Eclipse (but running Kaffe is not restricted by
> the GPL).
ACK, although I think it's considered factually debatable whether any
given technique of execution creates infringing copies along the way.
That isn't purely a technical question, especially considering the
criteria for "fair use" -- which also vary quite a bit by
jurisdiction.
> > I have argued that no derivative work containing Eclipse and any part
> > of Kaffe or Classpath is created at any stage, since a "derivative work"
> > is by definition an "original work" unto itself, and the interpretation
> > and linking processes don't create "original works".
>
> And I agree with you on this point.
>
> > But there is no question that both the Debian CD and the system on
> > which Eclipse and Kaffe are installed infringe on Ms. X's copyright
> > in the absence of a valid license to Kaffe.
>
> Yes there is. I've asked questions about the reason someone might make
> such a claim numerous times over the last week. So far, no one has
> provided a credible answer.
>
> I see no valid reason for such a claim.
I hope I've answered this above -- I'm positing the ingredients of
"copying" by assuming that Ms. X holds copyright on a meaningful
portion of Kaffe alone, so that we can get down to license and other
affirmative defenses.
> > > In the unlikely event that she did have standing, I'm sure the judge
> > > would ask her what she thought people would use Kaffe for, and why she
> > > contributed the code.
> >
> > Why would that matter? But suppose she did, and Ms. X answered that
> > it was her understanding that her contributions could only be used by
> > GPL applications, based on an argument similar to Grzegorz's. I think
> > that the defendants could successfully argue that they relied on the
> > actual text of the license, with its use of terms with a definite
> > meaning in copyright law, and a reasonable review of the relevant case
> > law, to conclude that the GPL doesn't cross published API boundaries
> > irrespective of the technical details of linking, interpreter
> > internals, etc.
>
> If Ms. X is going to refer to the text of the GPL as the basis for this
> expectation, please spell out the reasoning for thinking that people
> could not run Kaffe to run Eclipse.
Er, I'm not the best person to spell this out, since I disagree
strongly with this interpretation of the GPL text. Remember, I'm the
one who thinks that the GPL as written doesn't prohibit uses such as
dynamic linking GPL and non-GPL code, or even static linking as long
as the works don't become practically inseparable and hence a sort of
de facto derivative work instead of a compilation.
But there's no reason why Ms. X can't say it was her intention to
contribute code to a project that, based on FAQs that she had read,
could be used only to run GPL-compatible applications. There are
several approaches that one could take in countering this argument,
and I think that mine would be to attempt to rebut the entire linking
myth, not to cite the FSF's FAQ on interpreters. If money were at
stake, I'd go for de minimis, fair use, and equitable estoppel too, if
the facts supported them.
> > For the record, that's how I approach the issue -- relying on license
> > text and law, not the FSF's FAQ or the opinion of any particular
> > copyright holder -- and that's the defense that I think I would offer
> > if I were ever in the defendants' position.
>
> That's fine.
>
> Just spell out the reasoning. Don't say it's obvious, because it's not.
It's not obvious at all -- that's why I've been citing case law out
the yin-yang. :)
> > > [Also, if the FSF did get involved, I imagine they'd be able to cover
> > > a lot more ground in that brief -- I don't think they'd limit the scope
> > > to classpath.]
> >
> > Read the FSF's brief in MySQL v. Progress Software -- if you ask me,
> > it is less than scintillating as an exposition of the legal foundation
> > for their position.
>
> Can you point me at this? I can find the eldred brief, but haven't
> found that one.
http://www.fsf.org/press/mysql-affidavit.html
Cheers,
- Michael
Reply to: