Re: GPL and LGPL issues for LCC, or lack thereof
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
Reply to: