[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Benjamin
Subject: Re: GPL licenced Java application using non GPL jars (libraries)
Date: Tue, 23 May 2006 12:15:05 +0100
User-agent: Mail/News 1.5 (Windows/20051206)

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.


David Kastrup wrote:
Benjamin <> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]