Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of sknystautas@gmail.com designates
 64.233.184.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=oYLG19sZ8F+EPr66Vx0bUS8MbMfZg/k3DzEi6RUE5V07SUQTZebrkbCq6WehPB873tI+/Yx1YdUGKKWMLmJK746LSeSpDZH/JL2ZT4YqCjH6lIvut+6arVjdBJ7qMXT+T6577vKVTfmcDfHBafbfFMtAndlXF/H6pIYDd+/W7y4=
Message-ID: <140e061f05080216121f623ffb@mail.gmail.com>
Date: Tue, 2 Aug 2005 19:12:12 -0400
From: Serge Knystautas <sknystautas@gmail.com>
Reply-To: Serge Knystautas <sergek@lokitech.com>
To: legal-discuss@apache.org
Subject: Re: Apache's LGPL Policy
In-Reply-To: <redirect-1510789@lokitech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <redirect-1510789@lokitech.com>

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!).

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.  When the user runs James,
it would need to download Hibernate.jar on its own or have the user
download and install it.

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.

Am I just wishfully interpretting?

--=20
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

On 8/2/05, Cliff Schmidt <cliffs@apache.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> The Apache Board of Directors is planning to approve a resolution at
> their next meeting (currently scheduled for Aug 17) that would allow
> PMCs to ship software that depends on the presence of an LGPL-
> licensed library, without actually distributing the library.  We
> (myself and the Board) would like to hear any comments on this
> resolution in the next couple weeks.  Here is the proposed
> resolution, followed by a brief justification:
>=20
>         WHEREAS, some Project Management Committees (PMCs) within
>         The Apache Software Foundation (ASF) expect to better serve
>         their mission through the use of existing LGPL-licensed
>         libraries as a product dependency; and
>=20
>         WHEREAS, research into the impact of distributing ASF products
>         that depend on the presence of LGPL-licensed libraries has
>         indicated that the product licensing terms are not affected by
>         such a dependency; and
>=20
>         WHEREAS, the current ASF licensing policy continues to require
>         all intellectual property distributed by the ASF be licensed
>         under the Apache License, Version 2.0.
>=20
>         NOW, THEREFORE, BE IT RESOLVED, that PMCs may develop and
>         distribute products that depend on the presence of
>         LGPL-licensed libraries; and be it further
>=20
>         RESOLVED, that PMCs will register such use of an LGPL-licensed
>         library with the Vice President of Legal Affairs prior to the
>         PMC's next regularly scheduled Board report, and in no case
>         less than one week prior to the distribution of the applicable
>         product(s); and be it further
>=20
>         RESOLVED, that PMCs must continue to ensure they do not
>         distribute LGPL-licensed libraries or any other intellectual
>         property that cannot be strictly licensed under the Apache
>         License, Version 2.0.
>=20
>=20
> I'm sure some of you will be interested in the basis of the "research
> into the impact.." mentioned in the resolution.  This was primarily
> in the form of ongoing conversations with the FSF and other licensors
> of LGPL software regarding their interpretation of section 5 of the
> license.  The FSF specifically agreed to an assertion that a program
> that simply uses an LGPL library has no LGPL-related restrictions.
> This assertion was made within the context of a particular use case
> (but one requested by several ASF projects), which I have copied at
> the end of this post.
>=20
> In addition, ASF counsel, Larry Rosen, has reviewed the proposed
> policy and believes that the FSF's agreement to the assertion is
> consistent with his interpretation of the LGPL and copyright law, as
> well as the interpretation of other LGPL licensors, including JBoss,
> Inc. (http://jboss.com/elqNow/elqRedir.htm?ref=3D/pdf/
> Why_We_Use_the_LGPL.pdf) and the Hibernate copyright holders (http://
> www.hibernate.org/196.html).
>=20
> Below is the use case with the assertion, to which the FSF agreed.
>=20
> Thanks,
> Cliff Schmidt
> V.P., Legal Affairs
> Apache Software Foundation
>=20
>=20
>=20
> USE CASE: a "Program" that is distributed "In Isolation".
>=20
> Definitions
> - -------------------
> "Library":
>    as defined in the LGPL, but to be more specific, let's limit it to a
> Java .class or .jar file -- without source (which isn't needed for
> these use cases)
>=20
> "Program":
>    similar to "a work that uses the Library" (as defined in the LGPL),
> but in Java terms we are talking specifically about a Java source
> file, .class file, or .jar file that imports, implements, or extends
> portions of the Library, and otherwise, contains no code that is a
> derivative of any part of the Library
>=20
> "In Isolation":
>   not as part of a combined work that includes the Library
>=20
> Assertion
> - --------------
> - -->The Program can be distributed In Isolation without any restrictions=
.
>=20
> This is obviously the case for a Program that contains nothing
> derivative of any portion of the Library and would, therefore, fall
> outside the scope of the LGPL (as pointed out in the first paragraph
> of Section 5).
>=20
> Furthermore, even if the Program was considered a derivative work, the
> Program still has no licensing restrictions, if the derivative
> portions include no more than the following (and here is where I am
> interpreting your comments about Section 5's impact on Java):
>=20
> a) the Library's names (namespaces/classes/methods/properties/etc) and
> method signatures within the Program's source code or .class files, as
> necessary for such importing/implementing/extending,
>=20
> and/or
>=20
> b) minor portions (e.g. constant values/string within a Library's Java
> Interface) of the Library that may be copied into the Program's .class
> file as a direct result of the Java compilation process when
> importing, implementing, or extending another Java .class file.
>=20
>=20
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
>=20
> iD8DBQFC7+pCy6dGskFZ6tsRAo4vAJ9/d8amuKNboICpurnfzaf+IJ47ugCgjjat
> o0PXb1L8mzP5bSLmLuA/3pI=3D
> =3D+jY2
> -----END PGP SIGNATURE-----
>=20
> ---------------------------------------------------------------------
> 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
>=20
>

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