cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: Licenses of Libraries [was Re: cvs commit: cocoon-2.1/src/blocks/html/lib jtidy-04aug2000r7-dev.jar.license]
Date Sun, 29 Feb 2004 19:30:51 GMT
What about just adding an element for licence location to jars.xml?  e.g.,

<<file>
        <title>Avalon Excalibur DataSource</title>
        <description>Part of avalon, it is a set of classes and patterns 
that support high level server development.</description>
        <used-by>Cocoon</used-by>
        <lib>databases/lib/excalibur-datasource-1.1.1.jar</lib>
    <homepage>http://avalon.apache.org/excalibur/</homepage>
    <license>legal/LICENSE.avalon</license>
</file>

Geoff

Carsten Ziegeler wrote:

>Vadim Gritsenko wrote: 
>  
>
>>>Was it? It seems that it is more user friendly but I think it's not.
>>>How do you know, which libraries we have are covered by 
>>>      
>>>
>>licenses in the 
>>    
>>
>>>legal/ directory
>>>
>>>      
>>>
>>I had not said anything about dev-friendly :-)
>>
>>    
>>
>:) But what about board-friendly? How can they see if we have
>appropriate licenses?
>
>  
>
>>>and which library is coverd by which file?
>>>E.g. if you have an excalibur.*.jar or a commons-*.jar, how 
>>>      
>>>
>>can you see 
>>    
>>
>>>that this is covered by the LICENSE.Avalon resp.
>>>the for jakarta commons?
>>> 
>>>
>>>      
>>>
>>I would expect LICENSE.excalibur and LICENSE.commons files to 
>>be in legal/ Alternatively, jars should be named 
>>avalon-excalibur-*; so there would be no place for ambiguity, 
>>one way or another.
>>
>>    
>>
>Yes, but then you need some (simple) matching algorithmen to
>test the availability of a license.
>
>  
>
>>>Even worse with the next releases of Apache projects, they use
>>>the new 2.0 license, so in the case of Avalon you have subprojects
>>>that have been released with the old and others that have been
>>>released with the new one. THen you need a way to tell which
>>>library uses what license.
>>> 
>>>
>>>      
>>>
>>Well, this is transient issue. But I'd expect all excalibur-* 
>>libraries 
>>to be re-released with license v2 more or less simulteneously.
>>
>>    
>>
>No, that will not happen! A release is only made if required, so
>as long as an excalibur subproject doesn't change there will be
>no new release (we could of course ask for it or do it ourselves)
>
>  
>
>>>There was the strong feeling in the pmc list days ago that we
>>> 
>>>
>>>      
>>>
>>(and we had strong feelings against it as well)
>>
>>    
>>
>Yepp :)
>
>  
>
>>>need a tool to check if every lib in our cvs is covered
>>>by a license. With the current structure, this is impossible.
>>> 
>>>
>>>      
>>>
>>Possible, if license file starts with (LICENSE.excalibur) or 
>>ends with 
>>(excalibur.LICENSE) beginning of the JAR file name 
>>(excalibur-bla-bla-bla).
>>
>>    
>>
>Sure.
>
>  
>
>>>So, we need one license file per library and the easiest way
>>>is to give it the same name as the library itself. So, checking
>>>is easy.
>>> 
>>>
>>>      
>>>
>>One license per project is more appropriate, and checking is 
>>still possible.
>>
>>    
>>
>Sure, but not as easy :)
>
>  
>
>>>And we saw (with JISP, but also with the ASF projects changing
>>>to 2.0) that licenses for a project change. I bet that usually
>>>we only update the jar file but never touch the license that
>>>our stored somewhere else. WIth this approach, you have at
>>>least to rename the license and this should help in keeping
>>>the license upto date.
>>> 
>>>
>>>      
>>>
>>But from the users POV, licenses are all spread across module 
>>- instead 
>>of one (convinient) location.
>>
>>    
>>
>Agreed. But users might not use all modules/blocks and don't need
>all licenses.
>
>  
>
>>>This has discussed a while ago I think on the committers list
>>>(or somewhere else) and the output was that each jar should
>>>have the license directly next to the jar.
>>>
>>>I mentioned this days ago on the PMC list and noone disagreed,
>>>so... :)
>>> 
>>>
>>>      
>>>
>>Oops. Did I miss my chance?
>>    
>>
>Yes :) - No of course not, we can change everything back again.
>It's the old problem (this is no offense against you, Vadim), 
>only a few people are interested in this
>topic. It's been days since Dims informed us that we don't have
>all licenses! (We even didn'T notice that ourselves!)
>And what did we do?
>
>  
>
>>    
>>
>>>Ok, I really thing that we need a license file per lib. Otherwhise
>>>tracking is impossible. And giving this file the same name as
>>>the jar (including version) makes imho sense as well.
>>>
>>>If these are stored in the /legal directly or right next to
>>>the jars is imho not so important.
>>> 
>>>
>>>      
>>>
>>Well, it's really not so important; I guess it's matter of taste.
>>
>>    
>>
>:) Yes, exactly. I really see your points and they are of course valid.
>And if the general taste prefers your vision, than I'm still happy
>and not against it, but then someone has to do something.
>
>So, let's see what happens...
>
>Carsten
>  
>

Mime
View raw message