Daniel Joyce wrote:
>>True.  But what constitutes "application source" is muddy with
>>Smalltalk.  I believe that is Andrew's point.  Because of that, I
>>personally wouldn't touch GPL code for a Smalltalk image, if it were
>>my decision.
>>
>>However, note that I am talking about LGPL rather than GPL
>>(specifically in the context of GLORP having an LGPL license), and
>>LGPL has a more liberal license than GPL.
>>
>>Nevin
> 
> 
> I would say the changesets that impliment said code.
> 
> A LGPL library can call Kernel functions on a NON-GPL OS. That does not 
> require that the source of the OS has to be released too. ( Gnu C libs 
> on Solaris )
> 
> Likewise, LGPL classes can call code in non-Gpl classes, that does not 
> require the source to those non- LGPL classes be released either.
> 
> Likewise, a propietary library can call functions in LGPL libraries too 
> w/o being LGPL.
> 
> So non-LGPL classes can call GPL classes.
> 
> The only REAL muddy place I see is the case where someone subclasses a 
> LGPL class. Would the subclass fall under the LGPL too, or since it's 
> still just calling a LGPL class, and so technically is not a LGPL class 
> too.
>

What about the case where someone adds a method to an LGPL'ed class? 
This method is part of their package and it's only called by their 
package.  All it is doing is making calls to parts of the LGPL'ed class. 
  We do this all the time in Smalltalk... the method is logically part 
of another package but attached to the LGPL'ed class.  Does that mean 
that method has to be LGPL'ed?  Does the whole package?

Julian

> -Daniel
> 


-- 
julian at beta4.com
Beta4 Productions (http://www.beta4.com)