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 <[EMAIL PROTECTED]> wrote:
On Jan 24, 2008 9:31 AM, Ralph Goers <[EMAIL PROTECTED]> 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
