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 members@?)
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
licensing@gnu.org 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
|