Re: GPL and LGPL issues for LCC, or lack thereof
I guess it's not quite over yet. You have partly persuaded me on the
legal points -- convincing me further in the process that sharing
binaries around is a bad idea. Here's a revised summary of my
understanding of the legal issues:
The LGPL attempts to require constructive availability, to the
routinely equipped software developer, of the tools needed to exercise
the right to modify LGPL material when it is used by proprietary code.
It fails in this attempt unless a court construes a common-sense
relationship between source code and object code (the existence of a
verifiable procedure for the recipient to turn source into object)
which the LGPL neglects to spell out.
The (L)GPL is a license, which is a subspecies of contract. LGPL
Section 9 is incorrect in tying acceptance of a license to a
signature; there are numerous ways of establishing acceptance of a
contract. Downloading or purchasing media isn't always sufficient to
establish a contract, and giving away or selling a thing (including
software) conveys a common-law right to use it. Nevertheless, Section
9 is correct in saying: "However, nothing else grants you permission
to modify or distribute the Library or its derivative works."
Modifying or distributing may or may not be accompanied by acceptance
of the license, but if the return obligations are not met, then the
license is either rescinded or nonexistent, and copyright law applies.
"Distribution" under the (L)GPL appears to be intended to refer to the
act of offering a contract, not just the transfer of bits. However,
it 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. 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.
So the LGPL is a weak reed when it comes down to practical exercise of
the right to modify. The ISV's code can completely fail after a
security fix to an LGPL component on which it depends, and their
license can deny me any recourse unless I revert to the original
"golden binaries". This is freedom?
The details:
[Bruce's statements about hypothetical consent-free, non-contract
licenses omitted]
Specht, which you cited as a cautionary tale about consent, is about
contract law. The word "copyright" doesn't appear. 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."
If Specht is good law (i. e., not overridden or superseded), it
clearly applies to most end-user downloads of (L)GPL material, and
probably to most GNU/Linux CD sales as well. But picking up a free
newspaper doesn't grant you copyright license on its contents. The
only theory of which I am cognizant under which a distro or ISV can
distribute a derived work based on another party's copyright material
is that of a license granted by the copyright holder.
Bruce> You took an explicit requirement to provide one piece needed to
perform a task,
Bruce> the object code, and construed it as requiring all of the
pieces, compilers and
Bruce> such that the language doesn't mention.
My quote from the LGPL preamble mentioned "object files", but I was
only using that as evidence of the author's intentions. Here is the
full paragraph from LGPL Section 6, of which I previously cited the
last sentence:
LGPL> For an executable, the required form of the "work that uses the Library"
LGPL> must include any data and utility programs needed for reproducing the
LGPL> executable from it. However, as a special exception, the materials to be
LGPL> distributed need not include anything that is normally
distributed (in either
LGPL> source or binary form) with the major components (compiler, kernel, and
LGPL> so on) of the operating system on which the executable runs, unless that
LGPL> component itself accompanies the executable.
It is arguable that this paragraph requires only those tools needed to
reproduce the combined work once you've already recompiled the LGPL
material, given that the "work that uses the Library" is the non-LGPL
portion of the derived work. And I don't think this paragraph applies
anyway when using a dynamic linking mechanism.
So maybe you're right that the (L)GPL fails to compel any verifiable
relationship between object code and purported source code. I can
take LGPL code, modify my compiler to apply patches in the course of
compilation, and I don't have to distribute the patches because
they're part of the toolchain, not the source code. I would call this
a nightmare scenario, perhaps even a reductio ad absurdum that could
lead a court to construe a common-sense relationship between source
code and object code that depends on a consensus toolchain.
me> [Bruce claims] that the (L)GPL is a unilateral and unconditional
grant of rights
me> under some theory other than contract
Bruce> I didn't say "unconditional". The grant terminates in case of
various sorts of
Bruce> infringement. But yes, I read it as applying without some of
the essential
Bruce> components of a contract, such as consent and consideration.
A license is a form of contract and is governed by contract law --
even an implied license, which is "a creature of law, much like any
other implied-in-fact contract" (Effects v. Cohen 1990 section FN7,
http://www.kentlaw.edu/e-Ukraine/copyright/cases/effects_v_cohen.html
).
I'm sorry if I incorrectly summarized your position with
"unconditional". I filled in the "unconditional" because (per Fosson)
that's what makes a contract "unilateral" (e. g., "I'll pay you if I
use it", which doesn't involve any consideration on the offeree's
part). If the offeree has to accept some obligations in order to
receive the benefit of the offer, then it's a bilateral contract.
I've already addressed consent and consideration -- they're issues of
fact, not law (although provisions of law govern their
interpretation); in their absence, no contract and no license.
me> [Bruce claims] that the act of "distribution" is somehow separable from the
me> terms of a commercial software license.
Bruce> Nope, I didn't say that either.
[Followed by statements about the right to sublicense, with which I agree]
Actually, I wasn't referring to anything you said about sublicenses.
I was summarizing this statement from your previous message:
Bruce> However, it doesn't address your belief that certification and support
Bruce> obligations should survive such modifications. That's still
covered by the
Bruce> following:
LGPL> Activities other than copying, distribution and modification are
not covered
LGPL> by this License; they are outside its scope.
I'm interpreting "distribution" to refer to the entire license
agreement between ISV and customer, including hypothetical terms
offering technical support only if the customer uses LCC "golden
binaries". You seem to be interpreting it to exclude anything other
than transfer of bits.
I think neither of us is really right here; it's a question of fact,
hinging on the details of the ISV's license agreement as well as a
court's interpretation of "distribute that work under terms of your
choice", etc. This appears to me to implicitly define "distribution"
as a legal action (a written license with "terms"), but doubtless
there are ramifications of which I am ignorant.
Bruce appearing to quote me:
> and that the software license grant was a separate agreement from the service contract
I can't find anywhere that I wrote this. It's certainly not between
the sentences you quoted before and after it. I don't claim to have
refuted this; I have no idea to what agreement(s) it refers.
me> I believe that I have already adequately refuted these assertions.
[More civil, but still empty and ad hominem, response omitted]
Not all of my refutations appear adequate on review. I moved my
revised opinions to the top of this message. You didn't identify any
arguments I'd missed, so I'm content to end here.
Cheers,
- Michael
Reply to: