Re: Test release artifacts - Legal requirements check [take2]
On Mar 18, 2008, at 2:29 PM, Reinhard Poetz wrote: I've created another series of non-Maven release artifacts. See http://people.apache.org/~reinhard/cocoon-staging/cocoon-servlet-service/ Jar file name to source/documentation directory name mapping is inconsistent: cocoon-servlet-service-components-1.0.0-RC1.jar -- cocoon- components/ cocoon-servlet-service-impl-1.0.0-RC1 -- impl/ and http://people.apache.org/~reinhard/cocoon-staging/getting-started/ This contains spring version 2.0.6, while cocoon-webapp in trunk is linked against 2.5.1. Does not seem correct. Do we really have to include each license into single LICENSE.txt file? I think I missed this development... BTW you have duplicate AL2 there - for ehcache. Seems redundant - especially since all other AL2 jars are not explicitly mentioned. Vadim
Re: Test release artifacts - Legal requirements check [take2]
Vadim Gritsenko wrote:
On Mar 18, 2008, at 2:29 PM, Reinhard Poetz wrote:
I've created another series of non-Maven release artifacts. See
http://people.apache.org/~reinhard/cocoon-staging/cocoon-servlet-service/
Jar file name to source/documentation directory name mapping is
inconsistent:
cocoon-servlet-service-components-1.0.0-RC1.jar -- cocoon-components/
cocoon-servlet-service-impl-1.0.0-RC1 -- impl/
thanks, I will fix this.
and
http://people.apache.org/~reinhard/cocoon-staging/getting-started/
This contains spring version 2.0.6, while cocoon-webapp in trunk is
linked against 2.5.1. Does not seem correct.
I was using the RC1 Maven archetypes to create the cocoon-webapp. For the
release I will use the new archetypes that will be used on the latest stuff.
Do we really have to include each license into single LICENSE.txt file?
I think I missed this development...
There were so many discussions on several Apache lists that I can't point you to
the thread :-/
Anyway, I was following the proposed structure as being suggested at
http://wiki.apache.org/legal/3party/notice
BTW you have duplicate AL2 there -
for ehcache. Seems redundant - especially since all other AL2 jars are
not explicitly mentioned.
IIRC it was slightly different, but I will check this.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Test release artifacts - Legal requirements check [take2]
Reinhard Poetz wrote: Vadim Gritsenko wrote: Do we really have to include each license into single LICENSE.txt file? I think I missed this development... There were so many discussions on several Apache lists that I can't point you to the thread :-/ Anyway, I was following the proposed structure as being suggested at http://wiki.apache.org/legal/3party/notice It has always been required, and it gets re-iterated in many license discussions. At both Cocoon and Forrest we have had trouble doing it, having so many supporting libraries. So we put the licenses beside each jar as text files with the same filename. At Forrest i have done a further compromise (until we move to Ivy which hope can help automate this license management). We put the license beside the jar as a text file, and mention the pathname in LICENSE.txt file. See more in a legal-discuss@ link, mentioned by me earlier in this thread. -David
Re: Test release artifacts - Legal requirements check [take2]
I've created another series of non-Maven release artifacts. See
http://people.apache.org/~reinhard/cocoon-staging/cocoon-servlet-service/
and
http://people.apache.org/~reinhard/cocoon-staging/getting-started/
What has changed:
o The archive name is the base directory of the ZIP.
o fix EOL, depending whether it is a ZIP or a tar.gz archive
o the getting-started package is new and contains third-party libraries
This time I want also draw your attention to the LICENSE.txt file of the
getting-started package. There you will find a list of all subcomponents that
have licenses that are different to the Apache License 2.0. This is the same
style as proposed in http://wiki.apache.org/legal/3party/notice.
Additionally, could others please check
o NOTICE.txt
o MD5 checksums
o PGP signatures
Thanks in advance!
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Test release artifacts - Legal requirements check
Reinhard Poetz wrote: David Crossley wrote: I saw that some committers have been using lowercase filenames e.g. notice.txt, so the release-builder needs to handle that. Is there some requirement that the file names of notice.txt and license.txt have to be either lower or upper case? Or is it up to us? See http://www.apache.org/dev/apply-license.html#license-file-name so we should name them NOTICE and LICENSE. We should use the same name throughout all modules. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Test release artifacts - Legal requirements check
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
David Crossley wrote:
I saw that some committers have been using lowercase filenames
e.g. notice.txt, so the release-builder needs to handle that.
Is there some requirement that the file names of notice.txt and
license.txt have to be either lower or upper case? Or is it up to us?
See http://www.apache.org/dev/apply-license.html#license-file-name
so we should name them NOTICE and LICENSE.
We should use the same name throughout all modules.
If I understood some discussion on [EMAIL PROTECTED] correctly, we would also have to
put NOTICE and LICENSE into the main directory of each sub-tree, that in our
case relates to each of our modules that are released separately.
We should do this clean-up work in one go as soon as there is a Maven 2 plugin
available, that picks up those files and puts them into META-INF.
WDOT?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Test release artifacts - Legal requirements check
Reinhard Poetz wrote: If I understood some discussion on [EMAIL PROTECTED] correctly, we would also have to put NOTICE and LICENSE into the main directory of each sub-tree, that in our case relates to each of our modules that are released separately. Yes. We should do this clean-up work in one go as soon as there is a Maven 2 plugin available, that picks up those files and puts them into META-INF. No need to wait for a plugin, we can just add this to our parent pom: build .. resources resource directorysrc/main/resources/directory /resource resource directory./directory targetPathMETA-INF/targetPath includes includeLICENSE*/include includeNOTICE*/include /includes /resource /resources /build Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Test release artifacts - Legal requirements check
Reinhard Poetz wrote: David Crossley wrote: I see that the META-INF/NOTICE.txt etc. files in each of cocoon-components and impl directory, would correspond with those from the sources. However where does top-level NOTICE.txt file come from? Should it be generated as a combination of the other two? The files in the sub-directories could potentially be different. The problem is that the release artifacts are sometimes collections of several more focused artifacts, at least in the Maven 2 world they get distributed in smaller units. I guess that the correct solution is that each of those collection release artifacts has to contain a hand-crafted NOTICE.txt file. The license should because of the ASF policy always be the same. I gather from listening to legal-discuss@ list that the licenses of supporting products need to be appended to the main LICENSE file. This has been added to the draft legal pages. http://wiki.apache.org/legal/3party/notice This is another wrinkle that we have not yet fully addressed at Forrest. A comment from Roy made me realise why that is needed. The LICENSE and NOTICE files are intended to be shown to the user in an About... style pop-up box. http://markmail.org/message/evydcvctn6c6of27 -David
Re: Test release artifacts - Legal requirements check
Carsten Ziegeler wrote: Reinhard Poetz wrote: David Crossley wrote: I saw that some committers have been using lowercase filenames e.g. notice.txt, so the release-builder needs to handle that. Is there some requirement that the file names of notice.txt and license.txt have to be either lower or upper case? Or is it up to us? The uppercase might just be tradition, but also what people expect to see. See http://www.apache.org/dev/apply-license.html#license-file-name so we should name them NOTICE and LICENSE. We should use the same name throughout all modules. Ah thanks. Also from that page: Can the LICENSE and NOTICE files be called LICENSE.txt and NOTICE.txt? This is permitted. However the preference is that the files be called LICENSE and NOTICE. The .txt filename extension helps with svn clients. I am going to add explicit handling to the ASF committers configuration so we can use NOTICE and LICENSE. http://www.apache.org/dev/version-control.html#https-svn-config Would all committers please update their configuration. -David
Re: Test release artifacts - Legal requirements check
David Crossley wrote:
Reinhard Poetz wrote:
Reinhard Poetz wrote:
This time I will
create the Maven 2 release artifacts and normal zip/tar release
artifacts for non-Maven users.
I created release artifacts for the Servlet-Service framework using the old
RC1 release form October last year and published them to
http://people.apache.org/~reinhard/cocoon-staging/ssf/.
Could others please have a look and check if those release artifacts meet
all legal requirements?
I see that the META-INF/NOTICE.txt etc. files in each
of cocoon-components and impl directory, would correspond
with those from the sources. However where does top-level
NOTICE.txt file come from? Should it be generated as a
combination of the other two? The files in the sub-directories
could potentially be different.
The problem is that the release artifacts are sometimes collections of several
more focused artifacts, at least in the Maven 2 world they get distributed in
smaller units.
I guess that the correct solution is that each of those collection release
artifacts has to contain a hand-crafted NOTICE.txt file. The license should
because of the ASF policy always be the same.
I expected a top-level cocoon-servlet-service directory
to be created. Should it?
good suggestions. I will fix this in the script.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Test release artifacts - Legal requirements check
David Crossley wrote:
I saw that some committers have been using lowercase filenames
e.g. notice.txt, so the release-builder needs to handle that.
Is there some requirement that the file names of notice.txt and license.txt have
to be either lower or upper case? Or is it up to us?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Test release artifacts - Legal requirements check
Reinhard Poetz wrote: Reinhard Poetz wrote: This time I will create the Maven 2 release artifacts and normal zip/tar release artifacts for non-Maven users. I created release artifacts for the Servlet-Service framework using the old RC1 release form October last year and published them to http://people.apache.org/~reinhard/cocoon-staging/ssf/. Could others please have a look and check if those release artifacts meet all legal requirements? I see that the META-INF/NOTICE.txt etc. files in each of cocoon-components and impl directory, would correspond with those from the sources. However where does top-level NOTICE.txt file come from? Should it be generated as a combination of the other two? The files in the sub-directories could potentially be different. I expected a top-level cocoon-servlet-service directory to be created. Should it? -David
Re: Test release artifacts - Legal requirements check
I saw that some committers have been using lowercase filenames e.g. notice.txt, so the release-builder needs to handle that. -David
Test release artifacts - Legal requirements check
Reinhard Poetz wrote:
This time I will
create the Maven 2 release artifacts and normal zip/tar release
artifacts for non-Maven users.
I created release artifacts for the Servlet-Service framework using the old RC1
release form October last year and published them to
http://people.apache.org/~reinhard/cocoon-staging/ssf/.
Could others please have a look and check if those release artifacts meet all
legal requirements?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
