Hi Justin,
thanks for that ... I was just staring to get frustrated with writing a
response for an inline commented email in Ponymail ... I signed up for the
list, that I can in future reply with a real mail-client.
But I guess I have nothing to add to what Justin wrote.
Thanks,
Chris
On 2022/10/19 15:48:33 Justin Mclean wrote:
> Hi,
>
> Perhaps I can help.
>
> > I'm reading that published release artifacts MUST be signed, and that
> > eligible voters in the voting stage MAY provide a signature.
>
> The release candidate needs to be signed so that someone reviewing the
> release can check that it contains what it should and will be the same as the
> released software.
>
> > FWIW, all of our release tags (internal or external) are signed tags,
> > and in any case I can surely provide a signature of the tarball(s) in
> > the next candidate proposal.
>
> A vote can't be on a GitHub tag (as that could change) it needs to be on an
> artefact as the contents of LICENSE and NOTICE depend on what is in that
> bundle.
>
> > I don't see any requirement for that in the policy, is this somehow a
> > requirement ?
>
> Yes it is a requirement to have a signed artefact. See
> https://www.apache.org/legal/release-policy.html#what-must-every-release-contain
> for details.
>
> > It is our policy to never clutter these files with license statements
>
> That may be the case but it is not ASF policy, please see
> https://www.apache.org/legal/src-headers.html. Note it mentions what files
> need ASF headers and the limited exceptions.
>
> > It is my understanding that such derivative works must be listed in the
> > NOTICE file, which `doc/bst2html.py` is certainly mentioned.
>
> This is not correct only limited things belong in a NOTICE file, all license
> information goes in the LICENSE file. Please see
> https://infra.apache.org/licensing-howto.html. Anything included that is MIT
> or BSD licensed needs to be mentioned in LICENSE not NOTICE.
>
> > The tarballs are extremely lightweight are are only included as data to
> > run tests against (they are essentially hello world programs, or just
> > tarballs which contain data that tests expect).
>
> An ASF release cannot include compiled source code, not even compile hello
> world programs. They could be download or compiled as part of the testing
> process, if they are used for tests. See
> https://www.apache.org/legal/release-policy.html#source-packages
>
> > Although I wonder how important this is given the lower case "should"
> > (as opposed to "MUST")...
>
> This is a requirement only non ASF projects can use the other header. See
> https://www.apache.org/legal/src-headers.html#headers
>
> > and perhaps this is acceptable if added to the NOTICE file in some way
>
> Only relocated copyright notices i.e. those where you have had permission
> form the copyright owner to remove should be added to the NOTICE file. See
> https://www.apache.org/legal/src-headers.html#header-existingcopyright
>
> > Right, these are all very easy to account for, but I could use some
> > guidance as to how precisely to update the NOTICE file for this.
>
> In general you would not update the NOTICE file, you would update the LICENSE
> file. If the 3rd party code is ALv2 and has a NOTICE file then some additions
> to the NOTICE file may be required. See
> https://infra.apache.org/licensing-howto.html#alv2-dep
>
> > It would strike me as very odd to modify the LICENSE file
>
> The LICNSE file needs to contain all of the license of bundles software in
> the release artefact. See
> https://infra.apache.org/licensing-howto.html#permissive-deps
>
> Kind Regards,
> Justin
>
