Subject: Compatibility of the ASL and LGPL in the specific case of Java WAS: (Re: What about LGPL? Re: Compatibility of the AFL with the GPL)
From: "Andrew C. Oliver" <>
Date: Fri, 14 Mar 2003 16:32:03 -0500

> Just to keep everyone clear, the "AFL" in this week's discussion is the
> Academic Free License:
> 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 

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.

      import com.asl.*  ->import com.lgpl.*-> LGPL

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

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 

Thanks again for the correction Brian.  I appreciate any assistance you 
can render in clearing up this longstanding issue.


Andrew C. Oliver

> 	Brian
> --
> license-discuss archive is at

license-discuss archive is at