This probably belongs on debian-legal, but let's go one more round on debian-devel given the scope of the LCC's potential impact on Debian. (Personally, I'm more interested in the question of whether agreeing to consecrate particular binaries contravenes a distro's commitment to the Four Freedoms than I am in the legal niceties; but I feel obliged to substantiate my earlier assertions.) As always, IANAL.
[Bruce quoting the GPL] > .... However, as a > special exception, the source code distributed need not include > anything that is normally distributed (in either source or binary > form) with the major components (compiler, kernel, and so on) of the > operating system on which the executable runs, unless that component > itself accompanies the executable. Bruce> This does not require specification of the development environment. What part of "normally distributed ... with ... the operating system" is confusing? As written, this requires that any build requirement that doesn't come with the operating system must be available, in source code form, from the entity distributing the compiled Program. If the compiler required is some magic binary that isn't distributed with the operating system, then this clause isn't met. I will grant you that this clause was written in the days that commercial operating systems shipped with the C compiler bundled, and has since been interpreted to mean "as long as the development requirements are obtainable on the same terms as those needed to compile code in the same language, with similar functionality, that you wrote yourself" -- more or less. That's why I wrote "the letter of the GPL". What I expect from binary distributions of free software is that I can reproduce the binaries from the source code without undue effort, so that I can then exercise my freedom to modify it without debugging major functional regressions first. Given the complexity of a full GNU/Linux distro, I don't go around crying "GPL violation" every time something fails to build from source (or fails to work right when rebuilt). But I do think, based on the above-cited license text, that it's a technical violation of the GPL as well as a sign of poor software engineering process. me> Note that if Distro X distributes both NonFreeWareApp and glibc, and only me> offers technical support on NonFreeWareApp to those who don't recompile me> their glibc, then Distro X's right to distribute glibc under the LGPL is me> automatically revoked. Bruce> The word "support" does not appear in the LGPL. What Bruce> I do see is: Bruce> Bruce> Activities other than copying, distribution and modification are not Bruce> covered by this License; they are outside its scope. Bruce> Bruce> This would imply that support is outside the scope of the license. I don't Bruce> see any language in the LGPL specifying a support obligation of any kind. I'm relying on LGPL 6, which addresses distribution terms: As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. At first blush, I would expect "distribute ... under terms of your choice" to refer to the entire contract between "licensor" and "licensee" (if we are talking about software that is "licensed" and not sold; the common-law contract between seller and buyer is a whole different animal). If that contract includes a support clause, and the support clause does not permit modification of the work without loss of some of the economic benefits of the contract, then one could argue that this "exception" (from the requirement to offer source as per the GPL) should not apply, and that the distributor must either offer source or refrain from distributing the LGPL material. In fact, it depends on the legal regime that applies. Consider a recent (1999) decision of the U. S. 9th Circuit Court of Appeals, Sun v. Microsoft, which may be found at http://caselaw.lp.findlaw.com/data2/circs/9th/9915046.html (FindLaw is cool). The lower court had granted Sun a preliminary injunction against Microsoft's continued distribution of JVMs incompatible with Sun's Java standard. The appeals court vacated the district court's injunction, stating: [9] The enforcement of a copyright license raises issues that lie at the intersection of copyright and contract law, an area of law that is not yet well developed. We must decide an issue of first impression: whether, where two sophisticated parties have negotiated a copyright license and dispute its scope, the copyright holder who has demonstrated likely suc- cess on the merits is entitled to a presumption of irreparable harm. We hold that it is, but only after the copyright holder has established that the disputed terms are limitations on the scope of the license rather than independent contractual cove- nants. In other words, before Sun can gain the benefits of copyright enforcement, it must definitively establish that the rights it claims were violated are copyright, not contractual, rights. The appeals court essentially ruled that Sun was likely to succeed on the merits of the claim, but that would only lead immediately to a preliminary injunction under a "copyright law" standard, which the district court had applied in order to automatically presume irreparable harm. Applying a "contract law" standard in reaching a preliminary injunction would require that irreparable harm be demonstrated and, arguably, that the court decide that "Microsoft intentionally and willfully violated" the compatibility terms. The court of fact was told to go back and review the language in the contract, rule on the separability of the grant of license from the portion of the agreement that was violated, and thereby determine whether copyright or contract law should apply. It's very interesting to note that the (L)GPL is explicit about revoking the contractual license if the licensee violates the limits of the grant. E. g., LGPL section 8 contains, "Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License." AIUI, this guarantees that the relationship between LGPL author and distributor reverts to that of copyright holder and infringer in the event of a violation of any of the distributor's obligations in the LGPL. Yet it creates a contract-law obligation of continued performance on the distributor's part, so long as the distributor owes continued performance (such as technical support) under the terms of its license with the recipient of the bundled components. The tricky part is in determining whether distribution and technical support are in fact separate covenants in the distributor's contract with the recipient. This is a question of fact, not of law, which is why the Sun v. Microsoft appeals court declined to rule on the question, remanding it to the district court. I haven't really thought through whether it matters whether the same party distributes the proprietary and LGPL material; that's why I limited my statements to "Distro X". Cheers, - Michael
