www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: ASL Only Distribution Policy [was Apache's LGPL Policy]
Date Wed, 03 Aug 2005 03:54:30 GMT
Cliff Schmidt wrote:

>On 8/2/05, Justin Erenkrantz <justin@erenkrantz.com> wrote:
>>No.  When the LGPL code and AL code are distributed together, the AL code is
>>subject to additional terms inside of the LGPL - namely Section 6 - which
>>means that we have to permit modification and reverse engineering on our code.
>>Our position is that condition is not permissable to pass along to our
>>developers and users.
>>Keeping them separate triggers only Section 5 ("outside the scope of this
>Actually -- that is what I used to think before I concocted the
>following use case and assertion, which the FSF agreed to.  The short
>version is that Java actually should not have to invoke section 6
>because those requirements aren't needed for a .jar, which allows easy
>separation of program and library.  These requirements are there for
>C-style executables, which would be much more difficult to separate
>out the original library -- hence the reverse-engineering terms.
>So, again -- the only reason I did not propose an LGPL policy that
>allowed projects to distribute a work that includes an LGPL .jar is
>because of the long-standing ASF policy to only distribute software
>from Apache servers that can be licensed under the terms of the Apache
>Note that MPL executables are specifically allowed to be licensed
>under other terms as long as the license includes a few provisions
>that are covered in the Apache License.  This MPL distribution policy
>has never been formalized to my knowledge, but I am hoping to do that
>in parallel with the LGPL policy.
>and here's the second use case and assertion, to which the FSF also
>agreed (note that reference to use case #1 is the same use case sent
>at the beginning of the "Apache's LGPL Policy" thread):
>USE CASE #2: a "Program" and "Library" are merely aggregated inside a
>.jar/.tgz/.zip and distributed
>Definitions (same as last time, but copied here for convenience)
>  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)
>  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
>-->Distribution of the Library and Program as an aggregation inside a
>.jar/.tgz/.zip does not bring the Program under the scope of the LGPL,
>but does require compliance with the terms of sections 4 for the
>redistribution of the Library.
>I'm primarily basing this assertion on the last paragraph of section
>2, which I believe should apply whether the Library is distributed
>modified or verbatim:
>"In addition, mere aggregation of another work not based on the
>Library with the Library (or with a work based on the Library) on a
>volume of a storage or distribution medium does not bring the other
>work under the scope of this License."
>I'm suggesting that a .jar/.tgz/.zip are distribution mediums, just as
>a cd-rom is.  They are a means of packaging together multiple software
>components into the convenience of one download that is easily
>divisible.  As long as the license terms are met for each included
>component, distributing them together in  a .jar/.tgz/.zip should not
>cause any new terms to apply.
>If the Program of Use Case #1 could be distributed in isolation
>without any restrictions, the mere aggregation of the same Program
>with the Library in a single distribution medium should not put
>restrictions on the Program.
So, if I understand correctly, there is no redistribution problem at all 
from the legal side of things other than the ASF does not want LGPL jars 

To be clear, both ASF and FSF lawyers agree that:
* Importing classes from an LGPL jar does not create a derivitive work 
or require the work to be licensed under the LGPL
* Including an LGPL jar in a distribution does not create a derivitive 
work or require the work to be licensed under the LGPL
* Section 6 is NOT invoked

- Dan

Dan Diephouse
Envoi Solutions LLC

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

View raw message