[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Michael K. Edwards wrote:
If you want to argue that the Specht case applies to a distro's or an
ISV's use of LGPL code, then you are saying that the (L)GPL isn't
enforceable at all in the US unless the copyright holder takes
technical measures to require all recipients to read the license.
No, I saying almost the opposite. I am using that case to illustrate that a Free Software license had better be written to work without consent. If you write a license that depends upon consent, you may find that the consent isn't there and that your license can't be enforced.

There is a default in copyright law of "all rights reserved" that applies without consent. We can construct an entire license that works without consent. To do this, our license language must grant rights that you would not have by default, without taking away any rights that you would have otherwise. You don't have to consent to be granted a right, but your consent is  required to give up a right that you already have. The GPL and LGPL endeavor to only grant rights.

In contrast, contract law assumes that you are have all possible rights until you consent to give some of them up, and its definition of consent is problematical enough that one or both parties may think consent exists when it actually does not. Thus, it is a shaky foundation upon which to base a Free Software license, because there generally will be no explicit consent.
<>You also claim that the LGPL doesn't require constructive availability of tools required to exercise the right to modify
Yes. You took an explicit requirement to provide one piece needed to perform a task, the object code, and construed it as requiring all of the pieces, compilers and such that the language doesn't mention. I might accept your theory if the license said "you must make it possible to replace the software in the same physical device in which you distribute it, if replacement is physically possible". Perhaps a future version of the GPL should work this way. However, it would still have to be specific regarding what actually is required, lest producers of derivative works be required to give away hardware ROM burners and such. Thus, it would probably add to the requirement for object code a requirement for information necessary to program the device.
<>that the (L)GPL is a unilateral and unconditional grant of rights under some theory other
than contract
I didn't say "unconditional". The grant terminates in case of various sorts of infringement. But yes, I read it as applying without some of the essential components of a contract, such as consent and  consideration.
<>and that the act of "distribution" is somehow separable from the terms of a commercial software license.
Nope, I didn't say that either. What I said was that the right to sublicense applies to the copyright grant rather than any random contracts that touch upon the software in some way. But actually I can be more specific: the right to sublicense applies only to a license identical to the one which you were granted, the LGPL or GPL in this case, with the single exception that the LGPL terms allow you to convert to the GPL.

> and that the software license grant was a separate agreement from the service contract

<>I believe that I have already adequately refuted these assertions.
What you did was go on a number of flights through contract law that IMO wasn't quite germane, but took up lots of space and sounded knowledgable. I am tempted to say that you are welcome to believe that you refuted my points. However, I would prefer to see you set right, lest you cause some damage through leading others or even yourself astray. Talk to a lawyer experienced in LGPL and GPL whose opinion you would accept.



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

Reply to: