Hi! We need this only if we _distribute_ those 3rd party binaries. As long as we dont package those, we don't care.
LieGrue, strub --- On Wed, 6/8/11, Dan Haywood <[email protected]> wrote: > From: Dan Haywood <[email protected]> > Subject: Re: [VOTE] Apache Isis release candidate 0.1.2-RC3-incubating > To: "Mark Struberg" <[email protected]> > Cc: [email protected], [email protected] > Date: Wednesday, June 8, 2011, 12:41 PM > 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: > > >
