Re: GPL and LGPL issues for LCC, or lack thereof

[Bruce Perens <bruce@perens.com>]

Michael K. Edwards wrote:

What part of "normally distributed ... with ... the operating system"
is confusing?

The license requires that the source code all of the pieces that constitute a derivative work of some original piece of GPL code must be provided. This would be the original GPL program and the scripts used to build it, and any other code you link into it and the scripts used to build that. The build tools are separate works that never become derivative of the GPL program.

Concievably a contract could require that you specify the build system, but the GPL doesn't purport to be a contract. It is designed to only grant rights, not restrict any rights that you would otherwise have. This also side-steps the issue of consent.

I will grant you that this clause was written in the days that commercial operating systems shipped with the C compiler bundled

That section is specifically addressing the libraries that are actually linked into the work, and thus become part of a derivative work containing the GPL code. Back when all GPL code was developed on Sun, we had a non-free C library. That's the piece that came with the compiler and the OS for which we had to make an exception.

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.
  

This issue was researched very thoroughly by Moglen and Ravicher for FSF (who you can ask), and others, in regard to the Red Hat service contract. That may violate the spirit of the GPL, but it turns out not the letter, because the offering of service is outside of the scope of the license.

[Long analysis of Sun case deleted]

The Sun Java license granted to Microsoft included a restriction on the creation of derivative works: they were required to conform to, and not extend, Sun's published Java standard. The mention of "intersection of copyright and contract law" is an observation that isn't really connected with the finding that the irreperable harm was entirely within the domain of copyright law. And the finding contradicts the purpose for which you quoted the whole thing.

It's very interesting to note that the (L)GPL is explicit about revoking the contractual license

There's no contract. It revokes a copyright permission.

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.
  

There is no language in the license that would do this and no law that would imply it.

I'm not sure whether to take you seriously or not. Your reading of these licenses is so far off that I wonder if you're just playing with me to see if I can actually find the flaws in your argument.

    Thanks

    Bruce

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature