incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <dkhayw...@gmail.com>
Subject Re: [VOTE] Apache Isis release candidate 0.1.2-RC3-incubating
Date Wed, 08 Jun 2011 12:41:30 GMT
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<dkhaywood@gmail.com>  wrote:
>

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message