Hi Max,

1. We would both be fine with REUSE-Snippet-Begin, REUSE-SnippetBegin,
SPDX-Snippet-Begin or SPDX-SnippetBegin, and Snippet(-)End
respectively. Would SPDX want to introduce such a tag as an addition
to the existing Snippet information in the near future, or should
REUSE take the initiative here?

[G.O.] I personally would like to include this in the SPDX spec - we just need a volunteer to create an issue or (better yet) a pull request to update the Annex E Using SPDX license list short identifiers in source files (https://github.com/spdx/spdx-spec/blob/development/v2.2.1/chapters/using-SPDX-short-identifiers-in-source-files.md#annex-e-using-spdx-license-list-short-identifiers-in-source-files-informative). I would offer help on this, but I'm pretty busy with this year's Google Summer of Code and won't be able to help much for the next couple of months.

My preference would be SPDX-Snippet-Begin or SPDX-SnippetBegin.

2. For copyright, we would prefer SPDX-SnippetCopyrightText as an
equivalent to SPDX-FileCopyrightText

[G.O.] Agree

3. For license, we would prefer SPDX-License-Identifier. This is the tag
people use for declaring licensing of their files, but it could be
applicable for snippets as well, so in their enclosed context.

SPDX-LicenseInfoInSnippet might be the "official" way how to do it,
but to be brutally honest, I find this counter-intuitive and very
hard to memorise. I know that License-Identifier has become the
unloved child for a few people because of the lack of CamelCase and
clear context e.g. to files, but it's already out there, well-known,
and accepted. So I would suggest to use it for snippets as well.

[G.O] Is there a possible ambiguity of an SPDX-License-Identifier is associated with a file or a snippet?

Another question was raised regarding nesting of snippets, so the strange case
when a third-party code that I would like to use as a snippet would contain a
third-party snippet already. In this case, to also be compatible with the current
SPDX info on snippets, we would suggest to not allow nested snippets but
instead mandate that a snippet has to end in order for the next snippet to be
able to begin. Would you agree?

[G.O.] To be honest, I haven't considered the nesting of Snippets. Un-nested snippets are complex enough ;) In an SPDX document nesting is allowed since they are expressed with byte ranges and there is no rule to prevent nesting or even overlapping snippets. When marking snippets inline, it is a bit more challenging. I would definitely disallow overlapping snippets (e.g. Snippet A is lines 1 through 20 and Snippet B is lines 10 through 30). Nesting may be useful, however but it would significantly complicate the tooling. I don't feel strongly, but I tend to agree with the proposal that nesting not be allowed.

Looking forward to your replies and a constructive discussion!

Best,
Max



[^1]: To James' concerns: I would like to ignore the potential license
compliance problems with snippets carrying incompatible licenses for this
thread. Let's discuss first how devs can actually communicate that they've
used a third-party snippet and under which conditions, before we think about
how compliance might have to be handled in various (edge) cases.

--
Max Mehl - Programme Manager - Free Software Foundation Europe Contact
and information: https://fsfe.org/about/mehl | @mxmehl Become a
supporter of software freedom: https://fsfe.org/join