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:58:19 GMT
We don't distribute anything, so I guess we need no NOTICE or 
DEPENDENCIES entries, then.

What I'm now confused about is those banned LGPL dependencies such as 
XOM.  We don't distribute those either.  So what's different - why are 
they banned?

Dan


On 08/06/2011 13:49, Mark Struberg wrote:
> 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<dkhaywood@gmail.com>  wrote:
>
>> From: Dan Haywood<dkhaywood@gmail.com>
>> Subject: Re: [VOTE] Apache Isis release candidate 0.1.2-RC3-incubating
>> To: "Mark Struberg"<struberg@yahoo.de>
>> Cc: isis-dev@incubator.apache.org, dan@haywood-associates.co.uk
>> 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<dkhaywood@gmail.com>
>> wrote:

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