Hello, list! Thanks for tuning in. I'd like to kick off discussion with an issue that is bottlenecked right now on the "official" ASF counsel queue, and which we might be able to make some progress with some help on this list. I'll also repeat the call to invite any legal-eagle you know and trust to join this list.
As some of you might have witnessed from a long discussion about this at the beginning of the month on another mailing list (was that [EMAIL PROTECTED]) there is a very reasonable desire on the part of several projects within Apache implemented in Java to be able to do imports of other Java applications whose implementations (and interfaces) are licensed under the LGPL. One example is Hibernate. There is the widespread belief, correct or not, in the Open Source community that the LGPL is not "viral" in the way that the GPL is; that one can import such functions and not worry about the LGPL license having any effect on the license of the code doing the import. The belief is that it's just like the requirements on an application written in C and compiled with GCC, linking in the LGPL-licensed glibc or written against methods and classes defined in an LGPL-licensed C/C++ library.
In other words, if Apache James does an import of Hibernate's interfaces, Apache James can be licensed under the ASL 2.0, or any other license. There's a related question about what license a tarball containing both James and Hibernate would be under, but let's not go there for now.
However, a very close reading of the LGPL leads one to wonder if this is really the case. It really takes a better person than myself to summarize these issues, and I can dig up the posts from Roy Fielding and others who put this more clearly, but a close reading of the LGPL and even the FSF's own "clarification" at http://www.gnu.org/licenses/lgpl-java.html *still* leaves us in a state of uncertainty over whether the commonly-accepted understanding of the LGPL actually maps to the langauge of the license itself. The worry is that even a bare import (and more certainly an "extends" or "implements") would lead to enough taint as to consider the Apache project a derived work, falling under section 5 of the LGPL.
It looks like we're not alone in our interpretation; examples were given of other Open Source projects who answered this concern by dual-licensing with the MPL or CPL. Another project, Hibernate, decided to add "the Hibernate clause", http://www.hibernate.org/196.html, explaining their interpretation of the LGPL. However, they talk about "use" and "modify", but do not talk about "distribute"; it's unclear if this is just an oversight or if it's intentional. However, they do seem sincere in wanting Hibernate's license to be interpreted the way that the LGPL is "commonly" interpreted.
The consensus around the table within the ASF appears to be that the LGPL, by itself, is too vague for us to allow projects to import interfaces from LGPL'd projects, so we have banned it for now. Discussions are underway with the FSF to clarify this even more than their lgpl-java.html page did. Our need is pretty simple - we need to write applications that can import interfaces and yet be distributed under the Apache 2.0 license. We believe that most people who license their code under the LGPL want to see us able to do this. So the challenge here is to determine:
a) Is the Hibernate "clarification" clear enough for us, and our user community, and their lawyers, to be comfortable that the Apache project is not tainted by the LGPL dependency?
b) Is there a better clarification we could suggest to Hibernate and others like them who want to use the LGPL with a clarification?
c) Or should we press harder for the projects to use another modest-copyleft license, like the MPL or CPL?
First off: did I summarize this issue correctly? Does this make sense? I want to leave to a separate discussion the question of whether the LGPL by itself is compatible; I've sent a letter to Dave Turner and [EMAIL PROTECTED] asking for some very specific scenarios and clarifications which we will need an answer to before we can make progress there. This point here is to figure out the quickest way to unambiguously "fix the bugs" that keep the text from the LGPL from matching its commonly understood purpose.
If I've got the question right, then we can talk about answering it.
Brian
