On 28/07/2011 01:17, Ate Douma wrote:
Hi Paul, all,
I've finally found some time to review the release artifacts and
before I *will* vote +1 on it, I want to share some of my findings
concerning the current license/notice attributions and packaging in
general.
I'm sorry I didn't have time to properly review these much earlier but
there are several things concerning the handling of the license and
notice requirements which IMO could and probably should be done a
little bit different.
AFAIK, none of the suggestions I'd like to give below require
canceling this release, as one way or the other the *overall* coverage
of the license and notice requirements seem pretty good, albeit IMO
somewhat overdone in some area's.
So, please take the following suggestions as something to consider for
the next release. And to be clear, I'm not an absolute expert in this
area either, so I happily will hear others view on these. I'm not
claiming everything I say below is actually correct, they are just
represent *my* interpretation of what is needed, and what might be not.
* KEYS file packaged with every release artifact:
Having a KEYS file *within* a release artifact makes no much sense:
its whole purpose is to validate a signed release artifact itself, so
embedding it within is meaningless.
Most/all projects keep the KEYS file within svn outside the trunk
folders, e.g. like in the svn root folder or a separate sub folder
thereof,
e.g. like http://svn.apache.org/repos/asf/incubator/rave/KEYS.
ok, will note for next time
* wookie.war has DISCLAIMER/LICENSE/NOTICE/RUNTIME_LICENSE files in
root folder:
Having these files in the war root means these will be accessible as
web resources... While still pretty harmless in this case/release, its
a bad practice and could actually pose a security issue as everyone
can thereby find/read which runtime artifacts (including there
version) are in use.
The expected/advised location for these files would be under /META-INF.
will note for next time
* NOTICE/LICENSE/RUNTIME_LICENSE files in general:
The current ASF policy is that these files only need/should attribute
whatever is actually packaged (note: this equally concerns the svn
tree, which in itself can and should be regarded as a "distribution").
Anything not "packaged" need (should) not be attributed. These files
serve a legal purpose only, and anything not needed and/or redundant
will only make it more difficult to maintain and validate and properly.
Dependencies not packaged/distributed, but for instance needed (only)
for building is not required to be attributed in these files. If there
are specific (buid/runtime) requirements users should be aware of then
those should be mentioned and explained in additional README,
BUILD_NOTES, etc. files, only.
just to be clear, are you are talking about libraries we have used to
build the (war and standalone) binaries here and so don't need to be
mentioned in any of the licence files. Instead we would explain what is
needed in the README, BUILD_NOTES - and in theory would only be needed
to rebuild the source?
* License attribution to other ASF projects packaged sources/artifacts:
From a legal POV, this is not needed: the basic (required) NOTICE and
LICENSE attribution that the distribution includes ASF produces
software under the ASL 2.0 license already covers all legal requirements.
While mentioning each and every other ASF project source/artifact in
the LICENSE files is not harmful in anyway, it is a lot of extra and
unneeded effort not easy to maintain properly.
ok, will drop for next time
For example, the LICENSE file does mention the
shindig-common-1.1-BETA5-incubating.jar (which is *not* packaged in
the source distribution, more about that below), but does not mention
shindig/dist/shindig-features-1.1-BETA5-incubating.jar which *is*
packaged in the source distribution. However neither is really
problematic as isn't needed
anyway :)
Another example is some extra jackrabbit jars which are not mentioned
in either the LICENSE or RUNTIME_LICENSE file but are packaged with
the binary distributions.
And while commons-io and commons-email are mentioned in the LICENSE
file (but not packaged in the source distribution), they are not
mentioned in the RUNTIME_LICENSE file while they *are* packaged in the
binary distributions.
Yes, we had already done some work on getting rid of some of these
dependencies. We had already planned to refine this for the next
release, so it's on the radar already.
* RUNTIME_LICENSE file:
- The RUNTIME_LICENSE file is used/intended to cover the requirements
for (both) the binary distributions, wookie war/standalone.
However, as a single file it covers both distributions while the war
distribution does not package several artifacts (and thus licenses)
contained in the standalone distribution (Eclipsse, Jetty, Servlet/JSP
etc.)
From a legal POV, this is not "wrong", but AFAIK not ideal either.
To "solve" this however would require maintaining two separate
RUNTIME_LICENSE files which isn't ideal either. I have no strong
opinion on this but it might be considered to split these files up if
causing not too much of a burden to maintain.
we can look in to doing this
- More/most serious is the omission of the 3rd party license
attributions for many (all?) of the packaged Widgets in the
RUNTIME_LICENSE file. While these are distributed as "source", they
are (thereby) packaged in the binary distributions and as such
*should* be attributed in the RUNTIME_LICENSE file. However, as these
3rd party licenses are properly mentioned in the LICENSE file which
also is packaged in the binary distribution, legally everything
probably is still OK, even if somewhat confusing.
- My suggestion for future releases however is to consider packaging
only a is single LICENSE file within a release artifact/distribution
and thus maintain separate LICENSE files for source and binary
distributions (optionally even two for the latter). And the same holds
for the NOTICE file which currently also covers everything for both
source and binary distributions.
ok, I think your suggestion is valid.
Overall I think the legal LICENSE and NOTICE requirements however
still are met satisfactory enough for this first incubator release.
And as building the source and executing and testing both the war and
standalone worked fine for me, I'll vote +1 for the release right
after I send off this feedback.
thanks
With kind regards,
Ate
On 07/11/2011 11:44 AM, Paul Sharples wrote:
This is the first incubator release for Apache Wookie, with the
artifacts
being versioned as 0.9.0-incubating.
We are requesting a vote via wookie-dev for the release of the
artifacts found
here...
http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/
...as the final 0.9.0 release.
PGP release keys (signed using DDED352A):
http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/KEYS
Please take the time to verify the artifacts before casting your vote.
Vote will be open for 72 hours.
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
