www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: Apache's LGPL Policy
Date Tue, 02 Aug 2005 23:16:41 GMT
I think for the question "we could put the LGPL JAR into bundled
distribution", the answer is NO!!

-- dims

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


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

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