Hi Mark / other mentors / anyone,
Two questions:
1. Just looking into the NOTICES file and the reference you say is
needed for reciprocal (category-B) licenses.
I had a look at OpenJPA and OpenWebBeans (2 projects that I think you
are involved in), and they reference dependencies with other licenses in
NOTICES, eg [1] and [2]
However, it would seem that this is wrong. According to the latest v1.4
version of maven-remote-resources-plugin, the NOTICES file should simply
contain the Apache License text. see this ticket [3]. I think that the
legal-discuss thread that is mentioned in this ticket is [4].
My understanding therefore is that this information should go into the
DEPENDENCIES file. The latest org.apache:apache-jar-resource-bundle:1.4
does still allow DEPENDENCIES to be customised using a
${postDepListText} property.
Does this make sense? Would you rather I did this some other way?
~~~~~~~~~~~~~~
2. Although I've removed our direct dependency on XOM (LGPL licensed,
[5]), there is still a transitive dependency (we use Concordion [6])
which uses XOM. I really want to provide an integration with
Concordion, however. So, would it be reasonable to:
a) exclude the XOM dependency in our reference to Concordion, ie:
<dependency>
<groupId>org.concordion</groupId>
<artifactId>concordion</artifactId>
<exclusions>
<exclusion>
<!-- excluded because of LGPL; end-developer must include in POM file
directly -->
<groupId>xom</groupId>
<artifactId>xom</artifactId>
</exclusion>
</exclusions>
</dependency>
and then
b) in our *archetype* template, effectively add the dependency back in
(ie, in
quickstart-archetype/src/main/resources/archetype-resources/tests-bdd/pom.xml):
<dependencies>
...
<!-- BDD Viewers concordion dependencies -->
<dependency>
<groupId>org.apache.isis.viewer</groupId>
<artifactId>bdd-concordion</artifactId>
<scope>test</scope>
</dependency>
<!-- NB: XOM is licensed under LGPL. -->
<dependency>
<groupId>xom</groupId>
<artifactId>xom</artifactId>
<version>1.2.5</version>
</dependency>
</dependencies>
I think this is a valid and legally correct thing to do, but it is
somewhat sneaky so I wanted to raise it.
~~~~~~~~~~~~~~
Thanks,
Dan
[1] http://svn.apache.org/viewvc/openjpa/trunk/NOTICE?view=markup
[2] https://svn.apache.org/repos/asf/openwebbeans/trunk/NOTICE
[3] http://jira.codehaus.org/browse/MRRESOURCES-32
[4]
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200803.mbox/%3C1204576577.7635.76.camel@marlow%3E
[5] http://www.xom.nu/license.xhtml
[6] http://concordion.org/
On 06/06/2011 11:56, Mark Struberg wrote:
Hi Dan!
Are you ready for the next iteration? ;)
I fear I have to vote
-1
on the release.
I'm only looking at the sources distribution.zip since this is the only
official thing an Apache Software release contains (all other binaries are just
nice goodies, but not part of the official release).
https://repository.apache.org/content/repositories/orgapacheisis-042/org/apache/isis/isis/0.1.2-RC3-incubating/
1.) The source zip contains a file apache-rat-0.8-SNAPSHOT.jar. This is nothing
which belongs to our source release.
I've also deleted it from our SVN repo.
The other parts look pretty good so far!
* key is fine
* sha1 is ok
* md5 is ok
* rat passes
* check on a few random samples for *.properties, pom.xml, *.java all had valid
ALv2 headers
* LICENSE file is ok
A few parts are not 100% ok yet:
NOTICE file is ok _IF_ we only ship ALv2 licensed dependencies or category A
licenses as noted in [1].
IF we ship differently licensed jar dependencies in our binary distribution or
samples or 'shade' them into an own private package within isis, then we must
imo also mention those licenses in our NOTICE files.
If we only reference those deps via maven, then not.
Those are the following files:
org.hamcrest:hamcrest-library:jar -> BSD
javax.mail -> CDDL
asm -> BSD
jmock -> BSD style
dom4j -> MetaStuff license (BSD style)
org.owasp.esapi:esapi -> BSD
json -> JSON license (BSD style)
org.htmlparser -> CPL-1.0. This worries me a bit, since it falls under the
category B (reciprocal) As far as I interpret the cat B section, we must add this
to our NOTICE file, isn't?
xom:xom -> LGPL -> BLOCKER this is a catX license which we must not depend
upon! This seems to come as transitive dependency from org.owasp.esapi:esapi. Can we
exclude xom:xom without breaking functionality?
There are also a few javax.* dependencies from the java.net repo. Usually those
packages are CDDL, thus we should replace them with packages from
geronimo-specs [2]
You can easily check the dependencies yourself too with
$> mvn dependency:list
LieGrue,
strub
PS: sorry that you have to do a release run once again, but if it helps: doing
a proper review is not much less work :D
[1] http://www.apache.org/legal/3party.html
[2] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
--- On Mon, 6/6/11, Dan Haywood<[email protected]> wrote:
