Apache's LGPL Policy

[Cliff Schmidt <cl...@apache.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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:

        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

        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

        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.

        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

        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

        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.


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.

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=/pdf/ 
Why_We_Use_the_LGPL.pdf) and the Hibernate copyright holders (http:// 
www.hibernate.org/196.html).

Below is the use case with the assertion, to which the FSF agreed.

Thanks,
Cliff Schmidt
V.P., Legal Affairs
Apache Software Foundation



USE CASE: a "Program" that is distributed "In Isolation".

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)

"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

"In Isolation":
  not as part of a combined work that includes the Library

Assertion
- --------------
- -->The Program can be distributed In Isolation without any restrictions.

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

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

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,

and/or

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.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFC7+pCy6dGskFZ6tsRAo4vAJ9/d8amuKNboICpurnfzaf+IJ47ugCgjjat
o0PXb1L8mzP5bSLmLuA/3pI=
=+jY2
-----END PGP SIGNATURE-----

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