What about LGPL? Re: Compatibility of the AFL with the GPL
Andrew C. Oliver
acoliver at apache.org
Mon Mar 17 13:52:34 UTC 2003
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
More information about the License-discuss
mailing list