www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <br...@collab.net>
Subject LGPL and "the Hibernate clause".
Date Wed, 22 Dec 2004 04:36:37 GMT

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


Mime
View raw message