There has been some discussion on debian-devel recently regarding the Linux Core Consortium's plan to share build procedures and resulting object code among several GNU/Linux distros. Their intention is to satisfy independent software vendors' demands for a set of "golden binaries", including compiled versions of LGPL material such as glibc, against which to test and certify their applications.
Several questions arose on which I'd like to know the FSF's position. Most of them are legal in nature. I am copying the debian-legal mailing list on this message, since the answers may affect the Debian Project's level of interest in LCC involvement. 1) The (L)GPL is legally an offer of contract, right? It was claimed during the debian-devel discussion that the LGPL is somehow a unilateral grant of rights under some legal theory other than contract, which doesn't make sense to me. In researching the question of how copyright licenses are interpreted by courts, I ran across Fosson v. Palace Waterland (1995) at http://caselaw.lp.findlaw.com/data2/circs/9th/9455550.html . This opinion seems to make it clear that conditional promises constitute sufficient consideration to form a contract. Besides, any defect of consideration or consent that barred enforcement of the (L)GPL on a distributor of software containing work offered by another under the (L)GPL would leave that distributor without copyright license from the author. Reference was made to Specht v. Netscape 2001 (published at http://www.nysd.uscourts.gov/courtweb/pdf/D02NYSC/01-07482.PDF ) as a cautionary tale about the need to obtain consent in order to prove that a contract was formed. In Specht, the appeals court denied Netscape the right to enforce an arbitration clause in a "browse-wrap" license. The opinion states: "From the user's vantage point, SmartDownload could be analogized to a free neighborhood newspaper, readily obtained from a sidewalk box or supermarket counter without any exchange with a seller or vender." But picking up a free newspaper doesn't grant you copyright license on its contents. Specht doesn't even contain the word "copyright", and seems irrelevant to the validity of the (L)GPL. As I understand it, GNU licenses make no attempt to bind the receiver upon receipt of software (as the Netscape license attempted to do). They impose conditions which the distributor must satisfy in order to accept an offer of contract and receive an automatic license from the copyright holder, and the distributor can't claim "I didn't consent" and "I have a license" at the same time. They also clarify to the receiver what rights he has regarding the material he has received, and under what conditions he is permitted to obtain copyright license for himself. But unless and until he undertakes to redistribute this material (or, technically, to copy it to a greater extent than one is legally permitted to do without a copyright license), the receiver has accepted no conditions and is not bound. Do I have this straight? Or is there really some other way besides a contract to extend a non-exclusive copyright license to those parties which comply with particular obligations? 2) Is the (L)GPL violated if the tools needed to reproduce object code from source code are not merely non-free but unobtainable? If a software vendor distributes object code derived partially from work that another has released under the LGPL, and offers source code from which it claims that object code was built, does the LGPL compel any verifiable relationship between that source code and object code? If the object code cannot be reproduced from the source code with any toolchain available on reasonable terms, has the software vendor violated the LGPL? For instance, suppose the vendor has used a unique, internally modified tool to produce that object code. This could happen more or less innocently; the buildmaster could be working with a CVS snapshot of GCC or SWIG and patching compiler / code generator bugs exposed by the LGPL code. It could also be a more deliberate scheme to circumvent the LGPL, in which the vendor has deliberately modified the compiler rather than the source code to remedy defects. (Imagine a "fixincludes"-like step which contains special-case code to repair broken header files, or a malloc shim inserted by the compiler to work around buffer overruns.) Does the (L)GPL compel a standard of reproducibility for object code releases? Should it? 3) Can a vendor of non-free software that depends on LGPL libraries require users to use particular compiled versions of those libraries? "Distribution" under the (L)GPL appears to be intended to refer to the act of offering a contract, not just the transfer of bits. Thus, at first blush, I would expect "distribute ... under terms of your choice" in LGPL Section 6 to refer to the entire agreement between "licensor" and "licensee" regarding the "work that uses the Library". But suppose that the contract between the software vendor and the user includes a support clause, and the support clause does not permit modification of the LGPL work without loss of some of the economic benefits of the contract. If the limitations on distribution terms in Section 6 cover the entire agreement, then the Section 6 "exception" (from the requirement to offer source as per the GPL) should not apply, and that the distributor must either offer source for the non-free software or refrain from distributing the LGPL material. There are complications that occur when the user has received the non-free software from a different party than the LGPL libraries; let us presume that a court would consider the supplier of the LGPL material to acting as the software vendor's agent. However, the (L)GPL fails to assert, and even disclaims, that the scope of the offered contract must be the entire agreement between the distributor and recipient regarding the Program (or, for the LGPL, the "work containing portions of the Library"). The provision that "[y]ou may not impose any further restrictions on the recipients' exercise of the rights granted herein" fails to ban "contractual covenants" and other forms of separate agreement. (The distinction between "limitations of scope" and "contractual covenants" seems to be a question of fact, not law; see Sun v. Microsoft, which may be found at http://caselaw.lp.findlaw.com/data2/circs/9th/9915046.html .) Presumably, an agreement between ISV and customer can be written such that, say, conditioning the provision of technical support on the customer's use of "golden binaries" is a contractual covenant even though it reduces the usefulness of the customer's right to modify. Does the LGPL provide any recourse? Should it? Thanks in advance for any enlightenment. Cheers, - Michael
