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: ASL Only Distribution Policy [was Apache's LGPL Policy]
Date Wed, 03 Aug 2005 03:42:56 GMT
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
> license").

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

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.

Cliff
 
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)
-------------------
"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)

"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

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

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