[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gump
Subject:    Re: Gump3 Presentation
From:       Cliff Schmidt <cliffschmidt () gmail ! com>
Date:       2005-10-29 16:43:50
Message-ID: c5e632550510290943n2a3b0e78k1aab127052c5ab47 () mail ! gmail ! com
[Download RAW message or body]

On 10/28/05, Stefano Mazzocchi <stefano@apache.org> wrote:
> Leo Simons wrote:
> > On Fri, Oct 28, 2005 at 11:49:35AM +0200, Jan.Materne@rzf.fin-nrw.de wrote:
> >> Really, Leo?
> >> I thought LGPL is ok and GPL not.
> >> Ok - usually I try not to rely on non-ASF-licensed code. ONE license is
> >> the best (over
> >> a couple of).
> >
> > Heh. Don't ask me for authoritive details. Talk to Cliff Schmidt (our VP
> > legal).
> >
> > Depending on your interpretation of the LGPL and the Apache License, code
> > under these licenses can be used together without the AL code falling under
> > the LGPL license. The ASF recently switched interpretation to one where
> > this mixing and matching is possible for java code, too.

yes -- I'm also now working with the FSF's general counsel to get them
to make a formal statement about this.  I drafted something for them a
couple weeks ago and am waiting their response.  What I drafted is
pretty consistent with what I got agreement on with their GPL
compliance officer.

> > However, the ASF doesn't like to ship software for which parts of that
> > software which are needed for it to function are under terms more restrictive
> > than the AL (which is the case when you have a non-optional LGPL dependency).
> > So we have a policy in development (I don't think its ratified yet) to somewhat
> > constrain such a thing.

exactly -- things stalled out when it became obvious that the
membership was divided on whether we should be including components
under other licenses.  It's become clear to me that we have no choice
but to allow shipping some set of other licenses (since even binaries
under licenses like the CPL and MPL really should not be sublicensed
under the Apache license) -- so it's now on my plate to propose a
solution that not too many people will hate.

> As far as we currently stand, it is *OK* to *LINK* to LGPL and not to
> redistribute it.

From a legal point of view, it's definitely okay to link.  I even
firmly believe that it is okay to distribute the app that links to the
LGPL library along side the library itself within the same JAR, but I
want to get a final explicit confirmation from the FSF that they agree
with me on this before I promote the concept.  But the legal point of
view is not the hold up right now; as I mentioned above, it's really
about whether we think our users come to Apache to get products that
are entirely under the Apache License terms, and if not, how far
different can the terms be before they feel like they're not getting
what they want.

> There is no board resolution about it yet, but it's
> coming (Cliff, hint hint ;-)

yes, yes -- I now have a firm goal: have this whole thing resolve
(drafted, discussed, and voted upon) and announced by ApacheCon in
December.

> So, I suggest that we worry about this only when are ready to ship
> something. Also, remember, the act of 'bundling' and 'shipping' is what
> constitutes problems for us (details to come in the resolution),
> therefore if the user gets it on their own, we are fine. The use of
> things like maven to build, since they fetch the jars on their own,
> would therefore remove all our legal concerns, yet allow us to keep the
> hibernate functionality.

Again, I don't think there are legal concerns about this, but it does
fall into the yet-unresolved issue of what we think our users want:
will Apache products be less attractive if they have concerns about
redistributing the whole package (including the LGPL stuff, no matter
how they got it, if it is a core piece of the package).

Cliff

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]