cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: problems starting 2.1.6-dev
Date Mon, 18 Oct 2004 18:38:46 GMT

On 18 Oct 2004, at 18:27, Stefano Mazzocchi wrote:

> Sylvain Wallez wrote:
>> Stefano Mazzocchi wrote:
>>> Sylvain Wallez wrote:
>>>> Instead of creating yet-another-small-project at 
>>>> (like my own CVSSource), what about creating a general-purpose 
>>>> project that would host all interesting cocoon-releated things we 
>>>> cannot host at the ASF because of license problems?
>>> What about lobbying about changing the silly LGPL allergy that the 
>>> ASF has instead? Being a director might help at times, you know, 
>>> that's what your (member's) votes were for ;-)
>> Well, Mr Director, IIRC there's a board meeting tomorrow.
> Wednesday.
>> Should this subject be added to the agenda?
> In fact, I'm going to.
>> The problem also is that the solution to this problem doesn't depend 
>> only on the ASF, but also on the FSF which is the mighty priest that 
>> gives the interpretation of the holy license texts.
> Not really. It's neither the FSF nor the ASF that decide if a license 
> contract is valid or not, it's a judge, in court. In lack of that, 
> each one has its own opinion.
> My opinion is that the spirit of the LGPL was that "if you add 
> functionality to the library, then you should give it back, if you 
> just use the library, your code doesn't have to".
> What does this translate to java? Pretty simple, in fact: if you 
> import a class is fine, if you implement an interface is not.
> I would like to change the ASF policy toward the LGPL saying that 
> "importing is ok, implementing is not". That means that if you 
> implement, your code has to be LGPL, then you can import that. The 
> spirit of the LGPL is maintained and the FSF will not have a problem 
> with it, IMO.
> Now, whether or not the board digests this is yet another issue and 
> I'm going to find out soon.

Hi Stefano

I applaud your attempt to get this ridiculous situation sorted out !!!!

However, in this particular case, Pier's code actually implements 
Hibernate interfaces:

	public class HibernateCache implements net.sf.hibernate.cache.Cache
	public class HibernateCacheProvider implements 
	public class HibernateFactory implements 
So guys, I suspect we still need a cocoondev repo for this, even if 
Stefano is successful in what he says above.

Unless that code could be contributed to Hibernate ;)

Good luck anyway !!!

regards Jeremy


                   If email from this address is not signed
                                 IT IS NOT FROM ME

                         Always check the label, folks !!!!!

View raw message