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)

[Andrew C. Oliver]

> 
> 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.*-> 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 
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