cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: cvs commit: cocoon-2.1/lib jars.xml
Date Wed, 15 Oct 2003 09:56:34 GMT

On Wednesday, Oct 15, 2003, at 06:23 Europe/Rome, Stephen McConnell 
wrote:

>
>
> Geoff Howard wrote:
>
>> Geoff Howard wrote:
>>
>>>
>>> But a browse around ibiblio reveals:
>>> http://www.ibiblio.org/maven/jms/
>>> http://www.ibiblio.org/maven/jndi/
>>>
>>> exist but don't have any jars.
>>
>>
>> And looks like Stephen knows why - I had assumed ASF was being 
>> conservative (wisely, I assume) and that ibiblio would be able to 
>> redistribute.
>
>
> The ibiblio site is no different from Apache with respect to license 
> obligations. When the Maven project started its bid to TLP is 
> basically had to clean up its act bacause the content on ibiblio would 
> by implication be resource managed by an Apache PMC - i.e. 
> due-diligence required.  The Maven guys went though a process of 
> cleaning up the content on ibiblio.org/maven and the result of the 
> cleanup is the missing jar files.
>
>>
>> I guess the best bet would be to grab the openjms package which 
>> contains everything needed?  Unless it can be automated we'll need 
>> some work on the block to make sure it compiles and cocoon can start 
>> up without that part.  Not sure how to pull that off.
>
>
> One approach you may want to consider is to package the content into a 
> bar file, register the bar in cvs, add an ant task to download and 
> expand the bar, and invoke bar expansion in the build. Providing you 
> access the resources via a local repository, you are respecting the 
> Sun licensing conditions because your accessing the resources relative 
> to a particular application context that has a legal usage engagement. 
>  What this means is that whoever packages the jms libraries (or 
> whowever accepts responsibilioty for the packaging) agrees to 
> represent Sun should a problem arise.  If the bar contribution to 
> Cocoon is by a committer covered by a CLA, then the responsibility for 
> the application usage rests with Apache.

Nother approach is to rewrite the libraries from the javadocs under an 
apache license (the Servlet API code that is shipped with tomcat is 
licensed under the apache license and yet covers javax.servlet... if 
you pass the test, it's valid)

but I know this isn't really a sexy approach ;-)

--
Stefano.


Mime
View raw message