Just to keep everyone clear, the "AFL" in this week's discussion is the Academic Free License:
http://www.opensource.org/licenses/academic.php
it is NOT the Apache License.
The Apache license as it currently stands is not compatible with the GPL, we recognize this; whether it's compatible with the LGPL depends on what one's definition is of interfaces and derivative works. We're looking at a second rev of the Apache license that will be GPL compatible (and thus also LGPL compatible). No promises.
Oh Thanks for the correction Brian. I thought AFL was just another misnomer abbreviation for the Apache license. (I've seen it APL, ASL, AL, APSL and other ways so I thought AFL was just Apache Foundation License)..
Note that I mean to ask whether ASL and LGPL are compatible in the specific case of Java such that the LGPL terms do not extend to the client(software) of a software package with import statements to the LGPL'd jar based on Roy's comments.
Java(NON-LGPL->ASL.jar->LGPL.jar)
import com.asl.* ->import com.lgpl.*-> LGPLSince it's the Trove4J folks who would have standing in any case involving LGPL-nonconformance, *not* the FSF, it really only matters how the Trove4J folks intend the LGPL's language around derivative works and interfaces to be interpreted. If the Trove4J developers gave you a statement to the effect that they do not intend for applications that use the Trove4J interfaces to be considered derivative works, then your problem is solved, and you don't need to wait for RMS or Eben. If instead they want some sort of "canonical" interpretation from the authors of the GPL, then all of us have to wait, no matter what opinions are aired on license-discuss.
What I'm seeking is a statement regarding these issues with the LGPL license:
" 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. " - (Roy Fielding)
Trove4J is just one case that I'm interested and I intend to take it up with them at a latter point. I do not proclaim to have a profound understanding on why the Apache Software Foundation draws the distinction between linking HTTPD to LGPL'd libraries and java to
LGPL'd libraries. While I understand that the nature of import is
inherently different than include in that it ties you to a specific
interface, I would regard the situation with IFDEFs which tie you to
a specific libaries headers on a specific platform to be similar in nature.
In the past when I've asked Java authors if they'd kindly state their intention/interpertation, I've received a curt "thats what LGPL means doofus" or something to that effect. However as I'm sure you're aware the ASF does not regard it as so clear cut.
There are a number of situations where being able to work with LGPL would be nice for POI. (Not to mention being importable from GPL code, but I understand that won't be resolved any time in the near future). For brevity I'll exclude them as they are either a derivative or moot if the above question is answered.
Furthermore, I would like to see this cleared up so that Java folks who believe in OpenSource and Free Software can work together whenever minds meet.
Thanks again for the correction Brian. I appreciate any assistance you can render in clearing up this longstanding issue.
Thanks,
Andrew C. Oliver
Brian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
-- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
