LGPL reciprocity terms still unclear

IN A RECENT post to the POI developers list, Andrew Oliver interpreted a statement made by Dave Turner of the Free Software Foundation regarding the reciprocity provisions of the LGPL license when applied to Java.

Oliver's conclusion was that linking through import statements would indeed be covered under the "reciprocity provisions" in the LGPL. This news has reawakened debates in the software community regarding the risks of the LGPL and the failure of the FSF to clarify the matter.

Oliver has now released the entirety of Turner's emailed response, which begins:

"> Dear Mr. Turner: > > Brett Smith referred me to you regarding a question regarding the Lesser Gnu > Public License (LGPL) in regards to Java. It is the interpretation of most > of the open/free software communities that the use of a "jar" file by a > piece of software linked via a Java "import" statement does not bind the > linking work under the terms of the LGPL. The Apache Software Foundation, > presently takes a more conservative view and thus projects of the ASF are > not allowed to link/distribute LGPL programs into Java projects of the > foundation. This sort of linking falls under section 6 of the LGPL."

In his first response, Dave Turner refers Oliver to the license. He does not confirm Oliver's assertion and to assume so is dangerous. Presumably, Oliver asked Turner the question in the first place because the license was unclear. The second part of the letter continues:

"> Roy Fielding offered the following description of the issue: > > > " > > No. What the FSF needs to say is that inclusion of the > > external interface names (methods, filenames, imports, etc.) > > defined by an LGPL jar file, so that a non-LGPL jar can make > > calls to the LGPL jar's implementation, does not cause the > > including work to be derived from the LGPL work even though > > java uses late-binding by name (requiring that names be > > copied into the derived executable), and thus does not (in > > and of itself) cause the package as a whole to be restricted > > to distribution as (L)GPL or as open source per section 6 of > > the LGPL. " > > Is this statement true with regards to the use of LGPL Java libraries by > non-LGPL Java libraries? I appreciate your assistance in this matter. If I understand the statement correctly, yes -- that's exactly what section 6 is for."

Again, Turner has managed to evade the question. Far from making a simple, clear-cut definitive answer, he has wrapped his answer with two clauses. The first, "If I understand the statement correctly" shows either that he does not fully comprehend the question, is unwilling to admit that he understands the question, or that he is unwilling to write a simple and authoritative answer. The second, "that's exactly what section 6 is for", again refers the questioner to the license. He might be confirming Roy Fielding's assertion, or he might be confirming that section 6 covers it. Either way, his answer is wrapped in the "If I understand the statement" clause.

The LGPL license is unclear on its reciprocity requirements for software written in Java. Because the FSF has obfuscated the matter (if not deliberately then consistently), the issue remains a risk for software developers.

Which is why, to date, the Apache Software Foundation has yet to lift its prohibition on linking to LGPL libraries, binaries or including LGPL source code in its products.

Clear alternative from the OSI
Larry Rosen, the well known general counsel and secretary for the Open Source Initiative has definitively stated that with regards to its reciprocity provisions, "The Open Software License (OSL) can be used for the same purposes as the LGPL and the GPL".

Rosen further clarifies the matter by offering the Academic Free License, which

"addresses issues of patent, trademark, warranty, jurisdiction and venue, contributor recognition, etc., in ways entirely consistent with the "BSD" philosophy of open source. AFL-licensed software can be used in combination with any other software, open source *or* proprietary, for any purpose whatsoever, including to create derivative works. This new version of the AFL also helps eliminate possible confusion between academic-style licenses and reciprocal licenses [see, for example, the GPL, www.fsf.org/licenses/gpl.html, and the Open Software License (OSL), www.rosenlaw.com/osl2.0.html. Reciprocity requires that any Derivative Works be licensed under the same license as the Original Work. Reciprocal and non-reciprocal open source licenses ought to be the same -- except with respect to provisions dealing with reciprocity. Therefore, the new AFL is identical to the OSL except that the AFL does not contain a reciprocity provision. A redlined comparison of AFL2.0 and OSL2.0 is at http://rosenlaw.com/afl2.0-redline.pdf."

The inconsistencies surrounding the LGPL and GPL are a continued risk to the software community at large. The OSL and AFL resolve the matter quite thoroughly. µ

L'INQ
Oliver's original thread on the topic
The entirety of Turner's response
More on the OSL and AFL can be found in the license-discuss lists at OSI.