Re: GPL licenced Java application using non GPL jars (libraries)

[Benjamin]

Currently we use interfaces (i.e. stubs) where the non GPL code is used 
so this is possible (however no GPL alternative code exists and the 
interfaces would need to be implemented by the deriving code developers, 
this should be reasonably trivial as it is database access and logging).

The problem lies that one of the future project goals will make heavy 
use of Spring (Apache licensed) libraries in changing the foundations of 
the software. Spring is needed to save a *huge* amount of refactoring 
and implementation work. (Spring is a framework of libraries).

If what you say below is true regarding stubs and pure GPL alternatives 
then to cause the least amount of pain and inconvenience for the 
developers of the project the GPL would have to be avoided. I see no 
reason why the design of the software should change to accommodate the 
licence (i.e. providing interfaces, making the integral foundation of 
the code modular - all extra work, especially as Spring is huge), or why 
the wheel should be reinvented when technically Spring is also free and 
open source.

Again I'm on the fence with GPL and CPL. I like the assurances of GPL, 
but its ambiguity is making me favour the CPL.

I guess at the end of the day all I have to go on is the mostly pro GPL 
answers on here, (no answer yet from GNU) or the assurances of the CPL 
which has the backing of IBM.

Benjamin

David Kastrup wrote:
> Benjamin <na@na.com> writes:
>
> > That seems to make sense.
> >
> > Would this mean I must also provide GPL licenced alternatives for
> > those people who wish to adhere to just GPL side of the licencing or
> > can I leave this up to them to implement (and of course remove the
> > references imports-includes in the code)?
>
> The metric in generally is that a GPL-compatible library is actually
> available fitting the same API.  Whether it is implemented by you or a
> third party is irrelevant, but it must not be purely hypothetical.
>
> I think this has been the situation with the readline library (which
> is under the GPL).  Somebody created some stubs that provided
> basically the same interface, and this made software not derivative on
> readline unless explicitly linked with it.
>
> Of course it's not really in the spirit of the GNU project to do such
> trickery for the sake of accommodating proprietary products, but that
> seems to be the legal borderline where at least the FSF sees no
> reasonable chance in pursuing stuff legally.