[Kaffe] can the classpath project be used with Kaffe.

[Godmar Back]

Note: I'm reducing noise levels by combining three answers in one 
convenient email.  Other than that, the 'hit "d" for delete' disclaimer
still applies.

Alexandre wrote:
>
> On Feb 10, 1999, Godmar Back <gback at cs.utah.edu> wrote:
> 
> > I can take pieces of classpath, add my own stuff and sell it as proprietary
> > software without releasing the source code to the pieces I added?
> 
> Nope, you have to release the source code of the modified library, but 
> not of the program that uses the library.
> 
> > I still don't see the difference:  everything that's added to both 
> > classpath's and kaffe's libs would be contaminated (though RMS doesn't
> > like that term) and the source to it would have to be released if someone
> > wished to distribute it, for monetary reasons or not.
> 
> The difference between GPL and LGPL is that, for an LGPLed library,
> its license does not require programs linked with it to be L?GPLed,
> while GPL does.

But later he said:

> > a) your java.beans/kaffe's java.io+lang
> > b) your java.beans/classpath's java.io+lang.
> 
> > What you're saying is that you could keep your java.beans proprietary
> > in scenario b), but not in a)?
> 
> Yes, as long as someone can show that you used a)

So java.beans in a) would be a program that only uses classpath's 
java.io+lang, while java.beans in b) would be linked against kaffe's 
java.io+lang and hence subject to contamination?

But I assume that if you created a modified version java.io' of 
classpath/kaffe's java.io, then there is no question that you would 
have to distribute the source under the LGPL/GPL?

> 
> > Both classpath and kaffe's libs can run proprietary Java
> > applications without requiring their developers to release the
> > source code.
> 
> It is possible to interpret the `linking' terms of the GPL in a sense
> that disallows this.
> 

That's what I thought this discussion was about and that's why I seconded
your request for a clarification.  However, I thought it was clear but 
now it's not clear at all.  What is the boundary that code would have to
leave in order to be not contaminated?

Is it a file boundary?  Directory boundary?  Package boundary?  Extension
boundary?  The library/application boundary?  Does it require direct 
symbolic references to be considered linked?  What about classloaders 
that perform bytecode rewriting at run-time?

What if your java.beans uses gnu.whatever, but it also relies on a
java.io, which in turn relies on gnu.whatever.  Does that change the
situation?

Then Moses wrote:
> I assume you are talking about releasing the code for use in both the
> classpath and kaffe libs. In this case, I would think you would need
> to release it under the LGPL for use in Classpath. If it was going to
> be distributed with Kaffe, then you would need to release it with a
> GPL license. Of course this all depends on how you define the
> "linking" terminology in the GPL. I am facing this situation right
> now as I am currently working on a replacement for the
> sun.tools.jar.Main program that I would like see added to both the
> Kaffe and Classpath projects.

Moses, if you own the code, you can release it under as many licenses
as you like.  We'd certainly like to have a jar replacement in Kaffe.
Licensing issues, no matter how exciting they may be, will not prevent
us from including your work.

	- Godmar