www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <ru...@intertwingly.net>
Subject Re: Status of dependency on LGPL'd library (Was: Re: [Legal] Why is this LGPL notice file in our SVN?)
Date Fri, 25 Jan 2008 10:20:00 GMT
Trustin Lee wrote:
> I feel like I am getting pretty close to the conclusion, all thanks to you guys.

We are getting close, and there is a part that deals with ASF policy 
issues that I am committed to get the board as a whole to come to 
agreement on.  Whether I will be able to do it before next board meeting 
or at the next board meeting (Feb 20) is yet to be determined.

> On Jan 24, 2008 11:50 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>> On Jan 24, 2008 9:31 AM, Ralph Goers <Ralph.Goers@dslextreme.com> wrote:
>>> Sam Ruby wrote:
>>>>
>>> http://www.fsf.org/licensing/licenses/lgpl-java.html.
>> Thanks!
>>
>>> I've had to read this several times. My summary:
>>> 1. Applications which import LGPL libraries need not be licensed under LGPL
>>> 2. The LGPL'd library must be able to be modified or replaced.
>>> 3. The trickiest one - they must be able to reverse engineer your code
>>> to debug their modifications to the LGPL'd library.
>>> 3. If you distribute the LGPL'd library you must also make the source
>>> available. If you don't distribute it then you don't.
>> Excellent summary.
> 
> Indeed.  However, is this also agreed within the ASF?  I just sounds
> like we can use whatever LGPL'd libraries without restriction because
> we almost always don't modify LGPL'd Java library and it's free to
> reverse engineer or debug ASL'd stuff we distribute.

I want to separate legal concerns from policy concerns here.  Legally, 
if we wanted to (for example) ship MINA under the full GPL, and include 
both GPL'ed and LGPL'ed jars there is absolutely no reason why we 
couldn't do so.

We simply don't chose to do so.  That's for policy reasons, not legal 
reasons.  One thing that is important to us is that people can take our 
code and include it is wonderful and virtuous Free products and nasty 
and icky proprietary products alike.

That would include proprietary products include super secret and 
nefarious value add functions that are shipped only as binaries, are 
licensed for use on only one CPU, and -- here's where it gets sticky for 
LGPL and possibly MINA -- have either technical or legal barriers 
against reverse engineering in place.

I'm intentionally not saying that I personally would be thrilled by such 
a usage, or that the world would be a better place if we all agreed to 
switch to GPL, but the path the ASF has chosen is intentionally agnostic 
in matters such as these.

> What's in the gray area is whether using Maven to pull LGPL'd JARs or
> not, which occurs automatically.

> 1) Should we provide the source code of the LGPL's JAR too in this case?

No.

> 2) Should we explicitly state that what Maven is going to download is
> not distributed under ASL but under LGPL?

Explicitly state is along the right lines.  There is an amusing quote 
from Hitchhikers Guide to the Galaxy that I'm reminded of here "It was 
on display in the bottom of a locked filing cabinet stuck in a disused 
lavatory with a sign on the door saying 'Beware of the Leopard'."

It seems to me that we want something more than an LGPL notice file in 
our SVN.  Preferably something that requires an explicit action on the 
part of the developer.  In the case of having an optional dependency, we 
want ASF products to be substantially usable without the dependency in 
place, and for an explicit action (i.e., something more than a simple 
click through) for somebody to download and include code that imposes 
upon the additional restrictions over and above those that the ASF 
license requires.

> 3) What about transitive dependencies?  For example, someone could use
> Maven to pull a ASL'd JAR which depends on another LGPL'd JAR.  He or
> she will pull the LGPL'd JAR without any proper notice.

Same policy issue applies here.

> Simplistic solution would be to move any submodules that depends on
> LGPL'd library, but the problem still remains outside of the ASF if
> the submodules are licensed under ASL.  I think there needs to be
> clearer official guideline that works for both inside the foundation
> and outside the foundation.  Am I going too far?  :)

Apache Licensed code outside of the foundation are bound to the same 
terms of the license but are not bound to the same policy.

> Thanks,
> Trustin

P.S.  Pet peeve of mine.  The name of the license is Apache License, 
Version 2.0, not ASL.

- Sam Ruby

---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message