cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)
Date Mon, 27 Jan 2003 01:03:38 GMT
Luca Morandini wrote:
> I mean, Cocoon already has some components relying on non-ASL
 > libraries (like the SAP ones or the JDBC drivers); had these
 > libraries to change, ASF wouldn't be able to fork them, hence
 > resorting to change the Cocoon components, which is what was
 > to be avoided in the first place.
> This underlines, I fear, a more general problem: to make Cocoon
 > more powerful it has to interface to as many software packages
 > as possible, which means it will, in some ways, come to depend
 > on them.
> As a long-time Cocoon user, I dare to say: the gain is worth the
 > risk !

As an old Apache fart, I'd say nope... Look at HTTPd land, modules 
relyng on something over which we have some kind of legal troubles with 
are not included in the distro, not included in the "core", not on our 
CVS... mod_auth_mysql, for example). I don't think they ever will...

> Getting back to the point: in the case of JFreeChartTransformer
 > the idea would be to treat it like the SAP components: put the
> transformer in the codebase and leave the non-ASL library out.
> Does it sound too risky a strategy ?

This community should not rely on my only judgement to evaluate the 
possible risks of a strategy... (I'm the one who put all those nasty 
bugs two years ago, and you had to work for 2 years, in more than 30 to 
get rid of them! :-) :-) :-)

And please note that already many raised the same issue with the SAPv3 
components (I can't find them in CVS, so, I assume they're not going to 
be "in" until those problems are solved)...

Steven said:

 > If license issues do not allow these components to be added to ASF
 > CVS, we could look and see whether they could be hosted at
 > (since yes, they would be a valuable addition to
 > Cocoon).

And I share Sylvain's point here:

 > we voted a cocoon-apps module to host Cocoon-related developments
 > that don't belong to the core. And this ultra-specific component
 > typically falls in this category.

Well, in the past, our fellow colleagues on HTTPd created 
<>. I believe that most people would prefer to 
see a similar solution for Cocoon rather than adding, and adding, and 
adding stuff to the main CVS tree. And indeed it would solve the 
"legalities" as well, relegating the problem to the end user...

   AxKIT solved all this mess even before starting... They use CPAN, we
   don't even have that... :-( :-( :-( :-(


To unsubscribe, e-mail:
For additional commands, email:

View raw message