On 08/02/2012 10:52 AM, Luis Villa wrote:
In the world of platonic license forms, the structure doesn't matter. But in the world of actually reading and interpreting licenses, structure matters.
I agree.
With no offense to our host, I find reading/interpreting LGPL v3 maddening for exactly this structural reason, and I am pretty sure I'm in the majority in this area. And I actually like GPL v3; for those who are for predisposed not to like v3 for any of the various reasons available, LGPL v3's structure is only insult to injury.
Hmm. Are you saying that you find LGPLv3 maddening to read/interpret because you have to map its terms to GPLv3 and this is difficult, or are you saying instead that you find the substantive terms (the additional permissions) of LGPLv3 maddening to read/interpret?
I assume you mean the former. If you mean the latter, LGPLv3 is largely recasting LGPLv2.1 in a different form - policywise there isn't too much that's different, except for what comes in (explicitly or otherwise) through GPLv3. What's principally different are a few clarifications (one or two rather subtle) that make LGPLv3 at least marginally more permissive than LGPLv2.1. For example, if anyone is puzzled by LGPLv3 section 2, this is just an effort to transform LGPLv2.1 2(d) into a GPLv3 additional permission.
The result is a license document that appears far simpler than LGPLv2.1. This simplicity is illusory since understanding the license depends on understanding GPLv3. But appearance counts for something, and I can remember hearing from some people that LGPLv3 seemed like a great accomplishment because it *appeared* to get rid of the LGPLv2.1 complexity. Historical documents do show that quite a few people complained about interpretive complexity with respect to LGPLv2.x.
But anyway, I assume you mean instead that it's maddening to have to map a non-trivial set of additional permissions to a separate license text. I'm curious if you have a similar criticism of the GCC Runtime Library Exception (current version 3.1 at http://www.gnu.org/licenses/gcc-exception-3.1.html) though that is much simpler than LGPLv3. Bradley and I were both involved in drafting that Exception, though I left SFLC for Red Hat while that effort was still in its earlier stages. The GCC Runtime Library Exception reveals the stylistic influence of LGPLv3.
If it's specific to LGPLv3, it might relate to the previous point that LGPLv3 preserves the substance of LGPLv2.1 (more or less). Thus if LGPLv2.1 sections 5 and 6 are difficult for one to understand, I wouldn't expect them to find it any easier to take LGPLv3 sections 3 and 4 and try to understand them in the context of GPLv3. (Although to be honest I'm not seeing why the mapping is so hard. They're just exceptions to section 6 of GPLv3, essentially.
I personally think the FSF should have started from scratch with LGPLv3, but that isn't what was done.
To tie this more closely with copyleft-next, I believe that the FSF's decision to draft LGPLv3 as a set of additional permissions is historically significant, as I see it as an acknowledgement by the FSF that structural or formal simplicity and brevity in a license document (or at least the appearance of it) can be useful and valuable for developers and users.
Anyway, Free Software licenses are about public policy and philosophy. The rest is, ultimately, just details.
Adoption is intimately linked to achievement of any public policy goals, and ease of comprehension (encompassing not just policy but also drafting and structure) is intimately linked to adoption.
I agree with that too (though sometimes I've wondered if it's wishful thinking on my part).
- RF