www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Schmidt <cliffschm...@gmail.com>
Subject Re: Apache's LGPL Policy
Date Wed, 03 Aug 2005 00:04:42 GMT
On 8/2/05, Serge Knystautas <sknystautas@gmail.com> wrote:
> I'm confused by this in that you define "In Isolation", but do not use
> it in the proposal (and am hoping you meant to!).

It is used in the "assertion" -- the most important part:
Assertion
--------------
- -->The Program can be distributed In Isolation without any restrictions.


> My interpretation of the proposal sans "In Isolation" is: James (mail
> server) could require Hibernate.jar at build time, but we could not
> put it into SVN.  Furthermore, when we made a bundled distribution,
> that also could not contain Hibernate.jar.

James could also require Hibernate at run time on the user's system
(in the case of binary downloads), but Apache still could not, in any
case, distribute Hibernate -- not alone nor as part of the bundle.

> When the user runs James,
> it would need to download Hibernate.jar on its own

tricky -- see below

> or have the user
> download and install it.

yes -- that would be perfectly fine (assuming it's not already on
their classpath)

Before I mention the issue of James downloading Hibernate.jar on its
own, let me point out the key point when it comes to Apache shipping
software to our users:

KEY POINT (but should maybe be a different thread):
Distributing software that is licensed under terms that are not part
of the Apache License (whether in isolation or bundled) is currently
against ASF policy.  It's not a problem with the LGPL; it's a matter
of the expectation we have set up with our users.  Over the years, our
users have come to expect that when they point to http://apache.org,
follow a link to an Apache project, and then click download, they are
getting software licensed under the Apache License.  Of course, they
should read the LICENSE file, especially if they are redistributing
it, but so far (with few, if any, exceptions), users have been able to
rely on the fact that Apache always ships software that that includes
terms they are familiar with, which put relatively few restrictions on
the personal or commercial redistribution of the software.  This is
why we don't ship LGPL software in any form at all -- not because
there's a trick in the LGPL license, but simply because it would not
allow the package to be distributed solely under the terms of the
Apache License.

NOTE: if you want to raise an issue about the above policy, feel free,
but please start a new thread since it is orthogonal to the policy of
being able to distribute software that simply requires the LGPL
library to be present.

Getting back to your question, if our software stealthily downloads
non-Apache Licensed software onto our users machines, that violates
the principle above.  However, if some install/build program asks the
user if it is okay to go out and grab an LGPL-licensed library and
install it (along with a copy of the LGPL, of course), then IMHO, that
would be okay.

> This is where I thought "In Isolation" would have come in, for
> example, we could not distribute the LGPL JAR "In isolation,"
> translation, do not put it into SVN.  However, we could put the LGPL
> JAR into bundled distribution.

no -- as you should notice from a second reading of the assertion
statement, "In Isolation" is used to describe that ASF-developed
software can be distributed without any licensing terms beyond those
of the Apache License v2, as long as it is not distributed along with
the LGPL library.

> Am I just wishfully interpretting?

yep -- sorry.  Again, feel free to start a separate thread about the
policy of not distributing any software that isn't Apache-Licensed.  I
just want to try to keep this discussion to what is currently being
proposed to the Board.

Cliff

---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message