Re: GPL and LGPL issues for LCC, or lack thereof
Hopefully this continues to be interesting to debian-devel readers.
Perhaps replies should go to debian-legal; GMail doesn't seem to let
me set Followup-To, but feel free to do so if you think best.
I have copied Eben Moglen (General Counsel to the FSF) at Bruce's
suggestion. Mr. Moglen, I am not a lawyer, but I'm doing my humble
best to match the (L)GPL up to recent case law. Your name was invoked
by Bruce Perens with regard to an analysis of the Red Hat service
contract and the GPL, and if you have the time, I would value your
comments.
This debate arose in the context of a discussion about the Linux Core
Consortium's proposal to share binaries among GNU/Linux distros. I
don't think the LGPL ought to permit ISVs to discriminate between
users who link against these "golden binaries" and those who link
against functional equivalents, and I don't think that distros ought
to offer ISVs this illusory solution to their (perceived) quality and
interoperability problems. I also think, based on the actual text of
the LGPL, that it may already be enforceable as a ban against this
discrimination.
You can find previous messages in this thread at
http://lists.debian.org/debian-devel/2004/12/thrd3.html starting at
"Linux Core Consortium" (Bruce Perens).
me> What part of "normally distributed ... with ... the operating system" is
me> confusing?
Bruce> The license requires that the source code all of the pieces that
Bruce> constitute a derivative work of some original piece of GPL code must be
Bruce> provided. This would be the original GPL program and the scripts used to
Bruce> build it, and any other code you link into it and the scripts
used to build
Bruce> that. The build tools are separate works that never become derivative of
Bruce> the GPL program.
I am talking about the LGPL here, not the GPL. Please re-read
sections 5 and 6 of the LGPL for the definition of "work that uses the
Library" (which assumes that it only becomes a derivative work after
linking) and the "special exception" to the GPL requirement of
releasing source code. As I read it, the exception clause can and
does place limits on the allowable build tools even though they are
not derivative works.
It may not have been the original intention of the GPL authors to
address the availability of build tools. But the language I cited
from LGPL section 6 seems to succeed in the intention stated in the
preamble, which includes: "If you link other code with the library,
you must provide complete object files to the recipients, so that they
can relink them with the library after making changes to the library
and recompiling it." You can't do that if you don't have the full
means of recompiling it.
Bruce> Concievably a contract could require that you specify the build system,
Bruce> but the GPL doesn't purport to be a contract. It is designed to
only grant
Bruce> rights, not restrict any rights that you would otherwise have. This also
Bruce> side-steps the issue of consent.
I am having a hard time believing that you are arguing that the GPL is
not an enforceable contract.
If it's not a contract, then what is it? At least under U. S. law,
I'm not aware of any other theory under which copyright license can be
granted ("fair use" and the like are acceptable justifications for
using copyright material without a license, but do not result in a
grant of license). Even a grant with no return consideration is
considered a "unilateral contract", and the (L)GPL is certainly not
intended to be a unilateral grant. A grant of license in return for
specific performance is in fact a contract whether there's a signature
or not. The distributor can choose whether or not to accept the
offered contract, but if they don't choose to do so, they can't claim
to have received a copyright license.
For an analysis of similar issues in an offer of copyright license,
see Fosson v. Palace Waterland (1995) at
http://caselaw.lp.findlaw.com/data2/circs/9th/9455550.html . You will
again have to go beyond a superficial reading of "who won", because
issues of fact went against the copyright holder. Here are a few
excerpts (see the original for references to other cases):
<excerpts>
Under California law, an "offer is a manifestation of willingness to
enter into a bargain, so made as to justify another person in
understanding that his assent to that bargain is invited and will
conclude it."
... under California law, "acceptance is the `manifestation of assent
to the terms thereof made by the offeree in a manner invited or
required by the offer.'"
... under California law, where no time limit is specified for the
performance of an act, a reasonable time is implied. ... Thus, the
failure to specify a timeframe for payment of the license fee would
not render the contract illusory.
If doubt[exists] as to whether the agreement was bilateral or
unilateral, such doubt would have to be resolved by interpreting the
agreement to be bilateral. . . .There is a presumption in favor of
interpreting ambiguous agreements to be bilateral rather than
unilateral.
[A]ny valid promise, whether absolute or conditional, is sufficient
consideration for another promise.
[addressing Mattei 1958, a case involving a contract of sale in which
nothing ever changed hands] ... although obtaining the leases was
completely within the control of the plaintiff, the court found that
"a contract arose, and plaintiff was given the power and privilege to
terminate it in the event he did not obtain such leases."
In Rano, we recognized the rule applied in other circuits that once a
non-breaching party to an express copyright license obtains and
exercises a right of rescission by virtue of a material breach of the
agreement, any further distribution of the copyrighted material would
constitute infringement.
</excerpts>
I was surprised and delighted to find a recent case which brings
together so many of the issues raised by the GPL's grant of license in
return for abstract considerations, and (as I read it) decides them
all in favor of the validity of the GPL. Although this case makes
repeated reference to California law (because contract law issues in
the US are generally governed by state law), I think its arguments
would have force in most US jurisdictions. (IANAL, etc.)
me> I will grant you that this clause was written in the days that commercial
me> operating systems shipped with the C compiler bundled.
Bruce> That section is
Bruce> specifically addressing the libraries that are actually linked into the
Bruce> work, and thus become part of a derivative work containing the GPL code.
That sentence is also present in GPL section 3, which seems to be the
usage that you're addressing. But I was quoting from LGPL section 6,
which grants an exception under which a derivative work can be created
(at the link stage) without triggering the GPL requirements on the
full work. In that context, it addresses all of the tools required to
rebuild the LGPL material from source and re-link it to the closed
source material in order to create a new derivative work.
Bruce> Back when all GPL code was developed on Sun, we had a non-free C
Bruce> library. That's the piece that came with the compiler and the OS for
Bruce> which we had to make an exception.
I was around then too (as a local maintainer of GNU tools), and I
would agree with you that that's why the exception was inserted in GPL
section 3. But I also remember the hoo-ha when Sun didn't ship a full
compiler with Solaris 2.0 -- I think many people were caught off
guard, since they'd assumed that gcc could always be bootstrapped with
the "native" compiler.
Courts consider the intention of the contract writer when the text
isn't clear, but generally construe the text _against_ the writer of
the contract (i. e., take the interpretation least favorable to the
contract authors, since they had the ability to make their
expectations clearer at the time it was written). Since the declared
intention of the GPL authors was to prevent free software from
becoming non-free in the hands of third parties, and they could have
insisted on free tools but didn't, I wouldn't expect the GPL to be
interpreted to require reproducible build tools. But I would expect
the LGPL to be, since it explicitly addresses a use case in which the
build tools have to be sufficiently conformant between distributor and
recipient to allow the recipient to modify the LGPL material.
me> At first blush, I would expect "distribute ... under terms of your choice"
me> to refer to the entire contract between "licensor" and "licensee" (if we are
me> talking about software that is "licensed" and not sold; the common-law
me> contract between seller and buyer is a whole different animal). If that
me> contract includes a support clause, and the support clause does not permit
me> modification of the work without loss of some of the economic benefits of
me> the contract, then one could argue that this "exception" (from the
me> requirement to offer source as per the GPL) should not apply, and that the
me> distributor must either offer source or refrain from distributing the LGPL
me> material.
Bruce> This issue was researched very thoroughly by Moglen and Ravicher
Bruce> for FSF (who you can ask), and others, in regard to the Red Hat service
Bruce> contract. That may violate the spirit of the GPL, but it turns
out not the
Bruce> letter, because the offering of service is outside of the scope of the
Bruce> license.
Again, GPL agreed (because the GPL obligations are separable from the
offer of service contract), LGPL not necessarily (because any use of
proprietary and LGPL code together relies on the "permission to link"
clause) -- unless you can show me a legal meaning of "distribute" to
which the argument about inseparability of the LGPL's license terms
doesn't apply.
> [Long analysis of Sun case deleted]
(Mr. Moglen, I was analyzing
http://caselaw.lp.findlaw.com/data2/circs/9th/9915046.html [Sun v.
Microsoft 1999].)
Bruce, if you read this case and my attempt at analysis, you seem to
have addressed it only at a summary level. The outcome of the case
(this round went against Sun) isn't the point. I looked for an
appellate decision which touched on the revocability of a grant of
copyright due to the grantee's failure in an obligation of continued
performance. As far as I know it's good case law and it is clear
about what findings of fact are required in order for the grant to be
revoked.
Bruce> The Sun Java license granted to
Bruce> Microsoft included a restriction on the creation of derivative
works: they
Bruce> were required to conform to, and not extend, Sun's published Java
Bruce> standard. The mention of "intersection of copyright and
contract law" is an
Bruce> observation that isn't really connected with the finding that the
Bruce> irreperable harm was entirely within the domain of copyright law. And the
Bruce> finding contradicts the purpose for which you quoted the whole thing.
I don't agree with any of these statements. The appeals court
declared that it was unknown whether the license was actually
connected to the conformance requirement, because that was an issue of
fact (condition of grant vs. separate covenant) on which the district
court had failed to rule. The mention of "intersection of copyright
and contract law" is vital, because irreparable harm can be
demonstrated under either theory, but copyright law includes an
automatic presumption of irreparable harm on breach, which the
district court relied on in granting a preliminary injunction. The
appeals court said "it might be the right outcome, but it's the wrong
theory, unless you rule that the copyright license was properly
revoked under the contract". And the finding is exactly in line with
my purpose, which is to demonstrate that the devil is in the details
and you can't jump from "this case went against Sun" to "copyright
licenses can't be revoked". You have to look at the text of the
license and judge whether the connection between the license grant and
the obligations placed on the grantee is strong enough to hold up in
court; I think it is.
me> It's very interesting to note that the (L)GPL is explicit about revoking
me> the contractual license.
Bruce> There's no contract. It revokes a copyright permission.
Which is certainly a license, both legally and etymologically, and is
an offer of contract; the distributor may choose to accept it or not,
but if not, they don't receive a copyright license.
me> Yet it creates a contract-law obligation of continued performance on the
me> distributor's part, so long as the distributor owes continued performance
me> (such as technical support) under the terms of its license with the
me> recipient of the bundled components.
Bruce> There is no language in the license
Bruce> that would do this and no law that would imply it.
>From LGPL Section 8: "You may not copy, modify, sublicense, link
with, or distribute the Library except as expressly provided under
this License. Any attempt otherwise to copy, modify, sublicense, link
with, or distribute the Library is void, and will automatically
terminate your rights under this License." If you accept the
contention that "sublicensing" and/or "distribution" covers the
performance of contractual obligations between distributor and
recipient, then my statement stands. I will restore a portion of my
analysis which you omitted:
me> The tricky part is in determining whether distribution and technical
me> support are in fact separate covenants in the distributor's contract
me> with the recipient. This is a question of fact, not of law, which is
me> why the Sun v. Microsoft appeals court declined to rule on the
me> [analogous] question, remanding it to the district court. I haven't really
me> thought through whether it matters whether the same party distributes
me> the proprietary and LGPL material; that's why I limited my statements
me> to "Distro X".
After further thought, it seems to me that this could go either way in
an appeals court. Suppose the LGPL material and the proprietary code
which depends on it are distributed by separate parties (distro and
ISV respectively), and the terms of the ISV's contract with the
recipient restrict (contractually or practically) the recipient's
rights when combining them under the LGPL. Does the recipient have
legal recourse?
If I were the judge, I think I would rule that the ISV was relying on
the distro as its legal agent to fulfill part of the requirements of
Section 6. (This is similar to a manufacturer's reliance on a
retailer to fulfill portions of the implicit seller-buyer contract,
even if the manufacturer hasn't explicitly named that retailer as a
legal agent; I haven't sought out case law for this.) If the
recipient doesn't wind up with the ability to modify and re-link
without losing value under the ISV's contract, then Section 6 doesn't
apply and the ISV loses its license under the LGPL. But this is
pretty speculative, and if the LGPL authors had a more concrete theory
in mind, I'd love to hear it.
Bruce> I'm not sure whether to take you seriously or not. Your reading of these
Bruce> licenses is so far off that I wonder if you're just playing
with me to see
Bruce> if I can actually find the flaws in your argument.
What can I say to this? I'm taking your arguments in good faith,
though I think they are erroneous in detail. Please do me the
courtesy of doing likewise.
Cheers,
- Michael
Reply to: