Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41CFF981.2050204@apache.org>
Date: Mon, 27 Dec 2004 13:01:05 +0100
From: Torsten Curdt <tcurdt@apache.org>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041203)
MIME-Version: 1.0
To: legal-discuss@apache.org
Subject: Re: LGPL and "the Hibernate clause".
References: <20041221201253.P14071@fez.hyperreal.org>
In-Reply-To: <20041221201253.P14071@fez.hyperreal.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

> 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.

Just curious ...what would happen when *do* consider this
is ok and a few years later someone pops up saying "that's
not ok" ...can this be adjusted by removing the dependency
to the library? Or will the whole project by tainted?
I assume removing it should suffice ...but a definite
answer would be nice.

> 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.

Maybe we could try to educated people with what they have
to put in as an additional clause so ASF projects can
use them? ...that way they might keep their license but
we get the clarification we need. The projects that are
willing to corporate with us will add the clause and
we should be fine. ...just as hibernate did.

...or is this too simple?

> 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.

Think so too.

> 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?

AFAIU ...not even a lawyer might be able to tell
for sure until it gets decided in court. All they/we
can do is measure the risk.

> b) Is there a better clarification we could suggest to Hibernate and 
> others like them who want to use the LGPL with a clarification?

Maybe it would be worth trying to come with something
explicit and fool proof.

> c) Or should we press harder for the projects to use another 
> modest-copyleft license, like the MPL or CPL?

Of course it would be nice ...but it's always a challenge
making projects switch their license.

> 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.

Thanks for the extensive post.

cheers
--
Torsten