Re: [xml-dev] Re: licensing ... [Re: binary XML API and scientificuse cases [Re: [xml-dev] [ANN] nux-1.0beta2 release

[Aleksander Slominski <aslom@cs.indiana.edu>]

that should get all this clarified:

http://www.gnu.org/licenses/lgpl-java.html

so finally there is one official FSF link to refer when discussing java 
and LGPL.

alek

Stephen D. Williams wrote:

> I think that I'm pretty clear on GPL/LGPL; I've been part of these 
> kinds of discussions for a very long time, since the posting of the 
> first GPL.  I actually used both commercial Emacs products (CCA and 
> Unipress I think they were called) at work at GE Lighting in 1985; 
> products that caused Richard to write GNU Emacs and the GPL 1.0.  I've 
> also imported GPL/LGPL software into several large companies over the 
> years so I jump into this discussion out of long habit.
>
> You are right that the one question asked specifically about Java and 
> GPL, which was probably an oversight by the questioner.  The last 
> sentence of Eben's answer however makes it clear that LGPL+Java 
> wouldn't be a problem.  His answer on LGPL was: "If the author of the 
> other code had chosen to release his JAR under the Lesser GPL, your 
> contribution to the combined work could be released under any license 
> of your choosing."
>
> sdw
>
> Cutler, Roger (RogerCutler) wrote:
>
>> I believe that there is some confusion here between GPL and LGPL. Or at
>> least if you folks aren't confused you are confusing me, and by
>> extension possibly others.  Note that the notes below differ in which
>> one they refer to, and some of the links in other postings have, I
>> believe, been to discussions of GPL whereas the initial question was, I
>> think, about LGPL.  As I understand it GPL and LGPL are different, and
>> LGPL is weaker than GPL.  See, for example,
>> http://www.opensource.org/licenses/lgpl-license.php, which I beieve is
>> the "authoritative source" on LGPL somebody was asking for earlier.
>>
>> Just speaking personally, LGPL may be weaker than GPL, but I read the
>> document referenced above and I must confess that I still find it a bit
>> scary.  I do understand that many people are comfortable with these
>> licenses, but I think it's really a good idea to understand them clearly
>> if you are going to have anything to do with software using them.
>>
>> -----Original Message-----
>> From: public-xml-binary-request@w3.org
>> [mailto:public-xml-binary-request@w3.org] On Behalf Of Stephen D.
>> Williams
>> Sent: Monday, November 22, 2004 10:47 PM
>> To: John Cowan
>> Cc: xml-dev@lists.xml.org; public-xml-binary@w3.org
>> Subject: Re: licensing ... [Re: binary XML API and scientific use cases
>> [Re: [xml-dev] [ANN] nux-1.0beta2 release
>>
>>
>>
>> No, that is not right.  Eben, who as I mentioned often represents FSF in
>>
>> some sense and as a technical law professor should know, didn't draw 
>> that distinction.  I would argue that it is an artificial semantic 
>> conclusion.
>>
>> LGPL allows you to use a library  in a program (or another library) that
>>
>> has any license, but not distributing a modified library without 
>> source code.  Using a library means any use, while modifying it means 
>> actually changing the source code that went into the library.
>>
>> Subclassing is not different semantically from creating a new class with
>>
>> an instance of the LGPL'd class, creating a corresponding public 
>> method for every public method in the original class, and calling, 
>> with or without additional semantics, the corresponding LGPL'd 
>> method.  Both simply use the LGPL'd class without modifying its 
>> source code.
>>
>> The intent of LGPL is to allow use of any kind in any kind of program 
>> while maintaining the integrity of the LGPL'd library.  If you 
>> include the library and decide to call one of your own methods 
>> instead of one in
>>
>> the library, you haven't distributed a modified version of the library.
>>
>> You could in fact distribute a binary-only commercial library or 
>> application that uses the unmodified LGPL'd library.
>>
>> sdw
>>
>>
>> John Cowan wrote:
>>
>>  
>>
>>> Stephen D. Williams scripsit:
>>>
>>>
>>>
>>>   
>>>
>>>> Eben:
>>>>
>>>> The language or programming paradigm in use doesn't determine the 
>>>> rules
>>>> of compliance, nor does whether the GPL'd code has been modified. 
>>>> The situation is no different than the one where your code depends on
>>>>     
>>>
>> static  
>>
>>>> or dynamic linking of a GPL'd library, say GNU readline. Your code, in
>>>>     
>>>
>>
>>  
>>
>>>> order to operate, must be combined with the GPL'd code, forming a 
>>>> new combined work, which under GPL section 2(b) must be distributed 
>>>> under the terms of the GPL and only the GPL. If the author of the 
>>>> other code
>>>>     
>>>
>>
>>  
>>
>>>> had chosen to release his JAR under the Lesser GPL, your contribution
>>>>     
>>>
>> to  
>>
>>>> the combined work could be released under any license of your
>>>>     
>>>
>> choosing,  
>>
>>>>  
>>>>     
>>>
>>> But that leaves open the question of subclassing.  If some 
>>> application classes are subclasses of classes in the LGPL library, 
>>> does that make the total application a "work based on the library"?  
>>> The FSF seems to think so (as does the Apache Software Foundation), 
>>> because a Java program is essentially one big library.
>>>
>>>
>>>
>>>   
>>
>>
>>
>>  
>>
>
>


-- 
The best way to predict the future is to invent it - Alan Kay