<<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.licenses in the
How do you know, which libraries we have are covered by
legal/ directoryI 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?can you see
E.g. if you have an excalibur.*.jar or a commons-*.jar, how
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.that this is covered by the LICENSE.Avalon resp. the for jakarta commons?
Yes, but then you need some (simple) matching algorithmen to test the availability of a license.
Well, this is transient issue. But I'd expect all excalibur-* libraries to be re-released with license v2 more or less simulteneously.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.
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)
Yepp :)There was the strong feeling in the pmc list days ago that we(and we had strong feelings against it as well)
Sure.Possible, if license file starts with (LICENSE.excalibur) or ends with (excalibur.LICENSE) beginning of the JAR file name (excalibur-bla-bla-bla).need a tool to check if every lib in our cvs is covered by a license. With the current structure, this is impossible.
Sure, but not as easy :)One license per project is more appropriate, and checking is still possible.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.
But from the users POV, licenses are all spread across module - instead of one (convinient) location.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.
Agreed. But users might not use all modules/blocks and don't need all licenses.
Yes :) - No of course not, we can change everything back again.Oops. Did I miss my chance?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... :)
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?
Well, it's really not so important; I guess it's matter of taste.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.
:) 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
