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
