What about LGPL? Re: Compatibility of the AFL with the GPL

[Andrew C. Oliver]

My appologies.  I was confused between ASL and AFL.  I interperated the 
latter to be a misnomer
referring to the first.  It is currently the position of the Apache 
Software Foundation that the terms of
the LGPL in the case of Java might cause section 6 of that license to 
bind the ASL licensed software.
(and only in the case of Java)

-Andy

Lawrence E. Rosen wrote:

>The AFL has the same effect with the LGPL as it does with the GPL.  I
>contend it is also fully compatible.  All are free licenses.  
>
>The issue has nothing to do with linking.  
>
>/Larry Rosen
>
>  
>
>>-----Original Message-----
>>From: news [mailto:news at main.gmane.org] On Behalf Of Andrew C. Oliver
>>Sent: Friday, March 14, 2003 5:12 AM
>>To: license-discuss at opensource.org
>>Subject: What about LGPL? Re: Compatibility of the AFL with the GPL
>>
>>
>>Lawrence E. Rosen wrote:
>>    
>>
>>>Richard,
>>>
>>>Today you finally gave public reasons for your assertion 
>>>      
>>>
>>that the AFL 
>>    
>>
>>>is incompatible with the GPL.  Because you are simply wrong 
>>>      
>>>
>>on the law 
>>    
>>
>>>and wrong-headed on a matter of principle, I must file this public 
>>>response.
>>>      
>>>
>>So I think I understand the controvery regarding GPL and why 
>>GPL and ASL 
>>(aka AFL) don't work together.  What about LGPL and ASL in 
>>the situation 
>>of Java?  Apache has a long standing ban on LGPL being used in Java 
>>projects and I want to know if its justified.
>>
>>I asked if Eben Moglen's comments in slashdot on the subject were 
>>sufficient to lift the ban and Roy Fielding responded:
>>
>>"
>>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. "
>>
>>Most authors of Java software using the LGPL license intend to allow 
>>linking (basically the use of the java "import" of classes in 
>>their jar 
>>file).  Who is right?  Apache with their insistance that the LGPL is 
>>"viral" for Java software or the masses who think LGPLing their code 
>>causes modifiers to contribute but linking/use to be 
>>uninhibited even to 
>>proprietary software?  (where the term "link" is not wholely 
>>appropriate 
>>for Java, I interperate it to mean including a jar in the 
>>classpath at 
>>compile-time and runtime and having import statement naming classes 
>>inside of a jar)
>>
>>On a personal note, clearing this up would help me greatly as I would 
>>like to use Trove4J (http://trove4j.sourceforge.net/) in the Apache 
>>project I founded (http://jakarta.apache.org/poi) instead of our own 
>>collection classes.  Secondly, I am considering releasing an upcoming 
>>Java codebase in LGPL or GPL, and while I understand the full 
>>ramifications of GPL, I do not feel I fully understand the 
>>ramifications 
>>of LGPL with regards to this issue.
>>
>>I would greatly appreciate if Mr. Stallman and Mr. Rosen 
>>could provide a 
>>definitive answer on this.
>>
>>Thank you,
>>
>>Andrew C. Oliver
>>
>>
>>--
>>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