www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <br...@collab.net>
Subject Regarding Java and the LGPL (fwd)
Date Fri, 31 Dec 2004 02:20:18 GMT

For what it's worth, here is the letter I sent to the FSF earlier this 
month asking for further LGPL clarification.  No response yet, but it's 
the holidays.

 	Brian

---------- Forwarded message ----------
Date: Sat, 18 Dec 2004 19:19:17 -0800 (PST)
From: Brian Behlendorf <brianb@apache.org>
To: Dave Turner <novalis@gnu.org>, licensing@gnu.org
Subject: Regarding Java and the LGPL


Dear David, and others at licensing@gnu.org,

Recently we noticed an addition to the FSF's web site:

   http://www.gnu.org/licenses/lgpl-java.html

We welcome this move by the FSF to educate and clarify.  We have projects at 
the Apache Software Foundation that are eager to be able to make use of 
LGPL-licensed Java works.  We respect the commonly-accepted intention of the 
LGPL, which is to ensure that improvements to the LGPL-licensed work can be 
made, while not encumbering the license of other works that use the 
LGPL-licensed work.  We also respect the right-to-tinker freedom embodied in 
section 6 of the LGPL, especially as with Java this is trivially easy to 
accomplish.

We feel, however, that the LGPL, and your clarification, still leave us with 
many questions.  It is also clear from the fact that several LGPL Java 
applications are dual-licensing with other "medium-strength copyleft" licenses 
like the MPL and CPL, or are adding additional terms to their LGPL license like 
the Hibernate project has, that these uncertainties remain.  Part of the 
problem is that the language in the LGPL is still specific to the world of 
compiled executables, and not as relevant to the world of bytecode interpreters 
and name-based loaders.

We'd like your feedback on a number of scenarios, as clearly as possible, so we 
can determine whether we can lift the existing moratorium on importing 
LGPL-licensed works.  Please let us know if any particular scenario needs more 
fleshing out; but the idea was to reduce the examples as tightly as possible.

In the following, A represents an Apache Software License-licensed
work, and L represents the LGPL-licensed works.  A would contain the
parts of L necessary to make import and inheritance references to L,
but it is only used when the user chooses to separately download L.
Assume that those interfaces are unique to L, not an implementation of
interfaces defined elsewhere.  A_s and A_c are the source code and
compiled forms of A, and L_s and L_c are the source and compiled forms
of L.

1) A_s is distributed from apache.org, without L anywhere nearby.
Despite the references to L in A_s, can we distribute A_s under the
license of our choosing?

2) A_c is distributed from apache.org.  It was compiled with L_c in
the classpath, so function signatures were checked.  Can we distribute
A_c under the license of our choosing?

3) A_s and L_s are combined into a single tarball and distributed.
Does section 5 of the LGPL, or section 6 of the LGPL, or neither apply
to the tarball as a whole?

4) A_c and L_c are combined into a single tarball and distributed.
Does section 5 of the LGPL, or section 6 of the LGPL, or neither apply
to the tarball as a whole?

5) Say a recipient downloads the tarball defined in question #3,
deletes L_s, and distributes A_s.  Can that recipient then follow only
the terms of copyright on A_s?

6) Say a recipient downloads the tarball defined in question #3,
deletes L_c, and distributes A_c.  Can that recipient then follow only
the terms of copyright on A_c?


We have our own interpretations and opinions of the answers to these
questions, and we think LGPL users have a set of interpretations as
well, but they differed so widely we felt there was a need to
understand your interpretation and how that maps to the language in
the LGPL.

Thanks,

 	Brian Behlendorf
 	Director, ASF

Mime
View raw message