Questions about legal theory behind (L)GPL
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
Reply to: