www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee" <trus...@gmail.com>
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 09:14:57 GMT
I feel like I am getting pretty close to the conclusion, all thanks to you guys.

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:
> > >
> > > That would not be OK if RXTX were under the GPL, for example.  The
> > > current draft makes no distinction between LGPL and GPL.  I've heard
> > > statements that LGPL (as of version 2) is OK for C and C-like
> > > programming languages, but not for direct references from languages
> > > like Java, but indirect references through standard interfaces (such
> > > as JDBC) are OK.  So far, none of that is reflected in the current
> > > draft, nor would it apply to usage of RXTX by MINA.
> > >
> > > I've also heard a statement the the FSF has somehow clarified this for
> > > Java, but can not find any evidence that backs this up.  Can anybody
> > > provide a link?
> > >
> > > - Sam Ruby
> > >
> > >
> > >
> > 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.

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?

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

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.

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

Thanks,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

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