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 <[EMAIL PROTECTED]> To: Dave Turner <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Regarding Java and the LGPL
Dear David, and others at [EMAIL PROTECTED],
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
